Tài liệu Module 7: Planning Server Roles and Placement pptx

Contents
Overview 1
Introduction to Planning Server Roles
and Placement 2
Planning Mailbox Servers and Public Folder
Servers 3
Planning Connector Servers 9
Planning Front-end/Back-end Servers 12
Planning for Servers Running Active
Directory 17
Discussion: Planning Server Placement 21
Lab A: Identifying Server Roles and
Placement 22
Lab B: Implementing Front-end Load
Balancing 29
Lab C: Implementing a Front-end Server 35
Lab D: Implementing a Public Folder
Server 39
Lab Discussion 44

Module 7: Planning
Server Roles and
Placement

Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying

with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.


2001 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, BackOffice, FrontPage, NetMeeting, Outlook, PowerPoint,
SQL Server, Visio, Visual Studio, Win32, Windows, Windows Media, and Windows NT are either
registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.

Other product and company names mentioned herein may be the trademarks of their respective
owners.


Module 7: Planning Server Roles and Placement iii

Instructor Notes
This module provides students with the knowledge required to determine how
many servers their Microsoft
®
Exchange 2000 organization requires.
After completing this module, students will be able to:
!"

Plan mailbox servers and public folder servers.
!"
Plan connector servers.
!"
Plan front-end/back-end servers.
!"
Plan servers running the Microsoft
®
Active Directory
™
directory service.
!"
Identify the factors to be considered when designing server placement.

Materials and Preparation
This section provides the materials and preparation tasks that you need to teach
this module.
Required Materials
To teach this module, you need the following materials:
!"
Microsoft PowerPoint
®
file 1573A_07.ppt
!"
The Exchange 2000 & DS Topology Calculator job aid
!"
The Northwind Traders Case Study

Preparation Tasks
To prepare for this module, you should:

!"
Read all of the materials for this module.
!"
Complete the labs and the lab discussion questions.
!"
Read the following white papers, located under Additional Readings on the
Student Materials compact disc:
•
“E2K_FEScalability”
•
“E2KBackEnd_Scalability”
•
“Tuning”
•
“CalcPlan”
!"
Practice using the Exchange 2000 & DS Topology Calculator job aid.
!"
Review the Northwind Traders Case Study.


The job aids are in the Exchange 2000 Design Tool located at
C:\MOC\1573A\LabFiles\Exchange_2000_Design_Tool, and on the student
compact disc. The case studies are in the Appendices and on the student
compact disc.


Presentation:
60 Minutes

Lab:
95 Minutes
Note
iv Module 7: Planning Server Roles and Placement

Module Strategy
Use the following strategy to present this module:
!"
Planning Mailbox Servers and Public Folder Servers
Begin by making sure that the students understand the function of each type
of server. Continue by discussing capacity planning guidelines for each
server. Next, discuss the planning considerations that are associated with
mailbox servers and public folder servers. Complete the module by
explaining how to plan storage needs and partition databases.
!"
Planning Connector Servers
Make sure that the students understand the function of a connector server.
Explain each planning consideration, and then discuss the server
specifications for Simple Mail Transfer Protocol (SMTP) connector servers.
!"
Planning Front-end/Back-end Servers
Begin by discussing the advantages of using a front-end/back-end server
topology. Next, explain the server specifications for Post Office Protocol
version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4),
and Microsoft Outlook Web Access front-end servers.
!"
Planning for Servers Running Active Directory
Begin by making sure that the students understand how global catalog
servers and domain controllers function. Next, explain how to determine the
number of global catalog servers that a company needs. Finish this topic by

explaining how to place global catalog servers and domain controllers in an
Exchange 2000 organization.
!"
Discussion: Planning Server Placement
This topic presents a scenario, and then asks the students to discuss the
server placement options and design considerations that the company in the
scenario should take into account when planning where to place their
servers.

Module 7: Planning Server Roles and Placement v

