MCSE Training Kit (Exam 70-219): Designing a Microsoft Windows 2000 Directory Services Infrastructure

Overview

Make the right design decisions for your directory services architecture—and prepare for the Microsoft Certified Professional (MCP) exam—with this official Microsoft Training Kit. Work at your own pace through a system of case-study scenarios and tutorials to gain practical experience planning an Active Directory infrastructure for a Windows 2000 Server network. By building these real-world design skills, you’re also preparing for MCP Exam ...

See more details below
Available through our Marketplace sellers.
Other sellers (Paperback)
  • All (30) from $1.99   
  • New (10) from $4.72   
  • Used (20) from $1.99   
Close
Sort by
Page 1 of 1
Showing 1 – 9 of 10
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$4.72
Seller since 2009

Feedback rating:

(2392)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
2001-02-04 Hardcover 1St Edition New 0735611327 Ships Within 24 Hours. Tracking Number available for all USA orders. Excellent Customer Service. Upto 15 Days 100% Money Back ... Gurantee. Try Our Fast! ! ! ! Shipping With Tracking Number. Read more Show Less

Ships from: Bensalem, PA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$15.79
Seller since 2011

Feedback rating:

(748)

Condition: New
Hardcover New 0735611327 SERVING OUR CUSTOMERS WITH BEST PRICES. FROM A COMPANY YOU TRUST, HUGE SELECTION. RELIABLE CUSTOMER SERVICE! ! HASSLE FREE RETURN POLICY, SATISFACTION ... GURANTEED**** Read more Show Less

Ships from: Philadelphia, PA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$15.79
Seller since 2010

Feedback rating:

(933)

Condition: New
Hardcover New 0735611327 Friendly Return Policy. A+++ Customer Service!

Ships from: Philadelphia, PA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$15.81
Seller since 2014

Feedback rating:

(424)

Condition: New
Hardcover New 0735611327! ! KNOWLEDGE IS POWER! ! ENJOY OUR BEST PRICES! ! ! Ships Fast. All standard orders delivered within 5 to 12 business days.

Ships from: Southampton, PA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$15.81
Seller since 2014

Feedback rating:

(280)

Condition: New
Hardcover New 0735611327 XCITING PRICES JUST FOR YOU. Ships within 24 hours. Best customer service. 100% money back return policy.

Ships from: Bensalem, PA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$15.81
Seller since 2010

Feedback rating:

(701)

Condition: New
Hardcover New 0735611327! ! ! ! BEST PRICES WITH A SERVICE YOU CAN RELY! ! !

Ships from: Philadelphia, PA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$29.59
Seller since 2008

Feedback rating:

(169)

Condition: New
0735611327 BRAND NEW NEVER USED IN STOCK 125,000+ HAPPY CUSTOMERS SHIP EVERY DAY WITH FREE TRACKING NUMBER

Ships from: fallbrook, CA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$32.48
Seller since 2014

Feedback rating:

(273)

Condition: New
Brand New Item.

Ships from: Chatham, NJ

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$45.00
Seller since 2014

Feedback rating:

(162)

Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing 1 – 9 of 10
Close
Sort by
Sending request ...

Overview

Make the right design decisions for your directory services architecture—and prepare for the Microsoft Certified Professional (MCP) exam—with this official Microsoft Training Kit. Work at your own pace through a system of case-study scenarios and tutorials to gain practical experience planning an Active Directory infrastructure for a Windows 2000 Server network. By building these real-world design skills, you’re also preparing for MCP Exam 70-219—a core credit on the Windows 2000 MCSE track.

HERE’S WHAT YOU’LL LEARN.

  • Analyzing your company’s business requirements, including structure, work processes, and growth strategy
  • Identifying your current and future networking needs, from connectivity and access to security, performance, and end user support
  • Assessing the impact of Active Directory on existing systems and processes, as well as on potential upgrades
  • Creating a forest model and schema modification plan
  • Defining and naming domains
  • Designing site topology, including placement of domain controllers and DNS servers
  • Developing the structure of organizational units and planning for Group Policy

HERE’S WHAT’S INSIDE.

  • Comprehensive self-paced training manual that maps to MCP exam goals and objectives
  • Case study–based exercises and decision-making worksheets for learning you can apply to the job
  • Summaries and end-of-chapter review questions to help gauge your progress
  • 120-day evaluation version of Windows 2000 Advanced Server
  • All the book’s content—plus multimedia presentations, interviews with experienced Active Directory designers, and technical white papers—on CD-ROM
  • NEW! Sample MCSE Readiness Review practice-test questions on line. See “Getting Started” for details.

For customers who purchase an ebook version of this title, instructions for downloading the CD files can be found in the ebook.

Read More Show Less

Product Details

  • ISBN-13: 9780735611320
  • Publisher: Microsoft Press
  • Publication date: 2/4/2001
  • Series: MCSE Training Kits Series
  • Edition description: EXAM 70-219
  • Pages: 512
  • Product dimensions: 7.65 (w) x 9.31 (h) x 1.64 (d)

Meet the Author

Developed by senior editors and content managers at Microsoft Corporation.

Read More Show Less

Read an Excerpt

Chapter 5.
Creating an Organizational Unit Plan
    • About This Chapter
    • Before You Begin
  • Lesson 1: Defining OU Structures
    • Understanding OUs
    • Design Step: Defining OU Structures
    • Design Step Examples: Defining OU Structures
    • Lesson Summary
  • Activity 5.1: Defining OU Structures
    • Scenario: Arbor Shoes
  • Lesson 2: Planning User Accounts and Groups
    • Understanding Users and Groups
    • Design Step: Planning User Accounts and Groups
    • Design Process Examples: Planning User Accounts and Groups
    • Lesson Summary
  • Activity 5.2: Planning User Accounts
    • Scenario: Dearing School of Fine Art
  • Activity 5.3: Planning Groups
    • Scenario: The Ski Haus
  • Lab 5.1: Defining an OU Structure and Security Groups
    • Lab Objectives
    • About This Lab
    • Before You Begin
    • Exercise 5.1: Defining an OU Structure
    • Exercise 5.2: Defining Groups
  • Review

About This Chapter

After you and your design team finish creating a domain plan, the next stage in designing an Active Directory directory services infrastructure is to create an organizational unit (OU) plan. To create an OU plan, you define an OU structure and then plan user accounts and groups. The end result of an OU plan is a diagram of OU structures for each domain, a list of users in each OU, and a list of groups in each domain. This chapter discusses the process of creating an OU plan.


REAL WORLD
Read the "Designing in the Real World: Creating an Organization Unit Plan" interview with Xavier Minet, Microsoft Consulting Services, Belgium, for a real-world perspective of creating an organizational unit plan. You can find the interview on the Supplemental Course Materials CD-ROM (\chapt05\OUPlanInterview).


Before You Begin

To complete this chapter, you must have

  • Knowledge of Active Directory components and concepts covered in Chapter 1, "Introduction to Active Directory"
  • Knowledge of business and technical environment analyses components covered in Chapter 2, "Introduction to Designing a Directory Services Infrastructure"
  • Knowledge and skills covered in Chapter 3, "Creating a Forest Plan"
  • Knowledge and skills covered in Chapter 4, "Creating a Domain Plan"

Lesson 1: Defining OU Structures

The first step in creating an OU plan is to define OU structures. When you define OU structures, you define the OUs needed for each domain in your organization. This lesson discusses how to define OU structures, which includes defining OU structures to delegate administration, defining OU structures to hide objects, and defining OU structures to administer group policy.


After this lesson, you will be able to

  • Identify the three reasons for defining an OU
  • Explain the guidelines for defining OU structures
  • Identify the factors in an organization's environment that impact its need for OUs
  • Identify the tasks in the process of defining OU structures
  • Analyze an organization's environment to define its OUs

Estimated lesson time: 30 minutes


Understanding OUs

Recall that an organizational unit (OU) is a container used to organize objects within one domain into logical administrative groups. An OU can contain objects such as user accounts, groups, computers, printers, applications, file shares, and other OUs from the same domain. There are three reasons for defining an OU:

  • To delegate administration
  • To hide objects
  • To administer group policy

OUs can be added to other OUs to form a hierarchical structure; this process is known as nesting OUs. Each domain defines its own OU structure—the OU structure within a domain is independent of the OU structures of other domains.

Defining OUs to Delegate Administration

The primary reason for defining an OU is to delegate administration. Delegating administration is the assignment of IT management responsibility for a portion of the namespace, such as an OU, to an administrator, a user, or a group of administrators or users. In Windows 2000, you can delegate administration for the contents of an OU container (all users, computers, or resource objects in the OU) by granting administrators specific permissions for an OU on the OU's access control list. An access control list (ACL) is the mechanism for limiting access to certain items of information or certain controls based on users' identity and their membership in various groups. Access control entries (ACEs) in each ACL determine which users or groups can access the OU and what type of access they have.

Because ACEs are inherited by child OUs in an OU hierarchy by default, you can apply permissions to an entire tree of OUs, as shown in Figure 5.1. Inherited ACEs apply only to one domain and do not flow down to child domains. To prevent permissions from being inherited by child objects, you can clear the Allow Inheritable Permissions From Parent To Propagate To This Object check box on the Security tab of the Properties dialog box for the OU.

Figure 5.1 Inheriting permissions and blocking inheritance (Image Unavailable)

To delegate administration, you can use the Delegation of Control Wizard or manually modify the access control entries on the Security tab of the Properties dialog box for the OU.

OU Hierarchy Models for Delegation of Administration

Once you determine the OUs needed for your organization, you can add OUs to other OUs to form a hierarchy of administrative control. Hierarchies for delegating administration can reflect various organizational models:

  • Location. This structure may be used if administration within a domain is handled by location, as shown in Figure 5.2. The top-level OUs—West, Central, and East—correspond to the regions set up for the microsoft.com organization. The second-level OUs represent the physical locations of the company's eight offices.

    Figure 5.2 An OU structure based on location (Image Unavailable)

  • Business function. This structure may be used if administration within a domain is handled by business function, as shown in Figure 5.3. The top-level OUs—Admin, Devel, and Sales—correspond to microsoft.com's business divisions. The second-level OUs represent the functional divisions within the business divisions.

    Figure 5.3 An OU structure based on business function (Image Unavailable)

  • Object type. This structure may be used if administration within a domain is handled by the types of objects being managed, as shown in Figure 5.4. The top-level OUs—Users, Computers, and Resources—correspond to the types of objects used at microsoft.com. The second-level OUs represent further detailing of the object types.

    Figure 5.4 An OU structure based on types of objects (Image Unavailable)

  • A combination of location, business function, and object type. This structure may be used if administration within a domain is handled by a combination of hierarchy models, as shown in Figure 5.5. The top-level OUs—North America and Europe—correspond to the continents on which microsoft.com has offices. The second-level OUs represent the functional divisions within the company.

    Figure 5.5 An OU structure based on location and business function (Image Unavailable)

Defining OUs to Hide Objects

Your organization may require that certain domain objects be hidden from certain users. Although a user may not have the permission to read an object's attributes, the user can still see that the object exists by viewing the contents of the object's parent container. You can hide objects in a domain by creating an OU for the objects and limiting the set of users who have List Contents permission for that OU.

Defining OUs to Administer Group Policy

Recall that group policies are collections of user and computer configuration settings that can be linked to computers, sites, domains, and OUs to specify the behavior of users' desktops. To create a specific desktop configuration for a particular group of users, you create group policy objects (GPOs), which are collections of group policy settings. By linking GPOs to OUs, GPOs can be applied to either users or computers in the OU.

How Group Policy Is Processed

Group policy settings are processed in the following order:

  1. Local GPO
  2. Site GPOs
  3. Domain GPOs
  4. OU GPOs

GPOs linked to the OU highest in the Active Directory hierarchy are processed first, followed by GPOs linked to its child OU, and so on. Finally, the GPOs linked to the OU that contains the user or computer are processed. At the level of each OU in the Active Directory hierarchy, one, many, or no GPOs can be linked. If several group policies are linked to an OU, they are processed synchronously in an order specified by the administrator.

Figure 5.6 provides an example of how group policy is processed.

Figure 5.6 Group policy processing (Image Unavailable)

Group Policy Inheritance

In general, group policy is passed down from parent to child containers. Group policy is inherited in the following ways:

  • If a policy is configured for a parent OU, and the same policy is not already configured for its child OUs, the child OUs, which contain the user and computer objects, inherit the parent's policy setting.
  • If a policy is configured for a parent OU, and the same policy is configured for a child OU, the child OU's group policy setting overrides the setting inherited from the parent OU.
  • Policies are inherited as long as they are compatible. If a policy configured for a parent OU and a policy configured for a child OU are compatible, the child OU inherits the parent's policy, and the child's policy setting is also applied. For example, if the parent OU's policy causes a certain folder to be placed on the desktop and the child OU's policy calls for an additional folder, the users in the child OU see both folders.
  • If a policy configured for a parent OU is incompatible with the same policy configured for a child OU, the child OU does not inherit the policy setting from the parent OU. Only the setting configured for the child OU is applied.
  • If any of the policy settings of a parent OU are disabled, the child OU inherits them as disabled.
  • If any of the policy settings of a parent OU are not configured, the child OU does not inherit them.

Exceptions to Processing Order

The following are exceptions to the default processing order of group policy settings and may affect how GPOs are processed for OUs:

  • Member Computer of a Workgroup. These computers process only the local GPO.
  • No Override. Any GPO linked to a site, domain, or OU (not the local GPO) can be set to No Override with respect to that site, domain, or OU, so that none of its policy settings can be overwritten. When more than one GPO has been set to No Override, the one highest in the Active Directory hierarchy (or higher in the hierarchy specified by the administrator at each fixed level in Active Directory) takes precedence. No Override is applied to the GPO link.

    In Figure 5.7, No Override has been applied to the GPO 4 link to the Users OU. As a result, the policy settings in GPO 4 cannot be overwritten by other GPOs. Processing remains the same.

  • Block Policy Inheritance. At any site, domain, or OU, group policy inheritance can be blocked by selecting the Block Policy Inheritance check box on the Group Policy tab of the Properties dialog box for the site, domain, or OU. However, GPO links set to No Override are always applied and cannot be blocked by using Block Policy Inheritance.

    Block Policy Inheritance is applied directly to the site, domain, or OU. It is not applied to GPOs, nor is it applied to GPO links. Thus, Block Policy Inheritance deflects all group policy settings that reach the site, domain, or OU from above (by way of linkage to parents in the Active Directory hierarchy) no matter what GPOs those settings originate from.

    In Figure 5.7, Block Policy Inheritance has been applied to the Computers OU. As a result, GPOs 1 and 2, which are applied to the site and the domain, are deflected and do not apply to the Computers OU. Therefore, only GPOs 6 and 7 are processed for the Servers OU.

  • Loopback. Loopback is an advanced group policy setting that is useful on computers in certain closely managed environments such as kiosks, laboratories, classrooms, and reception areas. Loopback provides alternatives to the default method of obtaining the ordered list of GPOs whose user configuration settings affect a user.

Figure 5.7 Applying No Override and Block Policy Inheritance (Image Unavailable)

Guidelines for Defining OU Structures

Guidelines for defining OU structures include the following:

  • Design OUs for simplicity. Previous chapters emphasized the use of minimal numbers of forests and domains in your Active Directory design. However, it is likely that your domains will require a number of OUs to meet administrative requirements. The best practice is to begin with one OU and then add only those OUs that you can justify. You should note the specific reason for creating each OU that you add to your OU plan.
  • Assign control to groups rather than users to simplify management tasks. You should also delegate to local groups, rather than global or universal groups. Local groups are ideally suited for resource permissions because, unlike global groups, they can have members from any trusted domain and, unlike universal groups, local group membership is not replicated to the global catalog.

When defining OU structures for your organization, it's also important to keep the following in mind:

  • OUs are not security principals. That is, you cannot assign access permissions based on a user's membership in an OU. Access control is the responsibility of global, domain local, or universal groups.
  • Users will not use the OU structure for navigation. Although users can see the OU structure of a domain, the most efficient way for users to find resources in Active Directory is to query the global catalog. Therefore, you should define OUs with administration, not users, in mind.

Design Step: Defining OU Structures

To define OU structures, you must complete the following tasks:

  1. Define OU structures to delegate administration.
  2. Define OU structures to hide objects.
  3. Define OU structures to administer group policy.

IMPORTANT
Because there is only one way to delegate administration and there are multiple ways to administer group policy, you must define OU structures to delegate administration first. After an OU structure is defined to handle delegation of administration, you can define additional OUs to hide objects and to administer group policy.


Defining OU Structures to Delegate Administration

To define OU structures to delegate administration, you must complete the following tasks:

  1. Assess the organization's IT administration requirements to determine the type of administrative responsibility to delegate.
  2. Define OUs to delegate full control.
  3. Define OUs to delegate control for object classes.

Assessing IT Administration Requirements

To determine the type of administrative responsibility to delegate, you must first consult the IT Management Organization Worksheet compiled earlier by your design team and analyze how administrative tasks are accomplished. In addition to assessing the information compiled in this worksheet, it is imperative that you assess changes currently planned for IT management to address growth, flexibility, and the ideal design specifications of the organization. You will use these findings to determine the type of administrative responsibility to delegate.


NOTE
A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."


There are two types of administrative responsibility you can delegate for an OU:

  • Full control
  • Control for object classes

By default, only domain administrators have full control over all objects in a domain. Domain administrators are responsible for creating the initial OU structure, repairing mistakes, and creating additional domain controllers. It is usually sufficient to allow only domain administrators full control over objects in a domain. However, if there are units in the organization that need to determine their own OU structure and administrative models, you can provide them with this permission by delegating full control.

When determining whether to delegate full control for an OU, you must determine which areas in the organization need to be allowed to change OU properties and to create, delete, or modify any objects in the OU.

If additional OUs are necessary to delegate more restrictive control, you can accomplish this by delegating control of specific object classes for an OU. Although there are many object classes in the schema, you need to consider only the object classes in which administrators will create objects. Such object classes typically include user account objects, computer account objects, group objects, and organizational unit objects. When determining whether to delegate control of object classes, for each object class that your administrators will create in Active Directory you must determine the following:

  • Which areas in the organization should be granted full control over objects of this class in the OU
  • Which areas in the organization should be allowed to create objects of this class and thus have full control over these objects
  • Which areas in the organization should be allowed to modify only specific attributes for or perform specific tasks pertaining to existing objects of this class

Defining OUs to Delegate Full Control or Control of Object Classes

After you determine the type of administrative responsibility to delegate, you can create OUs to delegate full control or control of object classes.

To define OUs to delegate full control or control of object classes

  1. Diagram the desired OU.
  2. Diagram a security group and list administrators who require full control or control of a specific object class in the group.
  3. If the OU is allowed to set its own membership, place the administrator group inside the OU. If the OU is not allowed to set its own membership, place the administrator group outside the OU.

Defining OU Structures to Hide Objects

To define OU structures to hide objects, you must complete the following tasks:

  1. Assess the organization's IT administration requirements to determine the need to hide objects from users.
  2. Define OUs to hide objects.

Assessing the Need to Hide Objects

To define OU structures to hide objects, you must first consult the Technical Standards Worksheet compiled earlier by your design team to determine the objects that must be hidden from users and the users from which the objects must be hidden. In addition to assessing the information in this worksheet, it is imperative that you assess changes currently planned for IT management to address growth, flexibility, and the ideal design specifications of the organization. You will use these findings to determine whether to define OUs to hide objects.


NOTE
A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."


When determining whether to define OUs to hide objects, you must assess the following:

  • Which objects need to be hidden
  • Which groups need to access the OU where the hidden objects reside to perform specific administrative tasks
  • Which groups need read access to the OU where the hidden objects reside
  • Which groups need full control of the OU where the hidden objects reside

Defining OUs to Hide Objects

After you determine whether it's necessary to define OUs to hide objects, you can define the necessary OUs.

To define an OU to hide objects

  1. Diagram the OU in which you will place the objects to be hidden.
  2. List the groups that you want to have full control of the OU.
  3. List the groups that you want to have generic read access to the OU and its contents.
  4. List any groups that you want to have specific permissions, such as creating a specific object class, for the OU.
  5. Specify the objects that you want to hide in the OU.

Defining OU Structures to Administer Group Policy

To define OU structures to administer group policy, you must complete the following tasks:

  1. Assess the organization's group policy requirements and the existing OU structure you created to delegate administration to determine which group policies require the creation of additional OUs for administration.
  2. Define OU structures to administer group policy.

Assessing the Need to Define OU Structures to Administer Group Policy

To define OU structures to administer group policy, you must first consult the Technical Standards Worksheet compiled earlier by your design team and the existing OU structure you created to delegate administration and hide objects to determine which group policies require the creation of additional OUs for administration. In addition to assessing the information in this worksheet, it is imperative that you assess changes currently planned for IT management to address growth, flexibility, and the ideal design specifications of the organization. You will use these findings to determine whether to define additional OUs to administer group policy.


NOTE
A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."


When determining whether to define OUs to administer group policy, you must determine the following:

  • What group policy settings are necessary for the domain
  • To which users or computers do the group policy settings apply
  • Which of the group policy settings are not handled by GPOs linked to the site, domain, or existing OUs created to delegate administration or hide objects

Defining OUs to Administer Group Policy

After you determine whether to create OUs to administer group policy, you can define the necessary OUs.

To define OUs to administer group policy

  1. Diagram the OU that will administer the desired group policy settings.
  2. List the users or computers to which the group policy setting(s) for the OU apply.
  3. Diagram a security group and place administrators who require control of the OU in the group.
  4. Diagram the GPO and indicate its group policy settings.
  5. Indicate the groups that have administrative control for the GPO.
  6. Indicate any processing exceptions (such as No Override or Block Policy Inheritance) for the GPO.
  7. Link the GPO to the OU.

Design Step Examples: Defining OU Structures

The following scenarios are examples of defining OU structures to delegate administration, defining OU structures to hide objects, and defining OU structures to administer group policy.

Defining OU Structures to Delegate Administration

Figure 5.8 shows an example of defining an OU structure to delegate full administrative control of the OU. The Silk unit of Miller Textiles was a recent acquisition, with locations in Tokyo and Osaka. The Silk unit is maintaining its own IT Management department. Therefore, Silk has become its own OU in the asia.m-100times.com root domain. The Silk Admins group is allowed to set its own membership and is set inside the Silk OU. The Tokyo Admins and Osaka Admins groups are not allowed to set their own memberships and are set in the Silk OU, outside of their respective OUs.

Figure 5.8 Defining OUs to delegate full administrative control (Image Unavailable)

Figure 5.9 shows an example of defining an OU structure to delegate control of object classes. The Tokyo location for the Silk unit of Miller Textiles currently contains two Windows NT 4 resource domains, Natural and Synthetic. When the organization migrates to Windows 2000, the resource domains will be consolidated and replaced by OUs. The Natural and Synthetic administrators currently use their domains to share files controlled by group membership and to reset passwords for team members. Groups were created to administer group objects and user objects and then granted the appropriate level of control for the Natural and Synthetic OUs.

Figure 5.9 Defining OUs to delegate control of object classes (Image Unavailable)

Defining OU Structures to Hide Objects

Figure 5.10 shows an example of defining an OU to hide objects. The na.m-100times.com domain has locations in San Francisco, Kansas City, and Raleigh. The OUs in the top half of the diagram were already defined to delegate administration. Because Miller Textiles requires administrative accounts in each location to be hidden from users, it was necessary to create three new OUs to hide the accounts.

Figure 5.10 Defining OUs to hide objects (Image Unavailable)

Defining OU Structures to Administer Group Policy

Figure 5.11 shows an example of defining OUs to administer group policy. The na.m-100times.com domain has locations in San Francisco, Kansas City, and Raleigh. The OUs in the top half of the diagram were already created to delegate administration. Because Miller Textiles requires one group policy to provide folder redirection for users in the Managers group and another group policy to publish software on management workstations, six new OUs were necessary to administer the group policies. Group Policy 1 redirects the My Documents folder for the Managers group only. Group Policy 2 publishes software for installation on managers' workstations only.

Figure 5.11 Defining OUs to administer group policy (Image Unavailable)

Lesson Summary

In this lesson you learned that defining OU structures is a three-step process: (1) define OU structures to delegate administration, (2) define OU structures to hide objects, and (3) define OU structures to administer group policy. Because there is only one way to delegate administration and there are multiple ways to administer group policy, you must define the OU structures to delegate administration first. After an OU structure is defined to handle delegation of administration, you can define additional OUs to hide objects and to administer group policy.

You learned how OU structures to delegate administration can be arranged in a hierarchy to reflect various organizational models: location, business function, object type, or a combination of any of the models. You also learned how you can hide objects in a domain by defining an OU for the objects and limiting the set of users who have List Contents permission for that OU. Finally, you learned how you can link GPOs to OUs to apply group policy settings to either users or computers in the OU.

Activity 5.1: Defining OU Structures

In this activity you will read about an organization that is planning its Active Directory infrastructure. Your task is to analyze the organization's environment to define the OU structures needed in an Active Directory infrastructure. You will define the OU structures by creating a diagram.

Scenario: Arbor Shoes

You are an infrastructure planner on the Active Directory infrastructure design team for Arbor Shoes, a distributor of upscale non-leather shoes operating from three locations in San Francisco, Houston, and Boston. The business and technical environment analysis documents, the forest plan, and the domain plan have already been compiled, and copies have been distributed to everyone on the team. You are now in the process of defining the OU structures for the organization.

Arbor Shoes is a centralized organization, with major IT administration issues handled from its headquarters in Boston. Each of the three locations also has a small autonomous IT staff to handle support tasks. Your design team has created the domain hierarchy diagram shown in Figure 5.12.

Figure 5.12 Domain hierarchy diagram for Arbor Shoes (Image Unavailable)

While reading through the business and technical environment analysis documents, you note the following:

  • One administrative group at each location handles the administration of users.
  • A second administrative group at each location handles the administration of computers.
  • A third administrative group at each location handles the administration of resources.
  • Arbor Shoes requires a specific logon and logoff script for all users at each location, except for users in the Finance department. The Finance department at each location requires a separate logon script but no logoff script.
  1. Diagram the OU structures needed to delegate administration for the corp.a-100times.com domain. Explain your reasoning for defining each OU.
  2. Diagram the OU structures needed to hide objects. Explain your reasoning for defining each OU.
  3. Diagram the OU structures needed to administer group policy. Explain your reasoning for defining each OU.

Answers

Lesson 2: Planning User Accounts and Groups

After you define OU structures, the next step in creating an OU plan is to plan user accounts and groups. When you plan user accounts and groups, you define the user accounts and groups needed for each domain in your organization. This lesson discusses how to plan user accounts and groups, which includes naming and placing user accounts and naming and defining groups.


After this lesson, you will be able to

  • Identify the factors in an organization's environment that impact its naming conventions
  • Analyze an organization's environment to establish naming conventions for users and groups
  • Identify factors in an organization's environment that impact the placement of user accounts
  • Analyze an organization's environment to place user accounts
  • Identify factors in an organization's environment that impact its need for groups
  • Analyze an organization's environment to define groups

Estimated lesson time: 25 minutes


Understanding Users and Groups

Before launching into a discussion of users and groups, it's important to understand the difference between OUs and groups. In the previous lesson, you learned that OUs contain objects such as user accounts, groups, computers, printers, applications, file shares, and other OUs from the same domain. OUs are defined mainly to delegate the administration of their contents. Groups also contain objects such as user accounts, contacts, computers, and other groups. However, groups are defined mainly to assign permissions to users or to restrict user access to various objects in the domain. Planning user accounts and groups is the second part of creating an organizational unit plan.

User Accounts

A domain user account provides a user with the ability to log onto the domain to gain access to network resources. Each person who regularly uses the network should have a unique user account.

You create a domain user account in a container or in an OU on a domain controller. The domain controller replicates the new user account information to all domain controllers in the domain. After Windows 2000 replicates the new user account information, all of the domain controllers in the domain tree can authenticate the user during the logon process. During the logon process, each user provides his or her user name and password. By using this information, Windows 2000 authenticates the users and then builds an access token that contains information about the user and security settings. The access token identifies the user to computers running Windows 2000 and pre–Windows 2000 computers on which the user tries to gain access to resources. Windows 2000 provides the access token for the duration of the logon session.

Groups

A group is a collection of user accounts. Groups simplify administration by allowing you to assign permissions to a group of users rather than having to assign permissions to each individual user account. Permissions control what users can do with a resource, such as a folder, file, or printer. When you assign permissions, you give users the capability to gain access to a resource and define the type of access that they have. For example, if several users need to read the same file, you would add their user accounts to a group. Then, you would give the group permission to read the file.

In addition to user accounts, you can add other groups, contacts, and computers to groups. You add groups to other groups to create a consolidated group and reduce the number of times that you need to assign permissions. However, you should use caution to add only those groups that are absolutely necessary. You add computers to groups to simplify the process of giving a user logged on to one computer access to a resource on another computer.

Group Types

You can create groups for security-related purposes, such as assigning permissions, or for nonsecurity purposes, such as sending e-mail messages. To facilitate this, Windows 2000 includes two group types: security and distribution. The group type determines how you use the group. Both types of groups are stored in the database component of Active Directory, which allows you to use them anywhere in your network.

Windows 2000 uses only security groups, which you use to assign permissions to gain access to resources. Programs that are designed to search Active Directory can also use security groups for nonsecurity-related purposes, such as retrieving user information for use in a Web application. A security group also has all the capabilities of a distribution group. Because Windows 2000 uses only security groups, this lesson focuses on security groups.

Group Scopes

When you create a group you must select a group type and a group scope. Group scopes allow you to use groups in different ways to assign permissions. The scope of a group determines where in the network you are able to use the group to assign permissions to the group. The three group scopes are global, domain local, and universal.

Global security groups are most often used to organize users who share similar network access requirements. A global group has the following characteristics:

  • Limited membership. You can add members only from the domain in which you create the global group.
  • Access to resources in any domain. You can use a global group to assign permissions to gain access to resources that are located in any domain in the domain tree or forest.

Domain local security groups are most often used to assign permissions to resources. A domain local group has the following characteristics:

  • Open membership. You can add members from any domain.
  • Access to resources in one domain. You can use a domain local group to assign permissions to gain access only to resources located in the same domain where you create the domain local group.

Universal security groups are most often used to assign permissions to related resources in multiple domains. A universal security group has the following characteristics:

  • Open membership. You can add members from any domain.
  • Access to resources in any domain. You can use a universal group to assign permissions to gain access to resources that are located in any domain.
  • Available only in native mode. Universal security groups are not available in mixed mode.

Group Nesting

Adding groups to other groups, or nesting, creates a consolidated group and can reduce network traffic between domains and simplify administration in a domain tree. For example, you could create separate regional manager groups for the managers in each region. Then, you could add all of the regional manager groups to a worldwide managers group. When all managers need access to resources, you assign permissions only to the worldwide managers group.

Guidelines for group nesting include the following:

  • Minimize levels of nesting. Tracking permissions and troubleshooting becomes more complex with multiple levels of nesting. One level of nesting is the most effective to use.
  • Document group membership to keep track of permissions assignments. Providing documentation of group membership can eliminate the redundant assignment of user accounts to groups and reduce the likelihood of accidental group assignments.

To efficiently use nesting it is important to understand the membership rules of groups.

Rules for Group Membership

The group scope determines the membership of a group. Membership rules determine the members that a group can contain. Table 5.1 describes group membership rules, including what each group scope can contain in native and mixed mode.

Table 5.1 Group Scope Membership Rules

Group scope In native mode, group can contain In mixed mode, group can contain
Global User accounts and global groups from the same domain Users from the same domain
Domain local User accounts, universal groups, and global groups from any domain; domain local groups from the same domain User accounts and global groups from any domain
Universal User accounts, other universal groups, and global groups from any domain Not applicable; universal groups cannot be created in mixed mode

Design Step: Planning User Accounts and Groups

Planning user accounts and groups is a two-step process:

  1. Name and place user accounts.
  2. Name and define groups.

Naming and Placing User Accounts

To name and place user accounts, you must complete the following tasks:

  1. Assess the organization's existing user account naming conventions and OU structure to determine current user account naming requirements and the OU structure.
  2. Determine the user account naming convention.
  3. Place user accounts in the appropriate OUs.

Assessing User Account Naming Conventions and the OU Structure

To determine current user account naming conventions, you must first consult the Technical Standards Worksheet compiled earlier by your design team to find out the current user account naming requirements. In addition to assessing the information in this worksheet, it is imperative that you assess changes in user account names currently planned to address growth, flexibility, and the ideal design specifications of the organization.


