Additional Study Topics: Utilities | Groups | Migration Issues | RIS
I.
Verifying Active Directory installations
There are common configuration parameters which should be checked on all new AD
installations.
A. Verifying the
domain controller
1. My Network
Places
a. All domains
on the network should be visible from the Network Places utility.
2. Users and
Computers MMC snap-in
a. Once a domain
is configured, it should be manageable from the Users and Computers MMC snap-in, which
allows for the creation and manipulation of various user objects within the domain.
B. Verifying the
DNS server
1. Automatic
testing of DNS server
a. Time interval
option for system testing of DNS
b. Test is
customizable and scalable to fit most organizations.
II.
Moving server objects between sites
Server objects
are normally created automatically, but can be manually added to the domain. It is
possible, as shown in Exercise 3-4 on page 132 of the text, to create dummy server objects
before the actual servers are really installed.
A. Creating a
new server object within a site
1. Sites and
Services MMC snap-in
2. Can create
member servers and domain controllers, though objects will perform no functions on their
own. The actual server needs to be installed and configured properly.
3. See Exercise
3-4 on page 132.
B. Moving server
objects
1. Server
objects are moved via the Sites and Services MMC snap-in.
2. See Exercise
3-5 on page 134.
3. Removing
objects
a. Objects
should only be deleted when they will not be made available again.
b. Objects that are only temporarily disabled should
have their NTDS settings folder deleted instead.
c. This object
will automatically be recreated when server comes back online.
III.
Transferring operations master roles
Operations
master roles are specific services and features within the forest or domain that have to
be hosted on a single system to ensure consistency throughout the domain.
A. Operations
master roles
1. Forest-wide
operations master roles
a. Protect
information, which has to be unique throughout the entire organization. Normally assigned
to the first server of the first domain in the network.
i.
Schema master
role
ii.
Domain-naming
master role
2. Domain-wide
operations master roles
a. Protects
information, which has to be unique and consistent throughout the entire domain. Within a
multidomain forest there will at least one domain operations master in each domain.
a.
Relative ID
master role
b.
Primary
domain controller emulator role
c.
Infrastructure
master role
B. When to
transfer roles and why
1. Load
balancing
2. Changes in
the network
3. Maintenance
and hardware upgrades
C. How to
transfer roles
1. Identifying
and transferring forest-wide operations master roles
a. Use the
Active Directory Schema snap-in, which by default is not installed. Do a full install of
the Administrative tools to be able to use this snap-in.
b. See Exercise
3-7 on page 142 of the text.
2. Identifying
the current assignment of domain-wide operations master roles
a. Exercise 3-8
on page 144 explains how to identify the present assignment of roles, which you need to
know in order to transfer the domain-wide operations master roles from one server to
another.
3. Exercise 3-9
on page 146 explains how to perform the transfer of role assignments.
4. Seizing
operations master role
a. When servers
hosting the schema or operations master fail unexpectedly, the operations of the object
need to be transferred to another server.
b. Seizing
schema master
i.
Should only
be considered when the server is down for long periods of time, as the schema isn’t
changed that often
ii.
Only needed
when changes are being made to the schema
iii.
Old server
should not be brought back online after the process is complete without a complete
reinstallation of the OS.
c. Seizing
domain-naming master role
i.
Should only
be considered when server is down for a long period
ii.
Only used
when domains are added or removed from the forest
iii.
Old server
should not be brought back online after the process is complete without a complete
reinstallation of the OS.
d. Seizing RID
operations master
i.
Should only
be considered when server is down for long periods of time
ii.
Only needed
when new objects need to be added to the domain
iii.
Old server
should not be brought back online after the process is complete without a complete
reinstallation of the OS.
e. Seizing PDC
emulator
i.
Should be
reassigned whenever a failure occurs
ii.
Used in user
password changes
iii.
Used to
updated pre-existing NT-based domain controllers
iv.
Can be
reassigned to original server once it comes back online
f. Seizing
infrastructure operations master
i.
Should only
be considered when server is down for long periods of time
ii.
Only needed
when changes are being made objects within the domain
iii.
Can be
reassigned to original server once server is restored to the network
IV.
Implementing an organizational unit (OU) structure
OUs are part of
the predefined X.501 directory infrastructure and are common to all X.500 directories,
such as Exchange and Novell GroupWise. An OU is simply a container, which can be used to
store objects or other OU containers. Within Active Directory, OUs can be used to group
user and computer objects into management and policy groups.
A. OU design
overview
1. Organizational
structure: The structure of the organization itself as well as the business and policy
issues involved with the organization
2. Ease of
administration: OUs are configured to allow a mass administration of objects instead of
the individual hunt-and-replace methods common with NT-based networks. Give attention as
well to administrative groups and their responsibilities.
3. Room for
change and growth: Allow for flexibility of the directory to expand and contract to meet
the needs of an organization.
4. Use of group
policies: The capability to control a wide variety of desktop configurations, and
selective and dynamic application deployment.
5. Restricted
access: Access between client and directory must be secured, making it difficult for
impostors to gain access to a resource.
B. With these
considerations in place, there are number of functions within the OU that should be
considered during the planning stages as well.
1. All objects
created in one OU can be moved to another OU.
2. OUs can be
created, removed, or moved from one domain to another.
3. Changes in
OUs do not create any significant load on current network traffic.
4. Organizational
properties can be changed at any time.
C. Three main
hierarchy models
1. Function-based
2. Location-based
3. Function-and-location-based
D. Creating the
OU structure
1. Creating an
organizational unit
a. The
organizational unit structure decided upon by your organization is dependant upon the
items listed above. The decision-making process involved in these decisions is highlighted
in the class activities listed at the end of this lesson, and the steps involved in
creating an OU are covered in Exercise 3-10 on page 153 of the text.
2. Setting OU
properties
a. OUs have a
set of default properties
b. Additional
properties can be set from the OUs properties sheet, which is shown in Figure 3-2 on page
155.
3. Creating an
object
a. There are
various objects that can be created in a domain: Users, Groups, Computers, and Policies
are some examples.
b. See Exercise
3-11 on page 156 for an explanation of how to create an object.