Customization Information
This section identifies the lab setup requirements for a module and the
configuration changes that occur on student computers during the labs. This
information is provided to assist you in replicating or customizing Microsoft
Official Curriculum (MOC) courseware.
Lab Setup
The following list describes the setup requirements for the labs in this module.
!"
For each student, a Microsoft Management Console (MMC) custom console
must be created. This custom console must include both the
Active Directory Users and Computers snap-in and the Exchange System
snap-in, and must be named your_firstname Console.
!"
For each student, a personalized user account must be created in the
appropriate domain. This user account must be added to the Domain
Admins group, and assigned a mailbox on the server running
Exchange 2000 that the student is using.
!"
For each student, a user profile must be created on the student’s computer

that enables the student to access their mailbox by using Microsoft
Outlook
®
2000.
!"
The students sitting at the City-MBX1 computers will need the
IMAP4Stresser application that is located at c:\moc\1573a\labfiles

Lab Results
Performing the labs in this module introduces the following configuration
changes:
!"
Network Load Balancing is configured for the City-FE1 and City-FE2
servers.
!"
DNS is configured to have a front-end namespace for each routing group.
!"
The City-FE1 and City-FE2 servers in each routing group are converted to
front-end servers.
!"
All mailboxes are moved from the City-FE1, City-FE2, and City-PF1
servers to the City-MBX1 server in each routing group.
!"
The City-MBX1 server in each routing group is configured so that the
private information store databases point to the City-PF1 server in it’s
routing group.


Module 7: Planning Server Roles and Placement 1

Overview
!
Introduction to Planning Server Roles and Placement
!
Planning Mailbox Servers and Public Folder Servers
!
Planning Connector Servers
!
Planning Front-end/Back-end Servers
!
Planning for Servers Running Active Directory
!
Discussion: Planning Server Placement


Microsoft
®
Exchange 2000 organizations designed for the enterprise usually
deploy several different servers. Although it is possible to install the entire
functionality of Exchange 2000 on a single server, it is usually better to
distribute the functions among several servers. Architects designing an
Exchange 2000 organization need to be able to identify and plan for the
deployment of each of the types of servers that a company needs.
In addition to identifying server roles, the necessary planning tasks include
determining the number of each type of server that a company requires, as well
as where to place each server. To complete these tasks, you must understand the
various roles of the different types of servers, and of the design effects
associated with their deployment.
After completing this module, you will be able to:
!"

Plan mailbox servers and public folder servers.
!"
Plan connector servers.
!"
Plan front-end/back-end servers.
!"
Plan servers running the Microsoft
®
Active Directory
™
directory service.
!"
Identify the factors to be considered when designing server placement.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about the Exchange 2000
server roles, and how to
plan and place servers for
an effective Exchange 2000
organization.
2 Module 7: Planning Server Roles and Placement

Introduction to Planning Server Roles and Placement
User
Internet Front End

Servers
Back End
Servers
Mailbox Server Connector Server Internet
User
Mailbox Server
Public Folder Server


Although each server running Exchange 2000 often performs several roles in a
smaller organization or in a remote office, it is often preferable to dedicate
servers to perform specific roles.
Distributing functions among several different servers enables you to provide
faster response time and reduced downtime. Distributing roles also helps
prevent servers from becoming overloaded, and removes the dependencies
between services.
Planning server roles and placement will help you decide which hardware to
purchase and will affect the performance of your messaging system. It is
important to have your budget settled prior to planning your server roles,
because dedicating servers to specific roles may significantly increase the
number of servers that you will need to purchase.
Topic Objective
To outline the different types
of servers that a company
may deploy.
Lead-in
There are several ways to
deploy servers running
Exchange 2000.
Module 7: Planning Server Roles and Placement 3

#
##
#

Planning Mailbox Servers and Public Folder Servers
!
Capacity Planning
!
Planning Considerations
!
Planning Storage Needs
!
Partitioning Databases


Developing an effective design strategy for mailbox servers and public folder
servers involves taking into account the capacity that each server can handle, as
well as such considerations as service level agreements, retention policies, and
storage needs.
Topic Objective
To outline the design
considerations that are
associated with planning
mailbox and public folder
servers.
Lead-in
There are several design
considerations to take into
account when planning

mailbox and public folder
servers.
4 Module 7: Planning Server Roles and Placement

Capacity Planning
Storage limits
Time required to perform a backup
Time required to recover from a disaster
Time required to restore a single database
Time required to restore a single mailbox
Capacity Planning for Mailbox Servers
Capacity Planning for Mailbox Servers
Capacity Planning for Mailbox Servers
Service levels
Response time
Capacity Planning for Public Folder Servers
Capacity Planning for Public Folder Servers
Capacity Planning for Public Folder Servers


The number of users and public folders that each server can support depends
primarily on the usage profile for each user.
Mailbox Servers
The most important factors to consider when calculating the number of
mailboxes to store on each server are: the storage limits, the time required to
perform a backup, the time to recover from a disaster, the time to restore a
single database, and the time to restore a single mailbox.
Public Folder Servers
Service levels and response time are the primary factors to consider when
determining whether to dedicate a server to public folder storage. For example,

if your company builds custom applications into multiple public folder
hierarchies, it is recommended that you place these hierarchies on a separate
server so that people gaining access to these custom application folders do not
increase the response time for people checking their mailboxes.
Topic Objective
To provide capacity
planning information for
mailbox and public folder
servers.
Lead-in
The number of users and
public folders that each
server can support depends
primarily on the usage
profiles for each user.
Module 7: Planning Server Roles and Placement 5

Planning Considerations
What is the default storage limit on mailboxes?
What is the default storage limit on mailboxes?
What is the retention policy for deleted items?
What is the retention policy for deleted items?
Which protocols are enabled for mail?
Which protocols are enabled for mail?
How many mailboxes on each server are related to service level
agreements with customers?
How many mailboxes on each server are related to service level
agreements with customers?
How long will data be stored on the server?
How long will data be stored on the server?

Although Exchange 2000 does not impose a limit on the number of mailboxes
or public folders that can reside on any one server, you must consider storage
limits, data storage, retention policies, protocols, and service level agreements
when planning mailbox servers and public folder servers:
Default Storage Limit on Mailboxes
The default storage limit on mailboxes, combined with the number of users that
you support, will help you to determine how many mailbox servers you need.
For example, if you have 500 users, and if you limit each user mailbox to a
maximum size of 50 megabytes (MB), then you need to plan for a minimum of
25 gigabytes (GB) of mailbox space.
Storing Data
You can control the amount of data that is stored on a server by using tools such
as the Mailbox Cleanup Agent to search databases and to delete old messages.
You can also configure Post Office Protocol version 3 (POP3) and Internet
Message Access Protocol version 4 (IMAP4) client applications to move
retrieved messages to their local client. The less data you store on your server,
the less storage space you need.
Retention Policy
If you want to archive or to retain deleted items, you need to develop a retention
policy that accounts for the additional space that you will require. Consider the
average size of the messages that your users receive, as well as the average
number of messages that users delete per day.
Protocols
If you enable users to use POP3, IMAP4, or Microsoft Outlook
®
Web Access to
retrieve mailbox data, then you may need to configure servers in a
front-end/back-end configuration so that you can remove all authentication and

offload processing tasks from the mailbox server.
Topic Objective
To outline the planning
considerations that are
related to mailbox and
public folder server roles
and placement.
Lead-in
There are several
considerations to take into
account when planning
mailbox and public folder
servers.
6 Module 7: Planning Server Roles and Placement

Service Level Agreements
You must consider the number of mailboxes on each server that are related to
service level agreements. If large mailbox stores exist, consider splitting each of
them into several smaller ones. In the past, service level agreements often
required the deployment of multiple servers to ensure recovery within the time
constraints of the service level agreement. Creating multiple storage groups and
databases enables you to consolidate these servers into one larger server that
has multiple mailbox stores and databases.
Module 7: Planning Server Roles and Placement 7

Planning Storage Needs
Servers
First Storage Group
Default Mailbox Store
Executives

Second Storage Group
News Store
Third Storage Group
Public Folders
Server 1


You can use storage groups to store data on your mailbox servers and on your
public folder servers.
Microsoft Exchange 2000 Enterprise Server supports a maximum of four
storage groups with a maximum of five databases in each storage group. Each
mailbox and each public folder store is a member of a storage group. All
mailboxes and all public folder stores in each storage group share a single set of
transaction log files. You can place one or more storage groups on each server.
The following table outlines a possible Exchange 2000 store configuration.
Storage Group Database

First storage group User mailbox store and Executives
mailbox store
Second storage group Network news
Third storage group Public folders

Creating Multiple Storage Groups
If you plan to create multiple storage groups on one server, make sure that you
can place the transaction logs and the database onto separate disk spindles. The
primary reasons for separating the transaction logs from the database are to
increase performance while logging transactions, and to take advantage of
sequential writes. Storing transaction log files on their own dedicated disk
spindle also aids in the database recovery process. If your transaction log files
are stored on their own dedicated disk spindle, and if you have circular logging

disabled, then if a database associated with those transaction log files becomes
damaged, it is possible to recover all data that was entered up to the time when
the database became damaged.
Topic Objective
To outline the storage
requirements that are
associated with mailbox
servers and public folder
servers.
Lead-in
You can use storage groups
to store the data on your
mailbox servers and on your
public folder servers.
Delivery Tip
Have the students discuss
alternative storage group
options to those outlined in
the table on this page.
8 Module 7: Planning Server Roles and Placement

Partitioning Databases
!
Makes database management easier and more logical
!
Reduces the effects of a malfunctioning database
Storage Group 2Storage Group 1
Mailbox Server

If you do not have enough disk drives available, you can store all of your
databases on the same partition. However, if you do have enough disk space to
allow for placing separate databases on separate partitions, it is recommended
that you do so.
Placing database files from different storage groups on separate partitions:
!"
Makes database management easier and more logical.
!"
Reduces the effects of a malfunctioning database. If the drive array that
houses one storage group of databases goes offline, the failure will not
affect databases in any other storage group.
If you distribute databases from multiple storage groups over a single drive
array, and that drive array goes offline, then all databases associated with
those storage groups will go offline temporarily, even if some of those
databases are located on other arrays. The damaged database will be marked
as down, and the working databases will remount. Ordinarily, this type of
outage will only last for a few minutes. At the end of that period, Messaging
Application Programming Interface (MAPI) clients such as

Outlook will
recover their connections.

Topic Objective
To explain how to partition
databases.
Lead-in
There are several reasons
for storing database files
from separate storage
groups on separate

partitions.
Module 7: Planning Server Roles and Placement 9

#
##
#

Planning Connector Servers
!
Planning Considerations
!
Server Specifications for SMTP Connector Servers


There are several planning considerations, as well as several server
specifications, that you must take into account when deciding whether or not to
dedicate connector servers.
Topic Objective
To outline the design
considerations that are
associated with using
bridgehead servers.
Lead-in
There are several planning
considerations, as well as
several server
specifications, that you must
take into account when
deciding whether or not to
dedicate connector servers.

10 Module 7: Planning Server Roles and Placement

Planning Considerations
Frequency of Connector User
Frequency of Connector User
Routing Topology
Routing Topology
Internet Connectivity
Internet Connectivity
Number of Messages Sent between Routing Groups
Number of Messages Sent between Routing Groups


Connector servers route mail messages and public folder information. Consider
each of the following factors before dedicating a connector server to a routing
group:
!"
Frequency of connector use
In addition to how many routing groups are being connected, consider how
frequently the connector will be used. How frequently a connector will be
used is determined largely by its cost. For example, if you have an X.400
connector that connects a routing group to a foreign system with a cost
of 100, do not dedicate a bridgehead server to that routing group.
!"
Routing topology
If you use a hub-and-spoke topology, you must dedicate enough bridgehead
servers to accommodate the message flow between all of your routing
groups. Link cost is not an issue in this case, because all messages must
travel through the hub.
If you use a full-mesh topology, you should not need as many connector