NOTE
A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."


To place user accounts in the appropriate OUs, use the OU structure diagram to determine

  • The user accounts administered by each administrative group
  • The user accounts affected by each GPO

Determining User Account Naming Conventions

By establishing a naming convention for user accounts, you can standardize how users are identified in the domain. A consistent naming convention will help you and your users remember user logon names and locate them in lists. Table 5.2 summarizes some points you might want to consider in determining a user account naming convention for your organization.

Table 5.2 User Account Naming Convention Considerations

Consideration Explanation
Domain user accounts The user's logon name (distinguished name) must be unique to the directory. The user's full name (relative distinguished name, also referred to as display name or account name) must be unique within the OU where you create the domain user account. 20 characters maximum User logon names can contain up to 20 uppercase or lowercase characters. Although the field accepts more than 20 characters, Windows 2000 recognizes only the first 20. Invalid characters The following characters are invalid: " / \ [ ] : ; | = , + * ? < >
User logon names are not case sensitive You can use a combination of special and alphanumeric characters to help uniquely identify user accounts. User logon names are not case sensitive, but Windows 2000 preserves the case.
Accommodate duplicate employee names If two users were named John Doe, you could use the first name and the last initial and then add letters from the last name to differentiate the duplicate names. In this example, one user account logon name could be Johnd and the other Johndo. Another possibility would be to number each user logon name—for example, Johnd1 and Johnd2. Identify the type of employee In some organizations, it is useful to identify temporary employees by their user account. To identify temporary employees, you can use a T and a hyphen in front of the user's logon name—for example, T-Johnd. Alternatively, use parentheses in the name—for example, John Doe (Temp). E-mail compatibility Some e-mail systems may not accept characters, such as spaces and parentheses—"()".

Placing User Accounts in the Appropriate OUs

After you determine the user account naming convention, you can place user accounts in the appropriate OUs. To determine the OU for a user account, you must identify the administrative groups that administer the account and any GPOs that must apply to the account. The OU for the user account is the OU that is administered by the administrative group and the GPO.

To name and place user accounts

  1. Select a naming scheme that ensures that unique user account names are generated for all users in the forest.
  2. Ensure that all administrators adhere to the naming scheme.
  3. List the administrative groups that must administer the account.
  4. List the GPOs that must apply to the account.
  5. Place the account in the OU administered by the designated administrative group and the designated GPO. List the accounts contained in each OU.

Naming and Defining Groups

To name and define groups, you must complete the following tasks:

  1. Assess the organization's existing group naming conventions and OU structure to determine group naming requirements and the definition of appropriate groups.
  2. Determine the group naming convention.
  3. Define the appropriate global and domain local groups.
  4. Define the appropriate universal groups.

Assessing Group Naming Conventions and the OU Structure

To determine group naming requirements, you must first consult the Technical Standards Worksheet compiled earlier by your design team to find out the current group naming requirements. In addition to assessing the information in this worksheet, it is imperative that you assess changes to group names currently planned to address growth, flexibility, and the ideal design specifications of the organization.


NOTE
A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."


Use the list of accounts contained in each OU to define the appropriate global, domain local, and universal groups.

Determining the Group Naming Convention

By establishing a naming convention for groups, you can standardize how groups are identified in the domain. A consistent naming convention will help you and your users remember group names and locate them in lists. Table 5.3 summarizes some points you might want to consider in determining a group naming convention for your organization.

Table 5.3 Group Naming Convention Considerations

Consideration Explanation
Groups The group name must be unique to the directory.
64 characters maximum Group names can contain up to 64 uppercase or lowercase characters.
Invalid characters The following characters are invalid: " / \ [ ] : ; | = , + * ? < >
Group names are not case sensitive You can use a combination of special and alphanumeric characters to help uniquely identify groups. Group names are not case sensitive, but Windows 2000 preserves the case.

Defining the Appropriate Global and Domain Local Groups

Depending on the administration required for the group, you can define global and domain local groups in either domains or organizational units. The group scope determines the domain from which members can be added and the domain in which the rights and permissions assigned to the group are valid.

To define appropriate global and domain local groups:

  • Identify users with common job responsibilities and add the user accounts to a global group. For example, in a finance department, user accounts for all accountants are added to a global group called Finance.
  • Identify the resources to be shared, such as files or printers, and add the resources to a domain local group for that resource. For example, color printers in a company are added to a domain local group called Color Printers.
  • Identify all global groups that share the same access needs for resources and make them members of the appropriate domain local group. For example, add the global groups Finance, Sales, and Management to the domain local group Color Printers.
  • Assign the required permissions for the resource to the domain local group. For example, assign the necessary permissions to use color printers to the Color Printers group. Users in the Finance, Sales, and Management global groups receive the required permissions because their global group is a member of the domain local group Color Printers.

This strategy gives you the most flexibility for growth and reduces permissions assignments. Although there are other methods for defining groups, these methods have the following limitations:

  • Placing user accounts in domain local groups and assigning permissions to the domain local groups does not allow you to assign permissions for resources outside of the domain, reducing the flexibility when your network grows.
  • Placing user accounts in global groups and assigning permissions to the global groups can complicate administration if you are using multiple domains. If global groups from multiple domains require the same permissions, you have to assign permissions for each global group.

Defining the Appropriate Universal Groups

Use universal groups to grant or deny access to resources that are located in more than one domain. Because universal groups and their members are listed in the global catalog, when membership of any universal group changes, the changes must be replicated to every global catalog in the forest. This action can cause excessive network traffic. Therefore, you should define universal groups with caution.

Follow these guidelines to ensure minimal impact on replication traffic:

  • Add global groups, not users, to universal groups. The global groups are the members of the universal group. Keep the number of group members in universal groups as low as possible and minimize the number of individual users.
  • Change the membership of universal groups as infrequently as possible. By requiring all members of universal groups to be global groups and making individual membership changes in the global groups, the membership changes you make to the global groups will not affect the universal groups or replication traffic.

To name and define groups

  1. Select a naming scheme that ensures that unique group names are generated for all groups in the forest.
  2. Ensure that all administrators adhere to the naming scheme.
  3. List the user accounts that must be added to a global group.
  4. List the resources that must be added to a domain local group.
  5. List all global groups that share the same access needs for resources and note the domain local group to which they must be added.
  6. List the global groups that must be added to a universal group or groups.

Design Process Examples: Planning User Accounts and Groups

The following scenarios are examples of naming and placing user accounts and naming and defining groups.

Naming and Placing User Accounts

Consolidated Messenger, a worldwide fictitious delivery service, has 21 new users that need accounts at their location in Dallas. Consolidated Messenger has selected a user account naming scheme that ensures that unique user account names are generated for all users in the forest. Three years ago, the company instituted a naming scheme that creates the account name by taking the user's first initial followed by the first six letters of his or her last name. In case of the same last name, the first two letters of the first name will be used. For temporary employees, "T-" will precede the user account name. Consolidated Messenger will continue to use the naming scheme. All administrators have been trained and recognize the importance of adhering to the naming scheme. All administrators are aware of the procedures to follow in the event of exceptions to the naming scheme.

Table 5.4 provides fictitious names and hiring information for the new employees. The table also lists the administrative groups that must administer each account and the GPOs that apply to some of the accounts.

Table 5.4 New Hire List

User name User logon name Title Department Status Administrative group GPOs
Alboucq, Steve t-salbouc Representative Delivery Temp DelAdmin 1
Egert, Amy aegert Manager Human Resources Perm AdAdmin
Guo, Bei-Jing bguo Developer IT Perm ITAdmin
Hjellen, Robin rhjelle Representative Dispatch Perm DspAdmin
Koduri, Sunil skoduri Representative Delivery Perm DelAdmin
Lyon, Robert rlyon Representative Human Resources Perm HRAdmin
Lysaker, Jenny jlysake Representative Delivery Perm DelAdmin
Miksovsky, Jan t-jmiksov Representative Delivery Temp DelAdmin 1
Ota, Lani lota Representative Dispatch Perm DspAdmin
Ramirez, Francisco t-framire Representative Delivery Temp DelAdmin 1
Richardson, Miles mrichar System Administrator IT Perm DomainAdmins
Samarawickrama, Prasanna psamara Representative Delivery Perm Perm
Smith, James t-jasmith Representative Delivery Temp DelAdmin 1
Smith, Jeff jesmith Representative Delivery Perm DelAdmin
Smith, Jeff jsmith Representative Payroll Perm FinAdmin 4
Spencer, Phil pspence Representative Delivery Perm DelAdmin
Steiner, Alan asteine Manager Dispatch Perm DspAdmin
Thomas, Stephen t-sthomas Representative Delivery Temp DelAdmin 1
Van Dam, Tanya tvandam Representative Delivery Perm DelAdmin
Wood, John jwood Representative Dispatch Perm DspAdmin
Yim, Kevin kyim Manager Delivery Perm OpsAdmin

