Lesson 1: Planning Active Directory Implementation - MCSE Training Kit, Microsoft Windows 2000 Active Directory Services [Electronic resources] نسخه متنی

Lesson 1: Planning Active Directory Implementation

Active Directory provides methods for designing a directory structure that meet the needs of your
organization. Before implementing Active Directory you must examine your organization's business structure
and operations and plan the
domain structure, domain namespace, OU structure, and site structure needed
by your organization. With the flexibility of Active Directory, you can create the network
structure that best fits your company's needs. This lesson walks you through the steps of planning an
Active Directory implementation.

After this lesson, you will be able to

Plan a domain structure

Plan a domain namespace

Plan an OU structure

Plan a site structure

Estimated lesson time: 35 minutes

Planning a Domain Structure

Because the core unit of logical structure in Active Directory is the domain, which can store
millions of objects, it is essential to plan the domain structure for your company carefully. When
planning a domain structure, you must assess your company's

Logical and physical environment structure

Administrative requirements

Domain requirements

Domain organization needs

Assessing the Logical Environment

You must understand how your company conducts daily operations to determine the logical
structure of your organization. Consider how the company operates functionally and geographically.
For example, Figure 4.1 shows fictitious functional and geographical divisions for Microsoft.
Functionally, Microsoft operates through its Administration, Purchasing, Sales, and Distribution
departments. Geographically, Microsoft has offices in Kansas City, St. Paul, Chicago, and
Columbus.

Figure 4.1 Functional and geographical divisions for Microsoft

Assessing the Physical Environment

By assessing your company's physical environment, you can determine the technical requirements
for implementing Active Directory. Although you've already examined geographical locations, you must
now consider your company's user and network requirements so you can determine the logical requirements
for implementing Active Directory.

To assess user requirements, for each functional and geographical
division determine

The number of employees

The growth rate

Plans for expansion

To assess network requirements, for each geographical division determine

How network connections are organized

Network connection speed

How network connections are utilized

TCP/IP subnets

For example, Figure 4.2 shows the physical environment for Microsoft. Employees are distributed
fairly evenly among the four locations. However, among the functional divisions, more employees are
employed in the Administration department. In the next five years, growth for all locations and all
departments is estimated at 3 percent. The Chicago office is the hub of the Microsoft wide area network
(WAN). Network connections are utilized moderately; however, the Kansas
City-to-Chicago connection has a high degree of utilization.

Figure 4.2 Physical environment for Microsoft

Assessing Administrative Requirements

Assessing how your company's network resources are managed also helps you to plan your
domain structure. Identify the method of network administration used by your company:

Centralized administration. A single administrative team provides network services. Smaller
companies with fewer locations or business functions often use this method.

Decentralized administration. A number of administrators or administrative teams provide
network services. Teams may be divided by location or business function.

Customized administration. The administration of some resources is centralized
and it is decentralized for others, depending on business needs.

In the example, Microsoft requires decentralized administration methods. Each location requires
its own team of administrators to provide network services for all four functional divisions.

After you've determined the logical and physical environment structure and the administrative requirements for your company, you can begin to determine the need for a domain in your organization.

Domain Requirements

The easiest domain structure to administer is a single domain. When planning, you should start with a
single domain and only add domains when the single
domain model no longer meets your needs.

One domain can span multiple sites and contain millions of objects. Keep in mind that site and
domain structures are separate and flexible. A single domain can span multiple geographical sites,
and a single site can include users and
computers belonging to multiple domains. Planning your site structure is covered later in this lesson.

You do not need to create separate domains merely to reflect your company's
organization of divisions and departments. Within each domain, you can model your organization's
management hierarchy for delegation or administration using OUs for this purpose, which will act as
logical containers for other objects. You can then assign group policy and place users, groups, and
computers into the OUs. Planning OU structure is covered later in this lesson.

The following are some reasons to create more than one domain:

Decentralized network administration

Replication control

Different password requirements between organizations

Massive numbers of objects

Different Internet domain names

International requirements

Internal political requirements

In the example, Microsoft requires multiple domains for the following reasons:

Stricter password requirements exist at the Chicago office.

There is a need to control replication on the highly utilized Chicago-to-Kansas City
network connection.

There are plans for adding a new office in Fargo, North Dakota within two years.

Assessing Domain Organization Needs

If you've determined that your company requires more than one domain, you must
organize the domains into a hierarchy that fits the needs of your organization. You can arrange
domains into a tree or a forest depending on the company's business needs. Recall that domains in
trees and forests share the same configuration, schema, and global catalog. As domains are placed
in a tree or forest hierarchy, the two-way transitive trust relationship allows the domains to share
resources.