servers as you would with a hub-and-spoke topology, because in a full-mesh
topology all messages are routed directly from the originating routing group
to the destination routing group.
!"
Internet connectivity
Many companies prefer to dedicate a connector server to Internet
connectivity to ensure that Internet message activity is never slowed down
or interrupted. In addition, you can use virus scanners to filter messages and
information that are being routed through bridgehead servers.
!"
Number of messages sent between routing groups
If the majority of internal messages are sent between users in different
routing groups, dedicate a bridgehead server to each routing group in which
you expect heavy mail usage. If most messages will be sent between users
in the same routing group, you probably do not need to dedicate a specific
bridgehead server for that routing group.
Topic Objective
To outline the planning
considerations that are
related to connector servers.
Lead-in
There are several factors
that you must consider
before dedicating a
connector server to a
routing group.
Module 7: Planning Server Roles and Placement 11

Server Specifications for SMTP Connector Servers
Processor

Disk Space
Memory
Network
Connectivity
SMTP Connector Server


The following list provides general hardware recommendations for a dedicated
Simple Mail Transfer Protocol (SMTP) connector server:
!"
Processor. Scales well to four-processor servers, but not to eight-processor
servers.
!"
Memory. Requires a minimum of 256 MB of random access memory
(RAM) to manage large queues and to expand distribution lists. 512 MB of
RAM or higher is recommended.
!"
Disk space. Requires a large number of disk resources; at least seven disk
writes are required for each message that is queued. The drive that contains
the queue on high-end servers should be configured as Redundant Array of
Independent Disks (RAID) 0+1 and should have multiple disk spindles that
make use of a write-caching array controller.
!"
Network connectivity. Two-processor servers require a single 100 megabit-
per-second (Mbps) connection. Four-processor servers should be fitted
either with two 100-Mbps connections or with a single Gigabit Ethernet
connection.


For more detailed information about SMTP connector server scalability,

see Microsoft Exchange 2000 Front-End Server and SMTP Gateway Hardware
Scalability Guide under Additional Readings on the Student Materials
compact disc.

Topic Objective
To present the server
specifications for SMTP
connector servers.
Lead-in
You can reduce
implementation and
maintenance costs by using
the same hardware platform
for all of your connector
servers.
Note
12 Module 7: Planning Server Roles and Placement

#
##
#

Planning Front-end/Back-end Servers
!
Advantages of Using a Front-end/Back-end Topology
!
Server Specifications


Consider planning a front-end/back-end server topology if your company

deploys multiple servers running Exchange 2000, if those servers use Outlook
Web Access, POP3, or IMAP4, and if your company provides Outlook Web
Access, POP3, or IMAP4 access to their employees over the Internet.
Topic Objective
To discuss the planning
issues associated with using
front-end/back-end servers.
Lead-in
Using a front-end/back-end
server topology is a good
idea for companies that use
Outlook Web Access,
POP3, and IMAP4 in a
multiple server environment.
Module 7: Planning Server Roles and Placement 13

Advantages of Using a Front-end/Back-end Topology
Front-end
Exchange 2000 Servers
Client
mail.nwtraders.msft
Authentication, and directory
look-up for back-end server
Authentication, and directory
look-up for back-end server
Mailbox
Mailbox
Mailbox

In a front-end/back-end server topology, each front-end server determines
which back-end server stores the requested resource by using the Lightweight
Directory Access Protocol (LDAP) to query the Microsoft Windows
®
2000
Active Directory directory service.
Implementing a front-end/back-end server topology provides:
!"
A single namespace. The primary advantage of a front-end/back-end server
architecture is that it provides a single consistent namespace for each user.
You can define a single namespace for users that enables them to gain
access to their mailboxes. With a single namespace, users can use the same
Uniform Resource Locator (URL) or POP3 and IMAP4 client configuration,
even when servers are added and removed, or when mailboxes are moved
from one server to another server. In addition, creating a single namespace
ensures that Outlook Web Access, POP3, and IMAP4 access remains
scalable as the Exchange 2000 organization grows.
!"
Offload processing. Front-end servers can handle all encryption and
decryption processing. This improves performance by removing processing
tasks from back-end servers while still allowing the data to be encrypted
between the client computer and the Exchange 2000 servers. In addition,
you can offload Hypertext Transfer Protocol (HTTP) compression to the
front-end servers, which enables client computers in low-bandwidth
environments to retrieve data much more quickly, and improves network
availability.
Topic Objective
To present the advantages
of using front-end/back-end
servers.