Figure 5.13 shows the OU structure diagram for the corp.dallas.c-100times.com domain.

Figure 5.13 OU structure diagram for corp.dallas.c-100times.com domain (Image Unavailable)

Table 5.5 is a list of administrative groups that can administer users in each OU.

Table 5.5 Administrative Groups in Consolidated Messenger OUs

OU Administrative groups
Operations SysAdmin
OpsAdmin
Distribution SysAdmin
OpsAdmin
DstAdmin
Dispatch SysAdmin
OpsAdmin
DspAdmin
Delivery SysAdmin
OpsAdmin
DelAdmin
Administration SysAdmin
AdAdmin
Finance SysAdmin
AdAdmin
FinAdmin
Payroll SysAdmin
AdAdmin
FinAdmin
IT SysAdmin
AdAdmin
ITAdmin
Human Resources SysAdmin
AdAdmin
HRAdmin
Sales SysAdmin
AdAdmin
SlsAdmin
Temp SysAdmin
TmpAdmin

Table 5.6 shows the new user accounts placed in the OU administered by the designated administrative group and the designated GPO.

Table 5.6 New User Accounts Placed in OUs

OU New user accounts
Operations mrichar (or Administration OU)
Dispatch rhjelle, lota, asteine, jwood
Delivery skoduri, jlysake, psamara, jesmith, pspence, tvandam, kyim
Temp t-salbouc, t-jmiksov, t-framire, t-jasmith, t-sthomas
Administration mrichar (or Operations OU)
Payroll jsmith
IT bguo
Human Resources aegert, rlyon

Naming and Defining Groups

Consolidated Messenger has selected a group naming scheme that ensures that unique group names are generated for all groups in the forest. Three years ago, the company instituted a naming scheme for administrative groups that uses a two- or three-letter abbreviation for the group followed by "Admin." User group names consist of one word that describes the group. Consolidated Messenger will continue to use the naming scheme. All administrators have been trained and recognize the importance of adhering to the naming scheme. All administrators are aware of the procedures to follow in the event of exceptions to the naming scheme.

Table 5.7 provides the job function and number of employees in each job function in Consolidated Messenger's Operations division.

Table 5.7 Consolidated Messenger Operations Division Employee Information

Job function Number of employees
Distribution Tracker 50
Distribution Handler 100
Domestic Dispatcher 50
International Dispatcher 25
Delivery Representative 200
Manager 10

Table 5.8 lists the information access requirements for various employee functions.

Table 5.8 Employee Access Requirements

Employee Need access to
Domestic Dispatchers, International Dispatchers, Managers Customer database, full access
Delivery Representatives Customer database, read-only access
All employees Company policies, read-only access
Distribution Trackers, Managers Tracking database, full access
Distribution Handlers Tracking database, read-only access
All employees Company announcements through e-mail
All employees, except Delivery Shared installation of Microsoft Office
Representatives applications
Managers, Managers from other domains Delivery time reports

To meet the needs listed in the table, Consolidated Messenger has planned the groups listed in Table 5.9.

Table 5.9 Consolidated Messenger Groups

Group name Type and scope Members
Trackers Security, global All Distribution Trackers
Handlers Security, global All Distribution Handlers
DomDispatchers Security, global All Domestic Dispatchers
IntDispatchers Security, global All International Dispatchers
DeliveryReps Security, global All Delivery Representatives
Managers Security, global All Managers
AllEmployees Security, global All employees
CustDatabase Security, domain local Domestic Dispatchers, International Dispatchers, Managers, Delivery Representatives
CompanyPol Security, domain local All employees
TrackDatabase Security, domain local Distribution Trackers, Managers, Distribution Handlers
MSOffice Security, domain local Distribution Trackers, Distribution Handlers, Domestic Dispatchers, International Dispatchers, Managers
DeliveryTimeReports Security, domain local Managers
E-mail Distribution, domain local All employees

The Consolidated Messenger network does not require universal groups because the information provided indicates that no groups need access to resources in multiple domains and also need to have members from multiple domains.

Lesson Summary

To begin this lesson, you were reminded that the purpose of defining OUs is to delegate administration, while the purpose of groups is to provide users with access to resources. In this lesson you learned how planning user accounts and groups is a two step-process: (1) naming and placing user accounts and (2) naming and defining groups. You learned how naming conventions help you and your users remember user logon names and locate them in lists. To place user accounts in the appropriate OUs, you must use the OU structure diagram to determine the user accounts administered by each administrative group and the user accounts affected by each GPO. You also learned how a consistent group naming convention will help you and your users remember group names and locate them in lists. To define the appropriate global, domain local, and universal groups, you identify the users to be assigned to various global groups, the resources to be assigned to various domain local groups, and the resources that are located in more than one domain to be assigned to universal groups.

Activity 5.2: Planning User Accounts

In this activity you will read about an organization that is planning its Active Directory infrastructure. Your task is to analyze the organization's environment to plan the user accounts needed in an Active Directory infrastructure.

Scenario: Dearing School of Fine Art

You are an infrastructure planner on the Active Directory infrastructure design team for the Dearing School of Fine Art (DSFA), an art school located in Washington, D.C. The business and technical environment analysis documents, the forest plan, the domain plan, and the OU structure diagram have already been compiled and copies have been distributed to everyone on the team. You are now in the process of planning the naming and placing of user accounts for new students in the fiber arts department.

While looking over the Technical Standards Worksheet, you find that DSFA has selected a user account naming scheme that ensures that unique user account names are generated for all users in the forest. This naming scheme uses the first eight letters of a user's first and last names. In case of the same first and last names, the user's middle initial is used. For part-time students, "PT-" will precede the user account name.

Table 5.10 provides fictitious names and enrollment information for the new students. The table also lists the administrative groups that must administer each account.

Table 5.10 New Student List

Student name Department Status Administrative group
Akhtar, Sarah Fiber Arts Part Time PTFiberAdmin
Barnhill, Josh Painting Full Time FTPaintAdmin
Berry, Jo Fiber Arts Full Time FTFiberAdmin
Dunn, Matthew Drawing Full Time CompArtAdmin
Dunn, Micheal Drawing Part Time PTDrawAdmin
Hart, Sherri Painting Full Time FTPaintAdmin
Jacobson, Lisa Drawing Full Time CompArtAdmin
Khanna, Karan Painting Full Time FTPaintAdmin
Phua, Meng Fiber Arts Full Time FTFiberAdmin
Schafer, Christina Painting Part Time PTPaintAdmin
Tobey, Chris Drawing Full Time FTDrawAdmin
Wolfe-Hellene, Marta Fiber Arts Part Time PTFiberAdmin
Young, Rob Drawing Full Time FTDrawAdmin

Your design team has created the OU structure diagram shown in Figure 5.14.

Figure 5.14 OU structure diagram for the Dearing School of Fine Art (Image Unavailable)

Table 5.11 is a list of administrative groups that can administer users in each OU.

Table 5.11 Administrative Groups in DSFA OUs

OU Administrative groups
FTUsers (Fiber Arts) SysAdmin
FiberAdmin
FTFiberAdmin
PTUsers (Fiber Arts) SysAdmin
FiberAdmin
PTFiberAdmin
FTUsers (Painting) SysAdmin
PaintAdmin
FTPaintAdmin
PTUsers (Painting) SysAdmin
PaintAdmin
PTPaintAdmin
FTUsers (Drawing) SysAdmin
DrawAdmin
FTDrawAdmin
PTUsers (Drawing) SysAdmin
DrawAdmin
PTDrawAdmin
Computer Art SysAdmin
DrawAdmin
CompArtAdmin

In the table below, place the new student accounts, by account name, in the appropriate OU.

to be completed

