...Internet to resolve computer names to IP addresses. DNS names are hierarchical, like the directory structure.
In planning a namespace, you should consider how your company is structured, and also how it is likely to be structured in the future as it grows. A small company may very well start with a single domain, but as the organisation grows, you may find it useful to divide the network into multiple domains because a domain forms a security and administrative barrier.
The first domain is often named for the company. For example, if your company is named Acme Inc., your first domain might be Acme.com. You might then create "child" domains under it based on departmental divisions or geographic locations. The name of the child domain is prefaced to the name of the parent domain, so you end up with child domains called finance.acme.com and sales.acme.com representing different departments (or perhaps altanta.acme.com and dallas.acme.com representing branch offices).
The important part is to create a namespace that logically divides the network and makes each part easily identifiable. The first domain you create becomes the "root" of the domain tree (which consists of all the domains with a common namespace).
Growing the directory structure
You can easily add and delete domains if the structure of your organisation undergoes changes. If your company merges with another, you can create a separate domain tree by creating a new root domain with a different namespace (for example, Zeta.com). These two domain trees can be part of the same Active Directory forest, which means there will be a trust relationship between the root domains of each tree. Because Active Directory trusts are transitive, users in one domain tree will be able to access resources in the other tree (as long as their user accounts have been assigned the appropriate permissions to do so).
It is also possible, as your organisation grows even larger, to create a multiple-forest environment. This would be necessary if you have separate autonomous divisions that don't want to share the same schema (which defines directory objects and attributes) and the same Global Catalogue (which contains a searchable representation of all objects in the directory).
Active Directory domains can scale to hold millions of objects. Of course, a domain with a large number of objects can become unwieldy, but you can further divide and organise groups of objects within a domain by creating organisational units. You can even nest units inside other units, and you can apply policies and delegate administrative responsibilities at the unit level for very granular control. Policies and user rights are inherited by nested units from the units in which they reside.
An important part of Active Directory's scalability lies in the ability to replicate directory information between domain controllers at different sites across wide area networking links. This keeps the directory information up to date across the entire network and makes it available to all users, no matter where they are physically located.
Thus, if planned properly, your Active Directory structure should be able to grow with you as your company expands from a small business to a multi-site enterprise. For more detailed information about planning and deploying Active Directory, see Microsoft's Active Directory Collection on the TechNet web site.







Talkback
What plannet does Deb come from ? How can you possibly call any directory service scalable that requires an entire copy of the object database on which ever servers you choose to keep a copy ?????
Yes, that's very scalable - not.