Lead-in
There are several
advantages associated with
deploying a front-end/back-
end server topology.
14 Module 7: Planning Server Roles and Placement

!"
Load balancing. If you implement the Windows 2000 Network Load
Balancing Service on each of your front-end servers, you can load balance
the processing of your front-end servers. This service allows you to group as
many as 32 servers in a single namespace.
!"
Strengthened security. You can position each front-end server as the single
point of access either on or behind an Internet firewall that is configured to
allow traffic from the Internet to the front-end server only. Because the
front-end server does not store user information, it provides an additional
layer of security. Also, you can configure the front-end server to
authenticate requests before proxying them, which protects the back-end
servers from security breaches.

Module 7: Planning Server Roles and Placement 15

Server Specifications
POP3 Front-end Server
IMAP4 Front-end Server
Outlook Web Access
Front-end Server
!
Processor

!
Memory
!
Disk Space
!
Network
Connectivity


Front-end server configuration depends on several factors, including the
number of users per back-end server, the protocols used, and the expected rate
of use. As a general rule, one front-end server for every four back-end servers is
adequate. You should also plan to include at least two front-end servers in your
design for purposes of redundancy and load balancing. Consider the following
hardware recommendations for POP3, IMAP4 and Outlook Web Access front-
end servers.
POP3 Front-end Server
!"
Processor. POP3 scales well to 2-processor servers, but is not recommended
for 4-processor servers.
!"
Memory. 256 MB of RAM is sufficient for nearly all applications.
!"
Disk space. POP3 uses virtually no disk resources, unless the server is
paging or POP3 protocol logging is turned on.
!"
Network connectivity. If run on a high-end, 800-MHz, 2-processor server,
POP3 requires either a second 100-Mbps network interface card (NIC) or a
Gigabit Ethernet connection.
!"

It is recommended that you use a ratio of one front-end server to four back-
end servers.
!"
If all connections will be performed over Secure Sockets Layer (SSL), then
the processor capacity of a POP3 front-end server should be doubled.

Topic Objective
To discuss the server
specifications that are
associated with front-end
and back-end servers.
Lead-in
As a general rule, one front-
end server for every four
back-end servers is
adequate.
16 Module 7: Planning Server Roles and Placement

IMAP4 Front-end Server
!"
Processor. IMAP4 scales well to 2-processor servers.
!"
Memory. IMAP4 requires a minimum of 256 MB of RAM. However, if you
are using a front-end server that services more than five back-end servers,
you should use at least 512 MB of RAM.
!"
Disk space. IMAP4 uses virtually no disk resources, unless the front-end
server is paging, or unless IMAP4 protocol logging is turned on.
!"
Network connectivity. A single 100-Mbps full duplex network connection is

sufficient for most front-end applications. Depending on the type of users
that you plan to service and the number of back-end servers to be serviced,
it may be necessary to add an additional 100-Mbps full duplex NIC, or to
move to a gigabit-based network.
!"
As a general rule, use a ratio of one IMAP4 front-end server to eight back-
end servers.
!"
SSL connections generate a 50 percent increase in CPU activity, and require
an additional 10 percent of physical memory.

Outlook Web Access Front-end Server
!"
Processor. Outlook Web Access scales well to 4-processor servers.
!"
Memory. An Outlook Web Access front-end server uses approximately 30
KB of RAM per active connection.
!"
Disk space. Outlook Web Access uses virtually no disk resources, unless the
front-end server is paging, or unless HTTP Distributed Authoring and
Versioning (HTTP-DAV) protocol logging is turned on.
!"
Network connectivity. If Outlook Web Access is servicing over 5,000
connections, then it requires a second 100-Mbps NIC.
!"
As a general rule, use a ratio of one front-end server to four back-end
servers.
!"
Outlook Web Access SSL connections require up to 3 times more
processing power and 60 percent more memory on their front-end server.