OU New student accounts
FTUsers (Fiber Arts)
PTUsers (Fiber Arts)
FTUsers (Painting)
PTUsers (Painting)
FTUsers (Drawing)
PTUsers (Drawing)
Computer Art

Answers

Activity 5.3: Planning Groups

In this activity you will read about an organization that is planning its Active Directory infrastructure. Your task is to analyze the organization's environment to plan the groups needed in an Active Directory infrastructure.

Scenario: The Ski Haus

You are an infrastructure planner on the Active Directory infrastructure design team for The Ski Haus, an international retailer of ski apparel. The Ski Haus uses two domains, one for resources at their Denver, Colorado, location and another for resources at their Geneva, Switzerland, location.

The Product Design department at each location maintains a separate database of ski hat designs. Product Design users at each location must have full control of the ski hat design database in their own domain. Product Design users at both locations must have read permissions on both ski hat design databases. Product Design users at both locations must have change permissions on the ski sweater design database in the Geneva location.

  1. Explain how your design team will use security groups to allow the Product Design users in each domain full control of the ski hat design databases in their domains.
  2. Explain how your design team will use security groups to allow the Product Design users in each domain read permission to the Denver and Geneva ski hat design databases.
  3. Explain how your design team will use security groups to allow all Product Design users in both domains change permission to the ski sweater design database in Geneva.

Answers

Lab 5.1: Defining an OU Structure and Security Groups

Lab Objectives

After completing this lab, you will be able to

  • Define an OU structure
  • Define security groups

About This Lab

In this lab, you will analyze portions of the existing environment at a medium-sized company to define an OU structure and security groups.

Before You Begin

Before you begin this lab, you must be able to

  • Analyze an organization's environment to define its OUs
  • Analyze an organization's environment to place user accounts
  • Analyze an organization's environment to define groups

Exercise 5.1: Defining an OU Structure

In this exercise, you will analyze the existing environment at a medium-sized company to define an OU structure and security groups. Review the scenario; then follow the instructions to define the OU structure and security groups.

Scenario

Your design team is planning the Active Directory infrastructure for Uncle Bob's Root Beer, a worldwide producer of a root beer soft drink. Uncle Bob's has four regional offices in Melbourne, Chicago, Berlin, and New Delhi. There are 107 bottling plants worldwide. The corporate headquarters is located in Melbourne. Each regional office has a human resources, finance, sales, production, and distribution department. In addition, Melbourne also has a new products department. Uncle Bob's infrastructure plan uses one domain.

While reading through the business and technical environment analysis documents, you note the following:

  • The IT management organization in each regional office administers user accounts and user desktop configurations, manages servers, and enforces network security.
  • At the corporate headquarters, some administrators have administrative authority over the entire network in order to complete performance and security audits.
  • In order to keep new products secure in the competitive soft drink industry, the New Products department has its own IT management organization that administers user accounts, manages users, and enforces network security.
  • Though the IT management organization in each regional office administers user accounts for the Production department, each Production department administers access to its servers.
  • All users in the company use the same e-mail and word processing applications.
  • The Distribution department at each regional office uses its own proprietary distribution tracking software.
  • The company requires that all human resources (HR) servers be hidden from non-HR personnel.
  • Each regional office staffs a help desk whose users are permitted to reset passwords.

Exercise Questions

Based on your notes, follow the instructions below to define an OU structure.

  1. Create an OU structure diagram for Uncle Bob's Root Beer that supports the needs indicated in the scenario.
  2. Complete the table below to document each OU in your design, the reason for creating it, and the users and computers that it contains.

to be completed

OU created Reason created Users and computers contained in the OU

Answers

Exercise 5.2: Defining Groups

In this exercise, you will design security groups to provide users with access to network resources.

Scenario

Your design team is planning the security groups needed in connection with the Production department at the Chicago regional office of Uncle Bob's Root Beer. Recall that the Production department has its own IT management organization to manage resources, including servers. Users from all departments and locations of the company must be able to access information on the servers in the Chicago Production department. The table below identifies the resources managed by the Production department, the users that require access to the resources, and the level of access they require.

Resource Users requiring access Access level
Formulas Chicago Production Server Administrators Full control
Formulas Chicago Production Managers Change
Formulas Chicago Production Specialists Read
Formulas All Production Managers company-wide Read
Production Logs Chicago Production Server Administrators Full control
Production Logs Chicago Production Managers Change
Production Logs Chicago Production Specialists Read
Production Logs Chicago Distribution Managers Read
Production Logs All Production Managers company-wide Read
Bottling Logs Chicago Production Server Administrators Full control
Bottling Logs Chicago Production Managers Change
Bottling Logs Chicago Production Specialists Read
Bottling Logs Chicago Distribution Managers Read
Bottling Logs All Production Managers company-wide Read
Customer Service Logs Chicago Production Server Administrators Full control
Customer Service Logs Chicago Production Managers Change
Customer Service Logs Chicago Production Specialists Read
Customer Service Logs Chicago Distribution Managers Read
Customer Service Logs All Production Managers company-wide Read
Customer Service Logs All Distribution Managers company-wide Read

Exercise Questions

Complete the table below to document your security group design. Include the name of each security group, the group scope, and the members of the group. Also note whether the members are individuals or list group names if the members are groups.

to be completed

Group Scope Members

Answers

Review

The following questions are intended to reinforce key information presented in the chapter. If you are unable to answer a question, review the appropriate lesson and then try the question again. Answers to the questions can be found in Appendix A,"Questions and Answers."

  1. Your design team is getting ready to define OU structures for your organization's Active Directory infrastructure design. What are the three reasons for defining an OU? What is the primary reason?
  2. Your design team has defined an OU to delegate control of user objects. You have diagrammed the desired OU, diagrammed a security group, and listed the administrators who require control of the user object class in the group. You want to allow the OU to set its own membership. Where should the administrator group be placed?
  3. Your design team has defined a forest, domains, and OUs. Where should user accounts be placed?
  4. Your design team is assigning users to groups. Which group scope is most often used to assign permissions to resources?
  5. Your organization is running Windows 2000 in native mode. The design team is adding users to groups. Why shouldn't the team add individual users to universal groups?

Answers

Read More Show Less

Table of Contents

About This Book   Page xiii
        Intended Audience   Page xiv
        Prerequisites   Page xiv
        Reference Materials   Page xv
        About the Supplemental Course Materials CD-ROM   Page xv
        Features of This Book   Page xvi
            Notes   Page xvi
            Conventions   Page xvi
            Chapter and Appendix Overview   Page xviii
            Finding the Best Starting Point for You   Page xx
            Getting Started   Page xxiv
        The Microsoft Certified Professional Program   Page xxxvi
            Microsoft Certification Benefits   Page xvii
            Requirements for Becoming a Microsoft Certified Professional   Page xxxix
            Technical Training for Computer Professionals   Page xl
        Technical Support   Page xli
            Evaluation Edition Software Support   Page xlii
CHAPTER 1  Introduction to Active Directory   Page 1
            About This Chapter   Page 1
            Before You Begin   Page 1
        Lesson 1: Active Directory Overview   Page 2
            Windows 2000 Active Directory   Page 2
            Active Directory Objects   Page 2
            Active Directory Components   Page 5
            Logical Structures   Page 5
            Physical Structure   Page 10
            Catalog Services-The Global Catalog   Page 12
            Lesson Summary   Page 16
        Lesson 2: Understanding Active Directory Concepts   Page 17
            Replication   Page 17
            Trust Relationships   Page 21
            Group Policy   Page 23
            DNS Namespace   Page 26
            Name Servers   Page 31
            Naming Conventions   Page 32
            Lesson Summary   Page 34
        Review   Page 36
CHAPTER 2  Introduction to Designing a Directory Services Infrastructure   Page 37
            About This Chapter   Page 37
            Before You Begin   Page 37
        Lesson 1: Design Overview   Page 38
            What Is an Active Directory Infrastructure Design?   Page 38
            Design Tools   Page 39
            The Design Process   Page 43
            Design Guiding Principles   Page 46
            Lesson Summary   Page 47
        Lesson 2: Analyzing the Current Business Environment   Page 48
            Analyzing the Current Business Environment   Page 48
            Analyzing Products and Customers   Page 49
            Analyzing Current Business Structure   Page 52
            Analyzing Current Business Processes   Page 57
            Analyzing Business Strategy Influences   Page 63
            Analyzing the Information Technology Management Organization   Page 66
            Lesson Summary   Page 69
        Lesson 3: Analyzing the Current Technical Environment   Page 70
            Analyzing the Current Technical Environment   Page 70
            Analyzing the Current Network Architecture   Page 72
            Analyzing the Current Hardware and Software   Page 74
            Analyzing the Current Technical Standards   Page 77
            Analyzing the Current DNS Environment   Page 80
            Analyzing the Current Windows NT Domain Architecture   Page 82
            Lesson Summary   Page 83
        Lab 2.1: Analyzing Business Environment   Page 84
            Lab Objectives   Page 84
            About This Lab   Page 84
            Before You Begin   Page 84
            Exercise: Analyzing a Current Business Structure   Page 84
        Review   Page 88
CHAPTER 3  Creating a Forest Plan   Page 89
            About This Chapter   Page 89
            Before You Begin   Page 90
        Lesson 1: Designing a Forest Model   Page 91
            Understanding Forests   Page 91
            Design Step: Designing a Forest Model   Page 92
            Design Step Example: Designing a Forest Model   Page 96
            Lesson Summary   Page 97
        Activity 3.1: Designing a Forest Model   Page 98
            Scenario: Adventure Works   Page 98
        Lesson 2: Designing a Schema Modification Plan   Page 100
            Understanding the Schema   Page 100
            Design Step: Designing a Schema Modification Plan   Page 105
            Design Step Example: Designing a Schema Modification Plan   Page 111
            Lesson Summary   Page 112
        Lab 3.1: Creating a Forest Model and Schema Modification Plan   Page 113
            Lab Objectives   Page 113
            About This Lab   Page 113
            Before You Begin   Page 113
            Exercise 1: Designing a Forest Model   Page 113
            Exercise 2: Designing a Schema Modification Plan   Page 114
        Review   Page 116
CHAPTER 4  Creating a Domain Plan   Page 119
            About This Chapter   Page 119
            Before You Begin   Page 120
        Lesson 1: Defining Domains   Page 121
            Understanding Domains   Page 121
            Design Step: Defining Domains   Page 123
            Design Step Example: Defining Domains   Page 128
            Lesson Summary   Page 130
        Activity 4.1: Defining Domains   Page 131
            Scenario 1: Friendship Vineyards   Page 131
            Scenario 2: Awesome Computers   Page 132
        Lesson 2: Defining a Forest Root Domain   Page 135
            Understanding the Forest Root Domain   Page 135
            Design Step: Defining a Forest Root Domain   Page 136
            Design Step Example: Defining a Forest Root Domain   Page 139
            Lesson Summary   Page 140
        Lesson 3: Defining a Domain Hierarchy   Page 141
            Understanding Domain Hierarchies   Page 141
            Design Step: Defining a Domain Hierarchy   Page 145
            Design Step Example: Defining a Domain Hierarchy   Page 148
            Lesson Summary   Page 149
        Lesson 4: Naming Domains   Page 150
            Understanding Domain Names   Page 150
            Design Step: Naming Domains   Page 151
            Design Step Example: Naming Domains   Page 153
            Lesson Summary   Page 154
        Activity 4.2: Defining a Root Domain, Defining a Domain Hierarchy, and Naming Domains   Page 155
            Scenario 1: Friendship Vineyards   Page 155
            Scenario 2: Awesome Computers   Page 158
        Lesson 5: Planning DNS Server Deployment   Page 161
            Understanding DNS Servers   Page 161
            Design Step: Planning DNS Server Deployment   Page 169
            Design Step Example: Planning DNS Server Deployment   Page 172
            Lesson Summary   Page 172
        Lab 4.1: Creating a Domain Plan   Page 174
            Lab Objectives   Page 174
            About This Lab   Page 174
            Before You Begin   Page 174
            Exercise: Creating a Domain Plan   Page 174
        Review   Page 179
CHAPTER 5  Creating an Organizational Unit Plan   Page 181
            About This Chapter   Page 181
            Before You Begin   Page 182
        Lesson 1: Defining OU Structures   Page 183
            Understanding OUs   Page 183
            Design Step: Defining OU Structures   Page 193
            Design Step Examples: Defining OU Structures   Page 198
            Lesson Summary   Page 202
        Activity 5.1: Defining OU Structures   Page 203
            Scenario: Arbor Shoes   Page 203
        Lesson 2: Planning User Accounts and Groups   Page 205
            Understanding Users and Groups   Page 205
            Design Step: Planning User Accounts and Groups   Page 209
            Design Process Examples: Planning User Accounts and Groups   Page 215
            Lesson Summary   Page 222
         Activity 5.2: Planning User Accounts   Page 223
            Scenario: Dearing School of Fine Art   Page 223
        Activity 5.3: Planning Groups   Page 227
            Scenario: The Ski Haus   Page 227
        Lab 5.1: Defining an OU Structure and Security Groups   Page 228
            Lab Objectives   Page 228
            About This Lab   Page 228
            Before You Begin   Page 228
            Exercise 5.1: Defining an OU Structure   Page 228
            Exercise 5.2: Defining Groups   Page 230
        Review   Page 233
CHAPTER 6  Creating a Site Topology Plan   Page 235
            About This Chapter   Page 235
            Before You Begin   Page 236
        Lesson 1: Defining Sites   Page 237
            Understanding Sites   Page 237
            Design Step: Defining Sites   Page 238
            Design Step Example: Defining Sites   Page 240
            Lesson Summary   Page 242
        Lesson 2: Placing Domain Controllers in Sites   Page 243
            Understanding Domain Controller Placement   Page 243
            Design Step: Placing Domain Controllers   Page 245
            Design Step Example: Placing Domain Controllers   Page 247
            Lesson Summary   Page 248
        Activity 6.1: Defining Sites and Placing Domain Controllers in Sites   Page 249
            Scenario: Ramona Publishing   Page 249
        Lesson 3: Defining a Replication Strategy   Page 251
            Understanding Replication   Page 251
            Design Step: Defining a Replication Strategy   Page 258
            Design Step Example: Defining a Replication Strategy   Page 261
            Lesson Summary   Page 263
        Lesson 4: Placing Global Catalog Servers and Operations Masters   Page 264
            Understanding Global Catalog Servers   Page 264
            Understanding Operations Masters   Page 265
            Design Step: Placing Global Catalog Servers and Operations Masters   Page 267
            Design Step Example: Placing Global Catalog Servers and Operations Masters   Page 271
            Lesson Summary   Page 273
        Activity 6.2: Using Active Directory Sizer   Page 275
            Scenario: Margo Tea Company   Page 275
        Lab 6.1: Creating a Site Topology Plan   Page 278
            Lab Objectives   Page 278
            About This Lab   Page 278
            Before You Begin   Page 278
            Exercise: Creating a Site Topology Plan   Page 278
        Review   Page 281
CHAPTER 7  Creating an Active Directory Implementation Plan   Page 283
            About This Chapter   Page 283
            Before You Begin   Page 284
        Lesson 1: Planning a Migration from Windows NT 4 Directory Services to Windows 2000 Active Directory   Page 285
            Understanding Migration   Page 285
            Design Step: Planning a Windows NT 4 Directory Services Migration to Windows 2000 Active Directory   Page 294
            Design Step Example: Planning a Windows NT 4 Directory Services Migration to Windows 2000 Active Directory   Page 302
            Lesson Summary   Page 308
        Lesson 2: Planning Directory Service Synchronization with Active Directory   Page 309
            Understanding Directory Service Synchronization   Page 309
            Design Step: Planning Directory Service Synchronization with Active Directory   Page 314
            Design Step Example: Planning Directory Service Integration with Active Directory   Page 322
            Lesson Summary   Page 325
        Lab 7.1: Planning a Windows NT 4 Directory Services Migration to Windows 2000 Active Directory   Page 326
            Lab Objectives   Page 326
            About This Lab   Page 326
            Before You Begin   Page 326
            Exercise: Planning a Windows NT 4 Directory Services Migration to Windows 2000 Active Directory   Page 326
        Review   Page 329
Appendix A  Questions and Answers  Page 331
Appendix B  Base Schema Class Objects  Page 369
Appendix C  Base Schema Attribute Objects  Page 375
Glossary  Page 409
Index  Page 437
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)