Only one DC can't list another DC in a system of 3 DCs.

Fred Marshall
Fred Marshall used Ask the Experts™
on
I have 3 domain controllers on Windows Server 2019 Standard.  I just set them up in a testbed environment that replicates the real world environment with IP addresses, inter-subnet router, etc.
They are each on one of 3 subnets that are routed together.
All DCs can ping the other 2.
All DCs can open fileshares on the other 2.
However, ONE DC cannot show ONE other DC in Server Manager-All Servers.  It only shows itself and one other.
Trying to add the 3rd DC results in: No Items Found.
The other 2 DCs are showing all 3.  So, the missing DC in one case seems to be an OK DC in the other case???

I've checked everything I can think to check and haven't been able to solve this.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Author

Commented:
I find that one of the 3 is on a "Private" network even though the System properties show it joined to the domain.  This is the same as the "missing" one.
Distinguished Expert 2017

Commented:
Which dc does it point to for DNS?
It happens when it boots and queries that it can not detect the network as being in the domain.
If not mistaken, one cause is if the localhost, 127.0.0.1 is used as a name server.
Check the two that work versus the one that has this issue.
Potentially the one having issue is the first DC setup in the testbed?

Author

Commented:
Thanks for the replies!  This is greatly concerning as it morphed into a much more harmful situation.
The DCs are numbered 1,2,3 in their names.
DC2 was the first to be brought up, then 1 and then 3.
2 and 3 were on Private networks... so the firewall doesn't work as intended for a domain.
After a couple of reboots, 2 shows up on a domain network.
Then, suddenly, could not log into 3.  "The security database on the server does not have a computer account for this workstation trust relationship".  Horrifying.
On top of that, DC3 showed up twice on the other DCs as a DC: one with the correct name and one with what looks like a computer-generated name that starts with the correct name but is extended.

I got rid of both instances of DC3 and then restored it to an earlier time before it was promoted to DC status.  That redo is in process now.

In the end, the plan is to have each DC NIC DNS point to another DC as primary, another DC as secondary, its own network IP address 3rd and 127.0.0.1 4th.

This raises what may be a related question:
When one is bringing up an *additional* DC, how should the NIC DNS be set during the promotion process?  
From what you say, it might really matter!
Similarly, once things are running, are there "rules" for booting DCs?
Should they be rebooted separately in time?
Can they be rebooted all together in time?  e.g. when there's a power failure... ??
11/26 Forrester Webinar: Savings for Enterprise

How can your organization benefit from savings just by replacing your legacy backup solutions with Acronis' #CyberProtection? Join Forrester's Joe Branca and Ryan Davis from Acronis live as they explain how you can too.

Distinguished Expert 2017

Commented:
You should never restore a DC when there are others as it could lead to RID errors/conflicts.

Point of DCs if one fails, you build a new one ......

Author

Commented:
arnold:  that's good to know.  In this case, the computer restore was to a pre-DC configuration.
After that, may I presume that it's OK/necessary to bring up a new DC when it *is* connected to the others?
And, what is the recommended NIC DNS configuration during that process?

Author

Commented:
I believe there is progress.
Now all the computers are on a domain network type - as it should be.
The problem I'm seeing now is that All Servers list on DC1 and DC2 had both shown DC3 as "Kerberos target resolution error" under Manageability.
Now only DC1 is showing that error and DC2 is normal.
DC3 list of All Servers is normal.

After a time, this problem went away on its own....

Author

Commented:
Potentially the one having issue is the first DC setup in the testbed?
Why would that be if they are all equal?
Distinguished Expert 2017

Commented:
The DC determines its network affiliation on boot, have seen the DNS did not setup when the network came up, so initialy it defaulted to a public network, you could change it to a private.

point deals with how the OS determines whether it is part of a domain or on a public/private network......

the newer ones with the connection test option....... vary.

Author

Commented:
So, did you mean the first DC "powered up" in the testbed as compared to the first DC "set up" in the testbed?
Distinguished Expert 2017

Commented:
Either way you read it at this time it sounds "right"

A system is booted, the network interace is coming up, the dns query is run to determine "where it is" if it is a known network, it will be marked as you have. if the query gets a response indicating that it is on a domain, it will be reflected as a domain. in the absence of a viable DNS service against whom the query can be run the range of settings can go from public, that can then be only changed to private which seemingly is the situation in your case.
The system came up it did not receive a response to the DNS query and tagged the network as you have before pricate/work/home....

The network "classification" is more prevalent I think since server 2012...

Author

Commented:
So, what happens when there's a power failure?  Assume all the DCs go down. DC1, DC2, DC3.
Now, the power comes back on site-by-site.
The first site's DC1 comes on.

DC1 NIC DNS is configured:
DC2 IP
DC3 IP
DC1 IP
127.0.0.1

DC1 has forwarders configured.

Now, what happens when the Site 1 power comes back on re: "DNS Query"?
(Just assume that all other Site 1 devices and internet services are already operational when DC1 comes up).

Similarly, what happens if all 3 DCs come up "at the same time"?

In both cases, would we expect the DNS query to determine that the DC is on a domain?
This seems fundamental and I feel like I must be missing something.
Distinguished Expert 2017
Commented:
what I've seen intermittently, the first DC that comes up, depending on its settings it will not recognized that it is on a domain. the others will commonly will be able to query and come up.
in my case, the first time, the DC came up in this fashion it was in a public .....
once using DISm updated/changed the network type to private. The firewall rules for domain and private are commonly similar and does not impact functionality as when it is in a public zone...

Usually, you should not use 127.0.0.1 as there seem to be different/awkward behavior.
dc1 points to dc2 and dc3 for name resolution
dc2 points to dc1 and dc3 for name resolution
dc3 points to dc1 and dc2 ..

The situation you ran into and I encounter on  a few occassions might have been an aboration where everything align in such a way ....

Author

Commented:
For us, firewall rules do impact functionality for file and printer sharing.  Most Private firewall rules Remote Address are only for the local subnet and, if Private, the scope has to be expanded to cover all of the subnets involved - as we have 3 subnets.  (I believe this is only for the "fileserver" device Windows firewall).  

This isn't the case for a domain where all the File and Printer sharing rules are for ALL Remote Addresses .. except LLMNR-UDP-In which is only for the Local Subnet and, without knowing better, would have to have its scope expanded to cover the subnets in use.

Author

Commented:
Thanks!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial