Only one DC can't list another DC in a system of 3 DCs.
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.
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.
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?
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?
ASKER
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... ??
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... ??
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 ......
Point of DCs if one fails, you build a new one ......
ASKER
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?
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?
ASKER
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....
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....
ASKER
Potentially the one having issue is the first DC setup in the testbed?Why would that be if they are all equal?
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.
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.
ASKER
So, did you mean the first DC "powered up" in the testbed as compared to the first DC "set up" in the testbed?
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...
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...
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
ASKER
Thanks!
ASKER