The primary difference between domain trees and forests is in their Domain Name Service (DNS)
name structure. All domains in a domain tree have a contiguous DNS namespace. Unless your organization
operates as a group of several entities, such as a partnership or conglomerate, your network probably
lends itself to a contiguous DNS namespace, and you should set up multiple domains in a single domain tree.
If you need to combine organizations with unique domain names, create a forest. You can also use a forest
to separate DNS zones. Each tree in the forest has its own unique namespace.

In the example, the Microsoft organizational structure maps to a group of domains in a domain tree.
Microsoft is not a part of any other entity, nor are there any known plans for creating multiple entities
in the future.

Planning a Domain Namespace

In Windows 2000 Active Directory, domains are named with DNS names. But before you begin using
DNS on your network, you must plan your DNS namespace. You must make some decisions about how you
intend to use DNS naming and what goals you are trying to accomplish using DNS. For instance:

Have you previously chosen and registered a DNS domain name for use on the Internet?

Will your company's internal Active Directory namespace be the same or different from its
external Internet namespace?

What naming requirements and guidelines must you follow when choosing DNS domain names?

Choosing a DNS Domain Name

When setting up DNS servers, it is recommended that you first choose and register a unique
parent DNS name that can be used for hosting your organization on the Internet. For example,
Microsoft uses microsoft.com. This name is a second-level domain within one of the top-level
domains used on the Internet.

Before you decide on a parent DNS name for your organization to use on the Internet, perform a
search to see if the name is already registered to another
entity. The Internet DNS namespace is currently managed by Network Solutions, Inc.,
though other domain name registrars are also available.

Once you have chosen your parent DNS name, you can combine this name with
a location or organizational name used within your organization to form other subdomain names.
For example, a subdomain added to the Microsoft second-level domain might be chicago, forming the
namespace chicago.microsoft.com.

Internal and External Namespaces

To implement Active Directory, there are two choices for namespace design. The Active Directory namespace
can either be the same or separate from the established, registered DNS namespace.

Same Internal and External Namespaces

In this scenario, the company uses the same name for the internal and external namespaces as shown in
Figure 4.3. Microsoft.com is used both inside and
outside of the company. To implement this scenario, the following requirements must be met:

Users on the company's internal, private network must be able to access both internal and external
servers (both sides of the firewall).

Clients accessing resources from the outside must not be able to access internal company
resources or resolve names to protect company data.

Figure 4.3 Same internal and external namespaces

For this scenario to work, two separate DNS zones must exist. One zone will
exist outside the firewall, providing name resolution for public resources. This zone is not configured
to resolve internal resources, thereby making internal company resources nonaccessible to external clients.

The challenge in this configuration is making publicly available resources accessible to internal
clients, as the external DNS zone is not configured to resolve internal resources. One suggestion is to
duplicate the external zone on an internal DNS for internal clients to resolve resources. If a proxy server
is being used, the proxy client should be configured to treat microsoft.com as an internal resource.

The advantages to using the same internal and external namespaces are
as follows:

The tree name, microsoft.com, is consistent both on the internal private
network and on the external public Internet.

This scenario extends the idea of a single logon name to the public Internet,
allowing users to use the same logon name both internally and externally. For example,
jsmith@microsoft.com would serve as both the logon and e-mail ID.

The disadvantages to using the same internal and external namespaces are
as follows:

It results in a more complex proxy configuration. Proxy clients must be configured to know the
difference between internal and external resources.

Care must be taken not to publish internal resources on the external public Internet.

There will be duplication of efforts in managing resources; for example, maintaining duplicate
zone records for internal and external name resolution.

Even though the namespace is the same, users will get a different view of internal
and external resources.

Separate Internal and External Namespaces

In this scenario, the company uses separate internal and external namespaces as shown in Figure 4.4.
Basically, the names will be different on either side of the firewall. Microsoft.com is the name that is
used outside the firewall and msn.com is the name used inside the firewall.

Figure 4.4 Separate internal and external namespaces

Separate names are used inside and outside the corporation. Microsoft.com is
the name that the Internet community sees and uses. Msn.com is the name that the private network sees
and uses. To do this, two namespaces must be registered with the Internet DNS. The purpose of registering
both names is to prevent
duplication of the internal name by another public network. If the name were not reserved, internal
clients would not be able to distinguish between the internal name and the publicly registered DNS
namespace.

Two zones will be established. One zone will resolve microsoft.com and the other DNS zone will
resolve msn.com on the inside of the firewall. Users can clearly distinguish between internal and
external resources.

The advantages to using the separate internal and external namespaces are
as follows:

Based on different domain names, the difference between internal and external resources is clear.

There is no overlap or duplication of effort, resulting in a more easily managed environment.

Configuration of proxy clients is simpler because exclusion lists only need to contain microsoft.com
when identifying external resources.

The disadvantages to using the separate internal and external namespaces are
as follows:

Logon names are different from e-mail names. For example, John Smith would log on as
jsmith@msn.com and his e-mail address would be jsmith@microsoft.com.

Multiple names must be registered with an Internet DNS.

NOTE
In this scenario, logon names are different by default. An administrator can use the MMC to change the user principal name (UPN) suffix properties of users so that the user logon will match the user e-mail address. However, this
requires additional intervention.

Domain Naming Requirements and Guidelines

When you plan your company's domain namespace, consider the following
domain naming requirements and guidelines for root domains and subdomains:

Select a root domain name that will remain static. Changing a root domain name may be impossible
or costly in the future.

Use simple names. Simple and precise domain names are easier for users to remember and they enable
users to search intuitively for resources.

Use standard DNS characters and Unicode characters. Windows 2000 supports the following standard DNS characters: A-Z, a-z, 0-9, and the hyphen (-), as defined in Request for Comment (RFC) 1035. The Unicode character set includes additional characters not found in the American Standard Code for Information Exchange (ASCII) character set, which are required for some languages other than English.

NOTE
Use Unicode characters only if all servers running DNS service in your environment support Unicode.
For more information on the Unicode character set, read RFC 2044, by searching for RFC 2044
with your Web browser.

Limit the number of domain levels. Typically, DNS host entries should be three or four levels
down the DNS hierarchy and no more than five levels down the hierarchy. Multiple levels increase
administrative tasks.

Use unique names. Each subdomain must have a unique name within its parent domain to ensure
that the name is unique throughout the DNS namespace.

Avoid lengthy domain names. Domain names can be up to 63 characters, including the periods.
The total length of the name cannot exceed 255 characters. Case-sensitive naming is not supported.

Taking into account the logical, physical, and administrative requirements, as well as the need for domains and domain organization, Figure 4.5 shows the
domain structure for Microsoft. The company's root domain, microsoft.com, contains subdomains for its four offices.

Figure 4.5 Microsoft domain structure and domain names

Planning an OU Structure

After you determine your company's domain structure and plan its domain namespace, you must plan its OU
structure. You can create a hierarchy of OUs in a domain. In a single domain, organize users and resources
by using a hierarchy of OUs to reflect the structure of the company. OUs allow you to model your
organization in a meaningful and manageable way and to assign an appropriate local authority as
administrator at any hierarchical level.

Each domain can implement its own OU hierarchy. If your enterprise contains several domains,
you can create OU structures within each domain, independent of the structures in the other domains.

Consider creating an OU if you want to do the following:

Reflect your company's structure and organization within a domain. Without OUs, all users
are maintained and displayed in a single list, regardless of a user's department, location, or role.

Delegate administrative control over network resources, but maintain the ability to manage them.
You can grant administrative permissions to users or groups of users at the OU level.

Accommodate potential changes in your company's organizational structure. You can reorganize
users between OUs easily, whereas reorganizing users between domains generally requires more time and
effort.

Group objects to allow administrators to locate similar network resources easily, to simplify
security, and to perform any administrative tasks. For example, you could group all user accounts for
temporary employees into an OU called TempEmployees.

Restrict visibility of network resources in Active Directory. Users can view only the
objects for which they have access.

Planning an OU Hierarchy

When planning an OU hierarchy, it's important to consider two main guidelines:

Although there are no restrictions on the depth of the OU hierarchy, a shallow hierarchy
performs better than a deep one.

OUs should represent business structures that are not subject to change.

There are many ways to structure OUs for your company. It is important to
determine what model will be used as a base for the OU hierarchy. Consider the following models
for classifying OUs in the OU hierarchy:

Business function-based OUs can be created based on various business
functions within the organization. A business function-based OU hierarchy
for domain.com is shown in Figure 4.6. The top level of OUs—ADMIN,
DEVELOPMENT (DEVEL), and SALES—corresponds to the company's business divisions. The second level of OUs represents the functional
divisions within the business divisions.

Figure 4.6 A business function-based OU structure

Geographical-based OUs can be created based on the location of company
offices. A geographical-based OU hierarchy for domain.com is shown in Figure 4.7. The top level of
OUs—WEST, CENTRAL, and EAST—corresponds to the regions set up for the organization.
The second level of OUs represents the physical locations of the company's eight offices.

Figure 4.7 A geographical-based OU structure

Business function and geographical-based OUs
can be created based on both business function and the location of company offices.
A business function and geographical-based OU hierarchy for domain.com is shown in Figure 4.8.
The top level of OUs—NORTH AMERICA and EUROPE—corresponds to the continents on which the
company has offices. The second level of OUs represents the functional divisions within the company.

Figure 4.8 A business and geographical-based OU structure

Planning a Site Structure

Recall that a site is part of the Active Directory physical structure and is a combination of
one or more Internet Protocol (IP) subnets connected by a highly reliable and fast network connection.
In Active Directory, site structure is concerned with the physical environment and is maintained separately
from the logical environment, the domain structure. A single domain can include multiple sites, and a
single site can include multiple domains or parts of multiple domains. The main role of a site is to provide
good network connectivity.

The way in which you set up your sites affects Windows 2000 in two ways:

Workstation logon and authentication. When a user logs on, Windows 2000 will try to find a
domain controller in the same site as the user's computer to service the user's logon request and
subsequent requests for network information.

Directory replication. You can configure the schedule and path for replication of a
domain's directory differently for inter-site replication, as opposed to replication within a site.
Generally, you should set replication between sites to be less frequent than replication within a
site.

Optimizing Workstation Logon Traffic

When planning sites, consider which domain controller(s) the workstations on
a given subnet should use. To have a particular workstation only log on to a
specific set of domain controllers, define the sites so that only those domain
controllers are in the same subnet as that workstation.

Optimizing Directory Replication

When planning sites, consider where the domain controllers and the network connections between
the domain controllers will be located. Because each
domain controller must participate in directory replication with the other domain controllers in its
domain, configure sites so that replication occurs at times and intervals that will not interfere with
network performance. Consider establishing a bridgehead server to provide criteria for choosing which
domain controller should be preferred as the recipient for inter-site replication.

Designing a Site Structure

Designing a site structure for a network that consists of a single local area network (LAN) is simple.
Because local area connections are typically fast, the entire
network can be a single site. Establish a separate site with its own domain controllers
when you feel domain controllers are not responding fast enough to meet the needs of your users.
Determining what is fast enough depends on your criteria for network performance. Inadequate performance
is more common when deployments span a wide geographic range. Other inadequacies may be attributed to
poor network design and implementation.

Follow these steps to design a site structure for an organization with multiple physical locations:

Assess the physical environment. Review the information you gathered when determining
domain structure, including site locations, network speed, how network connections are organized,
network connection speed, how network connections are utilized, and TCP/IP subnets.

Determine the physical locations that form domains.
Determine which physical locations are involved in each domain.

Determine which areas of the network should be sites.
If the network area requires workstation logon controls or directory replication, the area should be
set up as a site.

Identify the physical links connecting sites.
Identify the link types, speeds, and utilization that exist so the links can be determined as
site link objects. A site link object contains the schedule that determines when replication
can occur between the sites that it connects.

For each site link object, determine the cost and schedule.
The lowest cost site link performs replication; determine the priority of each link by setting
the cost (default cost is 100; lower cost provides a higher priority). Replication occurs every 3
hours by default; set the schedule according to your needs.

Provide redundancy by configuring a site link bridge.
A site link bridge provides fault tolerance for replication.

NOTE
For detailed information on configuring sites and inter-site replication, see Chapter 6, "Configuring Sites."

Lesson Summary

In this lesson you learned that before implementing Active Directory you must examine your organization's business structure and operations and plan the
domain structure, domain namespace, OU structure, and site structure needed by your organization.

When planning a domain structure, you must assess your company's logical and physical environment structure, administrative requirements, need for multiple domains, and domain organization needs.

You also learned that you must make some decisions about how you intend to use DNS naming, including the use of previously chosen DNS domain names, and whether your company's internal Active Directory namespace will be the same or different from its external Internet namespace. You learned the naming requirements and guidelines you must follow when choosing DNS domain names.

You learned how OUs allow you to model your organization in a meaningful and manageable way and assign an appropriate local authority as administrator at any hierarchical level. You explored various ways to structure OUs for your company.

Finally, you learned how setting up sites affects Windows 2000 workstation logon traffic and directory replication. You learned about the steps necessary to design a site structure for an organization with multiple physical locations.