Active Directory planning and design

It's important to know how to design a plan to implement Active Directory. You should always
fully document your intended domains, forests, organizational units, sites, DNS infrastructure
and security strategies. This documentation becomes the plan for your new infrastructure when
you make the migration.

The basics of Active Directory planning

When you are performing an Active Directory migration, you basically have two options:
domain upgrading or domain restructuring. Domain upgrading is little more than upgrading each
existing Windows domain controller to a more current Windows domain controller. The upgrade
process starts by upgrading the PDCs in each domain, followed by the BDCs. Domain
restructuring involves creating an Active Directory network from scratch. In a restructure, you
will move systems and reroute connections to comply with a new infrastructure and layout
design. Often restructuring will result in fewer but larger domains.

So the question becomes, "Should you upgrade or restructure?"

Deciding which path to take, or which process to perform first, all depends on your specific
situation. But there are a few guidelines that can help you make the choice.

First, if your current domain structure is supporting your work tasks and doesn't seem to involve
an inordinate amount of extraneous administration, then upgrading may be preferable. However,
if the current domain structure is not adequate and is the primary motivation for the migration,
restructuring is likely the way to go. Secondly, if you must support the production environment
throughout the migration process, upgrading will retain overall network functionality and
therefore is preferable. But if you can afford to lose productivity during the migration,
restructuring is better. However, restructuring can be performed on a staggered schedule so no
significant loss of productivity is noticed.

Rememeber that while upgrading will cause the least downtime in terms of getting the domain
back into working order, it often is an insufficient migration. Many of the benefits of Windows
2000 and Windows 2003-based Active Directory domains cannot be fully realized without
reconfiguring the design of your network. Restructuring will require significant work to
implement, but it makes reaping the benefits of Active Directory easier to exploit for your
organization.

Developing an Active Directory migration strategy

When taking on an Active Directory migration project, like with all large projects, it's best to
have a strategy in place. It is key to create an Active Directory migration checklist, with steps
such as collecting diagrams and configuration of the current DNS and network structure
(bandwidth, remote locations, stability, etc.), determining the rights, objects and policies that will
need to be migrated, and creating fall back procedures in case of failure.
Another part of developing your migration strategy, is being aware of the key things you should
and should not do when performing an Active Directory migration.

For starters , it's important to make sure that your support staff is brought up to speed before you
begin migrating any production system. Depending on the size and structure of your
organization, you should have a help desk staff taking support calls. For a complex project like
Active Directory, it's a good idea to make a couple of network engineers available as well. Be
sure to train all members of the support staff involved in the process. Otherwise, you'll have IT
staff fielding questions that they don't know how to answer, and frustration will abound on all
sides.

You should also establish a test bed that mimics your production environment as closely as
possible in terms of hardware specifications and network speed. Leave nothing to chance in the
testing phase. Speaking of testing, be sure to test name resolution and replication before
deploying Active Directory in production. Unlike replication under NT4, Active Directory
replication is possibly the single most important item required for AD to function correctly.
Second only to file replication for a solid Active Directory implementation is name resolution.
Whether you are deploying WINS or DNS, ensure that all systems that need to can effectively
talk to one another.

Designing Active Directory simply

Active Directory is very flexible. So flexible that you can design an Active Directory forest that
is complex beyond imagination. Both Windows 2000 Server and Windows Server 2003 support
the Active Directory containers of forest, domain, site, and organizational unit (OU). With the
only real restriction of one forest per namespace, you can deploy as many domains, sites, and
OUs as you deem necessary.

However, don't be so fast to rush off and design an Active Directory network that includes a
domain for every department in your enterprise. The key to Active Directory design is simplicity.
As a general rule, you want to keep the number of domains to a minimum whenever possible. If
you really need department level divisions on your network that reflect the organization of your
business, then use OUs instead. OUs are much more flexible and easier overall to manage than
domains.

If you are migrating from a Windows NT 4.0 network to a Windows 2000 Server or Windows
Server 2003 Active Directory network, compare the number of domains from your existing
legacy system and compare that with the number of domains in your new AD-based design. If
your new Active Directory network has more domains than your legacy network, you may need
to re-think your design. Yes, it is possible to use as many domains as you wish, but you'll likely
regret that decision down the line. If you need lots of groupings and divisions, it is best to rely
upon OUs.

Active Directory domain design

When you are designing your Active Directory network, it is important to use the four divisions
(forests, domains, organizational units, and sites) to their maximum potential. This is especially
true for Active Directory domain design.

Domain divisions are most often used as logical containers. However, Microsoft recommends
that you employ domains also as physical containers. In other words, create domains whose
members are all geographically close rather than distant. This is an important design aspect since
the level of traffic within a domain is considerably higher than that between one domain and
another. In general, a domain with limited physical size is less likely to include expensive WAN
links or pay-per-bit connections. When slow links must be included in a network design, it is
often beneficial to create multiple domains connected by the slower connections.

Remember that it is not necessary to create separate domains to divide administrative privileges.
Within Active Directory, it is possible to delegate administrative privileges based on
organizational units.

Designing groups and organizational units

With the proper preparation and advance knowledge of their use, a functional organizational unit
(OU) and group design can do wonders to simplify your Active Directory environment. It can
also go a long way toward helping you gain control and reduce overhead.

Often, OUs are indiscriminately used without reason, and group structure is ineffectual and
confusing. Without some form of logical organization of users within your network environment,
chaos reigns and administration grinds to a halt. Some best practices when designing OUs
include:

 Keep the OU structure as simple as possible

 Do not nest OUs more than 10 layers deep
 Keep the number of OUs to a minimum
 Apply Group Policy to groups through Group Policy filtering
 Don't utilize local groups for permissions in a domain environment
 Use domain local groups to control access to resources, and use global groups to
organize similar groups of users.

You also have the option of hiding your OUs. The primary purpose of hidden OUs is to prevent
an administrator from one OU from being able to view, access, or alter another OU. Hidden OUs
are often used in environments that offer network application services to internal departments or
external customers. It allows for a solid separation of duties without requiring separate domains
or forests.

Design rules for Active Directory sites

Sites are an extremely useful design element for Active Directory domains. Sites are limited to
any computer object within a forest. Thus, they can cross domains and organizational units
(OUs) with indifference. An object's membership in a domain or OU does not exclude
simultaneous membership in a site. Sites are used to impose physical network divisions for the
purpose of traffic flow.

By using sites, you can control and reduce the amount of traffic that flows over your slower
WAN links. This can result in more efficient traffic flow for productivity tasks. It can also serve
to keep WAN link costs down on the pay-by-the-bit services.

In general, when designing sites, keep the following in mind:

 Sites should generally reflect the physical or geographic topology of the network.
 Each site should contain at least one local DC.
 Sites should not contain slow links of any type.
 Remote-access clients do not need a dedicated site.
 Sites should be used whenever control over replication traffic is needed or
desired.
 Sites can be added, removed, changed, and moved easily without affecting any
other AD container configuration.