For more detailed information about front-end server scalability, see
Microsoft Exchange 2000 Front-End Server and SMTP Gateway Hardware
Scalability Guide under Additional Readings on the Web page on the Student
Materials compact disc.

Note
Module 7: Planning Server Roles and Placement 17

#
##
#

Planning for Servers Running Active Directory
!
Placing Domain Controllers
!
Determining the Number of Global Catalog Servers
!
Placing Global Catalog Servers


Identifying the Active Directory domain controller and global catalog server
requirements for Exchange 2000 requires an understanding of how client
applications and servers gain access to information stored in the Active
Directory database.
Topic Objective
To outline the factors that
must be considered in

planning the number and
placement of Active
Directory servers.
Lead-in
If at all possible, it is a good
idea to plan your Active
Directory servers before you
install Exchange 2000.
18 Module 7: Planning Server Roles and Placement

Placing Domain Controllers
Domain
Controller
Exchange 2000
Exchange 2000
Exchange 2000
Domain
Controller
Domain 2
Domain 1
Windows 2000 Site


Exchange 2000 uses domain controllers running Active Directory to
authenticate the credentials of users who are attempting to gain access to their
mailboxes. There must be at least one domain controller in each domain. Each
domain controller contains a complete replica of the domain naming context for
the domain to which it belongs, as well as complete replicas of the
configuration naming context and the schema naming context for the entire
forest. Architects need to consider how the domain controllers will be placed in

an Exchange 2000 organization.
In a two-tier domain topology, where servers running Exchange 2000 are
located in one domain and the users whose mailboxes are located on those
servers are located in the other domains, you can improve performance by
locating a domain controller for the root domain in each of the child domains’
physical locations or sites. This way, the ticket-referral process is completed
locally, and only the session ticket is presented across the wide area network
(WAN).
Topic Objective
To explain the placement of
domain controllers.
Lead-in
Exchange 2000 uses
domain controllers running
Active Directory to
authenticate the credentials
of users who are attempting
to gain access to their
mailboxes. There must be at
least one domain controller
in each domain.
Module 7: Planning Server Roles and Placement 19

Determining the Number of Global Catalog Servers
Northwind Traders
General directory searches by
users and applications
User principle name logon requests
Universal group membership
enumeration

Queries from a server running
Exchange 2000
Calculations
Calculations
Calculations
Assessment
Access Hardware
Assessment
Assessment
Access Hardware
Access Hardware
Global Catalog
Servers


Like the sizing and placement of domain controllers, the sizing and placement
of global catalog server depends on several factors in addition to the
requirements of Exchange 2000. In an Exchange 2000 environment, the global
catalog server is generally accessed for:
!"
General directory searches by users and applications. An example of a
general directory search is a user looking up an address within the Global
Address List.
!"
User principle name logon requests from a domain controller.
!"
Universal group membership enumeration.
!"
Queries from a server running Exchange 2000.

Because the domain partition is not replicated between domains, the global
catalog provides visibility to objects across domains. In addition to storing and
replicating a complete set of all objects in the directory for reference by its own
host domain, a global catalog server stores and replicates a partial replica of the
domain directory partition for reference by all other domains in the forest.
Queries to the Global Catalog Server
By default, the partial set of attributes stored in the global catalog includes
those attributes most frequently used by Exchange 2000 users. Most Active
Directory queries from Exchange 2000 messaging clients are made to the global
catalog server. Servers running Exchange 2000 also query the global catalog
server for recipient information.
For example, when Outlook 2000 users look up addresses of other users in their
organization, the information comes from the global address list (GAL). The
GAL is built by Exchange 2000, which queries the global catalog server. When
a client computer requests specific user information, the query is sent to a
specific global catalog server.

Topic Objective
To outline the process of
calculating the number of
global catalog servers that
are required for a specific
Exchange 2000
organization.
Lead-in
It is important to plan for an
adequate number of global
catalog servers, because
the partial set of attributes
that are stored in the global

catalog includes the
attributes most frequently
used by Exchange 2000
users.