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