Chapter 8. Designing the Namespace
The
basic emphasis of this chapter is on reducing the number of domains
that you require for Active Directory while gaining administrative
control over sections of the namespace using Organizational Units.
This chapter aims to help you create a domain namespace design. That
includes all the domains you will need, the forest and domain-tree
hierarchies, and the contents of those domains in terms of
Organizational Units and even groups.
There are a number of restrictions that you have to be aware of when
beginning your Active Directory design. We will
introduce you to them in context as we go along, but here are some
important ones:
Too many Group Policy Objects (GPOs) means a long
logon time as the group policies are applied to sites, domains, and
Organizational Units. This obviously has a bearing on your
Organizational Unit structure, as a 10-deep Organizational Unit tree
with GPOs applying at each branch will incur more GPO processing than
a 5-deep Organizational Unit tree with GPOs at each branch. Under Windows 2000, you cannot rename a domain once it has been
created. Fortunately, with Windows Server 2003, this limitation
has been removed, although the rename process is tedious. You can
even rename forest root domains once you've reached
the Windows Server 2003 forest functional level. You can never remove the
forest root domain without destroying
the whole forest in the process. The forest root domain is the
cornerstone of your forest. The Schema Admins and Enterprise Admins
groups exist in the forest root domain only. So if you are migrating
from a previous version of NT, be cognizant of the fact that the
administrators of the first domain you migrate can have control over
these groups and over Active Directory. Lack of a regional catalog is
problematic. Imagine that you have 20 printers in your office in
Sweden and 12 printers in your office in Brazil. The users in Sweden
will never need to print to the printers in Brazil, and the users in
Brazil will never need to print to the printers in Sweden. However,
by default, details of all printers are published in the GC. Thus,
whenever changes are made to printers in Sweden, all the changes get
replicated to the GCs on the Brazil servers because the GC replicates
all of its data everywhere. You have three options. You can decide
not to replicate any printer data and force printer seraches to hit
Active Directory each time, you can replicate all printer data
everywhere, or you can create an application partition to host
printer data and replicate it to designated domain controllers. Multiple domains cannot be hosted on a
single DC. Imagine 3 domains off a root located in the United States,
which correspond to 3 business units. Now imagine a small office of
15 people in Eastern Europe or Latin America with a slow link to the
main site. The 15 users are made up of 3 sets of 5; each set of 5
users uses one of the 3 business units/domains. If you as an
administrator decide that the slow link is too slow and you would
like to put in a DC for the 3 domains at the local server and to ease
replication, the small office will have to install 3 DCs.
|
