Chapter 8. Designing Windows Server 2003 Domains
THE LAST FEW CHAPTERS HAVE EXAMINED THE critical components of DNS and Active Directory. We now know how a directory service improves operations compared to classic NT. Now it's time to get out the proverbial blank sheet of paper and start laying out an architectural plan.
Active Directory is a complex piece of technology. Many of the decisions you make regarding directory design have wide-ranging implications. Generally, the design should start with evaluating the technical merits of each available feature with an eye towards improving your current operations. If you do your homework and account for most of the variables, you'll end up with a design that is technologically sound. Good designs don't necessarily translate into deployable designs, though, generally because of issues at the eighth layer of the OSI model—the political layer.
This chapter addresses both the technical and the political issues involved in Active Directory design. I'll identify compromises that many administrators have had to make in their Active Directory designs and the best way to avoid problems caused by those compromises. I'll also outline the best practices that have emerged over the last couple of years as Active Directory has matured.
You have three major concerns when laying out the general structure of an Active Directory forest:
Number and name of domains
Upper Organizational Unit structure
Local Organizational Unit structure
The end result of this initial design assessment is a sketch that defines how your domain or domains should look, the DNS zones that will support the domain namespace, and the layout of the management organization defined by Organizational Units.
When that's done, you can define the location of your DNS servers, domain controllers, Global Catalog servers, and Flexible Single Master Operations servers (covered in detail later in this chapter).