Fri 15 Jun 2007
I don’t have much experience with RODCs yet. However, I already see some of the downsides of this new kind of domain controller:
- If you add RODCs to your network, you certainly increase the complexity. RODCs simply work differently than DCs, which means that new kind of problems might come up.
- Administrators need to invest time to learn how to manage RODCs.
- Some third party products will not work together with RODCs.
- An RODC usually needs a writeable domain controller to work properly. For example, users can’t change passwords, computers can’t join the domain, accounts whose passwords haven’t been cached can’t logon, and Group Policy doesn’t work properly if no writable RODC is available. This means that an RODC doesn’t provide the same failure safety like a writeable DC.
Don’t underestimate the first two points. At first, I thought, it can’t be too difficult installing an RODC. After all, it is just a DC with reduced functionality, i.e. with only unidirectional replication. However, it took me more time than expected to set up a test environment.
My RODC had two network cards, one was in the same sub network as the writeable DC, and the other network card was connected to the same sub network as my clients. Most things worked fine. However, I wasn’t able to authenticate against the RODC if the writeable DC was offline. In theory, this should work if the user’s password is cached on the RODC. Even though I could see that the password was cached, I always got this error message: The trust relationship between this workstation and the primary domain failed. However, if the writeable DC was online, I had no problems logging on to the RODC.
Maybe my configuration was not correct or maybe there was a bug involved. I didn’t try too long to solve this problem, since Windows Server 2008 is still beta. But this example shows how new kind of problems can arise. With two writable DCs I wouldn’t have to invest extra time. Time is money. Maybe it makes more sense to invest this money in a better physical protection of the servers in your branch offices.
There are certainly environments where it makes sense to work with RODCs. Big companies with Active Directory specialists probably won’t be afraid of the increased complexity. However, since bandwidth gets cheaper almost every day, it is probably only a matter of time until domain controllers in branch offices will not be necessary anymore. So maybe it is a bit late for this new technology.
But wait! Is this really new technology? Do you remember the BDCs (backup domain controllers) in Windows NT? When Windows 2000 came out most admins were quite happy that they didn’t need these DCs with limited capabilities anymore.
Articles in this series:- Windows Server 2008: Read-Only Domain Controller (RODC)
- Windows Server 2008: How to install and configure an RODC
- Windows Server 2008: the disadvantages of RODCs


Newsletter: 


I believe your problem was that you used a multi homed domain controller.
See KB272294.
One of the biggest advantages of the RODC is that you can give administrator access to it, without giving any domain specific privileges.
Thanks for the tip! I think your guess is right. It might be a problem related to multihomed DCs. I tried this feature with an RODC having just one network card and it worked there.
The reason you could not logon when the writable DC is down is probably because this DC is also the GC. You could give the RODC the role of GC. In that case you should be able to logon to the RODC with the writable DC offline.