We have two RODCs in our DMZ serving a number of client servers. The client machines exist in three different subnets in different private address ranges (modified for posting online, but the pattern is consistent): 10.1.20.0/24 10.1.21.0/24 192.168.30.0/24 The RODCs are at 10.1.21.100 and 10.1.21.101. We have two writable DCs as well, in a separate internal 192.168.20.0/24 network, but we have our firewalls configured to prevent the DMZ machines from accessing our internal network. All of the client servers are in the Allowed RODC Password Replication group and have their machine credentials cached correctly. Using AD Sites, we have all three of the DMZ networks configured to use the RODCs as their logon servers. What we've found is that the servers in the 10.1.20.x and 10.1.21.x networks are able to maintain their secure domain connections (i.e. via Netlogon) with no errors; if one of them is rebooted, it will authenticate against one of the RODCs as expected. The machines in the 192.168.30.x network, however, are not able to do so; if rebooted, they will return the following error: This computer was not able to set up a secure session with a domain controller in domain DOMAIN due to the following: There are currently no logon servers available to service the logon request. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator. (DOMAIN is, obviously, not the real name of our domain - changing it for posting online.) If, however, a domain admin manually runs a netdom reset and specifies the hostname of one of the RODCs with the /s: argument, the machine will establish a domain connection. To sum up: the machines in the 192.168.30.x network seem to be "ignoring" the RODCs when running Netlogon, while the clients in the other two DMZ networks, which are "closer" to them in terms of network topography, have no such problem. Just to repeat, a manual reset with Netdom works, so we know that there are no DNS/Firewall/Network issues preventing communication between the clients and the RODCs. So the question is: why is this happening, and what can we change to force the recalcitrant clients to authenticate against the RODCs when they reboot? I'd appreciate any advice anyone might have! TIA.

For your machines in the 192.168.30.0 network, what are they using for DNS? Sounds like whatever DNS they are using doesn't have SRV records for your RODCs. I know you said there are "no DNS issues", but I think that may be premature or maybe only partially correct. Of course I could be completely wrong, but an open mind may get you going the right way. Also, do you have any sites defined? Are the 192.168.30.0 machines in a different site than the RODCs?C Shane Cribbs http://www.georgiatechnologies.com

Hi Shane, The DMZ servers use the RODCs themselves for DNS. The SRV records exist in our domain DNS setup under Forward Lookup Zones -> _msdcs.domain.local -> dc -> _sites -> DMZ -> _tcp. There are kerberos and ldap entries for the RODCs at that location. It's true, however, that there are no SRV records for the RODCs at the "default" domain level of Forward Lookup Zones -> _msds.domain.local -> dc -> _tcp. There, only our writable DCs that are not accessible to the DMZ servers show up. That "shouldn't" matter, however, as our sites configuration "should" be pointing the DMZ servers to the correct place (?) In terms of our Sites setup, there are two sites defined: DMZ and Internal. The three networks I mentioned in my initial post are in the DMZ, pointing at the RODCs, and only our internal network, pointing at our writable DCs, is in the internal Site. For me, the question that arises is this: should there be SRV records for the RODCs in DNS at Forward Lookup Zones -> _msdcs.sitka.local -> dc -> _tcp? Isn't it "good enough" to have those records in the correct place under the Site? Thanks for your thoughts and suggestions on this.

Assuming that 10.x.x.x is the DMZ and 192.168.x.x is the Internal (maybe I'm wrong?) then: The Internal servers won't ask for the SRV records from the DMZ site. And if there aren't "generic" Forward Lookup Zones -> _msdcs.sitka.local -> dc -> _tcp records, the internal servers will never find the RODCs. This all assumes the firewall is configured correctly, which sounds like it is because a manual authentication works. C Shane Cribbs http://www.georgiatechnologies.com

Our network topography is relatively complex (we just have a lot of networks/vlans, for various reasons), so just to clarify: 192.168.30.x, 10.1.20.x, and 10.1.21.x are all DMZ networks and are part of the DMZ Site, pointing at the RODCs. They are prevented via firewalls from direct connections to our internal network, which is 192.168.20.x (note: internal = .20, while one of our three DMZ networks is .30.) I did a lot of troubleshooting on this yesterday, and here's what I think is happening: When a machine in the 10.1.20.x or 192.168.30.x DMZ networks reboots, it loses its site membership somehow. It comes back online and sends out a generic DNS query for a domain controller via broadcast (because, again, it doesn't know which site it's in so it doesn't know about the RODCs.) The same thing happens for the DMZ network 10.1.21.x, but the difference is that the RODCs themselves are in that network! Thus, even though a DNS lookup would fail, the simple broadcast reaches the RODCs, who respond, and the 10.1.21.x machines are then able to authenticate. I went ahead and followed the directions in http://support.microsoft.com/kb/977510 to have the RODCs register generic SRV records so that machines in any network can find out about the RODCs via generic DNS queries. What I still don't understand, though, is why site membership does not persist a reboot. You do not have to, for instance, re-join a machine to a domain every time you reboot it; its domain membership is cached, even if it needs to re-establish its secure connection to a DC after a reboot. Why on earth would site membership not be cached as well?