Domain Controller Test Restore Issue

[tom11011]

Hi Group,

I was running a test of our replicated environment and ran into some issues.

Essentially, what I have done is brought up our 2 replicated domain controllers in an isolated environment and a third replicated server to test.

What I noticed on the third server is the login seems to be using cached credentials to log in. I am unable to access the UNC path of the domain controllers without an NTLM popup window appearing. For example, I type \\DC1 and I cannot see sysvol or anything, only an NTLM popup asking for credentials.

I went on the Domain Controllers themselves (DC1 and DC2) and they cannot see any of their shares such as sysvol etc. either. DC1 and DC2 also have DNS installed which appears to be working as I can succussfully nslookup any host in the domain.

I thought I would try another server to check, but on this server I am getting "There are currently no login servers available to service the logon request" when attempting to RDP in.

I'm not sure where to start on this as this behavior only exists in the replicated environment.

[tom11011]

Looking at the network properties-

One the source server the interface is on the "Domain Network". On the replicated server the interface is on the "Private Network"?

Windows 2012 if that matters with vmxnet3 in vmware.

[Egor Yakovlev]

Hi Tom.
- Check if DNS Suffix is set correctly on servers's NIC->ipv4->Advanced->DNS tab(if not, adapter disable\enable required after change). That might help with network type being set incorrectly.
- Which DC holds FSMO roles?
- Was an application-aware image processing set for replication or respectful checkbox wasn't ticked under Replication Job settings -> Guest Processing tab? In first case your DCs shall be in "vanilla" state like a reboot happened, however in 2nd case we trigger non-authoritative mode on Domain Controllers(as Microsoft recommends), so there is no authoritative DC in your test zone, which would explain all authentication issues.
/Cheers!

[foggy]

Hi Tom, how do you perform a restore? Are you using SureBackup or just manually start DC's in an isolated environment? Please also review this KB, might be helpful. Thanks!

[tom11011]

Support case 04184361

Egor, there are no dns suffix's set, is that required since in a domain? I am booting up both DCs so does it matter which one? Application aware is set on the replication job for all these servers.

Foggy, we just manually start the replicas in an isolated environment.

[Egor Yakovlev]

- DNS Suffix is not mandatory, but good to have, because it is used to determine if you are on domain network in case of Network Location Awareness failure. You can also use [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\GUID\Category] parameter set to "2" in order to force all connections via this interface being treated as "Domain Network" by default no matter where you plug it in.
- Check KB2119 in more detail, as if application-aware replication was done, both DCs will launch in non-authoritative mode. You need to raise one with authoritative SYSVOL restore.
/Thanks!

[tom11011]

No way to automate this? I don't seem to recall having this problem in the past. Seems like it should just work.

[foggy]

This is automated in SureBackup/SureReplica, as mentioned in the KB.

[tom11011]

Foggy, in that kb, under
Restoring entire AD infrastructure (AKA “all DC’s are lost”)

It says "Note: During the restore procedure, make sure the restored DC’s DNS records point to available DNS servers (e.g. to itself)."

If there are two domain controllers and they both run DNS, should each one not point to the other for primary dns?

[foggy]

Yes, this is an option.

[tom11011]

Guys, thanks for your help, I set the registry entry and restarted the service and that fixed it. Since in a real DR situation we would be starting replicas without SureReplica, it seems we will have to incorporate this requirement into our documentation.

One thing, the document says to restart the NTFRS service. It took me a little google to find out that this is actually the "File Replication" service. ntfrs is the execuable, ie ntfrs.exe

Thanks again.

[Andreas Neufert]

I think it is best practices to add the local DNS server as first one and then add additional servers. Suggest to ad the seond one there.

[tom11011]

Local server?

[Andreas Neufert]

When you configure a windows server for DNS resolution, it will automatically configure the DNS entry in the network settings of that server for local name resolution. If I remember right 127.0.0.1 is added. This should be used that way for SureBackup as well. Second and higher DNS Server entries of these server should point to other AD/DNS Servers in the network.

[tom11011]

Well there is only 2 and they point to each other, are you saying this should be done differently?

[Andreas Neufert]

Yes, 2 entries. One pointing to the local DNS Server (usually configured by default if you enable DNS Server => 127.0.0.1) and then add the counterpart as second one.
At least you have to add the local one as secondary to avoid issues when you boot up one of the servers without the other one reachable.

[YouGotServered]

@tom11011 there's an ongoing feature request to add the option to automate this in actual restores, as happens with SureBackup. I would suggest posting on this forum for visibility into the feature request I'm with you - it can be confusing at first, that's why I think some automation would be good, as long as it is an opt-in check box, not opt-out.

topic41952.html

[tom11011]

Thanks for that, it is a little confusing as I just expected it to work. We run an annual full failover test and I do not recall having this issue in the past. Its something that has to be added to our internal documentation, if not we would fail to meet our SLA.

[Egor Yakovlev]

In your case it might be worth checking Veeam Availability Orchestrator to automate DR\Failover processes, automated switchover actions, automate periodic testing and report on SLA goals achievements.
/Cheers!