If you would like to read the other parts in this article series please go to:
Introduction
In Windows Server 2008, Microsoft has brought back a feature that we have not seen since Windows NT; Read Only Domain Controllers. In this article, I will explain why this is, and the advantages of using Read Only Domain Controllers.
I hardly ever watch television, but when I sat down to write this article, I couldn’t help but remember an episode of 30 Rock that I saw a while back. In that episode, the show’s main character, Liz Lemon, was dating a guy who was the only person in New York City who was still selling pagers. When Liz told him that nobody uses pagers anymore because everybody uses cell phones, he insisted that technology was cyclical, and that the pager was going to make a big comeback.
Although the remark was intended to be comical, I think that technology is more cyclical than most people realize. For example, I do not expect to ever see the pager making a comeback, but is cell phone texting really all that different from the text based pagers that we all had fifteen years ago?
Perhaps a better example of the cyclical nature of some technology is a new type of domain controller found in Windows Server 2008 called a Read Only Domain Controller, or RODC. The reason why I say that this is an example of cyclical technology is because in a way, RODCs are a left over from over a decade ago.
Windows NT was Microsoft’s first Windows Server operating system. Like modern Windows Server operating systems, Windows NT fully supported the use of domains. What was different though, was that only one domain controller within each domain was writable. This domain controller, known as the Primary Domain Controller or PDC, was the only domain controller that an administrator could write information to. The primary domain controller would then propagate updates to the other domain controllers within the domain. These other domain controllers were known as backup domain controllers, and were read only in the sense that they could only be updated by the primary domain controller.
Although this domain model worked, it had its downside. Most notably, a problem with the primary domain controller could cripple the entire domain. As you probably know, Microsoft introduced some major changes to the domain model when they released Windows 2000 Server. Windows 2000 Server introduced two new technologies for domain controllers, both of which are still in use today; the Active Directory, and the multi master domain model.
Although there is still a PDC emulator role and a few other specialized roles, for the most part every domain controller in a multi master domain model is writable. That means that an administrator can apply an update to any domain controller, and the update will eventually be propagated to all of the other domain controllers in the domain.
The multi master domain model was retained in Windows Server 2003, and is still used in Windows Server 2008. However, Windows Server 2008 also allows you to create Read Only Domain Controllers. RODCs are domain controllers on which the Active Directory database cannot be updated directly by administrators. The only way of updating these domain controllers is to apply a change to a writable domain controller, and then allow the change to propagate to a RODC. Sound familiar?
As you can see, RODCs are nothing short of a relic from the days of Windows NT. In this case technology truly has become cyclical! Of course Microsoft would not have brought back RODCs if there were not some advantage to doing so.
Before I begin explaining why Microsoft brought back RODCs, let me first clarify that the use of RODCs is completely optional. If you want every domain controller in your entire forest to be writable, then you can certainly do that.
The other thing that I want to quickly mention is that even though RODCs are very similar to the Backup Domain Controllers (BDCs) that were used in the days of Windows NT, they have evolved a bit. There are a couple of things that are unique about RODCs, and I will point those things out as we go along.
OK, so why did Microsoft bring back RODCs? It has to do with the challenges of supporting branch offices. Branch offices have traditionally been tough to support because of their isolation and because of the nature of the connection between the corporate headquarters and the branch office.
Traditionally, there have been several different options for managing branch offices, but each has its own set of advantages and disadvantages. One of the more common ways of dealing with branch offices is to keep all of the servers in the main office, and provide the branch office users connectivity to those servers through a WAN link.
Of course the most obvious disadvantage to using this method is that if the WAN link goes down then the users who are in the branch office are unable to do much of anything, because they are completely cut off from all of the server resources. Even if the WAN link is functional though, productivity may suffer because the WAN links are often slow and easily congested.
Another common option for dealing with branch offices is to place at least one domain controller in the branch office. Often times, this domain controller will also act as a DNS server and as a global catalog server. That way if the WAN link goes down, the users in the branch office will at least be able to log into the network. Depending on the nature of the branch office user’s jobs, there may also be other servers located at the branch office.
While this solution usually works out pretty well, there are some disadvantages to using it. The primary disadvantage is the cost. Placing servers in branch offices requires the organization to shell out money for server hardware and for any necessary software licenses. There are also support costs to consider. An organization needs to determine whether they want to hire full time IT staff to support the branch office, or if they can deal with the amount of time that it takes the IT staff to travel from the main office to the branch office when onsite support is needed.
Another issue with keeping servers at the branch office is security. It has been my experience that servers located outside of the datacenter are basically unsupervised. They are often just locked in a closet at the branch office, and employees at the office who have a key to the closet have to be trusted not to mess with the servers.
As I mentioned earlier, WAN connections can often be slow and unreliable. Herein lies another problem with placing servers in a branch office. Domain controller replication traffic can congest the WAN link.
This is where RODCs come into play. RODCs are just like any other domain controllers, except that the Active Directory database is not directly writable. Placing an RODC at a branch office does not get rid of Active Directory replication traffic, but it does reduce the workload of the bridgehead servers because only inbound replication traffic is allowed.
RODCs may also improve security, because people at the branch office cannot make any changes to the Active Directory database. Furthermore, no account information is replicated to RODCs. This means that if someone were to steal a RODC, they would not be able to use the information that they get off of it as a means for hacking user accounts. The fact that user account information is not written to RODCs also reduces the amount of replication traffic that flows across the WAN link, but it does mean that with some exceptions user authentication still depends on the WAN link being available.
Conclusion
As you can see, Read Only Domain Controllers do have their place. In my next article in this series, I will begin discussing the planning and deployment process for Read Only Domain Controllers.
If you would like to read the other parts in this article series please go to:
