(MOC 5053A) Designing A Messaging Infrastructure Using Microsoft Exchange Server 2007

5053A
Designing a Messaging
Infrastructure Using Microsoft®
Exchange Server 2007
Information in this document, including URL and other Internet Web site references, is subject to change without notice.
Unless otherwise noted, the example companies, organizations, products, domain names,
e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real
company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be
inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in
any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the
express written permission of Microsoft Corporation.
The names of manufacturers, products, or URLs are provided for informational purposes only and Microsoft makes no
representations and warranties, either expressed, implied, or statutory, regarding these manufacturers or the use of the
products with any Microsoft technologies. The inclusion of a manufacturer or product does not imply endorsement of
Microsoft of the manufacturer or product. Links are provided to third party sites. Such sites are not under the control of
Microsoft and Microsoft is not responsible for the contents of any linked site or any link contained in a linked site, or any
changes or updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission received
from any linked site. Microsoft is providing these links to you only as a convenience, and the inclusion of any link does not
imply endorsement of Microsoft of the site or the products contained therein.
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.
© 2007 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, ActiveSync, BizTalk, ForeFront, Internet Explorer, MSN, Outlook, PowerPoint, SharePoint,
SmartScreen, SQL Server, Visual Basic, Visual Studio, Windows, Windows Media, Windows Mobile, Windows
PowerShell, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation
in the United States and/or other countries.
All other trademarks are property of their respective owners.
Product Number: 5053A
Part Number: X13-66119
Released: 04/2007
Version 1.2
MICROSOFT LICENSE TERMS
OFFICIAL MICROSOFT LEARNING PRODUCTS - TRAINER EDITION
These license terms are an agreement between Microsoft Corporation and you. Please read them. They apply
to the Licensed Content named above, which includes the media on which you received it, if any. The terms
also apply to any Microsoft
• updates,
• supplements,
• Internet-based services, and
• support services
for this Licensed Content, unless other terms accompany those items. If so, those terms apply.
By using the Licensed Content, you accept these terms. If you do not accept them, do not use the
Licensed Content.
If you comply with these license terms, you have the rights below.
1. DEFINITIONS.
a. “Academic Materials” means the printed or electronic documentation such as manuals, workbooks,
white papers, press releases, datasheets, and FAQs which may be included in the Licensed Content.
b. “Authorized Learning Center(s)” means a Microsoft Certified Partner for Learning Solutions
location, an IT Academy location, or such other entity as Microsoft may designate from time to time.
c. “Authorized Training Session(s)” means those training sessions authorized by Microsoft and
conducted at or through Authorized Learning Centers by a Trainer providing training to Students
solely on Official Microsoft Learning Products (formerly known as Microsoft Official Curriculum or
“MOC”) and Microsoft Dynamics Learning Products (formerly know as Microsoft Business Solutions
Courseware). Each Authorized Training Session will provide training on the subject matter of one (1)
Course.
d. “Course” means one of the courses using Licensed Content offered by an Authorized Learning Center
during an Authorized Training Session, each of which provides training on a particular Microsoft
technology subject matter.
e. “Device(s)” means a single computer, device, workstation, terminal, or other digital electronic or
analog device.
f. “Licensed Content” means the materials accompanying these license terms. The Licensed Content
may include, but is not limited to, the following elements: (i) Trainer Content, (ii) Student Content,
(iii) classroom setup guide, and (iv) Software. There are different and separate components of the
Licensed Content for each Course.
g. “Software” means the Virtual Machines and Virtual Hard Disks, or other software applications that
may be included with the Licensed Content.
h. “Student(s)” means a student duly enrolled for an Authorized Training Session at your location.
i. “Student Content” means the learning materials accompanying these license terms that are for use
by Students and Trainers during an Authorized Training Session. Student Content may include labs,
simulations, and courseware files for a Course.
j. “Trainer(s)” means a) a person who is duly certified by Microsoft as a Microsoft Certified Trainer and
b) such other individual as authorized in writing by Microsoft and has been engaged by an Authorized
Learning Center to teach or instruct an Authorized Training Session to Students on its behalf.
k. “Trainer Content” means the materials accompanying these license terms that are for use by
Trainers and Students, as applicable, solely during an Authorized Training Session. Trainer Content
may include Virtual Machines, Virtual Hard Disks, Microsoft PowerPoint files, instructor notes, and
demonstration guides and script files for a Course.
l. “Virtual Hard Disks” means Microsoft Software that is comprised of virtualized hard disks (such as a
base virtual hard disk or differencing disks) for a Virtual Machine that can be loaded onto a single
computer or other device in order to allow end-users to run multiple operating systems concurrently.
For the purposes of these license terms, Virtual Hard Disks will be considered “Trainer Content”.
m. “Virtual Machine” means a virtualized computing experience, created and accessed using
Microsoft® Virtual PC or Microsoft® Virtual Server software that consists of a virtualized hardware
environment, one or more Virtual Hard Disks, and a configuration file setting the parameters of the
virtualized hardware environment (e.g., RAM). For the purposes of these license terms, Virtual Hard
Disks will be considered “Trainer Content”.
n. “you” means the Authorized Learning Center or Trainer, as applicable, that has agreed to these
license terms.
2. OVERVIEW.
Licensed Content. The Licensed Content includes Software, Academic Materials (online and electronic),
Trainer Content, Student Content, classroom setup guide, and associated media.
License Model. The Licensed Content is licensed on a per copy per Authorized Learning Center location
or per Trainer basis.
3. INSTALLATION AND USE RIGHTS.
a. Authorized Learning Centers and Trainers: For each Authorized Training Session, you
may:
i. either install individual copies of the relevant Licensed Content on classroom Devices only for use
by Students enrolled in and the Trainer delivering the Authorized Training Session, provided that
the number of copies in use does not exceed the number of Students enrolled in and the Trainer
delivering the Authorized Training Session, OR
ii. install one copy of the relevant Licensed Content on a network server only for access by
classroom Devices and only for use by Students enrolled in and the Trainer delivering the
Authorized Training Session, provided that the number of Devices accessing the Licensed Content
on such server does not exceed the number of Students enrolled in and the Trainer delivering the
Authorized Training Session.
iii. and allow the Students enrolled in and the Trainer delivering the Authorized Training Session to
use the Licensed Content that you install in accordance with (ii) or (ii) above during such
Authorized Training Session in accordance with these license terms.
iv. Separation of Components. The components of the Licensed Content are licensed as a single unit.
You may not separate the components and install them on different Devices.
v. Third Party Programs. The Licensed Content may contain third party programs. These license
terms will apply to the use of those third party programs, unless other terms accompany those
programs.
b. Trainers:
i. Trainers may Use the Licensed Content that you install or that is installed by an Authorized
Learning Center on a classroom Device to deliver an Authorized Training Session.
ii. Trainers may also Use a copy of the Licensed Content as follows:
A. Licensed Device. The licensed Device is the Device on which you Use the Licensed Content.
You may install and Use one copy of the Licensed Content on the licensed Device solely for
your own personal training Use and for preparation of an Authorized Training Session.
B. Portable Device. You may install another copy on a portable device solely for your own
personal training Use and for preparation of an Authorized Training Session.
4. ADDITIONAL LICENSING REQUIREMENTS AND/OR USE RIGHTS.
a. Authorized Learning Centers and Trainers:
i. Software.
Virtual Hard Disks. The Licensed Content may contain versions of Microsoft Windows XP,
Windows Server 2003, and Windows 2000 Advanced Server and/or other Microsoft products which
are provided in Virtual Hard Disks.
A. If the Virtual Hard Disks and the labs are launched through the Microsoft Learning
Lab Launcher, then these terms apply:
TIME-SENSITIVE SOFTWARE. If the Software is not re-launched, it will stop running one
hundred eighty days after you install it. You will not receive notice before it stops running.
You may not be able to access data used or information stored with the Software when it
stops running and/or when it is re-launched. You must remove the Software from the Devices
at the end of each Authorized Training Session and reinstall and launch it prior to the
beginning of the next Authorized Training Session.
B. If the Virtual Hard Disks require a product key to launch, then these terms apply:
Microsoft will deactivate the operating system associated with each Virtual Hard Disk. Before
installing any Virtual Hard Disks on classroom Devices for use during an Authorized Training
Session, you will obtain from Microsoft a product key for the operating system software for
the Virtual Hard Disks and will activate such Software with Microsoft using such product key.
C. These terms apply to all Virtual Machines and Virtual Hard Disks:
You may only use the Virtual Machines and Virtual Hard Disks if you comply with
the terms and conditions of this agreement and the following security
requirements:
o You may not install Virtual Machines and Virtual Hard Disks on portable Devices or
Devices that are accessible to other networks.
o You must remove Virtual Machines and Virtual Hard Disks from all classroom Devices at
the end of each Authorized Training Session, except those held at Microsoft Certified
Partners for Learning Solutions locations.
o You must remove the differencing drive portions of the Virtual Hard Disks from all
classroom Devices at the end of each Authorized Training Session at Microsoft Certified
Partners for Learning Solutions locations.
o You will ensure that the Virtual Machines and Virtual Hard Disks are not copied or
downloaded from Devices on which you installed them.
o You will strictly comply with all Microsoft instructions relating to installation, use,
activation and deactivation, and security of Virtual Machines and Virtual Hard Disks.
o You may not modify the Virtual Machines and Virtual Hard Disks or any contents thereof.
o You may not reproduce or redistribute the Virtual Machines or Virtual Hard Disks.
ii. Classroom Setup Guide. You will assure any Licensed Content installed for use during an
Authorized Training Session will be done in accordance with the classroom set-up guide for the
Course.
iii. Media Elements and Templates. You may allow Trainers and Students to use images, clip art,
animations, sounds, music, shapes, video clips and templates provided with the Licensed Content
solely in an Authorized Training Session. If Trainers have their own copy of the Licensed Content,
they may use Media Elements for their personal training use.
iv Evaluation Software. Any Software that is included in the Student Content designated as
“Evaluation Software” may be used by Students solely for their personal training outside of the
Authorized Training Session.
b. Trainers Only:
i. Use of PowerPoint Slide Deck Templates. The Trainer Content may include Microsoft
PowerPoint slide decks. Trainers may use, copy and modify the PowerPoint slide decks only for
providing an Authorized Training Session. If you elect to exercise the foregoing, you will agree or
ensure Trainer agrees: (a) that modification of the slide decks will not constitute creation of
obscene or scandalous works, as defined by federal law at the time the work is created; and
(b) to comply with all other terms and conditions of this agreement.
ii. Use of Instructional Components in Trainer Content. For each Authorized Training Session,
Trainers may customize and reproduce, in accordance with the MCT Agreement, those portions of
the Licensed Content that are logically associated with instruction of the Authorized Training
Session. If you elect to exercise the foregoing rights, you agree or ensure the Trainer agrees: (a)
that any of these customizations or reproductions will only be used for providing an Authorized
Training Session and (b) to comply with all other terms and conditions of this agreement.
iii. Academic Materials. If the Licensed Content contains Academic Materials, you may
copy and use the Academic Materials. You may not make any modifications to the Academic
Materials and you may not print any book (either electronic or print version) in its entirety. If you
reproduce any Academic Materials, you agree that:
• The use of the Academic Materials will be only for your personal reference or
training use
• You will not republish or post the Academic Materials on any network computer or
broadcast in any media;
• You will include the Academic Material’s original copyright notice, or a copyright
notice to Microsoft’s benefit in the format provided below:
Form of Notice:
© 2007 Reprinted for personal reference use only with permission by Microsoft
Corporation. All rights reserved.
Microsoft, Windows, and Windows Server are either registered trademarks or
trademarks of Microsoft Corporation in the US and/or other countries. Other
product and company names mentioned herein may be the trademarks of their
respective owners.
iv. Distributable Code. The Licensed Content may contain code that you are permitted to
distribute in programs you develop if you comply with the terms below.
A. Right to use and Distribute. The code and text files listed below are “Distributable Code.”
• REDIST.TXT Files. You may copy and distribute the object code form of code listed in
REDIST.TXT files.
• Sample Code. You may modify, copy, and distribute the source and object code form of
code marked as “sample.”
• OTHER-DIST.TXT Files. You may copy and distribute the object code form of code listed
in
OTHER-DIST.TXT files.
• Third Party Distribution. You may permit distributors of your programs to copy and
distribute the Distributable Code as part of those programs.
B. Distribution Requirements. For any Distributable Code you distribute, you must
• add significant primary functionality to it in your programs;
• require distributors and external end users to agree to terms that protect it at least as
much as this agreement;
• display your valid copyright notice on your programs; and
• indemnify, defend, and hold harmless Microsoft from any claims, including attorneys’
fees, related to the distribution or use of your programs.
C. Distribution Restrictions. You may not
• alter any copyright, trademark or patent notice in the Distributable Code;
• use Microsoft’s trademarks in your programs’ names or in a way that suggests your
programs come from or are endorsed by Microsoft;
• distribute Distributable Code to run on a platform other than the Windows platform;
• include Distributable Code in malicious, deceptive or unlawful programs; or
• modify or distribute the source code of any Distributable Code so that any part of it
becomes subject to an Excluded License. An Excluded License is one that requires, as a
condition of use, modification or distribution, that
• the code be disclosed or distributed in source code form; or
• others have the right to modify it.
5. INTERNET-BASED SERVICES. Microsoft may provide Internet-based services with the Licensed
Content. It may change or cancel them at any time. You may not use these services in any way that
could harm them or impair anyone else’s use of them. You may not use the services to try to gain
unauthorized access to any service, data, account or network by any means.
6. Scope of License. The Licensed Content is licensed, not sold. This agreement only gives you some rights
to use the Licensed Content. Microsoft reserves all other rights. Unless applicable law gives you more
rights despite this limitation, you may use the Licensed Content only as expressly permitted in this
agreement. In doing so, you must comply with any technical limitations in the Licensed Content that only
allow you to use it in certain ways. You may not
• install more copies of the Licensed Content on classroom Devices than the number of Students and
the Trainer in the Authorized Training Session;
• allow more classroom Devices to access the server than the number of Students enrolled in and the
Trainer delivering the Authorized Training Session if the Licensed Content is installed on a network
server;
• copy or reproduce the Licensed Content to any server or location for further reproduction or
distribution;
• disclose the results of any benchmark tests of the Licensed Content to any third party without
Microsoft’s prior written approval;
• work around any technical limitations in the Licensed Content;
• reverse engineer, decompile or disassemble the Licensed Content, except and only to the extent that
applicable law expressly permits, despite this limitation;
• make more copies of the Licensed Content than specified in this agreement or allowed by applicable
law, despite this limitation;
• publish the Licensed Content for others to copy;
• transfer the Licensed Content, in whole or in part, to a third party;
• access or use any Licensed Content for which you (i) are not providing a Course and/or (ii) have not
been authorized by Microsoft to access and use;
• rent, lease or lend the Licensed Content; or
• use the Licensed Content for commercial hosting services or general business purposes.
• Rights to access the server software that may be included with the Licensed Content, including the
Virtual Hard Disks does not give you any right to implement Microsoft patents or other Microsoft
intellectual property in software or devices that may access the server.
7. EXPORT RESTRICTIONS. The Licensed Content is subject to United States export laws and regulations.
You must comply with all domestic and international export laws and regulations that apply to the Licensed
Content. These laws include restrictions on destinations, end users and end use. For additional
information, see www.microsoft.com/exporting.
8. NOT FOR RESALE SOFTWARE/LICENSED CONTENT. You may not sell software or Licensed Content
marked as “NFR” or “Not for Resale.”
9. ACADEMIC EDITION. You must be a “Qualified Educational User” to use Licensed Content marked as
“Academic Edition” or “AE.” If you do not know whether you are a Qualified Educational User, visit
www.microsoft.com/education or contact the Microsoft affiliate serving your country.
10. TERMINATION. Without prejudice to any other rights, Microsoft may terminate this agreement if you fail
to comply with the terms and conditions of these license terms. In the event your status as an Authorized
Learning Center or Trainer a) expires, b) is voluntarily terminated by you, and/or c) is terminated by
Microsoft, this agreement shall automatically terminate. Upon any termination of this agreement, you must
destroy all copies of the Licensed Content and all of its component parts.
11. ENTIRE AGREEMENT. This agreement, and the terms for supplements, updates, Internet-
based services and support services that you use, are the entire agreement for the Licensed
Content and support services.
12. APPLICABLE LAW.
a. United States. If you acquired the Licensed Content in the United States, Washington state law
governs the interpretation of this agreement and applies to claims for breach of it, regardless of
conflict of laws principles. The laws of the state where you live govern all other claims, including
claims under state consumer protection laws, unfair competition laws, and in tort.
b. Outside the United States. If you acquired the Licensed Content in any other country, the laws of
that country apply.
13. LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the laws
of your country. You may also have rights with respect to the party from whom you acquired the Licensed
Content. This agreement does not change your rights under the laws of your country if the laws of your
country do not permit it to do so.
14. Disclaimer of Warranty. The Licensed Content is licensed “as-is.” You bear the risk of using
it. Microsoft gives no express warranties, guarantees or conditions. You may have additional
consumer rights under your local laws which this agreement cannot change. To the extent
permitted under your local laws, Microsoft excludes the implied warranties of
merchantability, fitness for a particular purpose and non-infringement.
15. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. YOU CAN RECOVER FROM
MICROSOFT AND ITS SUPPLIERS ONLY DIRECT DAMAGES UP TO U.S. $5.00. YOU CANNOT
RECOVER ANY OTHER DAMAGES, INCLUDING CONSEQUENTIAL, LOST PROFITS, SPECIAL,
INDIRECT OR INCIDENTAL DAMAGES.
This limitation applies to
• anything related to the Licensed Content, software, services, content (including code) on third party
Internet sites, or third party programs; and
• claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence, or
other tort to the extent permitted by applicable law.
It also applies even if Microsoft knew or should have known about the possibility of the damages. The
above limitation or exclusion may not apply to you because your country may not allow the exclusion or
limitation of incidental, consequential or other damages.
Please note: As this Licensed Content is distributed in Quebec, Canada, some of the clauses in this
agreement are provided below in French.
Remarque : Ce le contenu sous licence étant distribué au Québec, Canada, certaines des clauses
dans ce contrat sont fournies ci-dessous en français.
EXONÉRATION DE GARANTIE. Le contenu sous licence visé par une licence est offert « tel quel ». Toute
utilisation de ce contenu sous licence est à votre seule risque et péril. Microsoft n’accorde aucune autre
garantie expresse. Vous pouvez bénéficier de droits additionnels en vertu du droit local sur la protection dues
consommateurs, que ce contrat ne peut modifier. La ou elles sont permises par le droit locale, les garanties
implicites de qualité marchande, d’adéquation à un usage particulier et d’absence de contrefaçon sont exclues.
LIMITATION DES DOMMAGES-INTÉRÊTS ET EXCLUSION DE RESPONSABILITÉ POUR LES
DOMMAGES. Vous pouvez obtenir de Microsoft et de ses fournisseurs une indemnisation en cas de
dommages directs uniquement à hauteur de 5,00 $ US. Vous ne pouvez prétendre à aucune indemnisation
pour les autres dommages, y compris les dommages spéciaux, indirects ou accessoires et pertes de bénéfices.
Cette limitation concerne:
• tout ce qui est relié au le contenu sous licence , aux services ou au contenu (y compris le code)
figurant sur des sites Internet tiers ou dans des programmes tiers ; et
• les réclamations au titre de violation de contrat ou de garantie, ou au titre de responsabilité stricte, de
négligence ou d’une autre faute dans la limite autorisée par la loi en vigueur.
Elle s’applique également, même si Microsoft connaissait ou devrait connaître l’éventualité d’un tel dommage.
Si votre pays n’autorise pas l’exclusion ou la limitation de responsabilité pour les dommages indirects,
accessoires ou de quelque nature que ce soit, il se peut que la limitation ou l’exclusion ci-dessus ne
s’appliquera pas à votre égard.
EFFET JURIDIQUE. Le présent contrat décrit certains droits juridiques. Vous pourriez avoir d’autres droits
prévus par les lois de votre pays. Le présent contrat ne modifie pas les droits que vous confèrent les lois de
votre pays si celles-ci ne le permettent pas.
Contents xi
Table of Contents
Introduction
Introduction ...................................................................................................................................... iii
Course Materials.............................................................................................................................. iv
Microsoft Learning Product Types................................................................................................... vi
Microsoft Learning ........................................................................................................................... ix
Microsoft Certification Program ........................................................................................................x
Facilities......................................................................................................................................... xiv
About This Course .......................................................................................................................... xv
Prerequisites................................................................................................................................. xvii
Process for Designing a Messaging Infrastructure Using Microsoft Exchange Server 2007........ xix
Course Outline................................................................................................................................ xx
Virtual Machine Environment........................................................................................................ xxii
Demonstration: Using Microsoft Virtual Server ........................................................................... xxiv
Module 1: Gathering Requirements for a Messaging Infrastructure

Overview....................................................................................................................................... 1-1
Lesson 1: Gathering Business Requirements .............................................................................. 1-2
Lesson 2: Identifying Additional Requirements .......................................................................... 1-15
Lesson 3: Analyzing the Current Messaging Environment ........................................................ 1-28
Lesson 4: Creating a Requirements Document ......................................................................... 1-48
Lab: Gathering Requirements for a Messaging Infrastructure ................................................... 1-53
Module 2: Designing Active Directory and Message Routing

Overview....................................................................................................................................... 2-1
Lesson 1: Designing an Active Directory Infrastructure ............................................................... 2-2
Lesson 2: Designing Message Routing...................................................................................... 2-23
Lesson 3: Designing the Message Routing Perimeter ............................................................... 2-31
Lab: Designing Active Directory and Message Routing ............................................................. 2-44
Module 3: Designing Exchange Servers

Overview....................................................................................................................................... 3-1
Lesson 1: Designing Mailbox Servers .......................................................................................... 3-2
Lesson 2: Designing Non-Mailbox Servers ................................................................................ 3-21
Lesson 3: Designing a Public Folder Architecture...................................................................... 3-40
Lesson 4: Designing a Lab Environment.................................................................................... 3-54
Lab: Designing Exchange Servers ............................................................................................. 3-59
Module 4: Designing Security for a Messaging Environment

Overview....................................................................................................................................... 4-1
Lesson 1: Designing an Administrative Model ............................................................................. 4-2
Lesson 2: Designing Message Security ....................................................................................... 4-9
Lesson 3: Designing Antivirus and Anti-spam Solutions ............................................................ 4-24
Lab: Designing Security for a Messaging Environment.............................................................. 4-40
xii Contents
Module 5: Designing Messaging Policies

Overview....................................................................................................................................... 5-1
Lesson 1: Designing Exchange Recipient and Message Policies................................................ 5-2
Lesson 2: Designing Mobile Device Policies.............................................................................. 5-18
Lesson 3: Designing Messaging Policies for Compliance.......................................................... 5-25
Lab: Designing Messaging Policies............................................................................................ 5-39
Module 6: Designing Coexistence and Interoperability Strategies with Other

Messaging Systems
Overview....................................................................................................................................... 6-1
Lesson 1: Overview of Coexistence and Interoperability with Other Messaging Systems .......... 6-2
Lesson 2: Designing a Coexistence Strategy with Previous Exchange Versions........................ 6-7
Lesson 3: Designing an Interoperability Strategy with Other Messaging Systems.................... 6-22
Lab: Designing Coexistence and Interoperability Strategies with Other Messaging Systems... 6-33
Module 7: Designing an Exchange Server 2007 Upgrade Strategy

Overview....................................................................................................................................... 7-1
Lesson 1: Overview of Available Upgrade Strategies .................................................................. 7-2
Lesson 2: Designing a Transition from Previous Versions of Exchange...................................... 7-7
Lesson 3: Designing a Migration from Other Messaging Systems ............................................ 7-22
Lab: Designing an Upgrade Strategy ......................................................................................... 7-31
Module 8: Obtaining Approval for a Messaging Infrastructure Design

Overview....................................................................................................................................... 8-1
Lesson 1: Preparing to Obtain Approval ...................................................................................... 8-2
Lesson 2: Presenting and Finalizing a Design ........................................................................... 8-10
Lab: Obtaining Approval for a Messaging Infrastructure Design................................................ 8-18
Course Evaluation ...................................................................................................................... 8-22
Appendices
Active Directory and Routing Interview Notes
Trey Research Policy Requirements
Requirements Interview Notes
Messaging Security Requirements
Server Design Interview Notes
Trey Research Current Active Directory Site Design
Trey Research Current Perimeter Design
Trey Research Information
Trey Research Organization Chart
Trey Research Proposed Active Directory Site Design
Trey Research Proposed Perimeter Design
Trey Research Routing Groups
Index ..................................................................................................................I-1
Introduction
Table of Contents
Introduction iii
Course Materials iv
Microsoft Learning Product Types vi
Microsoft Learning ix
Microsoft Certification Program x
Facilities xiv
About This Course xv
Prerequisites xvii
Process for Designing a Messaging Infrastructure
Using Microsoft Exchange Server 2007 xix
Course Outline xx
Virtual Machine Environment xxii
Demonstration: Using Microsoft Virtual Server xxiv
Information in this document, including URL and other Internet Web site references, is subject to change
without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-
mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any
real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or
should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting
the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval
system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
The names of manufacturers, products, or URLs are provided for informational purposes only and Microsoft
makes no representations and warranties, either expressed, implied, or statutory, regarding these
manufacturers or the use of the products with any Microsoft technologies. The inclusion of a manufacturer or
product does not imply endorsement of Microsoft of the manufacturer or product. Links are provided to third
party sites. Such sites are not under the control of Microsoft and Microsoft is not responsible for the contents of
any linked site or any link contained in a linked site, or any changes or updates to such sites. Microsoft is not
responsible for webcasting or any other form of transmission received from any linked site. Microsoft is
providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement of
Microsoft of the site or the products contained therein.
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.
Microsoft, Active Directory, ActiveSync, BizTalk, ForeFront, Internet Explorer, MSN, Outlook, PowerPoint,
SharePoint, SmartScreen, SQL Server, Visual Basic, Visual Studio, Windows, Windows Media, Windows
Mobile, Windows PowerShell, Windows Server, and Windows Vista are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.
Version 1.2
Introduction iii
Introduction
iv Introduction
Course Materials
The following materials are included with your kit:

• Student workbook. The student workbook contains the material covered in class.
• Student Materials CD. The Student Materials CD contains a Web page that provides
you with links to resources pertaining to this course, including additional readings,
discussion answer keys, multimedia presentations, and course-related Web sites.
Note: To open the Web page, insert the Student Materials CD into the CD-ROM
drive, and then in the root directory of the CD, double-click StartCD.exe.
• Course evaluation. At the end of the course, you will have the opportunity to
complete an online evaluation to provide feedback on the course, training facility,
and instructor.
To provide additional comments or feedback on the course, send e-mail to

support@mscourseware.com. To inquire about the Microsoft Certification Program, send
e-mail to mcphelp@microsoft.com.
Introduction v
Document Conventions
The following conventions are used in course materials to distinguish elements of the text.
Convention Use
Bold Represents commands, command options, and syntax that must be
typed exactly as shown. It also indicates commands on menus and
buttons, dialog box titles and options, and icon and menu names.
Italic In syntax statements or descriptive text, indicates argument names or
placeholders for variable information. Italic is also used for introducing
new terms, for book titles, and for emphasis in the text.
Title Capitals Indicate domain names, user names, computer names, directory names,
and folder and file names, except when specifically referring to case-
sensitive names. Unless otherwise indicated, you can use lowercase
letters when you type a directory name or file name in a dialog box or at
a command prompt.
ALL CAPITALS Indicate the names of keys, key sequences, and key combinations—for
example, ALT+SPACEBAR.
monospace Represents code samples or examples of screen text.
[] In syntax statements, enclose optional items. For example, [filename] in
command syntax indicates that you can choose to type a file name with
the command. Type only the information within the brackets, not the
brackets themselves.
{} In syntax statements, enclose required items. Type only the information
within the braces, not the braces themselves.
| In syntax statements, separates an either/or choice.
X Indicates a procedure with sequential steps.
... In syntax statements, specifies that the preceding item may be repeated.
. Represents an omitted portion of a code sample.
.
.
vi Introduction
Microsoft Learning Product Types
Microsoft Learning offers the following instructor-led products. Each is specific to a

particular audience type and level of experience. The different product types also tend to
suit different learning styles. These types are as follows:
• Courses are for information technology (IT) professionals and developers who are
new to a particular product or technology and for experienced individuals who prefer
to learn in a traditional classroom format. Courses provide a relevant and guided
learning experience that combines lecture and practice to deliver thorough coverage
of a Microsoft product or technology. Courses are designed to address the needs of
learners engaged in planning, design, implementation, management, and support
phases of the technology adoption life-cycle. They provide detailed information by
focusing on concepts and principles, reference content, and in-depth hands-on lab
activities to ensure knowledge transfer. Typically, the content of a course is broad,
addressing a wide range of tasks necessary for the job role.
• Workshops are for knowledgeable IT professionals and developers who learn best
by doing and exploring. Workshops provide a hands-on learning experience in which
participants use Microsoft products in a safe and collaborative environment based on
real-world scenarios.
Introduction vii
• iWorker courses or Information Worker Courses are scenario-based courseware

lines to compete in the desktop applications market. This scenario-based courseware
line will fill a need for applications training that supports on-the-job performance
improvement with business and productivity solutions (rather than feature-based
training). The purpose of an iWorker course is to promote skills/ knowledge transfer
in the context of business scenarios to accomplish business objectives by working
individually or collaboratively to find answers. iWorker courses are aimed at users
who have working knowledge of the technology and are interested in applying that
knowledge in specific business scenarios.
viii Introduction
Microsoft Learning Product Types (continued)
• Clinics are for IT professionals, developers and technical decision makers. Clinics
offer a detailed “how to” presentation that describes the features and functionality
of an existing or new Microsoft product or technology, and that showcases product
demonstrations and solutions. Clinics focus on how specific features will solve
business problems.
• First-look Clinics are products specifically designed to deliver early content
or critical information that Product Groups or other internal customers need
communicated quickly and broadly. The First Look products convey knowledge-
based (not skills-based) information to an audience profile identified as high-level
Business Decision Makers.
• Hands-on Labs provide IT professionals and developers with hands-on experience
with an existing or new Microsoft product or technology. Hands-on labs provide a
realistic and safe environment to encourage knowledge transfer by learning through
doing. The labs provided are completely prescriptive so that no lab answer keys are
required. There is very little lecture or text content provided in hands-on labs, aside
from lab introductions, context setting, and lab reviews.
Introduction ix
Microsoft Learning
Microsoft Learning develops Official Microsoft Learning Product (OMLP) courseware

for computer professionals who design, develop, support, implement, or manage
solutions by using Microsoft products and technologies. These learning products provide
comprehensive, skills-based training in instructor-led and online formats.
Additional Recommended Learning Products

Each learning product relates in some way to other learning products. A related product
may be a prerequisite, a follow-up course, clinic, or course in a recommended series, or a
learning product that offers additional training.
It is recommended that you take the following learning products in this order:
• Course 5053A: Designing a Messaging Infrastructure Using Microsoft® Exchange
Server 2007.
• Course 5054A: Designing a High Availability Messaging Solution Using Microsoft®
Exchange Server 2007.
Other related learning products may become available in the future, so for up-to-date
information about recommended learning products, visit the Microsoft Learning Web site.
Microsoft Learning Information

For more information, visit the Microsoft Learning Web site at
http://www.microsoft.com/learning/.
x Introduction
Microsoft Certification Program
Microsoft Learning offers a variety of certification credentials for developers and IT

professionals. The Microsoft Certification Program (MCP) is the leading certification
program for validating your experience and skills, keeping you competitive in today’s
changing business environment.
MCP Certifications
The MCP program includes the following certifications.
MCITP
The new Microsoft Certified IT Professional (MCITP) credential allows IT professionals
to distinguish themselves as experts in their specific area of focus. There is a
straightforward upgrade path from the MCDBA certification to the new MCITP
credentials. There are currently three IT Professional certifications—in database
development, database administration, and business intelligence:
• Microsoft Certified IT Professional: Database Developer
• Microsoft Certified IT Professional: Database Administrator
• Microsoft Certified IT Professional: Business Intelligence Developer
Introduction xi
MCPD
The Microsoft Certified Professional Developer (MCPD) credential highlights developer
job roles, featuring specific areas of expertise. There is a straightforward upgrade path
from the MCAD and MCSD for Microsoft .NET certifications to the new MCPD
credentials. There are three MCPD certification paths—in Web application development,
Windows development, and enterprise applications development:
• Microsoft Certified Professional Developer: Web Developer
• Microsoft Certified Professional Developer: Windows Developer
• Microsoft Certified Professional Developer: Enterprise Applications Developer
MCTS
The Microsoft Certified Technology Specialist (MCTS) credential enables professionals
to target specific technologies and distinguish themselves by demonstrating in-depth
knowledge of and expertise in the technologies with which they work. There are currently
five MCTS certifications:
• Microsoft Certified Technology Specialist: .NET Framework 2.0 Web Applications
• Microsoft Certified Technology Specialist: .NET Framework 2.0 Windows
Applications
• Microsoft Certified Technology Specialist: .NET Framework 2.0 Distributed
Applications
• Microsoft Certified Technology Specialist: SQL Server™ 2005
• Microsoft Certified Technology Specialist: BizTalk® Server
Related Certification Exams

This course helps students to prepare for:
• Exam 70-237: Designing a Microsoft Exchange Server 2007 Infrastructure.
• Exam 70-238: Deploying a Microsoft Exchange Server 2007 Infrastructure.
Exam 70-237 and exam 70-238 are core exams for the MCITP: Messaging Engineer
certification.
MCDST on Microsoft Windows®
The Microsoft Certified Desktop Support Technician (MCDST) certification is designed
for professionals who successfully support and educate end users and troubleshoot
operating system and application issues on desktop computers running the Windows
operating system.
xii Introduction
MCSA on Microsoft Windows Server™ 2003

The Microsoft Certified Systems Administrator (MCSA) certification is designed for
professionals who implement, manage, and troubleshoot existing network and system
environments based on the Windows Server 2003 platform. Implementation
responsibilities include installing and configuring parts of systems. Management
responsibilities include administering and supporting systems.
MCSE on Microsoft Windows Server 2003
The Microsoft Certified Systems Engineer (MCSE) credential is the premier certification
for professionals who analyze business requirements and design and implement
infrastructure for business solutions based on the Windows Server 2003 platform.
Implementation responsibilities include installing, configuring, and troubleshooting
network systems.
MCAD for Microsoft .NET
The Microsoft Certified Application Developer (MCAD) for Microsoft .NET credential
provides industry recognition for professional developers who use Microsoft Visual
Studio® .NET and Web services to develop and maintain department-level applications,
components, Web or desktop clients, or back-end data services, or who work in teams
developing enterprise applications. The credential covers job tasks ranging from
developing to deploying and maintaining these solutions.
MCSD for Microsoft .NET
The Microsoft Certified Solution Developer (MCSD) for Microsoft .NET credential is
the top-level certification for advanced developers who design and develop leading-edge
enterprise solutions by using Microsoft development tools and technologies as well as the
Microsoft .NET Framework. The credential covers job tasks ranging from analyzing
business requirements to maintaining solutions.
MCDBA on Microsoft SQL Server 2000
The Microsoft Certified Database Administrator (MCDBA) credential is the premier
certification for professionals who implement and administer SQL Server 2000 databases.
The certification is appropriate for individuals who derive physical database designs,
develop logical data models, create physical databases, create data services by using
Transact-SQL, manage and maintain databases, configure and manage security, monitor
and optimize databases, and install and configure SQL Server.
MCP
The Microsoft Certified Professional (MCP) credential is for individuals who have the
skills to successfully implement a Microsoft product or technology as part of a business
solution in an organization. Hands-on experience with the product is necessary to
successfully achieve certification.
Introduction xiii
MCT
Microsoft Certified Trainers (MCTs) demonstrate the instructional and technical skills
that qualify them to deliver Official Microsoft Learning Products through a Microsoft
Certified Partner for Learning Solutions (CPLS).
Certification Requirements
Certification requirements differ for each certification category and are specific to the
products and job functions addressed by the certification. To earn a certification
credential, you must pass rigorous certification exams that provide a valid and reliable
measure of technical proficiency and expertise.
Additional Information: See the Microsoft Learning Web site at

http://www.microsoft.com/learning/. You can also send e-mail to
mcphelp@microsoft.com if you have specific certification questions.
Acquiring the Skills Tested by an MCP Exam

Official Microsoft Learning Products can help you develop the skills that you need to
do your job. They also complement the experience that you gain while working with
Microsoft products and technologies. However, no one-to-one correlation exists between
Official Microsoft Learning Products and MCP exams. Microsoft does not expect or
intend for the courses to be the sole preparation method for passing MCP exams.
Practical product knowledge and experience are also necessary to pass MCP exams.
To help prepare for MCP exams, use the preparation guides that are available for each
exam. Each Exam Preparation Guide contains exam-specific information, such as a list
of the topics on which you will be tested. These guides are available on the Microsoft
Learning Web site at http://www.microsoft.com/learning/.
xiv Introduction
Facilities
Introduction xv
About This Course
This section provides you with a brief description of the course, objectives, and target
audience.
Description
This course teaches messaging engineers to design a messaging infrastructure. Students
will assess an existing infrastructure and determine technical and business requirements
for new Exchange Server 2007 deployments and migrations. They will create a design
that addresses security, architecture, scalability, coexistence, and client access needs.
Students also will learn strategies for gaining design approval from stakeholders.
Objectives
After completing this course, you will be able to:
• Gather business and technical requirements for a messaging infrastructure.
• Design an Active Directory® directory service and message routing infrastructure.
• Design the hardware and system configuration for Exchange servers.
• Design security for the messaging environment.
• Design strategies for coexistence and interoperability.
• Design a strategy for upgrading to Exchange Server 2007.
• Design messaging policies.
• Obtain approval for a messaging infrastructure design.
xvi Introduction
Audience
The audience for this course includes people with three or more years experience
working with previous Exchange Server versions and experience implementing
Exchange Server 2007. Most students will have managed enterprise-level Exchange
Server organizations. Students are expected to be new to participating in designing
Exchange Server 2007 deployments on the job, or should be planning to design Exchange
Server 2007 deployments in the near future. Students may have done some design for
Exchange 2000 Server or Exchange Server 2003 deployments, but want to learn how to
design Exchange Server 2007 environments. Students will have experience in designing
and managing Active Directory and network infrastructure deployments.
Introduction xvii
Prerequisites
This course requires that you meet the following prerequisites:

• Must understand hardware concepts. For example, what redundant array of
independent disks (RAID) is, what a storage area network (SAN) is, processor
options, memory requirements, how disk input/output (I/O) functions and the
limitations of disk I/O, storage options for Exchange server, and the differences in
addressable memory spaces between 32- and 64-bit architectures.
• Must have detailed knowledge of Active Directory® concepts and design principles.
For example, site replication, integrated authentication, schema extension, Domain
Name System (DNS), group and organization unit structure and inheritance.
• Working experience with designing and implementing Active Directory in Windows
Server 2003.
• Must understand Exchange architecture. For example, the purpose of server roles,
functions of specific server roles, how message routing and queuing works in
Exchange, standard messaging protocols (Simple Mail Transfer Protocol [SMTP],
Internet Message Access Protocol version 4rev1 [IMAP4], Post Office Protocol
version 3 [POP3]), how Exchange replicates data stores, and client access methods.
• Working experience with Exchange 2000 Server or Exchange Server 2003 and
Exchange Server 2007. For example, you must have installed, maintained, and
supported a production Exchange environment.
xviii Introduction
• Must already know how to use:

• Exchange System Manager
• Exchange Best Practice Analyzer (ExBPA)
• Microsoft Office Visio® (to create infrastructure diagrams)
• Familiarity and experience with Windows scripting or command-line scripting.
Important: This learning product will be most useful to people who intend to use
their new skills and knowledge on the job immediately after training.
Introduction xix
Process for Designing a Messaging Infrastructure

Using Microsoft Exchange Server 2007
xx Introduction
Course Outline
Module 1, “Gathering Requirements for a Messaging Infrastructure,” discusses how to

gather business and technical requirements for a messaging system. This module focuses
on gathering business requirements for a Microsoft Exchange Server 2007 deployment,
identifying project stakeholders and non-business requirements, analyzing the current
messaging environment, and creating a requirements document.
Module 2, “Designing Active Directory and Message Routing,” covers the information
and tasks needed to design an Active Directory and message routing infrastructure. This
module focuses on designing an Active Directory infrastructure that is optimized for
Exchange Server 2007, and designing message routing and the message routing perimeter.
Module 3, “Designing Exchange Servers,” discusses how to design Mailbox server
configurations. This module focuses on how to design Mailbox server configurations,
configurations for other servers running Exchange Server 2007, public-folder architecture,
and a test lab.
Module 4, “Designing Security for a Messaging Environment,” covers the key
components for designing a messaging environment’s security. This module focuses on
designing an administrative model for Exchange Server 2007, designing message security,
and designing antivirus and anti-spam solutions.
Introduction xxi
Course Outline (continued)
Module 5, “Designing Messaging Policies,” discusses how to design messaging policies

for an Exchange Server 2007 organization. This module focuses on how to design
policies for Exchange recipients and message delivery, how to design policies for mobile
devices, and how to design messaging policies for compliance.
Module 6, “Designing Coexistence and Interoperability Strategies with Other Messaging
Systems,” covers the information and tasks needed to design Exchange coexistence and
messaging system interoperability strategies. This module focuses on the Exchange
coexistence and interoperability scenarios and terminology, how to design a coexistence
strategy with previous Exchange Server versions, and how to design an interoperability
strategy with other messaging systems.
Module 7, “Designing an Exchange Server 2007 Upgrade Strategy,” discusses how to
design a strategy for upgrading to Exchange Server 2007. This module focuses on the
Exchange upgrade terminology and strategies, how to design a transition strategy for
upgrading from previous Exchange Server versions, and how to design a migration
strategy for upgrading from other messaging systems.
Module 8, “Obtaining Approval for a Messaging Infrastructure Design,” discusses the
process of obtaining approval for a messaging infrastructure design. This module focuses
on the necessary preparation for a design approval meeting, and presenting and finalizing
an Exchange Server 2007 design.
xxii Introduction
Virtual Machine Environment
This section provides the information for setting up the classroom environment to support
the course’s business scenario.
Virtual Machine Configuration

In this course, you will use Microsoft Virtual Server 2005 to perform the hands-on
practices and labs.
Important: At the end of each lab, you must close the virtual machine and must
not save any changes. To close a virtual machine without saving the changes,
perform the following steps:
1. On the host computer, click Start, point to All Programs, point to Microsoft
Virtual Server, and then click Virtual Server Administration Website.
2. Under Navigation, click Master Status. For each virtual machine that is
running, point to the virtual machine name, and, in the context menu, click Turn off
Virtual Machine and Discard Undo Disks. Click OK
The following table shows the role of each virtual machine used in this course:
Virtual machine Role
The domain controller for the treyresearch.net domain. It has a
LON-DC1
standard Exchange Server 2007 installation.
A stand-alone server that has the Exchange Server 2007 Edge
LON-Edge1
Transport Server role installed on it.
LON-CL1 A member of the treyresearch.net domain.
Introduction xxiii
Software Configuration
The following software is installed on the VMs:
• Windows Server 2003, Service Pack 1, or Windows XP, Service Pack 2
• Exchange Server 2007
• Microsoft Office Outlook 2007
Classroom Setup
Each classroom computer will have the same virtual machine configured in the same way.
Course Hardware Level

To ensure a satisfactory student experience, Microsoft Learning requires a minimum
equipment configuration for trainer and student computers in all Microsoft Certified
Partner for Learning Solutions (CPLS) classrooms in which Official Microsoft Learning
Product courseware are taught. This course requires that you have a computer that meets
or exceeds hardware level 5, which specifies a 2.4–gigahertz (minimum) Pentium 4 or
equivalent CPU, at least 2 gigabytes (GB) of RAM, 16 megabytes (MB) of video RAM,
and a 7200 RPM 40-GB hard disk.
xxiv Introduction
Demonstration: Using Microsoft Virtual Server
Virtual Server Demonstration

In this demonstration, your instructor will help familiarize you with the Virtual Server
environment in which you will work to complete the course’s practices and labs. You
will learn:
• How to connect to the Virtual Server Administration Website.
• How to configure virtual machine configurations using the Virtual Server
Administration Website.
• How to connect to a virtual machine using the Virtual Machine Remote
Control Client.
• How to shut down a virtual machine without saving any changes.
Keyboard Shortcuts
While working in the Virtual Machine Remote Control Client environment, you might
find it helpful to use keyboard shortcuts. All Virtual Server shortcuts include a key that is
referred to as the HOST key or the RIGHT-ALT key. By default, the HOST key is the
ALT key on the right side of your keyboard. Some useful shortcuts include:
• RIGHT-ALT+DELETE to log on to the Virtual PC.
• RIGHT-ALT+ENTER to switch between full-screen and window modes.
For more information about using Virtual Server, see Virtual Server Help.
Module 1: Gathering Requirements for a
Messaging Infrastructure
Table of Contents
Overview 1-1
Lesson 1: Gathering Business Requirements 1-2
Lesson 2: Identifying Additional Requirements 1-15
Lesson 3: Analyzing the Current Messaging
Environment 1-28
Lesson 4: Creating a Requirements Document 1-48
Lab: Gathering Requirements for a Messaging
Infrastructure 1-53
without notice. Unless otherwise noted, the example companies, organizations, products, domain names,
e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any
Version 1.2
Module 1: Gathering Requirements for a Messaging Infrastructure 1-1
Overview
Before you can begin designing your organization’s new messaging system, you
must first understand why your organization plans to deploy the messaging system
and the state of the current messaging system. Most organizations need an information
technology (IT) infrastructure to ensure business tasks are performed correctly. Before
you deploy new IT technologies, administrators must understand and be able to present
clearly to decision makers the way in which these new technologies will address existing
and new business requirements.
Objectives
After completing this module, you will be able to:
• Gather business requirements for a Microsoft® Exchange Server 2007 deployment.
• Identify project stakeholders and non-business requirements.
• Analyze the current messaging environment.
• Create a requirements document.
1-2 Module 1: Gathering Requirements for a Messaging Infrastructure
Lesson 1: Gathering Business Requirements
In this lesson, you will gather business requirements for an Exchange Server 2007
deployment. Identifying business requirements helps determine the benefits of, and
rationale for, the deployment project.
Objectives
After completing this lesson, you will be able to:
• Describe the importance of business requirements.
• Define a project’s functional business requirements.
• Define service level agreements (SLAs).
• Identify types of regulatory and organizational compliance requirements.
• Identify project constraints.
• Gather business requirements.
What Are Business Requirements?
Organizations invest in technology to solve business problems or to provide new

opportunities. Business requirements typically dictate reasons for an organization’s
proposed new technology implementation.
Business Requirements
To operate more effectively, an organization must address its many needs, or business
requirements. Business requirements can take many different forms. For example, an
organization may need to:
• Become more efficient. Most businesses are very competitive and strive to be
more efficient than are their competitors. When evaluating new technologies, these
organizations typically will invest in the technology if it will improve efficiency.
• Meet an external requirement. Forces outside an organization, such as the
government or business partners, may impose requirements. For example,
government regulations may require archival of certain e-mail messages for a
specified time or business partners may enforce specific security requirements for
e-mail communication between locations.
• Avoid disruptions to business processes. A current technology may meet most
business requirements. However, if it is unreliable, an organization may invest in a
new technology that provides the requisite reliability and availability.
• Explore new business areas or solutions. Organizations sometimes use technologies
to pursue new business opportunities. For example, deploying Web-based tools for
selling products and services has increased the business potential for many
organizations significantly.
Importance of Business Requirements

A technology deployment is more likely to address an organization’s needs if business
requirements are defined clearly and concisely at the project’s inception. Additionally, it
is easier to measure a project’s success if the project team is knowledgeable about the
business problems that the project must solve.
What Are Functional Requirements?
Functional requirements define a technology’s expected behavior by describing a

system’s specific behaviors. You derive functional requirements from business
requirements. Business requirements define the problem to address, while functional
requirements define how the proposed technology should solve that problem.
For example, an organization may define a business requirement that all e-mail messages
to and from a partner organization must be secure. The resulting functional requirement is
that the servers running Exchange Server 2007 and that handle e-mail sent between the
two organizations must be configured to require that all e-mail messages are encrypted.
A use case typically accompanies each functional requirement. A use case describes an
activity performed within the organization and the activity’s intended outcome.
For example, a use case might specify steps that a user inside the organization must
follow when sending an e-mail message to someone at the partner organization, given the
business requirement that any message sent across a network connection must be secure.
In this example, the use case defines the functional requirement (encryption of all e-mail
messages) and subsequently tests whether the deployment (the specific steps the user
must follow) addresses the functional requirement.
Functional Specification
Functional requirements help create the functional specification, which serves as a
contract between the customer and the team, describes the proposed solution in exacting
detail, and forms the basis for project plans and schedules. The customer is the consumer
of the technology, and usually are the business sponsors and users.
The functional specification is important because it:
• Establishes an agreement between the team and the customer. This enables the team
to determine the correct solution to meet the customer’s expectations.
• Provides in-depth project details to help the team determine if it is building the
solution correctly. This, in turn, makes the solution easier to validate and verify.
• Enables the team to estimate budgets and schedules. The quantity of resources and
their respective skill sets are difficult to determine without the specific detail that a
functional specification provides.
Note: In addition to functional specifications, every design has nonfunctional

requirements. Nonfunctional specifications do not define what the system does but
rather, how the system will perform and/or the quality of service it will provide.
Common nonfunctional requirements include system availability, maintainability,
performance, reliability, and scalability.
Defining Service Level Agreements
Service level agreements (SLAs) are understandings reached between an organization

and its IT department that define expected infrastructure performance levels. It is
important to define an SLA because it documents the service expectations and
requirements that an organization expects the IT department to deliver. SLAs may
define several categories of expected performance, including:
• Availability. For example, an SLA may require that all users can access their
mailboxes on the Exchange servers 99.99 percent of the time during business hours
and 99.9 percent of the time during nonbusiness hours.
• Performance. For example, an SLA may specify that all messages sent between
company locations are received within 60 seconds, 99 percent of the time.
• Recovery. For example, an SLA may stipulate that if a mailbox server fails, all
mailboxes on that server will be restored within eight hours.
Types of SLAs
The SLAs that organizations use can vary from informal to very structured:
• Informal SLAs often are not documented, but rather are general expectations for
system performance that are well known. For example, an organization may have an
internal, unwritten policy that certain servers never are restarted during business
hours.
• Formal SLAs typically are documented extensively and detail expectations
determined from negotiations between service providers and business customers.
These SLAs may define exact expectations for each system component and may
include penalties if expectations are not met. Often, the most formal SLAs are
negotiated between business customers and outsourced IT providers.
Best Practice: If an organization does not have any written SLAs, it is very
important when beginning any deployment project to identify and document
informal SLAs. Clearly identifying the expected system performance enables future
validation of the project’s success.
Negotiating SLAs
SLAs have a significant impact on a project’s scope and budget, so it is important to
define them at the project’s inception.
Business requirements, plus functional and nonfunctional requirements, typically are the
basis for initial SLA negotiations. In most cases, the project team and business sponsors
negotiate the final SLA details. Initial requirements may set very high expectations.
However, meeting those high expectations can be very expensive. For example, say an
SLA requires that messages are delivered between company locations within 60 seconds,
100 percent of the time. The only way to meet this expectation may be to deploy fully
redundant systems throughout the organization. The cost of this likely would be
prohibitive. Thus, the organization may negotiate a more acceptable performance level
at a more reasonable cost.
Discussion: Identifying Regulatory and Organizational

Compliance Requirements
E-mail is a primary method of communication in many organizations and typically is

used to communicate much business information, including confidential materials such as
customer data or business intelligence. In many countries, governments have imposed
compliance requirements that mandate how organizations ensure data confidentiality.
Discussion Questions
Based on your experience, consider the following questions:
Q In what type of business does your organization participate? What are the legislated
compliance requirements for your organization?
A Answers will vary depending on the type of business in which your organization
participates. Examples of legislation restricting how organizations manage
information include:
• United States:
• Sarbanes-Oxley Act of 2002 (SOX)

• Gramm-Leach-Bliley Act (Financial Modernization Act)
• Health Insurance Portability and Accountability Act of 1996 (HIPAA)
• Uniting and Strengthening America by Providing Appropriate Tools
Required to Intercept and Obstruct Terrorism Act of 2001 (USAPatriot Act)
• Canada: The Personal Information Protection and Electronic Documents Act

• Australia: Federal Privacy Act
• Europe: European Union Data Protection Directive (EUDPD)
• Japan: Japan’s Personal Information Protection Act
Q What additional compliance requirements does your organization have?

A Answers will vary. For example, organizations may impose strict requirements for
managing e-mail. Some may add legal disclaimers to outgoing communications or
require that certain messages include an intellectual property disclosure disclaimer.
Additionally, the organization may have requirements for message retention that
require certain messages are retained while others are deleted after a specific amount
of time.
Q What issues do regulatory and organizational compliance requirements raise for your
organization? How are you addressing these issues? What are the gaps between the
requirements and the solutions?
A Answers will vary. Traditionally, it is difficult to address regulatory and
organizational compliance requirements. Answers may include:
• Archiving all messages using a third-party tool.
• Specifying policies to regulate the types of information sent via e-mail.
• Enforcing policies through auditing.
• Scanning messages for content and applying necessary disclaimers.
Q Are the compliance solutions based on policy or technology? In other words, does
your organization only have written policies that define what users can do, or is there
a technological solution in place to enforce some or all of the requirements? If you
are using a policy-based solution, how do you enforce policies?
A Answers will vary. Typically, organizations have policy-based solutions for cases
where a technology-based solution does not exist. Additionally, policy-based
solutions are difficult to enforce and policy violators often are detected only through
difficult investigation.
Identifying Project Constraints
Project constraints define the project’s parameters. Project constraints often set limits on
what you can accomplish. For example, if the project has a fixed budget, the budget
becomes a constraint that defines parameters for what you can accomplish.
Types of Project Constraints

There are three categories of project constraints: resource, schedule, and feature
constraints.
• Resource constraints. A project’s budget is a common resource constraint. If the
proposed budget cannot meet the projected personnel costs, equipment costs and
software costs, the project cannot continue. Additionally, a project may have
additional resource constraints:
• The appropriate personnel may not be available or their training may not be
sufficient to complete the project.
• Computer resources or equipment may not be accessible.
• Schedule constraints. A project schedule also may restrict what the project can
accomplish. For example, many organizations do not allow changes to the IT
environment during specific times, such as during the end of the corporate fiscal year
or peak business cycles. If a project is due for completion during one of these periods,
the project scope may require modification. Additionally, in large organizations, a
project may be constrained by the schedule of other projects.
• Feature constraints. Organizations may restrict features that are included in a project.
For example, a requirement may exist to provide users with cell phone-based mobile
devices access to Exchange server mailboxes. However, if the proposed solution
cannot address this requirement, the project might be canceled. Additionally,
requiring e-mail encryption might necessitate issuing a smart card to all mobile users.
However, the organization might not have the organizational maturity, necessary
infrastructure, or budget to do so.
Negotiating Project Constraints

The project team must identify constraints early in the project, as such constraints can
impact the solution design significantly.
The project team and business sponsors often negotiate project constraints, as well as
business requirements and SLAs. The budget may seem like a firm constraint, but if
increasing the budget results in meeting an important business requirement or SLA level,
you may decide to adjust the budget or remove a feature from the solution design.
Gathering Business Requirements
Assessing the company’s business needs is a key strategy for gaining approval to deploy
Exchange Server 2007. Typically, a business justification for investing in the new
technology is required. You need to collect information from many sources to define
business requirements. The most common methods for collecting this data include:
• Interviewing or holding focus groups for stakeholders and users.
• Observing users as they perform tasks, or asking users to demonstrate the tasks they
perform.
• Reviewing existing documentation, including business and technical documentation.
• Developing a solution prototype (often referred to as a “proof-of-concept”) or
demonstrating the available functionality that a product provides.
• Implementing user surveys.
• Talking with help-desk personnel to identify common issues that users experience.
Business requirements also may include additional relevant information, such as market
data, competitive analysis, and customer feedback. You may collect this information
from existing documentation or through additional surveys or interviews.
Identifying Business Requirements

When preparing to implement a new messaging solution, consider the following
questions that will help identify business requirements:
• Which business processes depend on the messaging system? How important are these
business processes to your organization?
• How are your business processes affected if the messaging system is unavailable?
Can you quantify your business costs should the messaging system be available for
10 minutes? For an hour? For a day?
• What new business areas are you exploring that may require messaging?
• Are there regulatory requirements that your messaging system must meet or exceed?
• What level of security is required for your messaging system? What data do
employees send by internal and external e-mail? Does you company regularly send
private customer information or confidential company information via e-mail?
Considerations for Identifying Business Requirements

Defining business requirements for a large project, such as a messaging system upgrade,
can be difficult and may require that you consider several factors:
• Be aware of exceptions to the business requirements for one or more of your
business groups. For example, rules for mailbox size limits or message size limits
do not always apply to executives. Typically, people who are most critical to an
organization’s success can define and receive executive support for their own
requirements. These groups often drive technology innovations, such as the
adoption of mobile messaging devices. Additionally, there may be employees
with exceptionally low technology requirements, such as users with assembly-line
positions who do not require messaging capability.
• Be aware of changing business requirements during the project design phase. For
example, constraints may necessitate removing or adding business requirements. A
project must accommodate changing requirements, but it is important to identify a
process early in the project schedule to address changes to business requirements.
• Create a strategy for communicating with the business customer early in the project
schedule. A project addresses business requirements, so the project’s initiation will
set expectations for when new functionality will be available. A communication
strategy keeps the customer informed about the project’s progress and also provides a
way in which to communicate changes to business requirements.
Lesson 2: Identifying Additional Requirements
Business requirements are not the only factors to consider when designing a messaging
system. Additional needs can add to the project design or constrain a project’s design by
limiting or strictly defining which business requirements the project can address.
Objectives
• Identify additional project stakeholders.
• Define technology requirements.
• Identify IT needs.
• Identify security mandates.
• Define user demands.
• Resolve conflicting requirements.
Typical Stakeholders
The business sponsor is one of the most important stakeholders for most projects. The
business sponsor typically provides the project’s business requirements and budget.
However, a large project, such as deploying a new messaging system, will impact an
entire organization significantly and many people throughout the organization must have
input into the project’s design.
Who Are Stakeholders?

A project stakeholder is anyone who sponsors a project or has interest in the project’s
completion. A stakeholder’s interest may be determined by how the project:
• Affects the way in which a person works.
• Affects a technological area for which a stakeholder is responsible.
• Provides new opportunities. For example, if a project provides new offerings to
customers, they may be important stakeholders.
• Increases workload. A stakeholder may be involved in the product’s deployment or
future support.
A project such as an Exchange Server 2007 deployment can have several additional
stakeholders besides the project sponsor, including:
• IT personnel. The Exchange Server 2007 deployment will affect almost all aspects of
IT administration. Therefore, IT personnel have an interest in the technical design.
The specific roles that will be affected include network administrators, storage area
network (SAN) administrators, Active Directory® directory service administrators,
administrators for network services such as Domain Name System (DNS), and
messaging administrators.
• Security and compliance officers. These people typically are important stakeholders
because of the data types being sent via e-mail and the integration of e-mail into
many business processes.
• Messaging users. A new technology often affects users directly, so they may have
different requirements than a business sponsor.
Identifying Stakeholders
Use the following process to determine which stakeholders should be consulted regarding
a messaging system deployment:
1. Identify a small group of the most critical and obvious stakeholders, and the
personnel who have the highest level of IT infrastructure understanding.
2. Present this group with a high-level description document of the project scope and
business requirements. The description document does not need to be detailed, but
should include the parts of the organization that the project may impact.
3. Allow this group to identify all other organizational parties or groups that the new
technology’s deployment will affect.
4. Gather additional information, if necessary, to verify the description document’s
accuracy. For each group that is listed, briefly describe its contribution to the project.
5. Select one or more group members to act as stakeholders and the group’s
representatives.
Defining Technology Requirements
IT personnel are one of the most important stakeholder groups in an Exchange

Server 2007 deployment. Typically, they have a thorough understanding of the current
technology environment. This means that they understand the current environment’s
limitations and can detail the project’s necessary technological requirements.
What Are the Technology Requirements?

Every organization has technology requirements that affect an Exchange Server 2007
deployment. One of the most important considerations in a deployment project is the
current technology infrastructure. In almost all cases, the Exchange Server 2007
deployment must integrate with the existing environment. Components to consider in
the existing infrastructure include:
• Server room equipment. This includes infrastructure such as air conditioning,
uninterruptible power supply (UPS), redundant power sources, and fire-suppression
equipment. Server room equipment also may include physical security to ensure that
only authorized personnel enter the room. In most cases, modifications to server
room equipment are not included in the Exchange Server 2007 deployment project
or budget. Therefore, available equipment may impact deployment.
• Storage technologies. Most large organizations have implemented storage area

networks for applications such as Exchange Server, which stores a large amount
of data. If an organization has a significant monetary investment in this solution,
the Exchange Server 2007 deployment likely will have to use the SAN solution,
regardless of whether an alternative solution provides more benefits. On the other
hand, if the SAN is operating at maximum capacity, the Exchange Server 2007
project must implement alternative storage solutions. Exchange Server 2007 provides
options such as continuous cluster replication (CCR) for providing data redundancy
and supports new technologies such as Internet SCSI (iSCSI).
• Backup and recovery solutions. The Exchange servers must be included in the regular
backup process. If an organization has an existing corporate backup solution, the
Exchange servers must use that solution. This may constrain the project’s design for
backing up Exchange servers. For example, the backup solution may have limited
capacity, which may require a small backup window for the Exchange Server
environment. You also will need to consider the changes made to Exchange
Server 2007 to support Volume Shadow Copy Service (VSS) backups and features
such as local continuous replication (LCR) and CCR when planning the Exchange
integration into the current backup solution.
• Network infrastructure. The Exchange Server 2007 deployment must integrate with
the current network infrastructure. The local area network (LAN) or wide area
network (WAN) environments may constrain the available messaging bandwidth,
which in turn may impact whether SLA-mandated message delivery times can be met.
As part of the project design, you must consider whether to include network upgrades
or renegotiate the SLA.
• Active Directory infrastructure. Exchange Server 2007 is integrated tightly
with Active Directory, but it can operate in almost any Microsoft® Windows
Server™ 2003 Active Directory environment. However, the Active Directory
configuration, such as the site configuration, and the locations of the domain
controller and global catalog server can impact Exchange server performance
significantly. If the Active Directory environment is not designed for optimal
performance, a redesign of the Active Directory configuration or modification of an
optimal Exchange server design may be necessary.
Identifying IT Requirements
In addition to requirements of the current technological environment, an Exchange

Server 2007 deployment project may need to be compatible with current IT policies and
processes. Business requirements typically drive adoption of new technologies. However,
the IT department—which can include messaging administrators, messaging engineers,
and help desk personnel—is responsible for actual technology deployment and operation
and, therefore, is an important project stakeholder.
Identifying IT Department Requirements

A project’s business requirements may differ from IT department needs. When discussing
the project with IT representatives, ask the following questions:
• What are the IT concerns about the project? Introduction of any new technology
likely will raise IT concerns, which may include potential disruptions to other IT
systems, the training needs for IT personnel who have to manage a new technology,
or the impact to current IT processes of a new solution.
• What are the current IT pain points that the project may address? IT departments
often have long-standing concerns or issues with organizational processes.
Sometimes, these issues result from a limitation in the current technology. By
exploring messaging-related issues with the IT department, you may be able to
incorporate a solution into the Exchange Server 2007 design.
• What are the IT requirements for accepting a new technology? Many organizations
have very detailed transition-to-production requirements that must be addressed
before the IT department can accept a new technology. These requirements may
include detailed documentation on deploying and managing new technologies, and
training for those who have to manage new technologies.
Identify IT Policies and Processes

The Exchange Server 2007 deployment project must follow IT processes and policies
during and after deployment. For example, if an organizational policy mandates that you
use a specific vendor for purchase of all network and server components, the Exchange
Server 2007 deployment project must follow that policy. This may impact the project
design if the vendor does not have a specific component available, or it may impact the
project schedule if delays occur in obtaining products from the vendor.
Interview IT managers and procurement personnel to identify and procure documentation
for relevant policies and processes that the project should follow.
Identifying Security Requirements
Another essential stakeholder group consists of those who create and enforce an
organization’s security policies. Messaging is an integral part of most organizations’
business processes, so it is imperative to identify any security issues early and include
their solutions in the project’s design.
Identifying Security Requirements

Virtually all IT projects have security requirements. Any project that includes a
messaging component is likely to have security requirements because of the importance
of messaging and its inherent security risks. The security officer is the most important
stakeholder you can interview to identify security requirements. However, you also
should interview network and server administrators and business managers to identify
additional security requirements.
To identify security requirements, ask the following questions:
• What are the organization’s security risks? There are many possible answers to this
question, including:
• E-mail clients are at risk from viruses and other malware that may be spread
through the e-mail system.
• When users access their mailboxes using Microsoft Office Outlook® Web
Access for Exchange Server 2007, authentication traffic and message-access
traffic are at risk for capture. A security risk also occurs if users save confidential
attachments on unsecured client computers.
• Mobile client computers are difficult to secure and frequently are lost or stolen.
• Internet-facing Simple Mail Transfer Protocol (SMTP) servers must accept

anonymous and unauthenticated connections and must be able to send e-mail
using the same connection types. This does not provide security for messages,
and may expose potentially private or confidential information. Additionally, the
server is exposed to Internet attacks.
• Messages on mailbox servers may contain private or confidential information
that is at risk if unauthorized users access the data or if the server is compromised.
• How are the security requirements currently addressed? Almost all organizations
have addressed at least some security requirements. For example, virtually all
organizations have implemented antivirus and anti-spam solutions. Most
organizations use Secure Sockets Layer (SSL) to secure Microsoft® Office
Outlook® Web Access traffic.
• What gaps exist between security requirements and current solutions? One of the
most difficult security gaps to address is with SMTP e-mail. Virtually all SMTP
e-mail is sent in clear text or is Multipurpose Internet Mail Extensions (MIME)
encoded. Organizations can implement features such as S/MIME (Secure/MIME) or
Transport Layer Security (TLS), but the functionality is limited and may be difficult
to implement or manage.
• What general security requirements or guidelines must the messaging project follow?
Most organizations have general security requirements that apply to all projects and
may require that:
• All user authentication traffic be encrypted on internal and external networks.
• Private customer information must never be exposed to the Internet.
• All servers are located in a locked facility that limits access to authorized
personnel.
Negotiating Security Requirements

Security requirements can sometimes conflict with business requirements. For example,
a business requirement may state that customers can request that information about their
account be sent to them via e-mail. However, the security requirement may state that
confidential customer information is never sent unencrypted on the Internet.
Security requirements often place restrictions on what a project can accomplish. A
technical solution may meet or exceed business requirements, but if the person who is
responsible for defining security requirements does not consider it secure, it may need
revision or you may need to remove the business requirement.
Defining User Requirements
Another important stakeholder group in an Exchange Server 2007 deployment are the
messaging system’s users.
Identifying User Requirements

User requirements may differ from requirements that the business sponsor identifies. For
example, the business sponsor likely is most interested in the functionality that the system
provides, while users typically are interested in the system’s ease of use or how it allows
them to perform tasks more efficiently.
Identify user requirements by interviewing users and help-desk or support personnel who
work most closely with users. During this interview, ask the following types of questions:
• How do the users currently utilize e-mail? Is there e-mail functionality that users
would like to have that the current system does not make available?
• What types of messaging clients does the organization use? What other messaging
clients would the users like to have?
• What problems do users experience with the current messaging system? Why are
users experiencing the issues? Is the problem due to technology limitations or a lack
of user knowledge or training? Is the problem due to a policy limitation, such as
mailbox size restrictions?
• What user training will be required when you implement the new system?
• What security requirements exist for client access to user mailboxes?
• How much do users utilize the messaging system? Can you characterize the activity
level of users as light, medium, or heavy? How many users fall into each category?
• Are there groups of users with special security needs, performance requirements, or
functionality concerns?
Important: User requirements are very important to a messaging system’s ultimate

success or failure. If the first user experience with a new system is negative,
because the system is difficult to use or does not meet expectations, it is very
difficult to achieve broad user acceptance of the system. As much as possible,
ensure that your solution addresses user requirements and that users receive the
required training for the new system.
Discussion: Dealing with Conflicting Requirements
As you gather all of the requirements for the Exchange Server 2007 deployment, it is
likely that you will identify conflicting requirements. For example, certain business
requirements, such as the budget, may conflict with other business requirements, such as
security requirements. In this example, the IT department may have security requirements
that add significant cost to a project, thereby exceeding the budget that the business
sponsor set.
Q What examples have you seen where requirements conflicted?
A There are many possible answers. In some cases, business requirements may conflict
with the IT requirements. For example, the business requirement may state that all
users have full access to their mailboxes via mobile clients, while the IT requirements
may state that only approved mobile devices should be used by a small user subset.
Q One of the most common scenarios for incompatible requirements occurs between
security and business requirements. How can security requirements be balanced with
other requirements?
A These types of conflicting requirements typically are the most difficult to resolve. It
is hard to assign a dollar value to a security breach, so business sponsors may view
security requirements as a project cost that adds no value. Some general guidelines
for addressing security requirements include:
• Express security requirements in business terms. For example, the business
sponsor may not understand when you state that all messages must be encrypted
using at least 128-bit encryption. However, you can explain that sending
messages over the Internet is similar to sending a post card, rather than a letter in
a sealed envelope. Ask what types of business data are sent via e-mail to Internet
clients, and discuss the implications of someone being able to capture and read
that e-mail.
• Be clear about which security requirements are non-negotiable and which are
open to discussion. Every organization typically has non-negotiable security
requirements, such as the mandates for secure authentication traffic on the
Internet or that prohibit sending of private customer information in a format that
others can read easily. Other security requirements may be negotiable, or there
may be available options that partially address both security and business
requirements.
Q What guidelines would you suggest for addressing conflicting requirements?

A Answers will vary, but some suggestions are:
• Keep discussions related to requirements at a professional, rather than personal,
level.
• Be prepared to suggest and discuss alternatives. Instead of rejecting a
requirement, propose an alternative solution that may be more compatible with
conflicting requirements.
• Be clear on the implications of each requirement. Some requirements may be
very difficult to implement from a technical standpoint or prohibitively expensive.
Ensure that all parties understand each requirement’s implications.
• Address conflicting requirements early in the project schedule.
Lesson 3: Analyzing the Current Messaging

Environment
Once you have gathered the messaging infrastructure requirements, the next step is
to analyze the current network and messaging environment. Analyzing the current
environment helps determine the gaps between the current messaging infrastructure and
the requirements and goals of the intended messaging infrastructure. This information
provides a starting point for determining the appropriate design and implementation plan
for the Exchange Server 2007 deployment.
Objectives
• Analyze the physical network infrastructure.
• Analyze the name resolution services infrastructure.
• Analyze the Active Directory infrastructure.
• Analyze an existing messaging infrastructure.
• Identify usage statistics for a messaging system.
• Identify additional infrastructure requirements.
• Analyze administrative models and processes.
• Analyze a change-control process.
Analyzing the Physical Network Infrastructure
To determine how your existing network will support an Exchange Server 2007
messaging environment, build a complete picture of your network infrastructure,
including site locations, connection types, and router and switch configuration details.
Important: As you collect information about the current network infrastructure or

any other component in the current environment, you also should ensure that you
collect information about any planned environment changes. These changes may
interfere with the Exchange Server 2007 deployment or may result in changes to
your design.
Elements of the Physical Network Infrastructure

Consider the following elements of the physical network infrastructure:
• The number, geographic locations, and link speed of all sites where network services
exist. It is important to identify all locations that make up the network infrastructure,
such as buildings, campuses, and branch offices. You also must determine the
connection types and network speed for each location.
• A routing topology map that illustrates the physical sites and the Internet Protocol
(IP) subnets in use at those sites. This map is useful in planning or integrating with
the Active Directory site design, which in turn has a profound impact on Active
Directory replication and message routing.
• Bandwidth, latency, and current usage. Bandwidth is the transmission speed over a
network connection in kilobits per second (Kpbs). Latency refers to the time it takes,
in milliseconds, to transfer data between two points. Both of these factors combine
to determine how much data that can be transmitted in a set time period over the
network. This information, as well as the current applications using the network and
the number of users at various sites, and their use patterns, can be used to create a
design for your Exchange Server organization that provides a satisfactory user
experience. When mapping site locations and connections, determine the type and
speed of network connectivity and factor in the latency that distances between sites
introduces. The project may need to include network upgrades to provide Exchange
servers with adequate bandwidth for the messaging service.
• Use of virtual local area networks (VLANs). Determine the current use of any VLAN
configurations within your networking infrastructure. If required, ensure that you
configure these VLANs, or have the ability to configure them, to pass the traffic that
the existing and intended messaging system generates.
• Firewall configuration requirements. Depending on your deployment plan, you
should determine any firewall configuration requirements for implementation and
synchronization of an Edge Transport server, which you should place within a
secured perimeter network.
• Nontechnical constraints. These include geographical, political, or cost-related
restrictions resulting from a change or upgrade of network links between sites.
Note: Refer to the Existing Network Infrastructure Analysis job aid located on the
Student Materials CD.
Analyzing the Name Resolution Services Infrastructure
Name resolution services translate network addresses to computer names and vice versa.
The Domain Name System (DNS) provides the required name resolution services for the
Active Directory directory service, as well as for internal and external name resolution.
Exchange Server 2007 depends upon DNS for locating Active Directory domain
controllers, global catalog servers, other Exchange servers and remote domains. All
SMTP servers also use DNS Mail Exchange (MX) records for routing outbound mail.
Name Resolution Services Infrastructure

There are many factors to consider regarding the name resolution services infrastructure:
• What type of DNS software do you currently use? Is it able to handle service
resource records (SRV)?
• Who maintains and administers the organization’s internal and external DNS servers
and zone information? What are the IP addresses of all DNS servers?
• Who assigns DNS names and domains within the organization? Is there a centralized
authority for DNS namespace planning and control?
• Where are internal DNS servers located on the network?
• How many DNS zones are currently managed within the environment? Are the DNS
zones Active Directory integrated?
• What resource records are stored in DNS? For example, have the Sender ID records
been configured? How are the MX records configured? Have the Pointer (PTR)
resource records been configured for internal and external zones?
Analyzing the Active Directory Infrastructure
Active Directory directory service planning and administration is tied closely with
messaging-service delivery. In many organizations, the same team is responsible
for both. For messaging systems, the Active Directory is important because it is the
mechanism by which the mail transport agent decides which recipients are local and
where their mailboxes are stored. Many organizations have already migrated to
Active Directory, which means that the most important design and service decisions
have been made.
Active Directory Infrastructure

There are some specific points to investigate in existing Active Directory deployments.
These points include the following:
• Active Directory Site Configuration. Unlike Microsoft Exchange 2000 Server
and Microsoft Exchange Server 2003, Exchange Server 2007 does not require
configuration of a separate routing topology. Exchange Server 2007 uses the Active
Directory site topology to determine where messages are routed in the organization.
Because of this new dependency, it is important to have a solid understanding of the
current Active Directory site topology including:
• Number of configured sites.
• Subnet configurations and their site association.
• IP site links and their member sites.
• IP site link costs and replication schedules.
• Number of domain controllers and global catalog servers in each site.
• Active Directory forest and domain topology. To effectively integrate Exchange

Server 2007 into your current Active Directory structure, you must understand the
following:
• Does your organization consist of a single forest or multiple forests? The
complexity of the Exchange deployment depends on the complexity of the Active
Directory forest topology. A single forest provides the richest set of mail system
features and provides effective administration. You can create multiple forests to
address specific situations, such as when a merger or acquisition takes place.
• How many domains exist? Are there explicit trust relationships between them?
What trust relationships exist with external domains? If you have a resource
forest, or multiple forests in your organization, a trust relationship may be
required. If your topology includes multiple forests that contain Exchange
Server 2007 or if your implementation requires a forest-to-forest trust between
forests containing Exchange Server 2007, the minimum Active Directory forest
functional level for each forest must be Microsoft® Windows Server 2003. The
Active Directory domain functional level must be Microsoft® Windows 2000
Server-native or Windows Server 2003 for all domains in the Active Directory
forest in which you will install Exchange Server 2007.
• Domain controller and Global Catalog server configuration. As you analyze each
Active Directory site, document the configuration and location of each domain
controller and global catalog server. A Hub Transport server must be able to
communicate directly with a global catalog server to perform Active Directory
lookups. You may have to add a global catalog server to each site to ensure
availability. Also, at least one domain controller in each Active Directory site that
contains Exchange Server 2007 must be running Windows Server 2003 Service
Pack 1 (SP1).
• Group Policy configuration. Many organizations use Active Directory group policy
to provide centralized management and security of users, groups, and computers, and
other directory objects. Document the organization of servers in Active Directory and
how group policy is applied to the organizational units that contain server computer
accounts.
• Schema Master configuration. Because Exchange Server 2007 requires an update to
the Active Directory schema, it is important to document who controls the schema
master and the associated rights to make schema modifications. To support Exchange
Server 2007, the domain controller that is the schema master must have Windows
Server 2003 SP1 or Windows Server 2003 R2 installed.
Migration to Active Directory

If your organization is migrating to Active Directory during the messaging deployment,
evaluate the following factors when assessing the current directory:
• What directory service do you use currently? What are the revision and patch levels
installed on the servers?
• What is the location of the existing directory servers? For performance reasons, it
may be desirable to install new directory servers in the same locations.
• What metadirectory, connector, or directory-synchronization tools are in use? Will
any such tools be installed during the messaging deployment?
• How is directory data partitioned? Is data for different applications kept separately in
the directory?
• Are there existing directory access controls? If so, who controls and maintains them?
• Who owns the directory schema definition? How are changes managed?
• What physical sites and IP subnets exist? Will the number or location of these entities
change because of the messaging deployment?
Analyzing the Messaging Infrastructure
If your network contains an existing Exchange messaging environment, it is critical to

assess and document the specific functionality and configuration parameters before
proceeding with the Exchange Server 2007 deployment. The following sections discuss
what information you should gather when analyzing the current messaging infrastructure.
Capturing Current Information about the Messaging Environment

One way to capture most information about your current Exchange environment and your
current Active Directory and other required settings, is to use the Microsoft Exchange
Server Best Practices Analyzer Tool (ExBPA). The latest version of the ExBPA provides
an Exchange Server 2007 Readiness Check that assesses your organization’s suitability
for Exchange Server 2007. The ExBPA provides an extensive transition report to assist in
preparing to deploy Exchange Sever 2007.
Additional Information about the Messaging Environment

In addition to the information that ExBPA provides, you also should document other
information that you can use to roll back to a previous environment or configuration and
that is useful as reference material for comparing your existing environment to the
intended Exchange Server 2007 environment. Consider documenting the following
additional information:
• Exchange Server hardware and software version. Includes data related to the
processors, memory, and disk storage. Additionally, it is important to document the
version and service-pack level of the current Exchange Server software.
• Exchange Server configuration. This consists of data related to server roles, such as
front-end servers or SMTP gateway configurations, dedicated bridgehead servers,
mailbox servers, and public folder servers.
• Administrative roles. Document all Exchange administrators and administrative

groups and any delegated permissions that have been performed.
• Routing group configuration. Include data that indicates each group’s Routing master,
names and locations of servers, and detailed information about the connectors used
between routing groups. This information helps determine how you will transition
this configuration to the Active Directory site structure.
• Storage group and mailbox store configuration. This consists of the current mailbox
store configuration, database and log-file locations, and any policies that apply to the
current mailbox stores. Also take note of the current backup and restore plan for data
recovery.
• SMTP namespaces. Document SMTP namespace for all domains for which your
Exchange organization has authority.
• Global settings for message delivery. Consists of a number of configuration settings
that control message delivery, including:
• Sender and Recipient filters
• Address Filters
• Message size limits and message formats
• Anti-spam and antivirus settings. This includes information related to antivirus
software installed currently and specific settings related to content filtering or the
Intelligent Message Filter, IP Block lists, IP Allow lists, and attachment blocking
settings.
• Message security settings. This may include information related to the virtual server
settings, authentication and encryption settings, and secure relationships with other
SMTP e-mail domains.
• Third-party add-on services. Be sure to document any third-party add-on services,
including fax solutions or voicemail systems. You must determine if the new system
will need these services and develop plans to decommission these services when they
become unnecessary.
Integration Considerations
When integrating with an existing messaging environment, consider the following:
• Exchange Server 2007 does not support an in-place upgrade from any earlier
Exchange version.
• The Exchange organization must be operating in native mode before you can
introduce Exchange 2007 servers into the environment. This means that only servers
running Exchange Server 2003 and Exchange 2000 Server can exist in the
organization.
• If your organization includes Exchange Server version 5.5, you must perform an
upgrade to Exchange Server 2003 or Exchange 2000 Server before moving to
Exchange Server 2007. To move messaging services and data from Exchange
Server 2003 or Exchange 2000 Server to Exchange Server 2007, you must use the
move mailbox functionality in Exchange Server 2007.
Note: Refer to the Current Messaging Infrastructure Analysis job aid located on the
Identifying Messaging System Usage
Transitioning to a new messaging system requires a thorough understanding of current

usage statistics for your existing messaging system. This aids in estimating how the new
messaging environment will perform and if any hardware upgrades are necessary to meet
user demands. The following sections provide information to help you identify messaging
system usage within your network environment.
Profiling the Client Environment

You must determine how users connect to your current environment to facilitate planning
for processor and memory configurations for your intended messaging environment.
Collect the following types of information:
• Client environment. Updating to a new messaging system often requires careful
consideration of how users will access their messages and other mailbox information.
You may need to provide specific connection methods based upon a user’s
requirements or location. Consider the following when determining the client
environment:
• What operating system are the clients running? Some Outlook features are only
available on Microsoft Windows® XP. Older clients or Macintosh systems may
provide lower functionality. For using the messaging system, UNIX and Linux
clients may be restricted to Internet Mail Access Protocol version 4 (IMAP4),
Post Office Protocol version 3 (POP3), or Microsoft® Outlook Web Access
(OWA).
• How many client computers exist and where are they located on the network?
These two factors have a profound influence on the user’s messaging access
experience because slow networks or heavy server loads are common causes of
reported dissatisfaction. By understanding where users are located, you can better
determine client access bottlenecks within the messaging environment.
• Are there plans to redeploy, update, or replace clients? These efforts may happen
before, during, or after deployment of the new messaging system, and you can
plan the deployment accordingly.
• Which client protocols are used to access e-mail? Depending upon user
requirements, many organizations deploy one or more of the following client
protocols:
• MAPI clients
• HTTPS (Outlook Web Access)
• POP3/IMAP4
• Outlook Anywhere (formerly known as remote procedure call (RPC) over
HTTPS)
• Microsoft Exchange ActiveSync® or other mobile messaging clients
• WebDAV (Entourage clients)
Profiling Messaging Statistics

A number of messaging statistics are useful for determining your current messaging
environment’s usage. Specific statistics include the following:
• Total size of user mailboxes.
• Size of all messages in specific folders, such as the Deleted Items or Sent Items
folders.
• Average number of messages received per day.
• Average number of messages sent per day.
• Average number of recipients of each sent message.
• Attachment size statistics across all attachments.
• Number of contacts in a mailbox.
• Number of appointments in a mailbox calendar.
• Average number of meeting requests received per day.
Determine an extensive client user profile by using the Microsoft Exchange Server
Profile Analyzer or other third-party tools.
For more information: Additional documentation about the Microsoft Exchange

Server Profile Analyzer, see the “Microsoft Exchange Server Profile Analyzer (32
bit)” page on the Microsoft Download Center Web site.
You can use Microsoft Windows Performance Monitor to obtain current usage patterns
and statistics. Exchange Server installs many of its own performance objects and counters
to provide information about Exchange Server services and resources. Specific objects
and counters related to user statistics include the following:
Object Counter
MSExchangeIS • User Count
• RPC Requests
MSExchange IS Mailbox • Messages Sent/min
• Messages Delivered/min
SMTP Server • Inbound Connections Current
• Message Bytes Sent/sec
• Message Bytes Received/sec
Identifying Additional Infrastructure Components
You may need to consider a number of additional components when documenting your
current messaging environment. If you understand the use of these additional components,
you can determine the new messaging environment’s requirements and provide insight on
whether updated third-party components are necessary.
Additional Infrastructure Components

Consider the following sample points when documenting information related to
additional infrastructure components within your current environment:
• What is the current storage method for messaging databases?
Many of the currently deployed messaging systems use direct attached storage (DAS).
However, many organizations are adopting network attached storage (NAS) and SAN
devices because of their growing capabilities and decreasing storage cost per
gigabyte.
The 64-bit version of Exchange Server provides new performance and scalability
opportunities. The increased memory that 64-bit makes available means that
Exchange Server 2007 has tremendously different performance characteristics than
Exchange Server 2003. 64-bit code also reduces the disk I/O required for Exchange
Server 2007 substantially.
Today’s larger Exchange deployments typically require a high-performance SAN-
based storage solution to ensure scalability. With Exchange Server 2007’s ability to
use large amounts of memory, the disk I/O throughput is reduced dramatically.
For more information: When selecting a storage solution, choose a solution that
the Microsoft Exchange Solution Reviewed Program (ESRP) has reviewed. For
more information about ESRP, see the “Microsoft Exchange Solution Reviewed
Program (ESRP) – Storage” page on the Microsoft TechNet Web site.
• Have you integrated Windows Clustering services? It is important to document

how you have implemented Windows Clustering services within your messaging
environment. There have been significant changes and improvements related to high
availability and clustering in Exchange Server 2007.
• What additional software has been integrated into the current messaging system?
Examples of additional software or services that may have been implemented include
archiving solutions, anti-spam and antivirus solutions, backup solutions, and third-
party high-availability solutions.
• Have you implemented a specific backup and disaster-recovery infrastructure? Many
organizations use a separate high-speed network solution for backup and disaster-
recovery purposes. It is important to document this structure’s use and configuration
to ensure that it is adequate for the new Exchange Server 2007 infrastructure.
• How does your current messaging environment integrate with other systems? Be
sure to document this integration, such as with other messaging environments or
network services. For example, do you need to integrate or synchronize information
with a Lotus Domino environment? Many organizations also purchase solutions
to provide integration into existing telephone messaging systems. All external
integration solutions need to be documented and evaluated to ensure functionality
with Exchange Server 2007.
Create an inventory of the products used in your environment, including antivirus and
anti-spam solutions, storage management software, fax or unified messaging connectors,
and system management and monitoring tools.
Analyzing Administrative Models and Processes
Your organization’s administrative structure and processes have great influence over
the IT infrastructure design. Understanding the constraints inherent in a particular
organization is a crucial part of assessing the environment before you deploy the new
messaging system. Areas to investigate include:
• Current organizational administrative model. In some organizations, IT management
may be centralized, while in other organizations, the responsibilities may be
delegated to regional areas or individual business units. The most common approach
is a combination of the two, in which some IT functions are centralized, such as
network provisioning and security, while others, such as user account management
and mail administration, are delegated to geographic or business subdivisions.
• User account administrative model. In a centralized environment, a single group of
administrators may perform these tasks for all organizational users. In a decentralized
environment, this responsibility may lie with the messaging team or another team,
such as the human resources or corporate security departments.
The Exchange Server 2007 administrative model has changed significantly from
previous Exchange versions. Mailbox attributes and recipient information are no
longer managed with the Active Directory Users and Computers snap-in. This change
provides a simplified model for delegating Active Directory tasks versus Exchange-
related tasks.
• Business unit structure. It is not necessary to explore exhaustively the

interrelationships between an organization’s business units or divisions. However,
it is useful to examine some aspects of these relationships. For example:
• Do separate business units or divisions require security boundaries between
them? If so, you may need a multiple-forest design, but it has implications for
directory synchronization and message interchange.
• What are the requirements for communication between different business
units? For example, is a unified directory or address list necessary for the
entire organization? Do different business units need to be able to schedule
appointments or otherwise collaborate? If so, you must accommodate this with
your messaging system design.
• How is cross-unit communication controlled? In other words, which group is
responsible for locating and resolving authentication, network, or protocol
problems that hinder communication between users and resources in different
units?
• How is the messaging system funded? While this question might seem to
be irrelevant from a design standpoint, the answer is important. In many
organizations, the business units that fund the messaging systems want the
initial design to specify accounting, chargeback, quota, and tracking features.
• Troubleshooting processes. Most large organizations have a well-defined
troubleshooting process that may include multiple support levels. The information
about the current troubleshooting processes is useful when you create the deployment
plan and helps to ensure that the appropriate administrators receive the necessary
training for troubleshooting the Exchange Server 2007 deployment.
Analyzing the Change Control Process
The change control process varies greatly between organizations. Some organizations
have not implemented a formal change control process, while others implement strict
change requests, approval, and notification processes. It is important to understand how
your organization manages changes to ensure that all users and stakeholders are aware
and approve of changes made to your messaging environment.
Identifying Change Control Processes

Change is any modification, introduction, or elimination of an IT component that may
affect an IT service level or the functionality of its environment or components. Key
questions to ask regarding change control processes include:
• How does the organization implement IT changes? You need to identify specific
processes that take place when you implement changes. These processes may
include:
• IT infrastructure change approvals. Before you make changes, IT managers,
architects, or security personnel may have to provide approval. You need to
document who the decision makers are and how they affect the change-approval
process.
• Change notification. Before the change takes place, all affected users must be
notified of the change and any impact it may cause. It is important to document
all current change-notification processes and the requirements specifying when
change notifications are required.
• Emergency escalation notification processes. If issues arise during
implementation of the approved change, you will need to know who to contact to
provide troubleshooting and recovery procedures.
• What are the time frames for making changes that may impact availability? Many
organizations implement SLAs with their internal users or customers. An SLA
provides a guarantee that specific network services will be available and outlines
acceptable outage time frames should an upgrade or failure occur. Document all
current SLAs that the organization uses to ensure that changes do not impact legal
requirements to users.
• What are the risk management processes related to change management? A complete
change control process includes a risk analysis and processes for mitigating risks.
Note: For more information on change control processes and risk analysis, see
Course 5054: Designing a High Availability Messaging Solution Using Microsoft®
Lesson 4: Creating a Requirements Document
After you have gathered the business requirements and current environment data, you are
ready to create a requirements document. A requirements document summarizes all of the
information that you gather and provides a basis for the new messaging infrastructure’s
design and implementation plans. This lesson describes the components of a requirements
document and discusses how to evaluate priorities and constraints when determining the
project’s business and technical goals.
Objectives
• Describe the components of a requirements document.
• Define project priorities and constraints.
What Is a Requirements Document?
A formal requirements document may vary depending upon a project’s complexity and
the organization that is implementing the project. However, there are many common
sections that should be included in all requirements documents to ensure effective
decision making and provide a foundation for subsequent design and implementation
documentation.
Components of a Requirements Document

A typical requirements document includes:
• Executive summary. The requirements document may be several pages. The
executive summary provides an overview of the document’s major points. It should
be no more than one page and should target managers and key project stakeholders,
such as the business sponsor, who will make decisions related to the project.
• Project vision. This section states the overall project goal(s). The vision should be a
brief statement that identifies key business requirements and how the project will
address those specific requirements to enable the organization to be more successful.
This section should not be more than one paragraph and often is just one sentence.
This vision should make the project’s main purpose and importance obvious to the
primary decision makers.
• Project scope. This information details the project’s extent, specifically what is, and
is not, included. This section enables you to state clearly and concisely what
assumptions and boundaries pertain to the project to avoid any perception that the
solution fails to address specific concerns.
Important: All project stakeholders should review and sign off on the project vision
and scope. This ensures that there is an understanding of project goals and
boundaries.
• Summary of business requirements. Detail the information collected during the

business requirements analysis task. You must clearly define the needs that the
project must address so that the organization can perform its business tasks more
effectively and efficiently.
• Summary of functional requirements. List the functional requirements that were
identified during the requirements analysis task. The functional requirements should
define how the proposed technology addresses the project’s business requirements,
and may be quite extensive because it relates to many areas, including performance,
security, manageability, usability, availability, and scalability.
• Summary of additional requirements. State any additional requirements identified
during the requirements analysis task. These may include data related to additional
stakeholders, required technology, and user requirements.
• Project priorities and constraints. Outline the project’s priorities and constraints.
During the requirements analysis task, specific priorities likely were identified related
to the schedule, resources, or features that must, or must not, be included.
• Summary of current environment. Summarize the information collected during the
current environment analysis task by outlining the data related to the existing
physical and logical network infrastructure, the messaging infrastructure, system-
usage statistics, and any additional infrastructure components that are identified.
Provide details of the current administrative model and processes within the existing
network environment.
Discussion: Defining Project Priorities and Constraints
Three categories of constraints bind implementation projects—resources (people and

money), schedule (time to complete the project), and features (scope). These three
categories comprise what is known as the Tradeoff Triangle. You can view quality as a
fourth dimension that transforms the triangle into a three-sided pyramid. Remember that
lowering the quality bar results in simultaneously reducing resources, shortening the
schedule, and increasing features, but it is often a recipe for failure.
After you establish the triangle, any change to one of its sides requires a correction to one
or both of the other sides to maintain project balance.
You also can use the Project Tradeoff Matrix. This tool helps identify project constraints
that essentially are unchangeable (represented by the Fixed column), those that are
desired priorities (represented by the Chosen column) and constraints (represented by the
Adjustable column) that are adjustable to accommodate Fixed and Chosen constraints.
To understand how the tradeoff matrix works, insert resource, schedule and feature
variables in the following blanks:
Given fixed ____________, we will choose a ___________ and adjust ___________ as
necessary.
Q What tradeoff decisions must be made during a project design?
A Tradeoff decisions that you need to consider are Resource, Schedule, and Features.
The Resource tradeoff includes factors such as personnel and budget. For example,
the messaging engineers may be engaged on several projects and may not be
available full-time for the deployment project. The Schedule indicates the time
needed to complete the project. The Features tradeoff indicates the functional
specifications that are both part of, and not part of, the project’s scope. Exchange
Server 2007 provides many new features related to client access to e-mail and
messaging policies. Resource or schedule constraints may limit which of these
features you can implement.
Q How are project priorities determined?

A The project priorities are determined based on the project’s business and technical
requirements. This is why it is so important that stakeholders sign off on the priorities.
Priorities determine the overall success of the project.
Q How can the Tradeoffs Triangle and Project Tradeoff Matrix help to make tradeoff or
priority decisions?
A Both tools provide a visual reference of the impact of prioritizing one element over
another.
Q How do you decide which variable on the triangle is most important?

A This depends on the business and technical requirements. For some projects, the
budget may be more important and is therefore a fixed constraint. For other projects,
the schedule or features may be the fixed constraint.
Lab: Gathering Requirements for a Messaging

Infrastructure
After completing this lab, you will be able to:

• Evaluate an existing messaging infrastructure.
• Create a requirements document.
• Balance budget restrictions.
Estimated time to complete this lab: 100 minutes
Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the
lab, you must:
• Start the 5053A-LON-CL1 virtual machine.
• Log on to the virtual machine as TreyResearch\Administrator with a password of
Pa$$w0rd.
Note: Two additional virtual machines are provided with this course. 5053A-LON-
DC1 is configured as a domain controller in the treyresearch.net domain and has a
standard Exchange Server 2007 installation. 5053A-LON-Edge1 is a stand-alone
server and has the Exchange Server 2007 Edge Transport Server role installed on
it. The 5053A-LON-CL1 computer is a member of the treyresearch.net domain.
These additional virtual machines are provided for your reference. You will not be
performing any lab steps on the computers, but you can use them to investigate
Exchange Server 2007 configuration options when required.
Lab Scenario
You are a messaging engineer for Trey Research, an enterprise-level organization with
multiple locations. Trey Research is an international corporation involved in technology
research and investment, and is planning to upgrade from Exchange 2000 Server to
Exchange Server 2007. Trey Research currently has three remote sites and their
headquarters. The company is pursuing an aggressive expansion plan and will be adding
two new office locations during the upgrade project.
Location Internal Users Mobile Users
London 12,000 currently • 1000 – Outlook Web Access users
Corporate Headquarters 10,000 after the new • 500 – Outlook Anywhere and mobile client users
London office is ready • 800 – Outlook users connecting through a VPN
London (new office) 4,000 (anticipated) • 200 – Outlook Web Access users
• 50 – Outlook Anywhere and mobile client users
San Diego 500 • 50 – POP3 client users
Former head office of
A. Datum Corporation
Toronto 6,000 • 800 – Outlook Web Access users
Tokyo 5,000 • 1000 – Outlook Web Access users
• 200 – Outlook users connecting through a VPN
Chennai (new office) 800 (anticipated) • 200 – Outlook Web Access users
TreyResearch has deployed a single Active Directory forest with a dedicated root domain
named TreyResearch.net and three child domains in the same tree. These domains are:
• EU.TreyResearch.net
• NA.TreyResearch.net
• AS.TreyResearch.net
Additionally, the organization has deployed a domain named Adatum.com in the San
Diego location. This domain is configured as a separate tree in the TreyResearch.net
forest.
Exercise 1: Evaluating an Existing Messaging Infrastructure

In this exercise, you will complete two sections of a messaging infrastructure checklist.
To complete this exercise, review the existing Trey Research documentation. You can
review the following documentation sources:
• Microsoft Office Visio diagrams describing the Trey Research environment.
• Visio diagram describing a part of the Trey Research organizational structure.
• Interview notes from meetings with various personnel at Trey Research.
Note: The documents in the LabResource folder on the LON-CL1 are also
available in the Appendix in the student workbook.
Tasks Supporting information
1. Review the Trey Research • Review the following sources of information located in the
documentation. D:\LabResources folder:
• TR_Info.vsd
• TR_Orgchart.vsd
• Requirements Interview Notes.doc
2. Complete the appropriate • The Current Network Infrastructure Analysis.doc file is located in
sections in the Current the D:\Mod01\Labfiles\LabInputs folder.
Network Infrastructure • Complete the following sections in the document:
Analysis document.
• Active Directory Infrastructure – Sites
• Active Directory Infrastructure – Forest and domain
topology
Note: Only fill in the details in these two sections. You may not
be able to fill in all of the information in these sections.
• Save the file as D:\Mod01\Labfiles\LabOutputs\Trey Research

Network Infrastructure.doc.
3. Complete the appropriate • The Current Messaging Infrastructure Analysis.doc file is located
sections in the Current in the D:\Mod01\Labfiles\LabInputs folder.
Messaging Infrastructure • Complete the following sections in the document:
Analysis document.
• Exchange Server Configuration
• Exchange Organization Information
Note: Only fill in the details in these two sections. You may not
be able to fill in all of the information in these sections.
• Save the file as D:\Mod01\Labfiles\LabOutputs\Trey Research

Messaging Infrastructure.doc.
Q What additional information may be required to complete a design for the Trey
Research messaging infrastructure?
A Answers will vary. Additional requirements might include storage groups and stores
information, including the storage mechanism used to store the databases, message
flow statistics, message security settings, and antivirus and anti-spam settings.
Q How would you get that information?

A Compiling this information may require meeting with other people or performing
additional research and documentation.
Note: The answers to the labs are on the Student Materials CD.
Exercise 2: Creating a Requirements Document

In this exercise, you will complete a portion of a requirements document for Trey
Research Corporation.
To complete this exercise, review the existing Trey Research documentation. You can
review the following information sources:
• Visio diagrams describing the Trey Research environment.
• Visio diagram describing a part of the Trey Research organizational structure.
• Interview notes from meetings with various personnel at Trey Research.
You should also use notes from the previous exercise.
1. As a group, discuss the • What are Trey Research’s requirements and pain points?
questions. You will • How can Exchange Server 2007 help address the requirements?
incorporate your answers
• Which requirements have the potential to cause conflicts? What
in to the requirements
solutions would you propose to resolve these conflicts?
documentation.
2. As a group, complete the • The Project Requirements Analysis.doc file is located in the
appropriate sections in the D:\Mod01\Labfiles\LabInputs folder.
Project Requirements • Complete the following sections in the document:
Analysis document.
• Summary of Business Requirements
• Summary of Functional Requirements
• Summary of Additional Requirements
• Project Priorities and Constraints
Note: Only fill in the details in these four sections. You may not be
able to fill in all of the information in these sections.
• Save the file as D:\Mod01\Labfiles\LabOutputs\

Trey Research Project Requirements.doc.
3. As a group, discuss the • Discuss the following questions:

components that you will • What components will you need to include in the Exchange
need to include in the Server 2007 deployment to meet the business requirements?
Exchange design to meet
• What components will you need to include in the Exchange
the company
Server 2007 deployment to meet the technical and additional
requirements.
requirements?
• How will the priorities and constraints affect the design?
• Are there any requirements that cannot be addressed by an
Exchange Server 2007 deployment? In each case, what are
some possible alternatives?
Exercise 3: Discussion: Real-World Best Practices for Setting

Budget Expectations
In this exercise, you will discuss guidelines for setting budget expectations for projects.
The first of several budget reviews should happen early. The team needs to determine
whether the project is feasible. If the costs are very high, the team needs to start thinking
about how much each of the requirements will cost and how cutting certain requirements
will affect the budget.
Q What information is required to set the preliminary budget?
A Answers include:
• Project vision and scope
• Business requirements—what business problems is this project expected to solve
• Functional requirements
• Project constraints
Q How do you resolve scenarios where addressing all of the requirements will cost
significantly more than the proposed budget?
A This can be very complicated. In the project’s early stage, the most important step is
to alert business sponsors that there may be budget issues. This enables them to
prepare for a future tradeoff discussion or consider increasing the budget. You also
may need to provide the business sponsor with an initial proposal identifying the
project components that will cost the most money.
Note: If you shut down the virtual machines without saving changes, the files that
you created during the lab will not be saved. To retain those files, you can leave
the virtual machines running, or you can shut down 5053A-LON-CL1 and commit
the changes.
Lab Shutdown
2. Under Navigation, click Master Status. For each virtual machine that is running,
click the Virtual Machine Name, and, in the context menu, click Turn off Virtual
Machine and Discard Undo Disks. Click OK.
3. Start the 5053A-LON-CL1 virtual machine. Additionally, you can also start the
5047A-LON-DC1 and the 5047A-LON-Edge1 virtual machines.
Module 2: Designing Active Directory
and Message Routing
Table of Contents
Overview 2-1
Lesson 1: Designing an Active Directory
Infrastructure 2-2
Lesson 2: Designing Message Routing 2-23
Lesson 3: Designing the Message Routing
Perimeter 2-31
Lab: Designing Active Directory and Message
Routing 2-44
Version 1.2
Module 2: Designing Active Directory and Message Routing 2-1
Overview
You can begin designing the Microsoft® Exchange Server 2007 messaging environment
after you define business requirements and have a good understanding of the current
environment. The Active Directory® directory service and Exchange Server 2007
integrate tightly, so you should start by reviewing the Active Directory design to
determine if any changes are necessary to optimize the Exchange Server 2007 design.
The logical next step is to design message routing, because Exchange Server 2007
depends on the Active Directory site topology to define the routing configuration.
Another design component you must define is the message routing perimeter.
Objectives
After completing this module, you will be able to design:
• An Active Directory infrastructure that is optimized for Exchange Server 2007
• Message routing
• The message routing perimeter
2-2 Module 2: Designing Active Directory and Message Routing
Lesson 1: Designing an Active Directory

Infrastructure
Exchange Server 2007 depends on Active Directory to store the Exchange-specific

configuration and recipient information. This means that the Active Directory design can
have a significant impact on the Exchange Server 2007 design and on the performance of
the Exchange servers and messaging clients. This lesson describes the Active Directory
requirements for Exchange Server 2007, and the implications that the Active Directory
design has on the Exchange Server 2007 design.
Objectives
• Identify the Active Directory design owners.
• Design the Active Directory forest.
• Design the Active Directory domain.
• Design the Active Directory sites for Exchange Server.
• Deploy Exchange servers in Active Directory sites.
• Design Internet access for Microsoft Office Outlook® Web Access.
• Design the Active Directory domain controller strategy.
• Apply considerations for modifying the Active Directory design.
Identifying the Active Directory Design Owners
In most small- or medium-sized organizations, the same administrator or administrator

group likely is responsible for the Active Directory and Exchange Server infrastructure.
Larger organizations often split these roles between two different teams, which must
work together because of the interrelationship between the Active Directory and
Exchange Server 2007 designs.
Note: Exchange Server 2007 uses a split permissions model, which distinguishes
between Active Directory and Exchange Server permissions. This makes it easier
to separate the administrative tasks between the two services. However, during the
design phase, the Active Directory and Exchange Server design teams must work
together to ensure an optimal Active Directory and Exchange Server design.
Who are the Active Directory design owners?

Active Directory design owners may be an individual or group of administrators who are
responsible for the overall Active Directory infrastructure design and management. This
group usually includes business stakeholders and technical directory services specialists.
Additionally, in most organizations, the design owners include personnel responsible for
the regular Active Directory administration.
The Active Directory design owners are responsible for any changes to the Active
Directory environment that may impact the entire forest. For example, in most
organizations, the design owners must approve all schema changes or approve new
domains or forests.
Note: From an administrative point of view, the members of the forest Schema
Admins and Enterprise Admins groups can be considered the Active Directory
design owners. However, these groups should be used only to implement
decisions that the actual design owners make.
Some organizations may have multiple teams of Active Directory design owners. These
organizations typically have more multiple Active Directory forests. In most cases, the
organization created these forests to establish security boundaries between its different
parts. Thus, each forest is likely to have a different group of owners. If an organization
has multiple teams of Active Directory design owners, you may need to negotiate with all
teams during the Exchange Server 2007 design.
Importance of working with the Active Directory design owners

You must review the Active Directory design as part of the Exchange Server 2007
design process, during which you identify issues where the Active Directory design is not
optimized for Exchange Server. When you identify these issues, you then must work with
the Active Directory design owners to understand the current design’s rationale and to
explore options for changing it.
If you identify issues with the Active Directory design that may impact the Exchange
Server 2007 design, you might convince the Active Directory design owners to modify
the Active Directory design. In other cases, the Active Directory design owners may have
good reasons for why they cannot change the design, and you may need to modify the
Exchange Server 2007 design.
Designing the Active Directory Forest
The Active Directory forest design can impact the Exchange Server 2007 design
significantly. The Exchange Server 2007 organization boundary is always the same as
the Active Directory forest boundary. Although you can deploy Exchange Server 2007
in a multiple forest environment, it is complicated to design this type of Exchange
Server 2007 deployment.
Active Directory forest options

Exchange 2007 supports a variety of Active Directory forest options, including:
• No forest. If you do not deploy Active Directory, you still can deploy an Exchange
Server 2007 computer running the Edge Transport server role. The Edge Transport
server role stores server configuration information in Active Directory Application
Mode (ADAM) rather than Active Directory.
• Single forest. In this topology, you install Exchange in a single Active Directory
forest that spans the entire organization. The same forest contains all user and group
accounts, and all of the Exchange configuration information.
• Resource forest. In this topology, you install Exchange in an Active Directory forest
that does not contain the user and group accounts. Organizations that require a secure
boundary between the administration of Active Directory and Exchange use this
design. In a resource forest, you designate one forest for accounts and authentication,
and another for Exchange.
• Cross-forest. In this topology, you install Exchange into multiple, different Active
Directory forests. Organizations that are highly distributed typically deploy this
topology, as it enables different organizational groups to retain management
ownership of a forest. In this topology, each forest has a complete Exchange
deployment and a unique Exchange organization object.
Exchange Server design in a single forest environment

The Exchange Server 2007 organization boundary must correlate to the Active Directory
forest boundary. This means that the single forest deployment is the easiest Exchange
Server 2007 deployment to configure and manage. The single forest option offers the
following advantages:
• Provides the richest set of e-mail system features. In a single forest, you do not need
to complete any additional actions to enable features such as calendar access, public
folder access, or a common global address list (GAL).
• Provides a streamlined administrative model. In a single forest, you do not need to
configure trust relationships or manage multiple Exchange administrative groups.
• Takes advantage of an existing Active Directory structure. If you already have
deployed Active Directory, you can use the existing structure and domain controllers,
and the global catalog servers. Thus, you do not have to deploy new servers.
A single forest has one disadvantage—administrators must determine how to share or

divide management responsibilities for Active Directory and Exchange objects.
Best Practice: A single forest means that the Exchange Server 2007 design and
deployment is significantly simpler than any other option. Therefore, you should
always use a single forest unless there are highly compelling reasons to use
multiple forests.
Exchange Server design in a resource forest environment

If your organization has multiple forests, the preferred method for implementing
Exchange is to create an Exchange resource forest. In this scenario, you set up a separate
Active Directory forest that you dedicate to running Exchange and hosting mailboxes.
This is known as an Exchange resource forest. User accounts are contained in one or
more forests, known as accounts forests.
A resource forest environment requires a one-way trust between the accounts forest and
the Exchange resource forest so users in the accounts forest can access mailboxes in the
Exchange resource forest. Each mailbox that you create in the Exchange resource forest
must have a disabled user object in the Exchange resource forest and an enabled user
account in the accounts forest. Additionally, the accounts forest account must have access
to log on to the linked mailbox that you create on the Exchange Servers.
In a resource forest environment, the GAL is created in the resource forest. You may not
need to configure directory synchronization between the two forests if you configure all
of the required user properties in the resource forest. However, you will need to configure
synchronization between the forests if the accounts forest manages account attributes or if
you want to automate configuration of the resource forest’s accounts and mailboxes.
Exchange Server design in a cross-forest environment

An organization with a cross-forest topology has multiple Active Directory forests, each
containing an Exchange organization. Unlike a resource forest topology, this design does
not separate user accounts from their mailboxes. Rather, a user account and its associated
mailbox are in the same forest.
The Exchange organizations share no information, by default, which complicates a cross-
forest design. This means that information, such as the GAL, availability data, and public
folders, is not available between the organizations. Additionally, information—including
mailbox rules and delegate permissions—does not move when you move users between
the Exchange organizations.
Other issues that may arise with a cross-forest design include:
• Synchronization of availability information and public folder information between
forests.
• Distribution groups from one forest are represented as a contact in the other forests,
so you cannot view the group’s members. Group membership does not expand until
mail is sent to the forest containing the group that the contact represents.
• Synchronization of directory objects between forests.
Note: For more information on addressing cross-forest design issues, see

Module 6, “Designing Co-Existence and Interoperability Strategies with Other
Messaging Systems,” in this course.
Designing the Active Directory Domain
You can deploy Exchange Server 2007 in several different domain configurations.
Although deploying Exchange Server 2007 in a single domain environment may be the
simplest design, there is very little difference between deploying Exchange Server 2007
in a single domain or in a single forest with multiple domains.
Domain deployment options

A domain is a grouping of security principals and other objects that you administer
collectively. You can deploy domains in many configurations within different
organizations. A single domain is the most common domain deployment for small- and
medium-sized businesses, while larger organizations will have multiple domains. Larger
organizations often create domains based on organizational or geographic distinctions.
There are three primary domain configurations within a single forest:
• Single domain.
• Multiple domains in the same Active Directory tree. In this case, there is a single top-
level parent domain, and all of the domains share a contiguous Domain Name System
(DNS) namespace with that parent domain.
• Multiple domains in multiple Active Directory trees. In this case, there are multiple
top-level parent domains with multiple DNS namespaces.
Note: Regardless of how many domains and trees are in a forest, the first domain
you deploy in the forest always is the forest root domain. By default, this domain
contains the Schema Master and Domain Naming Master roles, and the Schema
Admins and Enterprise Admins security groups.
Domain design implications for Exchange Server 2007

Provided that all domains are in the same Active Directory forest, there are few design
implications for the Exchange Server 2007 implementation. In a single forest, all domains
share the same schema, configuration information, and global catalog information. This
means that the domain boundaries are transparent to Exchange Server services and to
Exchange recipients.
Note: The functional level for all Active Directory forest domains in which you
deploy Exchange Server 2007 must be Windows 2000 native mode or higher.
One reason is that Exchange Server 2007 allows only universal security groups or
universal distribution groups to be mail-enabled. Additionally, when you prepare
the Active Directory forest for the Exchange Server 2007 installation, several
Exchange universal security groups are created that are used to set permissions
on Exchange configuration objects. You can create universal security groups only
in a domain that is in Windows 2000 native mode or higher.
There are two domain options that may impact the Exchange Server 2007 design in a
multiple domain environment:
• Creating a dedicated domain for the Exchange servers. Some organizations may
choose to deploy a separate domain for all Exchange servers and Exchange Server
administrators.
One advantage of this is that the Exchange administrators also can be the dedicated
domain’s administrators. This means that they can perform all administrative tasks on
the Exchange servers without requiring any administrative rights in other Active
Directory domains. To manage recipients in other domains, you must add the
Exchange administrators to the Exchange Recipient Administrators group.
A primary disadvantage of deploying a dedicated Exchange Server domain is the
extra cost that results from deploying and managing an additional domain. You
should deploy at least two domain controllers for the Exchange Server domain, and
this configuration may require additional domain controllers for the domain in other
locations.
Instead of deploying a dedicated domain for the Exchange servers, consider using the
Exchange Server Administrator role to delegate Exchange Server permissions. Users
or groups that you assign to this role receive full administrative permissions to the
specific Exchange Server computer.
• Deploying Exchange Server 2007 in a multi-tree forest. The main reason for
deploying multiple trees in a forest is to create separate namespaces for different
organizational business units. This configuration often requires separate Simple Mail
Transfer Protocol (SMTP) addresses for the different business units’ users. By
default, Exchange Server 2007 creates SMTP addresses for all users based on the
domain name of the forest root domain. You can easily modify the default SMTP
address assignment by creating additional accepted domains and then configuring
e-mail address policies to assign the required e-mail addresses to the different
business units’ users.
Designing the Active Directory Sites for Exchange Server
In an organization with multiple locations, the Active Directory site design will have
a significant impact on the Exchange Server 2007 design. Exchange Server 2007 and
messaging clients use Active Directory sites to locate domain controllers and to define
message routing.
How Exchange Server 2007 uses Active Directory sites

Exchange Server 2007 is a site-aware application, which means that Exchange servers
are aware of which site they are in and use this information while providing messaging
services. The Microsoft Exchange Active Directory Topology service determines and
updates the site attribute of the Exchange server object. Exchange servers also can
retrieve and use the site information for other Exchange Servers.
The Exchange 2007 server roles use Active Directory site membership information as
follows:
• The Mailbox server role uses Active Directory site membership information to
determine which Hub Transport servers are located in the same Active Directory site
as the Mailbox servers. The Mailbox server then submits messages for routing and
transport to a Hub Transport server that is in the same site.
• The Client Access server role uses Active Directory site information to provide
efficient access to user mailboxes. When the Client Access server role receives a user
connection request, it queries Active Directory to determine which Mailbox server is
hosting the user’s mailbox and the server’s site membership. If the Client Access
server that received the initial user connection is not in the same site as the user’s
Mailbox server, the connection is redirected or “proxied” to a Client Access server in
the same site as the Mailbox server.
• The Hub Transport server role retrieves information from Active Directory to
determine the organization’s internal and external mail routing. When a message
is submitted to the Microsoft Exchange Transport service, the categorizer queries
Active Directory for information about where the message must be delivered. If
the recipient’s mailbox is on a Mailbox server in the same Active Directory site as
the Hub Transport server, it delivers the message directly to that mailbox. If the
recipient’s mailbox is on a Mailbox server in a different Active Directory site, the
message is relayed to a Hub Transport server in that site, which then delivers it to the
Mailbox server.
Note: Designing Active Directory sites for message routing is discussed in

Lesson 2, “Designing Message Routing,” in this module.
• The Unified Messaging server role uses Active Directory site membership
information to determine which Hub Transport servers are located in the same Active
Directory site as the Unified Messaging server. The Unified Messaging (UM) server
submits messages for routing and transport to a Hub Transport server in the same site
as the Unified Messaging server. The Hub Transport server also queries Active
Directory to match a telephone number, or other UM property such as the user’s
Mailbox server, to a recipient account. The Hub Transport server delivers the
message to a Mailbox server within its same Active Directory site or relays the
message to another Hub Transport server, which then delivers it to a Mailbox server
that is outside the Active Directory site.
Considerations for designing Exchange Server 2007 sites

When designing the Active Directory site configuration, consider the following factors:
• Understand the rationale for the current Active Directory site design. Organizations
that have deployed Active Directory already will have implemented a site design that
likely is based on Active Directory design best practices. Active Directory sites are
designed to decrease replication traffic between company locations and client logon
traffic across slow network connections, and to optimize site-aware applications,
such as Distributed File System (DFS).
• Consider using a centralized Exchange Server deployment. You do not have to
deploy Exchange Servers in each Active Directory site. If high-bandwidth and
reliable network connections link all of your organization’s locations, regardless
of the distance between offices, you should consider implementing a centralized
messaging system in which all Exchange Servers are in one central location. Because
all Exchange servers, and other required services such as domain controllers and
DNS servers, are on the same fast network, this design will produce the best
Exchange Server performance. However, note that the most important reason not to
implement a centralized design is if the network bandwidth between company
locations cannot support it. If the requirements for user experience and availability
cannot be met by connecting to a central location, you may have no choice but to
position servers in the remote sites.
• Consider creating a dedicated Active Directory site for Exchange servers. If you use
a centralized design for Exchange servers, or if you deploy several Exchange servers
in a data center, you should consider creating a dedicated Active Directory site that
contains all of the Exchange servers in the location, and domain controllers and
global catalog servers that are dedicated to providing directory services for the
Exchange servers. This design enables more predictable Exchange Server
performance because other clients are not using the domain controllers for
authentication.
• Consider modifying the Active Directory site design. If the Active Directory site
configuration results in an inefficient Exchange Server design, you may need to
modify it. For example, you may configure two company locations as a single site.
If you need to deploy Exchange servers in both locations, you should consider
configuring separate sites to optimize domain controller access for Exchange servers
and messaging clients.
Deploying Exchange Servers in Active Directory Sites
Exchange Server 2007 has a much stronger reliance on Active Directory sites than
previous Exchange Server versions. Therefore, you must consider the Active Directory
site configuration when you design the Exchange Server 2007 deployment.
Considerations for Deploying Exchange servers in

Active Directory sites
Consider the following information when deciding whether to deploy Exchange Servers
in an Active Directory site.
• The first decision you must make when designing the Exchange Server deployment is
whether to place a server running the Mailbox server role in the Active Directory site.
If there are a sufficient number of users in the company location, and you do not want
their client access traffic to cross a network link to another location, then you must
place one or more Mailbox servers in the site.
• If you place a Mailbox server in the site, you also must place a Hub Transport server
role and Client Access server role in the site. At least one Hub Transport server must
be available in the site to route messages to the site’s Mailbox server. You also must
deploy a Client Access server in the site to enable users to access Outlook 2007 client
features, including Autodiscover and Availability services, or to access their
mailboxes via Outlook Web Access or Outlook Anywhere.
• You should deploy a Unified Messaging server in the site if you are using the Unified
Messaging features and if you deploy a supported Voice over IP (VoIP) gateway in
the site.
Note: You can deploy all Exchange Server 2007 server roles, except the Edge
Transport server and clustered mailbox servers, on the same server. This means
that in a small site, a single computer can hold all of the required server roles.
Designing Internet Access for Outlook Web Access
If you have multiple Active Directory sites, there are two options for designing Outlook
Web Access from the Internet:
• You can restrict all Internet client access to a single Client Access server in one of
the sites. If you choose this option, the Internet-accessible Client Access server
proxies all Outlook Web Access client access requests to a Client Access server in
the site that contains the Mailbox server that hosts the user mailbox.
• You can enable Internet client access to Client Access servers in each Active
Directory site. If you choose this option, Outlook Web Access client access requests
to a Client Access server in a site other than that containing the user mailbox are
redirected to the Client Access server in the site where the user mailbox resides.
Note: All Client Access server client connections, other than Outlook Web Access,
always are proxied to a Client Access server in the same site as the user mailbox.
Only Outlook Web Access allows redirection.
Using a Single Client Access Server to Provide Outlook Web Access

If you use a single Client Access server to provide Outlook Web Access, the Client
Access server authenticates the user and then queries the global catalog server for the
user mailbox location. If the user mailbox is in a different site, the Client Access server
uses Secure Hypertext Transfer Protocol (HTTPS) to proxy the client request to a Client
Access server in the user mailbox site. The Client Access server in the same site as the
Mailbox Server hosting the user mailbox then uses Remote Procedure Call (RPC) to
communicate with the Mailbox server and forward any data back to the first Client
Access server. To enable Outlook Web Access proxy between multiple sites, you must
complete the following steps:
1. Verify that the ExternalURL attribute is blank for all Client Access servers that
should not be accessible from the Internet. The ExternalURL attribute enables
Outlook Web Access redirection, so you must remove this attribute to stop the Client
Access server from attempting client redirection.
2. Verify or configure the InternalURL for all Client Access servers that should not be
accessible from the Internet. This attribute is configured by default and is required so
that the Client Access server that accepts the client connection from the Internet can
locate the other Client Access servers.
3. Ensure the Outlook Web Access virtual directories on the Client Access servers that
are not accessible from the Internet are configured to use Integrated Windows
authentication. When the Client Access server that accepts the Internet client
connection tries to proxy the client request, it uses the Exchange Server computer
account to authenticate the connection.
Note: By default, the Outlook Web Access virtual directory is configured to use
forms-based authentication. You should leave forms-based authentication enabled
on the Client Access server that is accessible from the Internet. However, you must
configure the other Client Access servers to use Integrated Windows
authentication.
Enabling Access to Multiple Client Access Servers

If you enable access to multiple Client Access servers for Internet Outlook Web Access
clients, you can configure Exchange Server 2007 to enable redirection to a Client Access
server that is in the site that contains the user mailbox. If you enable this option and a
user connects to a Client Access server in a different site than the user’s mailbox, the
client receives a page that provides the correct Client Access server URL so that the user
can connect to the appropriate one. To enable redirection, complete the following steps.
1. Ensure that you enable the Outlook Web Access virtual directory’s externalURL
property for all Client Access servers that need to be accessible from the Internet.
The Client Access server that accepts the initial client connection will enable
redirection by providing the URL for the Client Access server in the user’s site.
2. Ensure that the Outlook Web Access virtual directory’s
RedirectToOptimalOWAServer value is set to true on all Client Access servers. By
default, this value is configured as true, which enables the Client Access server to
redirect the client request.
Designing a Domain Controller Placement Strategy
As part of the Active Directory site design, you must also consider the domain controller
and global catalog server placement. The location and capacity of these domain
controllers can impact Exchange Server and messaging-client performance significantly.
How Exchange servers locate domain controllers

Like other Active Directory clients, Exchange servers locate domain controllers and
global catalog servers by querying DNS for the Service locator (SRV) resource records
associated with each domain controller and global catalog server. The SRV records for
domain controllers and global catalog servers are registered with different variations to
enable locating domain controllers and global catalog servers using several methods. One
method in which the DNS records are registered is by site name. This enables computers
running Exchange Server 2007 to find domain controllers and global catalog servers in
the local Active Directory site.
Each Exchange server is configured dynamically with its site each time it authenticates to
Active Directory. As part of the authentication process, the site name is stored in the
registry. If the computer running Exchange Server is a domain controller, the server
determines its site by comparing its IP address to the site configuration information that
the Active Directory configuration partition stores.
Planning the domain controller and global catalog placement

Consider the following when you are planning the domain controller and global catalog
placement:
• Deploy at least one domain controller and global catalog server in each site that
contains an Exchange Server 2007 server. All Exchange servers and Outlook users
must have fast access to a global catalog server to ensure a positive user experience.
• For security and performance reasons, you should not run Exchange Server 2007 on
computers that also function as Windows domain controllers, as this configuration
may cause performance issues in all but the smallest deployments.
Note: You cannot promote a member server running Exchange Server 2007 to
become a domain controller. Once you install Exchange 2007, changing its role
from a member server to a domain controller, or vice versa, is not supported
• For the best performance, when an Active Directory organization contains more than
20,000 objects, you should upgrade the domain controllers and global catalog servers
to 64-bit hardware. This improves your Exchange Server 2007 environment’s overall
performance and scalability. However, Exchange Server 2007 still supports 32-bit
domain controllers.
• As a general guideline, you should implement Exchange processors to global catalog
server processors in a 4:1 ratio in each site, assuming that the processors are similar
models and speeds. In some situations, however, if Active Directory includes a large
number of users or you have large distribution lists, you may need more global
catalog servers.
Discussion: Considerations for Modifying the Current Active

Directory Design
The Exchange design may require some Active Directory changes. However, it can be
difficult to modify the Active Directory design in a large, complex organization.
Q What impact might result from changing the Active Directory design in a large,
complex company?
A Answers will vary. In some cases, modifying the Active Directory design may be
fairly simple. For example, it may be easy to create a new Active Directory site or
remove one in an organization that does not have many deployed site-aware
applications. In other cases, it can be very difficult to modify the Active Directory
design, such as adding or removing domains or forests.
Q How can you balance the complications of modifying the current Active Directory
design with the optimal Exchange Server-based design?
A Answers will vary. The optimal Active Directory design for Exchange Server 2007
may be different than the current Active Directory design. However, there may be
many good reasons for the current design, and it may take a lot of effort to modify
the current Active Directory infrastructure. If the current Active Directory design is
optimized for another reason, or if the necessary change is too difficult, modifying
the current design may not be an option. In some cases, the maintenance costs of, or
functionality loss from, the current Active Directory design, may make it feasible
to modify the design. For example, if you have multiple forests that contain your
organization’s user accounts, it will be very difficult to merge the forests into a single
forest. However, Exchange Server 2007 provides the most functionality in a single
forest, so the effort required to merge the forests may be worth it.
Q How can you help an organization determine whether to modify the Active Directory
design?
A When addressing this question, you must first decide what to change in the Active
Directory design to make Exchange Server 2007 more efficient. Then you must
determine the difficulty associated with making the changes and determine whether
the benefits that result are worth the effort. Present this information to the appropriate
stakeholders to help them make the decision.
Lesson 2: Designing Message Routing
One of an Exchange Server 2007 infrastructure’s most important design components is

the message-routing topology, for messages sent within the organization and those sent to
and from the Internet. In Exchange Server 2007, the routing topology integrates tightly
with the Active Directory site configuration.
Objectives
• Describe Exchange Server 2007 default message routing configuration.
• Design hub sites to manage message routing.
• Design message routing to deal with message routing failure.
What Is the Default Message Routing Configuration?
Many organizations create Active Directory sites to control Active Directory replication
and client authentication network traffic. Exchange Server 2007 uses Active Directory
sites and Active Directory site links to define an organization’s internal and external
message routing.
How Exchange Server 2007 uses sites for message routing

A Hub Transport server is responsible for message routing within and between sites.
Between sites, the Hub Transport server determines the best route to the destination site
for the destination recipient, and delivers the message to a Hub Transport server in the
destination site.
When a message is addressed to a recipient in the same Exchange Server organization
and is sent between Active Directory sites, the following steps occur:
1. The Mailbox server uses Active Directory site membership information to determine
which Hub Transport servers are in the same Active Directory site as the Mailbox
server. The Mailbox server submits the message to the Hub Transport server. If more
than one Hub Transport server exists in the site, the Mailbox server uses the Hub
Transport servers on a round-robin basis.
2. The Hub Transport server performs recipient resolution and queries Active Directory
to match the recipient e-mail address to a recipient account. The recipient account
information includes the fully qualified domain name (FQDN) of the user’s Mailbox
server. The FQDN determines the Active Directory site of the user’s Mailbox server.
3. The Hub Transport server uses Active Directory site link information to determine
the lowest cost route to the destination Active Directory site. In a default
configuration, the Hub Transport server opens an SMTP connection to the Hub
Transport server in the destination site and delivers the message.
4. After a Hub Transport server in the destination Active Directory site receives a
message, the Hub Transport server forwards the message to the appropriate Mailbox
server in the destination Active Directory site.
5. If the message has multiple recipients whose mailboxes are in different Active
Directory sites, Exchange Server uses delayed fan-out to optimize message delivery.
If the recipients share part of, or the entire path, Exchange Server sends a single
copy of the message with these recipients until the bifurcation point. When the mail
reaches the bifurcation point, the message is bifurcated and a separate copy is sent to
each recipient. For example, if the least-cost route from Site1 to Site3 and Site4 both
pass through Site2, then a single copy of a message intended for recipients in Site3
and Site4 is sent to a Hub Transport server in Site2. The Hub Transport server in
Site2 then sends two copies of the message, one each to a Hub Transport server in
Site3 and Site4.
Note: If you are deploying Exchange Server 2007 in an Exchange 2000 Server or
Exchange Server 2003 environment, the organization’s message routing will vary
if the messages are routed to, or from, previous Exchange Server versions. This
scenario will be covered in Module 5, “Designing Co-Existence and Interoperability
Strategies,” in this course.
How Exchange Server 2007 selects a message route

In some cases, there may be more than one route available for delivering messages
between Active Directory sites. If a recipient is in the remote Active Directory site and
multiple paths exist to get to that site, the Exchange Server’s routing service uses the
following criteria to choose a path on which to send the message:
• The path that has the lowest cost from source to destination site. The lowest-cost
route is calculated by aggregating all Active Directory IP site link costs or the
Exchange cost assigned to the site links between the source and destination sites.
• The path with the least number of segments. If the aggregated costs for the site links
are the same for more multiple paths, then Exchange Server chooses the path with the
fewest site links between the source and destination sites.
Important: Exchange Servers do not use the underlying network topology to make
message routing decisions. A single site link may actually cross multiple network
segments, but the Exchange Server will evaluate only the site link. Therefore, it is
important that the site links logically reflect the underlying network topology.
• Alphanumerically lower preceding Active Directory site name. If the previous

criteria do not result in a single path, the Exchange Server selects the route that
passes through the intervening site with the lowest alphanumeric name. The
Exchange Server uses the site closest to the destination site to make the selection.
If the paths pass through the same site before reaching the destination site, the
Exchange Server backs along the routing path until a unique site name is available.
Note: Each Exchange transport server calculates a set of routing tables that
determine how to route messages to recipients. Whenever the Exchange server
calculates the routing table, it logs the result. By default, these logs are located in
the %Program Files%\Microsoft\Exchange Server\Transport\Logs\Routing
folder. The Exchange transport server recalculates the routing tables when the
transport services begin, when the server receives a notification of an Active
Directory change, and every six hours.
Modifying the Default Message Routing Topology
In some cases, you may want modify the default message routing configuration by
configuring specific Active Directory sites as Hub sites, and by assigning Exchange-
specific routing costs to Active Directory site links.
Options for modifying the default message-routing topology

By default, Hub Transport servers in one site will attempt message delivery to another
site’s recipient by establishing a direct connection to a Hub Transport server in the
remote Active Directory site. However, you can modify the default message-routing
topology in three ways:
• Configure hub sites. You can configure one or more Active Directory sites in your
organization as hub sites. When a hub site exists along the least-cost routing path
between two Hub Transport servers, the messages are routed to, and processed in, a
Hub Transport server in the hub site before they are relayed to the destination server.
Note: Use the Set-ADSite –Identity sitename –HubSiteEnabled $true command to

configure a hub site.
• Configure Exchange-specific routing costs. You also can modify the default
message-routing topology by configuring an Exchange-specific cost to an Active
Directory IP site link. If you assign an Exchange-specific cost to the site link, the
Hub Transport server uses this attribute rather than the Active Directory-assigned
cost to determine the least-cost routing path.
Note: Use the Set-AdSiteLink –Identity ADsitelinkname –ExchangeCost value

command to assign Exchange-specific routing costs.
• Configure expansion servers for distribution groups. You also can modify the default
routing topology by assigning expansion servers for distribution groups. By default,
when a message is sent to distribution group, the first Hub Transport server that
receives the message expands the distribution list and calculates how to route the
messages to each recipient. If you configure an expansion server for the distribution
list, all messages sent to the distribution list are sent to the specified Hub Transport
server, which expands the list and distributes the messages.
Considerations for modifying the default routing topology

Most organizations do not need to modify the default Exchange Server 2007 routing
topology. However, consider the following if you modify the default topology:
• Use hub sites when the network topology does not support direct connections
between Hub Transport servers in different sites. For example, use hub sites when
firewalls that exist between Active Directory sites prevent direct SMTP
communications.
Note: Configuring hub sites does not decrease the network traffic as Exchange
Server 2007 uses delayed fan out, regardless of whether you configure hub sites.
• Consider configuring an Exchange-specific cost to an IP site link if the cost does not
result in an optimal Exchange message routing topology and if you cannot modify the
Active Directory parameter.
• Consider site link costs when configuring hub sites. Hub sites are used only if the hub
site is along the least-cost routing path between two Hub Transport servers. The Hub
Transport server first calculates the least-cost route between two sites, then checks to
see if that route has any hub sites.
• Consider using expansion servers for very large distribution lists. Expanding large
distribution groups is a resource-intensive process for the Hub Transport server and a
global catalog server. If your organization has a central location with more powerful
Hub Transport servers or more global catalog server capacity, you may want to
configure one of the Hub Transport servers in the site as the expansion server for
large distribution lists. Ensure that this server is highly available, because it is not
possible to assign more than one expansion server to a distribution list.
Planning for Message Routing Failure
When designing the message routing topology, you also should consider how Exchange
Server 2007 deals with situations where message routing between sites fails.
How Exchange Server 2007 deals with message-delivery failure

If a Hub Transport server cannot deliver a message to a Hub Transport server in the
destination site or a hub site, the Hub Transport server delivers the messages via the least-
cost routing path to a Hub Transport server as close as possible to the destination site.
The source Hub Transport server attempts to deliver the message to a Hub Transport
server in the last site before the destination site, along the least-cost routing path. The
Hub Transport server continues its attempts to connect to a Hub Transport server as close
as possible to the target Hub Transport server. The messages are queued in that Active
Directory site and the queue is in a retry state. If no Hub Transport servers are available
in any site along the least-cost route, the message is queued on the local Hub Transport
server. This feature is called queue at point of failure.
Important: Exchange Server 2007 uses deterministic algorithms to choose

available paths between Active Directory sites. The algorithms are deterministic
because they always choose one path providing that contributing factors do not
change. Exchange Server 2007 does not load balance message delivery across
multiple connectors with the same cost, and it will not fail over to an alternate path
if a Hub Transport server in a site does not respond.
Guidelines for dealing with message routing failure

You should consider how Exchange Server 2007 deals with message routing failure when
designing the message routing topology. Consider the following guidelines:
• For each of your organization’s possible routing paths, consider where you will
queue messages that cannot be delivered to a destination hub site.
• Deploy multiple Hub Transport servers in the Active Directory sites where messages
will be queued for multiple destination sites. For example, if your organization uses a
hub and spoke topology for the Active Directory site links, messages are queued in
the hub Active Directory site. Ensure that you have multiple Hub Transport servers in
the site to ensure availability and performance scalability.
• To reduce the chance of message-routing failure, deploy multiple Hub Transport
servers in each Active Directory site. If one of the Hub Transport servers is not
available in a site, the source Hub Transport server will attempt to connect to the
site’s other Hub Transport servers before queuing to the failure point.
Note: Deploying multiple Hub Transport servers in a site also provides load
balancing. If there are multiple Hub Transport servers available in the destination
site, message delivery is distributed across all available servers.
Lesson 3: Designing the Message Routing Perimeter
Another important component in designing an Exchanger Server 2007 organization’s

message routing is to plan how messages pass through the network perimeter. The
network perimeter requires special consideration because of issues related to connecting
an internal network to the Internet. You must consider all possible ways that messages
may be sent outside the Exchange organization as you plan the message routing perimeter.
Objectives
• Deploy and secure Edge Transport servers.
• Design edge subscriptions.
• Design outbound message flow to the Internet.
• Design inbound message flow from the Internet.
• Design message routing from the internal network to the network perimeter.
Deploying and Securing Edge Transport Servers
The Edge Transport server design and deployment is a critical component when you
create a network perimeter message-routing solution. The Edge Transport server role
provides a secure SMTP gateway server that handles all messages sent to and from the
organization.
Note: The Edge Transport server role provides messaging security by enabling
SMTP connector security, transport rules, and anti-spam and antivirus scanning.
Module 4, “Designing Security for a Messaging Environment,” in this course
discusses these topics in more detail.
Guidelines for deploying and securing Edge Transport servers

When designing an Edge Transport server deployment, consider the following guidelines:
• Deploy the Edge Transport server in the perimeter network. You should deploy the
Edge Transport server role on a computer running Windows Server 2003 that is not a
member of your internal Active Directory domain. This means that you can deploy
the server role in a perimeter network and no internal domain information is available
on the server. You can install the Edge Transport server on a member server in an
extranet or perimeter network Active Directory forest. This configuration enables the
use of policies to manage the Edge Transport server computer.
• Reduce the attack surface on the Edge Transport server. As a best practice,
implement a dedicated server to operate as the Edge Transport server. This means
that the server will have no other running applications, and you can use a host-based
firewall to block all network traffic except for the port that the server role specifically
requires. Use the Security Configuration Wizard that Windows Server 2003 SP1
includes to disable all services that the server does not require and to configure
Windows Firewall.
• Open as few ports as possible on the internal and external firewalls. The following
table describes the firewall rules that you need to configure:
Firewall Firewall rule Explanation

External Allow port 25 to and from all Required for SMTP e-mail delivery.
external IP addresses to the Edge
Transport server.
External Allow port 53 to all external IP Required for the Edge Transport server to resolve
addresses from the Edge DNS names on the Internet.
Transport server.
Internal Allow port 25 to and from the Required for Edge Transport server and Hub
Edge Transport server to Transport servers to exchange SMTP e-mail.
specified Hub Transport servers.
Internal Allow port 50636 Secure Required for the Hub Transport server to replicate
Lightweight Directory Access information to the Edge Transport servers using
Protocol (LDAPS) from specified Edge Synchronization. This port is not the default
Hub Transport servers to the LDAPS port, but it is used specifically for the Edge
Edge Transport server. Synchronization process.
• Configure administrative permissions. If you deploy the Edge Transport server role
on a stand-alone server, you must use local user accounts to administer the Edge
Transport server. The local administrators group is granted full control of the Edge
Transport server, including the Active Directory Application Mode (ADAM)
instance on the Edge Transport server. In most cases, you will use Remote Desktop
to perform remote Edge Transport server administration. The local administrators
group is granted remote logon permissions automatically. If you want to assign Edge
Transport server administrative permissions to other accounts, create a user account
on the local computer and add the user account to the local administrators group to
ensure that the correct access level is granted.
Note: If you are going to use Remote Desktop from the internal network to
administer the Edge Transport server, configure the internal firewall to allow port
3389 for Remote Desktop Protocol (RDP) from the internal network to the Edge
Transport server.
• Configure settings to enable message flow or configure an edge subscription. As a

best practice, you should configure an edge subscription between the Edge Transport
server and a local Active Directory site. However, you also can configure send and
receive connectors and other settings manually, such as the accepted domains, to
enable message flow between the Edge Transport server, the Internet, and internal
Hub Transport servers.
Designing Edge Subscriptions
You can subscribe an Edge Transport server to an Active Directory site. This associates
the Edge Transport server with the Exchange organization. A subscribed Edge Transport
server is stamped with an Active Directory site attribute, which means that you can
configure the edge subscription as a source server for Send connectors that you create in
the Exchange organization.
When you configure an edge subscription, Exchange-organization and Edge Transport
server configuration occurs automatically to enable Internet message flow. After you
configure the edge subscription, the edge synchronization process replicates the
following data from Active Directory to ADAM:
• Accepted and remote domains.
• Recipients (Hashed). A one-way hash is used on the recipient information so that an
attacker cannot retrieve it from the Edge Transport server.
• Safe senders (Hashed).
• Send connectors.
• Hub Transport server list (for dynamic connector generation).
Considerations for Designing Edge Subscriptions

When designing the edge subscription, consider the following:
• You can subscribe an Edge Transport server only to a single Active Directory site.
If you have multiple Active Directory sites through which you want to route Internet
e-mail, you must configure a separate edge subscription for each site.
• An edge subscription is specific to each Edge Transport server. If you deploy
multiple Edge Transport servers in a perimeter network, you must configure an edge
subscription for each Edge Transport server. After you deploy each server’s edge
subscription, edge synchronization configures many of the Edge Transport server
settings. You also can use edge cloning to duplicate other configuration settings, such
as the anti-spam filters.
• When you configure the edge subscription, it sets up secure message transfer between
the Edge Transport server and all Hub Transport servers in the subscribed Active
Directory site. If you deploy new Hub Transport servers in the site after you
configure the edge subscription, you must remove the existing edge subscription and
add a new one so that the new Hub Transport servers will use the Edge Transport
server for message routing.
• Deploy multiple Edge Transport servers to enable high availability and load
balancing. If you are deploying multiple Edge Transport servers, then configure an
MX record for each Edge Transport server in the DNS zone that is accessible from
the Internet. Internet SMTP hosts will use DNS round robin to distribute the load for
incoming e-mail. Additionally, the internal Hub Transport servers distribute message
flow between all available Edge Transport servers to load balance outbound message
delivery. If one of the Edge Transport servers is not available, both inbound and
outbound e-mail is sent through the available servers.
Designing Outbound Message Flow
To enable message flow to the Internet, you must configure the Exchange organization
with at least one SMTP send connector that has an SMTP address space that includes
Internet SMTP domains. Depending on your organization’s requirements, you can
deploy multiple Edge Transport servers with multiple SMTP send connectors to send
Internet e-mail.
Considerations for Designing Outbound Message Flow

When designing outbound message flow, consider the following issues:
• Will you use a single location for routing all messages to the Internet or will you
enable message routing through multiple locations? If your organization has more
than one location with an Internet connection, you can enable message routing
through each. To do this, you can either:
• Install an Edge Transport server in each location and configure edge
subscriptions between the Edge Transport servers and the local Active Directory
sites.
• Manually configure Send connectors on the Hub Transport or Edge Transport
servers.
Load balancing and availability are the primary advantages of using multiple
connections.
Important: Exchange Server 2007 does not fail over automatically to use an
alternate connector if one connector is unavailable. Each Exchange Server 2007
chooses a single route for delivering messages to a specified recipient. If a
connector will be unavailable for an extended period of time, and you need to force
the Exchange Servers to use an alternate connection, remove the connector from
the Exchange organization, wait for Active Directory replication to update all
organizational domain controllers, and restart the Microsoft Exchange Transport
service to force the Hub Transport servers to recalculate routing.
• How will you configure the SMTP send connectors? To enable outbound message
flow, you must configure at least one SMTP send connector to send e-mail to the
Internet. You can use the following options to configure SMTP send connectors:
• Use edge synchronization to configure the SMTP send connectors. When you
configure an edge subscription, edge synchronization automatically configures a
send connector for the Active Directory site to enable message delivery between
the local Hub Transport servers and the Edge Transport server. Additionally,
edge synchronization configures a send connector to enable message delivery
from the Edge Transport server to the Internet.
• Create additional SMTP send connectors. You may have additional requirements
for send connectors. For example, you may need to configure unique message
routing or message security for a partner organization. You can configure an
additional send connector using the organization’s SMTP domain as the address
space and then configure the other send connector properties.
• Manually configure send connectors for Internet e-mail. If you are not using
an Edge Transport server or if you do not want to use edge synchronization,
you must configure the send connectors manually. You can configure send
connectors in the Hub Transport servers to route e-mail directly to the Internet or
to an SMTP gateway server or other smart host.
• How will you configure DNS lookups? By default, the Hub Transport server and
Edge Transport server perform DNS lookups for Internet message delivery by using
the DNS server that is configured on the network connection. Configure the settings
on the Exchange Server properties to configure other DNS servers for message
delivery. Consider this option if you want to use external DNS servers to perform
name-resolution services for the Edge Transport servers rather than use internal DNS
servers.
Designing Inbound Message Flow
To enable message flow from the Internet, you must configure the Exchange organization
with at least one SMTP receive connector that will accept anonymous SMTP connections
from Internet SMTP servers. Depending on your organization’s requirements, you can
deploy multiple Edge Transport servers with multiple SMTP receive connectors to
receive Internet e-mail.
Considerations for Designing Inbound Message Flow

When designing inbound message flow, consider the following issues:
• Will you use a single location for inbound routing from the Internet, or will you
enable message routing through multiple locations? If your organization has more
than one location with an Internet connection, you can enable inbound message
routing through each location. To do this, you can either install an Edge Transport
server in each location and configure edge subscriptions between the Edge Transport
servers and the local Active Directory sites, or you can configure receive connectors
manually on the Hub Transport or Edge Transport servers. Load balancing and
availability are the primary advantages of using multiple connections.
• If you are going to implement multiple inbound routing points, how do you plan
to design the MX records? If you configure MX records for each inbound SMTP
server with equal priorities, the inbound messages are load balanced between the two
servers. If you configure MX records with different priorities, the SMTP servers that
the lowest priority MX record references are used for all inbound message flow and
those that the higher priority MX record references are used only when the first
SMTP server(s) are not available.
• How will you configure SMTP receive connectors? By default, an Edge Transport
server is configured with an SMTP receive connector that accepts anonymous
connections from all IP addresses. You can use this receive connector to accept
incoming e-mail. All Hub Transport servers also are configured with a receive
connector. However, this connector only accepts authentication connections.
If you configure an edge subscription, this creates a send connector on the Edge
Transport server to send messages to the internal Hub Transport servers. The edge
subscription also configures an account that authenticates the connection to the Hub
Transport server and provides an encryption key that can encrypt messages sent
between the two servers.
You can create additional SMTP receive connectors to address specific business
requirements. For example, you may want to configure a receive connector that
requires authentication or TLS encryption to ensure that messages are secured from a
partner organization. Each receive connector must use a unique combination of IP
address bindings, port-number assignments, and the remote IP address ranges from
which the connector will accept mail.
Designing Message Routing to the Perimeter
In addition to planning a message routing topology inside the Exchange organization, you
also need to plan one for messages sent to recipients outside the Exchange organization.
To do this, you must understand how Exchange Server 2007 selects a route for outbound
messages and how to optimize this configuration.
How Exchange Server 2007 routes messages to the network

perimeter
In order for Exchange Server 2007 to route messages outside the organization, you must
configure at least one SMTP send connector with an address space that includes external
SMTP domains. By default, when you deploy a Hub Transport server and an Edge
Transport server, no send connectors are configured. When you configure an edge
subscription between an Active Directory site and an Edge Transport server, a send
connector is configured with an address space of * that uses the subscribed Edge
Transport server as the connector source server. This send connector enables the Hub
Transport servers in the subscribed Active Directory site to route messages to the Edge
Transport server, which then routes the message outside the organization.
Note: You also can configure a send connector on one or more Hub Transport
servers to enable message flow outside the organization.
If you configure more than one Send connector with a name space that meets the routing
requirements for an external recipient, Exchange Server 2007 routing will select a single
connector through which to route the message using the following algorithm:
• Select the connectors that do not have restrictions that prevent message delivery. If
you configure a send connector with a 3MB size limit, it will not be considered for
sending a message with a 4MB attachment. A disabled connector is not selected for
sending messages.
• From the remaining connectors, select the connectors with the most specific address
space match. For example, if one Send connector is configured with the address
space *.contoso.com and a second connector is configured with the address space *,
a message that is addressed to a recipient with an SMTP address @contoso.com is
routed through the first connector.
• From the remaining connectors, select the connector with the lowest aggregate cost.
The connector’s cost is determined by adding the cost of the IP site links between the
source site and the Active Directory site that contains the source servers for the Send
connector, and the cost assigned to the connector.
• From the remaining connectors, select the connector with the closest proximity.
The local server is chosen over another Hub Transport server in the same Active
Directory site, while a server in the local Active Directory site is chosen over a
source server in a remote Active Directory site.
• From the remaining connectors, select the connector with the lowest alphanumeric
connector name.
Note: After selecting the SMTP send connector to use to send the message
outside the organization, the Hub Transport server in the source site routes the
message to a Hub Transport server in the site where you have configured the send
connector. Exchange Server 2007 uses deterministic routing for message sent
outside the organization. Exchange Server 2007 chooses a single route through
which to send messages outside the organization, and it will not use an alternate
route unless you change the underlying routing configuration.
Configuring the connector scope to manage message routing to the

perimeter
The address space for a send connector can be scoped to an Active Directory site. When a
scope is applied to a Send connector, it is visible to only the Hub Transport servers in the
Active Directory site to which the connector is scoped. Only servers that have site
membership can consider that connector for routing to external recipients.
Note: Assign limited scope to a connector by adding the Local: prefix to the
address space. Do this with the Set-SendConnector cmdlet. For example, to limit
a Send connector’s scope to an Active Directory site, you run the following
command: Set-SendConnector -identity Connectorname -AddressSpaces
local:*
Considerations for designing message routing to the network

perimeter
For all organizations, including those with a single Active Directory site, if you are
planning message routing to the network perimeter, it is important to consider whether to
use an Edge Transport server to route messages to and from the Internet and whether to
configure edge subscriptions between the Edge Transport server and the Active Directory
site. Both of these options are highly recommended to provide maximum security and
administrative ease.
If your organization has multiple Active Directory sites, you also should consider:
• Whether you want to implement a single path for routing messages to the Internet or
whether you will implement multiple paths. The greatest advantage of a single route
is security. You need be concerned only with a single connection, from the internal
network to the Internet. Redundancy and load balancing are the greatest advantages
of multiple routes.
• If you implement multiple paths to the Internet, you also must plan the internal
message routing for messages being sent to the Internet. By default, each Exchange
Server 2007 server considers all SMTP send connectors with the correct external
address space when choosing a route over which to send messages to the Internet.
When you plan message routing to the Active Directory site that can route messages
to the Internet, use the same considerations that you used for planning internal
message routing between Active Directory sites.
• Use the connector scope to control whether messages sent to recipients outside the
organization are sent between Active Directory sites. For example, if you have two
company locations that have Internet connections, but are connected by a WAN link
with limited available bandwidth, you can define the send connector scope in both
locations as local so that messages bound for the Internet are never routed across the
wide area network (WAN) link.
Lab: Designing Active Directory and Message

Routing
After completing this lab, you will be able to design:

• Message-routing topology
• Message-routing perimeter
• Active Directory and message routing
Lab Setup
lab, you must:
Pa$$w0rd.
DC1 is configured as a domain controller in the TreyResearch.net domain and has
a standard Exchange Server 2007 installation. 5053A-LON-Edge1 is a stand-alone
server and has the Exchange Server 2007 Edge Transport Server role installed.
The 5053A-LON-CL1 computer is a member of the Treyresearch.net domain.
Lab Scenario
Exchange Server 2007. Trey Research currently has three remote sites and their
Corporate Headquarters 10,000 after the • 500 – Outlook Anywhere and mobile client users
new London • 800 – Outlook users connecting through a VPN
office is ready
London (new office) 4,000 • 200 – Outlook Web Access users
(anticipated) • 50 – Outlook Anywhere and mobile client users
You can review the Trey Research Active Directory infrastructure, network infrastructure,
or the messaging-system requirements in the following documents in the
D:\Mod01\Labfiles\LabAnswers folder.
• Trey Research Project Requirements Analysis.doc
• Trey Research Messaging Infrastructure.doc
• Trey Research Network Infrastructure.doc
Exercise 1: Designing a Message Routing Topology

In this exercise, you will design a message routing topology for the Trey Research
Exchange organization.
To complete this exercise, review the existing Trey Research documentation:
• Interview notes from meetings with various Trey Research personnel.
• Visio diagrams describing the Trey Research site topology.
• AD and Routing Interview Notes.doc
• TR_CurrentADSiteDesign.vsd
Note: You may need to review files such as the TR_Info.vsd file in
the LabResources folder to review the information discussed in the
previous lab. You may also need to review the answer files from
the previous module.
2. Modify the • Use callouts in the Visio file to document proposed changes to the
TR_CurrentADSiteDesign. site design. For each proposed change, provide:
vsd file with proposed • The proposed change
changes to the site design.
• A rationale for the proposed change
• Indicate which server roles need to be deployed in each Active
Directory site.
• Document message flow within the organization. Document the
changes that you will need to make to the Active Directory
configuration to enable optimal message flow.
TR_ProposedADSiteDesign.vsd
Note: Be prepared to discuss your proposed changes with the

class.
Exercise 2: Designing a Messaging Perimeter

In this exercise, you will design a message perimeter for the Trey Research Exchange
organization.
• Visio diagram describing the Trey Research network perimeter configuration.
documentation. D:\Mod02\Labfiles\LabInputs folder:
• AD and Routing Interview Notes.doc
• TR_CurrentPerimeterDesign.vsd
Note: You may need to review files such as the TR_Info.vsd

file in the LabResources folder to review the information
discussed in the previous lab. You may also need to review
the answer files from the previous module.
2. Modify the • Use callouts in the Visio file to document proposed changes
TR_CurrentPerimeterDesign.vsd to the perimeter design. For each proposed change, provide:
file with proposed changes to the • The proposed change
site design.
• A rationale for the proposed change
• Indicate whether you need to deploy any additional server
roles in each Active Directory site.
• Indicate the required firewall changes to meet your design
requirements.
• Indicate any other infrastructure changes that you must
implement to meet your design requirements.
• For each company location, document how messages are
delivered to the Internet and how inbound messages are
delivered to internal recipients.
TR_ProposedPerimeterDesign.vsd
Note: Be prepared to discuss your proposed changes with

the class.
Exercise 3: Discussion: Improving an Active Directory and

Message Routing Design
In this exercise, you will present your design decisions from the previous two exercises
and discuss your recommendations.
Discussion Questions:
Q What changes did you make to the Active Directory site configuration and the
organization’s message routing?
A Answers should include:
• The current site link setting will create very inefficient message routing. By
default, the DefaultIPSiteLink site link has a cost of 100, which means that all
messages will be routed directly to the site with the closest proximity. To use the
network connections with the highest bandwidth and ensure that messages are
queued outside the main offices if a destination server is unavailable, you must
make the following changes:
• The LondonSite to SanDiegoSite connection must have a higher cost than the
LondonSite-TorontoSite-SanDiegoSite connection.
• The LondonSite to ChennaiSite connection must have a higher cost than the
LondonSite-TokyoSite-ChennaiSite connection.
• The TorontoSite to TokyoSite connection must have a higher cost than the
TorontoSite-LondonSite-TokyoSite connection.
• You must create new site links to implement these changes. At a minimum, you
will need new three new site links:
• LondonSite to SanDiegoSite
• LondonSite to ChennaiSite
• TorontoSite to TokyoSite
• The cost for the new site links must be 201 or higher, or the route’s Exchange
cost must be assigned at 201 or higher.
• You should merge LondonSite and LondonSite2 to address the issues of
messages remaining in the categorizer queue and with the global address list
(GAL) lookups for clients. This enables the LondonSite clients to access the
global catalog server in the LondonSite2 location and does not require
deployment of an additional domain controller.
• You must deploy at least one Mailbox server role, one Hub Transport server role,
and one Client Access server role in each site.
• Recommendation: Retain the domain controller in Chennai and build the secure
server room. If this is not done, the users in Chennai will have a very poor
experience as the logon process and access to any e-mail services will be very
slow. As an alternative, you could propose upgrading the network connection
between Chennai and London, or between Chennai and Tokyo.
Q If your recommended changes are implemented, how will messages flow between the
Active Directory sites? Where will messages be queued in the event of a server or
network connection failure?
A Message routing will flow as follows:
• From San Diego: San Diego-Toronto-London-Tokyo-Chennai
• From Toronto: Toronto-London-Tokyo-Chennai, and Toronto-San Diego
• From London: London-Tokyo-Chennai, and London-Toronto-San Diego
• From Tokyo: Tokyo-London-Toronto-San Diego, and Tokyo-Chennai
• From Chennai: Chennai-Tokyo-London-Toronto-San Diego
In each case, the messages are queued on an available Hub Transport server in the
Active Directory site that is closest to the destination site.
Q How did you design message routing to the Internet?

A To save network bandwidth and to decrease the messages queued on the Hub
Transport server in London, install an Edge Transport server in Toronto and in Tokyo,
and enable inbound and outbound SMTP traffic. You can save additional bandwidth
by deploying Edge Transport servers in San Diego and Chennai as well, but the
network administrators are hesitant to open more ports, so the two requirements
will need to be balanced. For outbound e-mail, the Edge Transport server could be
configured to send e-mail to the Internet through the local Internet connection in each
location.
To ensure that inbound messages are distributed evenly between the three Edge
Transport servers, you should create three MX records in the TreyResearch.net zone
with equal priorities. One MX record should be created for the Adatum.com domain
and should use the Edge Transport server in Toronto.
Q What conflicting requirements were presented in the scenario? How did you resolve
conflicting requirements?
A Conflict may result from resistance to changing the Active Directory structure. If
this arises, emphasize that creating the additional site links is the only way to meet
message-routing requirements. Thus, you have to change the requirements or modify
the Active Directory structure. Suggest that if you do not change the Active Directory
site link costs, Active Directory replication remains unaffected. You can still control
message flow by configuring Exchange costs to the site links.
The requirement for creating a positive experience for Outlook Web Access users
conflicts with the network administrators’ requirement to reduce firewall changes.
In particular, this will create a problem in Chennai. If Outlook Web Access users
connect to a Client Access server in Tokyo or London, the Client Access server will
proxy the client request to the Client Access server in Chennai across a very slow
network connection. To resolve this issue, you can:
• Enable Internet access to the Client Access server in Chennai.
• Move the mailboxes for Outlook Web Access users from Chennai to London or
Tokyo.
• Significantly increase the bandwidth between Tokyo and Chennai, or between
London and Chennai.
Q What additional information should you consider when designing message routing in
this scenario?
A In a real-world scenario, an important additional piece of information that you need is
how many messages actually are sent between company locations. This may affect
the design and, in particular, this information may help to resolve some of the
conflicting requirements.
the changes.
Lab Shutdown
3. Start the 5053A-LON-CL1 virtual machine. Additionally, you can also start the
Module 3: Designing Exchange Servers
Table of Contents
Overview 3-1
Lesson 1: Designing Mailbox Servers 3-2
Lesson 2: Designing Non-Mailbox Servers 3-21
Lesson 3: Designing a Public Folder Architecture 3-40
Lesson 4: Designing a Lab Environment 3-54
Lab: Designing Exchange Servers 3-59
Version 1.2
Module 3: Designing Exchange Servers 3-1
Overview
Because Microsoft® Exchange Server depends on the Active Directory® directory

service, many Active Directory design decisions have an impact on the Exchange Server
design, and Exchange Server design decisions have an impact on the Active Directory
design. This is why you must complete the high level Active Directory® directory
service and message routing design, before you start creating the individual Exchange
Server design and deployment. In this module, you will learn how to design and deploy
the Exchange Server roles. You also will learn how to incorporate public folders into the
new system if your organization requires them. Last, you will design a test lab based on
the plans you created for the servers.
Objectives
• Design Mailbox servers configurations
• Design configurations for other servers running Exchange Server 2007
• Design a public folder architecture
• Design a test lab
3-2 Module 3: Designing Exchange Servers
Lesson 1: Designing Mailbox Servers
In an Exchange Server 2007 environment, the Mailbox server role manages access to all
user mailboxes and public folders. In this role, the Exchange server may host dozens of
databases containing hundreds of megabytes of data. It also may support connections for
thousands of concurrent users. To provide a positive experience for messaging system
users, you need to plan the Mailbox server configuration carefully.
Objectives
• List the information needed to design mailbox servers.
• Design mailbox sizing.
• Design mailbox server database configurations.
• Design mailbox server disk storage.
• Design mailbox server hardware requirements.
• Design mailbox servers for high availability.
Discussion: Requirements for Designing Mailbox Servers
Before starting the design of your organization’s Mailbox servers, make sure you have
collected all the information you need to ensure the design meets the organization’s
requirements.
Q What information do you need to design a mailbox server?
• The total number of mailboxes in the organization and in each location.
• The types of messaging clients that the organization uses.
• The total number of public folders and data on the public folder usage.
• Information on mailbox size limitations and on exceptions to the size limits.
• Message retention requirements.
• Mailbox retention requirements.
• Whether any current requirements will change when you deploy Exchange
Server 2007.
• Budget restrictions. For example, you may need to decide whether you have the
budget to allow dedicated server roles for mailboxes and public folder servers.
• Service level agreements (SLA), including the acceptable availability
expectations and recovery times.
• Storage technologies. Does the organization have a storage area network (SAN)
or is it planning to deploy one? Are they using directly attached storage (DAS)?
Q What additional information do you need to plan for future requirements?

• What are the company’s growth plans for the next six, 12, and 24 months?
• What is the organization’s hardware refresh cycle?
• What has the growth rate in Exchange storage been for the last two years? Is this
trend likely to continue or change?
Designing Mailbox Sizing
When designing the Mailbox server configuration and performance, you first need to
understand the organization’s mailbox storage requirements.
What Are the Business Requirements for Mailbox Size?

The first step in designing the organization’s mailbox sizes is to understand the business
requirements. To determine these requirements, ask the following questions:
• What are the organization’s current mailbox size restrictions?
• How many users have exceptions to the standard size restriction? How much
variation is there from the standard to the exception limits?
• What is the organization’s average mailbox size?
• Are users experiencing frustrations with the current mailbox size limit? Is the
organization planning on addressing these frustrations by raising the current mailbox
size limit? If yes, how much larger will the new mailbox size limit be?
Tip: You must balance the business requirements for mailbox size with the cost
and the server design required to meet those requirements. Almost any mailbox
size can be accommodated, but the cost may be prohibitive.
Client Performance and Mailbox Sizes

One of the features available in Microsoft Office Outlook® 2003 and Microsoft Office
Outlook 2007 is the ability to configure the clients to use Cached Exchange Mode. In
this configuration, the clients access a locally cached version of the database, which is
synchronized with the Exchange Server mailbox. This feature can significantly decrease
the disk input/output (I/O) required on the Mailbox server, but as mailbox sizes increase,
the client performance also can degrade.
If you enable Cached Exchange Mode for these Outlook clients and users have mailboxes
approaching 1 GB in size, you should configure the Windows clients with at least 1 GB
of memory and a fast hard disk configuration. If user mailboxes are larger than 2 GB, you
should disable Cached Exchange Mode and use Online mode.
Additional Considerations for Mailbox Sizing

When designing the mailbox size limitations, you need to consider the following
additional factors:
• The mailbox size quota may not represent how much space users actually are using.
In most organizations, a large number of mailboxes are below the size limit, while
many are close to the size limit and a small number have exceptions that exceed the
limit. When designing the mailbox server, include the actual usage in your design,
but remember that all mailboxes could grow to the mailbox size limit.
• Consider the actual mailbox size when planning the server design. The mailbox
database size is not just the number of mailboxes multiplied by the user quota or even
multiplied by the average mailbox size. You need to plan for the following additional
factors:
• The mailbox database always has free pages, or whitespace, spread throughout
the database. During online maintenance, items marked for removal from the
database are removed, freeing up these pages. The percentage of white space is
constantly changing with the highest percentage occurring immediately after
online maintenance and the lowest percentage right before online maintenance.
The size of database white space is approximately equal to the amount of e-mail
sent and received by the users with mailboxes in the database. White space can
grow beyond any approximation if online maintenance is not able to complete a
full pass. It is important that your operational activities include enough time for
online maintenance to run each night.
• Each database maintains a dumpster that stores hard-deleted items, including
items that have been removed from the deleted items folder. By default, items are
stored for 14 days in Exchange Server 2007. These items are not included in the
mailbox size, but are included in the mailbox database size. After the retention
period passes, these items are removed from the database during an online
maintenance cycle. Eventually, a steady state is reached in which your dumpster
size is roughly equivalent to two weeks’ worth of incoming mail.
• The database dumpster also stores the mailboxes that are deleted but have not
reached their retention time limit. By default, the retention time limit is 30 days.
• If most of your organization’s users are using Post Office Protocol version 3
(POP3) clients, the mailbox size may be significantly smaller than if they are
using MAPI clients. By default, POP3 clients download all e-mail from the
Mailbox servers and delete the server copy.
Designing Mailbox Server Database Configurations
Exchange Server 2007 provides some important enhancements influencing how data
storage is designed for the server. These enhancements mean that the optimal database
and storage group designs for Exchange Server 2007 are different from earlier Exchange
Server versions.
Exchange Server 2007 Data Storage Enhancements

In earlier Exchange Server versions, disk I/O often is the most significant factor,
particularly when the Exchange servers host many large mailboxes. Exchange
Server 2007 reduces the overall I/O footprint for Exchange Server through several
key design changes:
• As a 64-bit application, Exchange 2007 does not have the virtual memory limitations
of its 32-bit predecessors. This enables a much larger database cache, increasing it
from 900 megabytes (MB) to potentially dozens of gigabytes, depending on the total
system memory.
• Database read operations also benefit from new cache optimizations. The amount of
data Exchange Server 2007 reads from a disk or writes to the disk increases from 64
kilobytes (KB) to 1 MB per disk I/O.
• There is no streaming database file, and the installable file system is removed.
Planning Storage Groups

Exchange Server 2007 Enterprise Edition Mailbox servers support up to 50 storage
groups with a maximum of 50 databases per server, and you can place up to five
databases in a storage group.
Note: Exchange Server 2007 Standard Edition supports only five storage groups
and a total of five databases.
Consider the following when designing the storage group configuration:

• Each storage group should be assigned its own transaction log logical unit number
(LUN) and database LUN. This provides higher performance since the transaction
log LUN I/O consists mainly of sequential writes, while the database LUN I/O is
balanced between random reads and writes. This configuration also provides higher
recoverability if either the transaction log LUN or database LUN fails.
Note: A LUN is the physical disk that the operating system recognizes. For most
storage solutions, other than internal disks, a LUN does not represent the actual
hard disks that store data. A LUN may refer to multiple disks in a redundant array
of independent disks (RAID) configuration on a storage device. A drive letter in the
operating system may not represent the LUN. However, you can use volume
mount points.
• Use volume mount points rather than drive letters to represent LUNs. If you are
deploying more than 11 storage groups and using two LUNs per storage group, you
will run out of drive letters to assign to the LUNS. By using volume mount points,
you can increase the number of available LUNs.
• Each storage group should contain only a single database. If you are using local
continuous replication (LCR) or continuous cluster replication (CCR), you can only
have one database per storage group. This best practice means that to determine the
number of storage groups on a Mailbox server, you must first determine how many
mailbox databases the server requires.
• When planning storage groups, you also should plan for transaction log storage. The
transaction log files are a record of physical changes made to the database. When
planning transaction log storage, consider the following:
• Consider the mailbox storage needed. Determine how much e-mail is sent to
mailboxes in each storage group on a daily basis. One or more transaction logs
save all data sent to mailboxes in the storage group.
• Consider the backup design. Full backups and incremental backups delete the
transaction log files after a successful backup. You must have enough hard drive
space to store all of the transaction logs accumulating between each of these
backups.
• Account for backup failures. If the backup fails, the transaction logs are not
deleted. When planning for hard disk space, ensure that you have adequate
storage to accommodate multiple failures. You must determine the number
of failed backups your organization will accept, and then ensure that there is
sufficient hard disk space to store the transaction logs for each storage group for
the specified time. If you perform weekly full backups and daily differential
backups, you may need space for two weeks of transaction logs to accommodate
a full backup failure.
• Account for move mailbox operations. When you move a mailbox to a server, the
target server must write all transferred data to the transaction logs. If you are
moving mailboxes during a migration or just as regular practice, ensure that you
account for this additional data.
Planning Mailbox Databases

When planning the mailbox database on an Exchange Server 2007, you need to consider
the mailbox size limitations and the total number of mailboxes on a server.
For both Exchange Server 2007 Standard Edition and Enterprise Edition, there are no
hard limits on the maximum mailbox database size.
Note: In the Standard Edition, there is a soft database limit of 50 GB. As the
database size approaches 50 GB, events are logged in the application log file, and
the database will be dismounted when it reaches 50 GB. You can override this soft
limit using a registry value.
The following considerations limit database size:

• Data backup and restore requirements. In most cases, this is the most important
factor that limits mailbox database size. Depending on your backup design, you may
have a limited time for backing up individual databases. More importantly, you may
have an SLA that defines how long it should take you to restore a mailbox database
if a failure occurs. To determine the maximum database size, determine your
infrastructure’s backup and restore capacity, and apply it to the mailbox backup and
restore expectations.
Note: If you are using hardware-based snapshot backups and restores on a SAN,
the mailbox backup and restore requirements are not as critical in determining the
maximum database size.
• Offline database maintenance or repair. You may need to use Eseutil.exe to

defragment, repair, or check a database’s consistency. To complete these actions, you
must dismount the database and have available disk space on the server that is equal
to the database size plus 10 percent. You should be aware that as the database size
increases, so does the time required to run this procedure.
• Online maintenance. For optimal database efficiency, it is important that your

operational activities include enough time for online maintenance to run each night,
so that a full pass can complete within one week or less. The larger the database, the
longer this process takes.
• Content indexing. Exchange Server 2007 creates an index that is about 5 percent of
the total database size, which is placed on the same LUN as the database. Factor an
additional 5 percent capacity into the database LUN size for content indexing.
• Recovery Storage Group. If you plan to use a recovery storage group for disaster
recovery, you must ensure enough capacity is available to handle all of the databases
you want to restore simultaneously on that server.
• Backup to disk. If the backup strategy includes backups to disk, you will need to plan
for additional storage and performance.
Note: As a general guideline, the recommended maximum size for a mailbox

database in Exchange Server 2007 is 100 GB. If you are using continuous
replication, you may be able to double this size because of the rapid recovery that
continuous replication provides.
Designing Mailbox Server Disk Storage
As part of planning the database and storage group requirements, you also need to
consider the hard disk design of where you store the data.
Designing a Storage Architecture

When designing the storage architecture, consider storage technology and the type of
RAID configuration to use for the hard disks. When choosing a storage technology, you
have the following options.
• Serial ATA (SATA). SATA disks generally are slower than SCSI and Fibre Channel
disks, but they are fairly reliable. If you use 10,000 RPM disks, they provide
sufficient I/O for most Mailbox server scenarios.
• Serial Attached SCSI (SAS). SAS provides the highest throughput and is fairly easy
to deploy. You can attach many SAS arrays directly to the server and the cabling is
simple.
• Internet SCSI (iSCSI). iSCSI is the only network-based storage that Exchange
Server 2007 supports. iSCSI provides a connection between the server and the
storage enclosure over Ethernet. Although iSCSI is significantly slower than SAS, it
can support enough throughput for most Mailbox server scenarios. An advantage of
using iSCSI is that it enables you to deploy a SAN without implementing a more
complicated Fibre Channel network.
• Fibre Channel. Fibre Channel is a network technology often using fiber optic
cables in storage area networks. It is a high-performing, gigabit speed network, and
excellent for storage consolidation and management. Fibre Channel networks require
specialized skills to deploy and manage.
Selecting a RAID Option

To achieve high availability, you should implement a RAID solution for Exchange server
data. There are many RAID types, and many proprietary modifications to the known
RAID types. However, the most common types used in server environments are RAID 1,
RAID 10, RAID 5, and RAID 6. The following table compares these types of RAID
solutions based on speed, space utilization, and performance during rebuilds and failures:
Capacity Rebuild Disk Failure
RAID Speed I/O Performance
Utilization Performance Performance
RAID 1 Good Poor Good Best Good
RAID 10 Best Poor Best Best Best
RAID 5 Good Best Poor Poor Poor
RAID 6 Poor Good Poor Poor Poor
The best RAID type from a performance perspective is RAID 10. However, in a RAID
10 configuration, the storage capacity is only 50 percent of the total disk space. Because
transaction logs are the most important data set, and good write latency is critical for
server performance, you should place transaction logs on RAID 1 (mirrored) or RAID 10
arrays with write cache that includes a battery backup.
RAID 10 is also the ideal database configuration, and it works well with large capacity
disks. However, RAID 5 is much more efficient in terms of capacity utilization and
provides enough speed for most deployments, particularly if you configure the Outlook
clients to use Cached Exchange Mode. We do not recommend RAID 6 for Exchange
Servers because of its poor performance when you compare it to other RAID solutions
and because it is not as efficient in utilizing disk capacity as RAID 5.
Tools for Testing Server and Storage Performance

You can use the following tools to evaluate the performance of an Exchange Server 2007
storage solution:
• Microsoft Exchange Load Generator (LoadGen) tool. LoadGen is a simulation tool
to measure the impact of MAPI clients on Exchange servers. LoadGen enables you
to test how a server running Exchange responds to e-mail loads. To simulate the
delivery of these messaging requests, run LoadGen tests on client computers. These
tests send multiple messaging requests to the Exchange server, thereby causing a mail
load. Use the output from these tests to:
• Calculate the client response time for the server configuration under client load.
• Estimate the number of users per server.
• Identify server bottlenecks.
• Exchange Server Stress and Performance (ESP) tool. ESP simulates large numbers of
client sessions by concurrently accessing one or more protocol servers. ESP includes
multiple modules that simulate a variety of protocols and loads. You can run modules
concurrently from multiple hosts, thereby more realistically simulating physically
separate client machines. There is no limit to the number of computers on your
network that can host ESP modules.
• Microsoft Exchange Server Jetstress tool. Jetstress helps verify disk performance by
simulating Exchange Server database and log file loads that a specific number of
users produce. Use System Monitor, Event Viewer, and Extensible Storage Engine
Utility (ESEUTIL) in conjunction with Jetstress to verify that your disk subsystem
meets or exceeds the performance criteria you establish.
Note: You can download all of these tools from the “Tools for Exchange
Server 2007” page on the Microsoft TechNet Web site.
Designing Mailbox Server Processor and Memory Requirements
The primary hardware difference between earlier Exchange Server versions and
Exchange 2007 is the move from a 32-bit to a 64-bit platform. This means significant
changes to the way you design processor and memory configurations for Exchange
Server 2007.
Designing a Processor Configuration

Exchange Server 2007 is supported in production environments only when the x64
version of Exchange Server 2007 is installed on a computer with x64-compatible
processors running an x64 edition of Windows Server 2003. These processors include
Intel processors supporting Intel Extended Memory 64 Technology or AMD processors
supporting AMD64.
Note: You cannot use Intel Itanium processors with x64-based versions of
Windows Server 2003.
Exchange Server 2007 benefits from using multicore processors, which provide a good
price-to-performance ratio. Therefore, you should consider using them in your Exchange
Server 2007 servers.
The recommended processor configuration for the Mailbox server role is based
predominantly on the number of mailboxes on the server and the user profile. To
determine the average user profile on the server, use the Microsoft Exchange Server
Profile Analyzer or a third-party tool. The following table lists generic and common
knowledge worker profiles for Microsoft Outlook clients:
Send/receive per day approximately 50 kilobyte (KB)
User type (usage profile)
message size
Light Five sent/20 received
Average 10 sent/40 received
Heavy 20 sent/80 received
Very heavy 30 sent/120 received
In addition to the number of mailboxes and the user profile, also consider other factors,
such as:
• Whether the server is configured to use LCR.
• Whether the server is running Microsoft Forefront Security for Exchange Server or
other antivirus software.
• Which third-party applications are running on the server.
• Whether Outlook clients are using online or Cached Exchange Mode.
• Which other clients are used to access Exchange data.
As a general guideline, plan for one processor core on the server for every 1,000
mailboxes with an average user profile. If most of the users have a heavy usage profile,
you need to double the number of processor cores.
A Mailbox server’s recommended processor configuration is four processor cores. The
recommended maximum number of processor cores for Mailbox servers is eight, which
is the upper boundary of viable processor and memory configurations based on price
and performance. The recommended maximum configuration is a guideline, not a
support criterion. It does not take into account the resource requirements of third-party
applications that might be installed on or access the server. The recommended maximum
configuration may change over time based on price changes and technological
advancements.
For more information: See the Exchange Server 2007 TechCenter Web site for
detailed information and additional links on choosing the appropriate processor
configuration for your Exchange servers.
Designing a Memory Configuration

Moving to a 64-bit architecture enables Exchange 2007 to have better memory utilization
than earlier Exchange Server versions. For example, because of the virtual address space
limitations of a 32-bit platform, Exchange Server 2003 is limited to using 4 gigabytes
(GB) or less of physical memory. In contrast, Exchange 2007 can use 32 GB of memory
and more.
Note: 32 GB is not a physical limitation, but rather it is currently the most cost-
efficient maximum memory configuration. Depending upon the number of memory
slots in a server, the most cost-efficient maximum memory configuration might be
less than 32 GB (for example, 16 GB). Consider this when choosing server
hardware.
The Mailbox server role’s memory configuration design is more complex than that of
the other server roles because the optimal Mailbox server role memory configuration
depends upon the number of mailboxes and the mailbox client profile. Memory sizing for
the Mailbox server role is critical to reducing disk I/O on the server. The more memory
you add to the Mailbox server, the less disk I/O Exchange generates. Diminishing returns
may occur, however, when adding memory to the server is no longer justifiable based on
price and performance.
Use the following table to estimate memory requirements for a specific Mailbox server
with a specific number of hosted mailboxes and profile type:
Usage profile Mailbox memory recommendation
Light 2 GB plus 2 MB per mailbox
Average 2 GB plus 3.5 MB per mailbox
Heavy 2 GB plus 5 MB per mailbox
You also need to consider the number of Exchange Server storage groups when
calculating memory requirements. Increasing the number of storage groups increases the
database cache used for write activity. This increased cache has a positive impact of
reducing database write I/O, but configuring too many storage groups on a server with
insufficient physical memory may reduce the effectiveness of the database read cache.
This reduced cache can have an overall negative effect on the server’s performance.
The following table identifies the specific minimum memory requirements per server,
based on the number of server storage groups:
Number of storage groups Minimum required physical RAM
1-4 2 GB
5-8 4 GB
9-12 6 GB
13-16 8 GB
17-20 10 GB
21-24 12 GB
25-28 14 GB
29-32 16 GB
33-36 18 GB
37-40 20 GB
41-44 22 GB
45-48 24 GB
49-50 26 GB
Note: This table lists the amount of RAM that each storage group requires. Add the
memory used for each mailbox to this amount. For example, if you have 10 storage
groups on a server and the user profile is average, you will need 6 GB of memory,
plus 3.5 MB for each mailbox.
Designing Mailbox Servers for High Availability
Server performance may be only one of several criteria to include when designing a
Mailbox server configuration. For example, many organizations have, or are introducing,
service level agreements (SLAs) that define acceptable availability levels for user
mailboxes and standards for database recovery if a disaster occurs. In these organizations,
the requirements related to disaster recovery and availability may be just as important as
server performance when designing the mailbox servers.
These organizations should consider using Exchange Server 2007 features such as LCR,
CCR, and single copy clusters (SCC) to provide high availability.
Server Design Implications for LCR

Because LCR stores both active and passive database versions on a single Mailbox server,
implementing LCR has the most impact on server performance. CCR and SCC do not
have a significant impact on server performance because they provide redundancy by
implementing multiple servers, and the impacts are spread over multiple servers. When
designing Mailbox servers using LCR, consider the following issues:
• Passive LUNs in a continuous replication environment require two to three times the
disk I/O as active LUNs because the log replay is a significant generator of both read
and write disk I/O. To ensure server performance does not suffer if the passive LUN
becomes the active LUN, physically isolate the active and passive LUNs from LUNs
that other storage groups use.
• Separate the transaction logs and databases for the active and passive storage groups,
and house them on separate physical disks to increase fault tolerance. This means you
need at least four LUNs for each storage group.
• Separate the storage controllers on a different Peripheral Component Interconnect

(PCI) bus. Additionally, you should design storage for the passive copy to match the
storage that the active copy uses, in terms of both capacity and performance.
• If you are using LCR or CCR, you might be able to implement a larger maximum
database size. Because continuous replication provides a very rapid failover to a
functional database if a failure occurs, you may be able to increase the database size
without affecting the restored database.
• LCR requires additional server processing because the Replication service copies
files to the passive version of the storage group where the logs must be replayed. This
is approximately 20 percent additional processing overhead and should be factored in
when sizing Mailbox servers with one or more LCR enabled storage groups.
• LCR requires additional memory to ensure that the ESE database cache maintains
optimal efficiency. It is recommended that you install an additional 1 GB of RAM to
Mailbox servers that have one or more LCR enabled storage groups.
For more information: For detailed information on how to design mailbox servers
for LCR, CCR, and SCC, see Course 5054: Designing a High Availability
Messaging Solution Using Microsoft Exchange Server 2007.
Lesson 2: Designing Non-Mailbox Servers
In addition to designing the Mailbox server configuration, you need to design the server
configurations for the other Exchange Server 2007 server roles. Because these other
server roles do not store data like the mailbox server role does, the considerations for
designing their server roles are quite different.
Objectives
• Design Transport server configurations.
• Describe the back pressure feature.
• Design Client Access server configurations.
• Design Client Access server deployments.
• Design Unified Messaging server configurations.
• Design hardware configurations for Exchange servers that run multiple roles.
• Plan Exchange Server hardware requirements.
Designing Transport Server Configurations
All messages in the Exchange Server 2007 organization must pass through a Hub
Transport server. Additionally, you can deploy an Edge Transport server so all messages
sent to and from the Internet pass through this server. This means that the primary goal
for the server configuration design for the Hub Transport server and the Edge Transport
server is to optimize message throughput.
Information Needed to Design Transport Servers

When designing the transport server configuration, collect the following data types:
• The number of messages sent within the organization, the average number of
recipients for each message, and the average message size.
• The number of sites, and the site routing configuration.
• The number of Hub Transport servers in each site.
• The transport agent configuration on the Hub Transport servers. For example, how
many transport rules does the organization have configured and what is the transport
rule configuration?
• The number of messages sent to and from the Internet each day, and the average size
of those messages.
• The spam and virus filtering configuration on the Edge Transport server. For example,
is the Edge Transport server only applying connection filtering, or is it also
performing content filtering?
• The transport agent configuration on the Edge Transport servers.
• The number of Edge Transport servers and how load balancing is enabled across the
Edge Transport servers.
• The TLS (Transport Layer Security) authentication and encryption requirements on

the Edge Transport server.
• The third party applications running on the Edge Transport server or Hub Transport
server.
Designing Server Configurations for Transport Servers

When designing server configurations for transport servers, consider the following
guidelines:
• For Edge Transport servers, the recommended processor configuration is two
processor cores. This recommendation assumes more than one Edge Transport server
is deployed to ensure availability. Edge Transport servers can be configured with four
processor cores to reduce the number of Edge Transport servers.
• For Hub Transport servers, the recommended processor configuration is four
processor cores in organizations where Hub Transport servers are deployed with
several Mailbox servers and thousands of mailboxes. You can use eight processor-
core servers when you configure the Hub Transport server to perform virus and spam
filtering, or configure it with a large number of transport rules. Configurations using
one or two processor cores can be considered for organizations where there are not
enough mailboxes or insufficient message traffic, or for small offices within a large
organization. Processor utilization is based on several factors, such as message rate,
average message size, number of enabled transport agents, antivirus configuration,
and third-party applications.
• The Edge Transport and Hub Transport server roles do not require large amounts of
memory. Generally, 1 GB of RAM per processor core with a 2 GB minimum is
sufficient for most deployment scenarios. The Edge Transport and Hub Transport
server roles can use up to 16 GB of memory for scenarios in which the transport
servers are handling an average of 1 million messages with an average number of
recipients each.
• You should consider increasing the memory on a transport server when the servers
are expected to manage large queues (for example, 1 million messages in a single
server queue) or when the servers are configured to use Edgesync in a very large
organization. When messages are queued on a server, the server holds the queued
message recipient information in memory to optimize sending and retry operations.
Each message in the queue consumes about 3 KB of memory, while each recipient
for the message consumes an additional 1 KB. The amount of memory used for edge
synchronization is determined by the number of mail-enabled objects in the directory.
Each mail-enabled object requires approximately 4 KB of memory to be consumed
by the Edgesync process.
• Edge Transport servers and Hub Transport servers use hard disk storage for storing
messages in a queue, for storing transaction logs, for content conversion, and for
storing protocol logging and message tracking logs.
The following table lists how these activities affect hard disk I/O and provides
recommendations for hard disk configuration:
Activity Description and recommendations
ESE database Both the Exchange 2007 Edge Transport server and Hub Transport
(mail.que file) server store all queued mail in an ESE database. For reliability and
performance reasons, the database should be kept on separate disks
from the transaction logs.
Transaction log All changes made to the database are first committed to the transaction
files (.log files) log, which is a sequential write to the disk. The transaction logs use
circular logging so they can be deleted without being backed up.
Protocol logging Message tracking and protocol logging are sequential writes that, if
and message enabled, cause a disk performance issue and consume disk space to
tracking logs store the logs. Message tracking is enabled with a default maximum size
and time limit for storing logs. On a server that handles a large number
of messages, consider moving these log files to a dedicated disk.
Content On the Hub Transport server, incoming mail from the Internet is
conversion converted to MAPI prior to being delivered. This content conversion
process occurs in the TMP folder. To improve performance, the TMP
folder should not be on the same LUN as the paging file and the
operating system.
Agents The transport servers use agents to monitor messages and modify
messages in transit. Some agents log data, which requires disk space
and may have an impact on disk performance.
Paging If a process requests a page in memory and the system cannot find the
page at the requested location, a page fault occurs. If the page is
elsewhere in memory, the fault is a soft page fault. If the page must be
retrieved from disk, the fault is a hard page fault. Most processors can
handle large numbers of soft page faults without consequence. However,
hard page faults can cause significant delays. Continuous high rates of
disk paging indicate a memory shortage.
What Is the Back Pressure Feature?
Back pressure is a system resource monitoring feature of the Microsoft Exchange

Transport service that runs on Hub Transport servers and Edge Transport servers. It
monitors important system resources, such as available hard disk drive space and
available memory. If utilization of a system resource exceeds the specified limit, the
Exchange server stops accepting new connections and messages. This prevents the
system resources from becoming overwhelmed and enables the Exchange server to
deliver the existing messages. When utilization of the system resource returns to a normal
level, the Exchange server accepts new connections and messages.
Resources Monitored by the Back Pressure Feature

The back pressure feature monitors the following system resources:
• Hard disk drive free space that stores the message queue database
• Hard disk drive free space that stores the message queue database transaction logs
• The number of uncommitted message queue database transactions that exist in
memory
• The memory that the EdgeTransport.exe process uses
• The memory that all processes use
How Back Pressure Is Applied

For each monitored system resource on a Hub Transport server and Edge Transport
server, the following three levels of resource utilization are applied when it is
appropriate:
• Normal. The resource is not overused. The server accepts new connections and
messages.
• Medium. The resource is slightly overused. Back pressure is applied to the server in a
limited manner. Mail can flow from senders in the authoritative domain. However,
the server rejects new connections and messages from other sources.
• High. The resource is severely overused. Full back pressure is applied. All message
flow stops, and the server rejects all new connections and messages.
Options for Configuring Back Pressure

You can modify the back pressure settings in the EdgeTransport.exe.config application
configuration file that is located in the %programfiles% \Microsoft\Exchange Server\Bin
directory. The EdgeTransport.exe.config file is an XML application configuration file
that is associated with the executable files that the Microsoft Exchange Transport service
uses. The Edge Transport and Hub Transport servers both contain this file. This service
runs on every Hub Transport and Edge Transport server.
You can modify any of the monitored settings that the back pressure feature uses. When
you modify the settings, you are configuring the server’s normal, medium, and high
resource utilization values. For example, you can:
• Modify the free hard disk space values for the message queue database disk. By
default, when the hard disk containing the message queue database has less than 4
GB of available space, the resource is considered to be highly utilized. You can
modify the PercentageDatabaseDiskSpaceUsedHighThreshold setting in the
EdgeTransport.exe.config file to modify this setting. For example, if you set this
value to 50, the high threshold would be set to 2 GB.
• Modify the resource utilization settings for the EdgeTransport.exe process memory
utilization. By default, the high memory utilization for this process is set at 75
percent of the entire physical memory, medium memory utilization is set at 73
percent, and normal memory utilization is set at 71 percent of the entire physical
memory. You can modify the normal memory utilization setting by modifying the
PercentagePrivateBytesUsedNormalThreshold value in the EdgeTransport.exe.config
file. If you set this value to 15, then the normal memory utilization value will be set
to 15 percent less than the high memory utilization value.
Note: You should modify the default values only if you clearly understand your
normal server performance parameters. For detailed information on other options
that you can configure, see Exchange Help.
Important: Changes that you save to the EdgeTransport.exe.config file are applied
after you restart the Microsoft Exchange Transport service.
Designing Client Access Server Configurations
The Client Access server’s design can have a significant impact on how satisfied users
are with the messaging system. All clients other than MAPI clients must connect to a
Client Access server to access a mailbox on an Exchange Server 2007 Mailbox server.
Outlook 2007 clients also connect to Client Access servers to download the offline
address book, and to access the Availability services and to use the Autodiscover feature.
This means that poor Client Access server performance directly affects users.
Information Needed to Design Client Access Servers

When designing the Client Access server configuration, collect the following data:
• The total number and type of client connections. This should also include an average
client profile that includes the number of messages read and sent, and the average
size of messages and attachments.
• The Windows SharePoint Services and Windows File Shares integration
configuration.
• SSL encryption requirements. SSL encryption requires additional resources on the
Client Access server.
• The Active Directory site configuration and Client Access server placement within
the sites. This includes how many Client Access servers are deployed in each site,
and how many of the Client Access servers are accessible from the Internet.
• The number of Outlook 2007 clients in each site.
Designing Server Configurations for Client Access Servers

Exchange 2007 architecture has moved most of the client-specific functions from the
Mailbox server to the Client Access server. In Exchange 2007, messages are converted
on the Client Access server when they are accessed by a non-MAPI client [for example,
POP3 (Post Office Protocol version 3) and IMAP4 (Internet Message Access Protocol
version 4rev1) clients]. Additionally, rendering for Microsoft Office Outlook® Web
Access for Exchange Server 2007 is performed on the Client Access server. In earlier
Exchange Server versions, it was performed on the Microsoft Exchange Information
Store. These architectural changes allow the Client Access server to offload significant
processing from the Mailbox server.
In addition to performing client access functions, the Client Access server provides the
Autodiscover service, provides the Availability service, and operates as a download
location for the offline address book for Outlook 2007 clients.
When designing the Client Access server configuration, consider the following
recommendations:
• The recommended processor configuration for Client Access servers is four
processor cores. This is also the maximum recommended number of processors. You
can utilize servers with either single or dual processor cores for Client Access servers
in organizations where there are not enough mailboxes or insufficient non-MAPI
client traffic to warrant using four processor core servers.
• As a general guideline, you should deploy one Client Access server processor core in
an Active Directory site for every four Mailbox server processor cores.
• The recommended memory configuration is dependant on the number of client
connections and the transaction rate for a Client Access server. Based on the current
recommendations for processor and memory configurations, a Client Access server is
balanced in terms of memory/processor utilization, and it becomes processor-bound
at roughly the same time it becomes memory-bound. For the majority of deployments,
4 GB (1 GB per processor core) is sufficient and recommended for Client Access
server operations. Large scale deployments, especially those with Microsoft Outlook
Anywhere as the primary client access method, should consider using 2 GB per
processor core. The recommended maximum amount of memory per server for Client
Access servers is 8 GB.
• The Client Access server is not a hard disk intensive application. The following table
describes Client Access server role activities and how each activity affects disk I/O:
Activity Descriptions and recommendations

Protocol Protocol logging is a sequential write that, if enabled, causes a performance
logging issue and consumes disk space to store the logs. On a server that handles a
large number of messages, consider moving these log files to a dedicated disk.
Content Content conversion for all Exchange Server 2007 protocols occurs on the Client
conversion Access server. Disk access can become an issue for Client Access servers if
you have a large number of Internet clients that access mailbox data through
either POP3 or IMAP4. The POP3 and IMAP4 client requires that the content
be converted into MIME before sending it to the client. This conversion occurs
on the Client Access server, and if the message is larger than 64KB, the
conversion occurs on disk. If a large percentage of the user base is using POP3
or IMAP4, the temporary folder where conversion occurs should be placed on a
dedicated fast disk.
Paging Continuous high rates of disk paging indicate a memory shortage.
• The network connection is the bottleneck on a server that you configure with
recommended memory and processor combination. To reduce the network bottleneck,
configure the Client Access server with multiple 1 Gbps network cards.
Designing the Client Access Server Deployment
In addition to planning the Client Access server hardware configuration, you also need to
design the Client Access server deployment. Clients outside the organization frequently
access the Client Access server, so you need to ensure that its deployment is secure while
providing all required functionality.
Designing the Client Access Server Placement

Because Client Access servers often are accessible from the Internet, you need to take
extra precautions in deploying them. One of the most important design decisions you
need to make is whether to locate the Client Access server on the perimeter or internal
network.
Deploying Client Access servers on a perimeter network is not a supported scenario. The
Client Access server must be deployed on the internal network. The Client Access server
role must be installed on a member server, and it must have access to a domain controller
and global catalog server, as well as the Mailbox servers inside the organization.
Securing the Client Access Server

As part of the Client Access server deployment, you should ensure that the server is
as secure as possible. When designing the Client Access server deployment, determine
which e-mail services you require on the server. By default, the IMAP4 and POP3
services are installed on the Client Access server but are not configured to start
automatically. If you are not providing access for these protocols, disable these services.
You can use the Security Configuration Wizard to lock down all Windows Firewall ports
and disable the services that Client Access server deployment does not require.
When you deploy the Client Access server on the internal network, you need to allow
access through the external and internal firewall only for the specific protocols that the
Client Access server clients use. For each of these protocols, you should require that all
traffic be encrypted using Secure Sockets Layer (SSL).
As a best practice, you should protect the Client Access server on the internal network by
deploying an advanced firewall, such as Microsoft Internet Security and Acceleration
(ISA) Server 2006. ISA Server provides the following benefits:
Configuration Benefit Description
ISA Server can authenticate all No unauthenticated traffic enters the internal network. ISA
client connections Server supports the use of forms-based authentication.
ISA Server can load balance client ISA Server randomly selects a Client Access server and then
requests and send them to an array sends the name of the Client Access server back for the
of Client Access servers client application to use.
ISA Server can use SSL bridging ISA Server acts as an end point to the SSL connection from
the client. ISA Server can decrypt the client traffic, filter the
network traffic using content level analysis, and then re-
encrypt the traffic before sending to the Client Access server.
Designing High Availability for Client Access Servers

To provide high availability for the Client Access server role, you can deploy multiple
Client Access servers and then use a load balancing solution to provide load distribution
and availability. You can use a solution such as Windows Network Load Balancing or a
hardware-based load balancer. When you use these tools, clients can use the same URL
or fully qualified host name to connect to the Client Access server, and the load balancing
solution distributes the load across all available servers.
Designing Unified Messaging Server Configurations
Unified Messaging combines voice messaging, fax, and e-mail messaging into one store
that is accessible via a telephone or computer. When you integrate Exchange Server 2007
into your voice system, availability becomes critical. User expectations are high for
telephone systems and their associated components.
The following table lists some of the Unified Messaging server features:
Feature Description
Call Answering Includes answering an incoming call on behalf of a user, playing their
personal greeting, recording a message, and submitting it for delivery to
their inbox as an e-mail message.
Fax Receiving Lets users receive fax messages in their Inbox.
Subscriber Access Enables dial-in access for company users. Company users or subscribers
who are dialing into the Unified Messaging system can access their mailbox
using Outlook Voice Access.
Auto Attendant Lets users place a call to another user, or locate another user and then
place a call to that user.
Note: For more information on the Unified Messaging server, see the following
eLRNing courses: Clinic 5091AE: Introduction to Microsoft® Exchange Server
2007 Unified Messaging and Course 5092AE: Implementing Microsoft® Exchange
Server 2007 Unified Messaging.
Information Needed to Design Unified Messaging Servers

When designing server configuration for Unified Messaging servers, collect the
following information:
• Number of users enabled for Unified Messaging.
• Client profile for the users. For example, you need to know how often users are
accessing the Unified Messaging server directly by calling into the Unified
Messaging pilot number, logging on to their mailboxes, and accessing their messages,
calendar, contacts, and the directory. Additionally, you need to know how many
users are using Outlook or Outlook Web Access to get a Unified Messaging server to
play back voice content on a telephone.
• Usage by unauthenticated callers. Unauthenticated callers, who may or may not be
subscribers, also use resources on the Unified Messaging server. These users may
transfer a call to the user’s phone, send a voice message to the user, or use an
Automated Attendant to transfer to another number, another Auto Attendant, or listen
to recorded audio.
• Peak usage periods. In most cases, Unified Messaging server usage will not be
distributed evenly throughout the day. There are periods when the demand is low
(often at night and in the early morning), and periods of high demand (perhaps
shortly after business hours begin, and after lunch).
Designing Server Configurations for Unified Messaging Servers

The performance limitation on Unified Messaging servers is the server’s ability to sustain
concurrent conversations, or sessions, with telephone callers. Every voice over IP (VoIP)
session requires the Unified Messaging server to dedicate some network bandwidth,
processing time, and virtual memory.
When designing the Unified Messaging server configuration, consider the following
recommendations:
• The recommended processor configuration for the Unified Messaging server role
is four processor cores. Servers with one or two processor cores can be used for
Unified Messaging servers in organizations where there are not enough mailboxes or
insufficient Unified Messaging server activity to warrant using four processor core
servers.
• The recommended memory configuration for Unified messaging servers is 1 GB per
processor core with a 2 GB minimum. The maximum recommended memory on a
Unified Messaging server is 4 GB.
• The Unified Messaging server is not a hard-disk intensive server role. Files, such as
custom audio files, are stored on the local hard disk on the Unified Messaging server,
but have very little associated disk activity.
• With the recommended hardware configuration, each Unified Messaging should
support a maximum of 60–100 concurrent calls.
Designing Server Role Combinations
Small and medium-sized companies, and large organizations that have a small number of
users in a single location, may choose to combine multiple Exchange Server 2007 server
roles on a single computer.
Combining Server Roles

You can install all roles, except the Edge Transport server role and clustered Mailbox
server roles, on a single computer. When designing the hardware configuration for
servers where you install multiple server roles, consider the following recommendations:
• To accommodate the Client Access and Hub Transport server roles on the same
server as the Mailbox server role, reduce the 1,000 mailboxes per core calculation
based on the average client profile by 20 percent (800 mailboxes per core) when
performing sizing.
• The maximum recommended number of processor cores for a server with multiple
server roles is four.
• The recommended base memory configuration for a server with multiple server roles
is 4 GB plus from 2 MB to 5 MB per mailbox. This is variable based on user profile
and the number of storage groups. To determine if you should use a different amount
of memory, apply the same calculations that you applied to determine a Mailbox
server’s memory. The recommended maximum amount of memory is 8 GB.
• You cannot use CCR or SCC on a server also running the Hub Transport or Client
Access server roles. If you need the high availability options that these clustering
solutions provide, you need to deploy dedicated mailbox servers. The only way you
can increase the availability for the Hub Transport and Client Access server roles is
to deploy multiple servers, so you may choose to deploy multiple servers with these
two roles installed.
Practice: Planning Server Hardware Requirements
In this practice, you will define the hardware specifications for Exchange Server
configurations. You will use the Exchange Server 2007 Help files to provide information
on server sizing including memory, processor, and disk space.
Note: The most recent version of the Exchange Server 2007 Help files are on the
“Microsoft Exchange Server TechCenter” page of the Microsoft TechNet Web site.
For this exercise, you will use an offline version of the Help files.
Objectives
In this practice, you will define hardware specifications for Exchange Servers.
Instructions
Pa$$w0rd.
f Designing Exchange Server hardware specifications

1. Open Windows Explorer and browse to D:\Mod03\Practices. Open exchhelp.chm.
2. In Microsoft Exchange Server 2007 Help, in the Planning and Architecture section,
click Planning Your Deployment.
3. Use the Planning Processor and Memory Configurations and the Planning Disk
Storage topics to fill in the following table:
Processor Memory Disk space
Server role Comment
requirement requirement requirement
Large Mailbox • 3,000 - 3,500 mailboxes
server • 80 MB average mailbox
size
• Average to heavy usage
profile
Medium Mailbox • 1,500 - 2,000 mailboxes
server • 80 MB average mailbox
size
• Average to heavy usage
profile
Client Access • Maximum of 14,000 users
server per Active Directory site
• 50 percent of users are
using Outlook 2007
• 10 percent of users are
using Outlook Anywhere
or Exchange ActiveSync
Hub Transport • 70 percent of e-mail sent
server in the organization is sent
between Active Directory
sites
• 30 percent of e-mail is
sent to the Internet
• Maximum of 750,000
messages sent per day in
any Active Directory site
Edge Transport • 50 percent of Internet
server e-mail is inbound, 50
percent is outbound
• All incoming messages are
scanned for spam and
viruses
Unified Messaging • Maximum of 14,000 users
server per Active Directory site
Mailbox server, • 700-1000 mailboxes
Client Access • 80 MB average mailbox
server, and Hub size
Transport server
• Average usage profile
• Maximum of 1,000 users
in the Active Directory site
Tip: To calculate the amount of hard disk space that a Mailbox server requires, use
the following information:
Number of Mailboxes * mailbox average = Mailbox data

Average amount of mailbox per day * 14 days = Dumpster size
Content indexing = 5% of total database
Eseutil requirements = 110% of largest database
Transaction log requirements = Daily message flow * days between backups
The final formula is:

Mailbox data + Dumpster size + Content index + Eseutil requirements +
Transaction log requirements
Q What additional factors should you consider when calculating the server
requirements?
A There are many other factors that you should consider, including:
• How many servers of each server role will you deploy? This is particularly
important for Client Access servers, Hub Transport servers, and Edge Transport
servers. With these server roles, you may choose to deploy multiple servers and
use less hardware per server.
• Will the computer store any public folder databases for Mailbox servers?
• What additional software is installed on the computer, or what additional
functionality does the computer provide? For example, if the server is running
antivirus software, you will need to increase the memory and processor
requirement. In a small office, the Exchange Server may also function as DNS,
Active Directory domain controller, or a file server.
• What are the growth projections? Most organizations include some growth
projection in their planning.
Best practice: After you calculate the hardware requirements for each server, you
should plan for some excess capacity. We recommend planning for at least 20
percent excess capacity.
Lesson 3: Designing a Public Folder Architecture
As part of the Exchange Server 2007 deployment, you also may need to design the
organization’s public folder architecture. Although Exchange Server 2007 de-emphasizes
public folders, they remain fully supported and some organizations use them extensively.
Objectives
• Analyze business requirements for public folders.
• Design mailbox servers for storing public folders.
• Design public folder replication.
• Design client access to public folders.
• Design public folder permissions.
• Describe options for transitioning away from public folders.
Analyzing Business Requirements for Public Folders
Some organizations make little use of public folders. Others use them extensively and
may have developed manual or automated business processes that require public folders.
Because of the variation in public folder use, you should start your public folder design
by analyzing your organization’s business requirements for public folders.
Data to Collect about Public Folder Usage

To clarify and determine business requirements for public folders, answer the following
questions:
• What versions of Outlook does your organization use? If you use Outlook 2003 or
earlier versions, public folders are still required to store the offline address book and
Free/Busy information.
• How many public folders does your organization have implemented, and how much
data does each store?
• How often are public folders used? Calculate how frequently public folders are
accessed and the number of users who access them. Understanding public folder
usage levels helps you plan where public folder servers should be located and for
capacity. For example, high public folder usage may require you to use a dedicated
public folder server.
• How are users of public folders distributed within the organization? Are the public
folder users primarily in one location or are they distributed across the organization’s
locations? Do users from the Internet need access to public folders?
• What function do the public folders serve? Some organizations use public folders
only for basic functions, such as storing company data, while other organizations use
public folders for more advanced functions, such as creating customized applications.
• Do the public folders support strategic business applications? Analyze the
organization’s primary business applications and decide whether they are using
public folders as a front-end system for form-based and event-based applications.
• What are the plans for sharing the types of information that may be stored in public
folders? For example, is the organization considering deploying an intranet on
Windows SharePoint Services or another Web server for sharing some types of
company information?
Designing Mailbox Servers for Storing Public Folders
Public folders are stored in public folder databases on Exchange Server 2007 Mailbox
servers. By default, if you specify that your organization includes Outlook 2003 or earlier
clients when you install your organization’s first Mailbox server, a public folder database
is created on this first Mailbox server. No other public folder databases are installed, but
you can create a public folder store on any other Mailbox server in the organization.
Considerations When Designing Mailbox Servers to Host Public

Folders
When designing storage space for the public folder database, consider the following
factors:
• Item retention and deletion
• Average and maximum size of physical messages
• Maximum item storage time configured for each public folder
• Default maximum item storage time for the public folder database
• Projected growth rate for public folder usage
If your organization currently uses public folders, you may determine this information
easily. If your organization would like to use public folders now, but has not used them
previously, you might need to spend more time gathering the business requirements to
determine the space to dedicate to a public folder database.
The processor and memory requirements for servers hosting a public folders database are
the same as for other Mailbox servers. If the server is hosting both mailboxes and public
folders, then each MAPI connection requires the same amount of resources whether
connecting to the mailbox database or the public folder database. Because the public
folder database is in its own storage group, you must plan for the extra memory that the
storage group is using.
If your organization uses public folders extensively, you might choose to deploy one or
more dedicated public folder servers. Dedicated public folder servers may have different
hardware requirements than servers that are both mailbox and public folder servers,
depending on the number of user using the public folders and the size of the public folder
store. Because a Mailbox server can host only one public folder database, the hardware
requirements for the dedicated public folder server are likely to be significantly less than
a Mailbox server that has multiple storage groups for mailbox databases.
Exchange Server 2007 Options for Providing High Availability

Exchange Server 2007 provides three options for providing high availability for public
folder databases. Like earlier Exchange Server versions, you can configure public folder
replication so that copies of the public folders are replicated to multiple Mailbox servers.
You also can store the public folder database on a Mailbox server that is part of a single
copy cluster.
Additionally, you can configure LCR or CCR for the public folder database. For LCR,
this option is available if you have only a single public folder database in the entire
organization.
Designing Public Folder Replication
Organizations that use public folders extensively also frequently use public folder
replication to provide fault tolerance for the public folders and better access to public
folders for users in different locations.
Default Configuration for Public Folder Replication and Referrals

Exchange Server 2007 supports a single public folder tree, also known as the public
folder hierarchy. The public folder hierarchy is replicated to each Exchange Server 2007
Mailbox server configured with a public folder database. By default, the content of public
folders exists only on the public folder database where the public folder was created,
unless the public folders were replicated to other public folder databases.
By default, Outlook clients always try to access a replica of a public folder in the same
Active Directory site as the user mailbox. However, if a replica of the public folder
does not exist in the site, users can connect to public folder replicas in another Active
Directory site. This process is called public folder referral. By default, public folder
referrals are enabled between Active Directory sites in Exchange Server 2007. If a public
folder replica is located in more than one other site, the Exchange server refers the client
to access the replicas in order based on the lowest IP site link costs between the sites.
Considerations for Designing Public Folder Replication and Referrals

When developing a public folder replication and referral strategy, it is important to
consider the usage patterns for public folders, the physical network between the
organization’s locations, and the impact that replicating public folders and referrals have
on the network. When designing a public folder replication and referral strategy, consider
the following:
• If network bandwidth is limited between company locations, optimize network
usage by calculating the relative impact of public folder referrals and replication.
The network utilization for public folder referrals is easy to calculate. You simply
calculate how much new content is added to the public folder on a daily basis, and
that is how much network traffic is created if you enable public folder replication.
The network traffic created by public folder referrals is more difficult to measure.
You must determine how many times a day users access the public folder contents
and what the average message size is in the folder. When making this decision,
consider:
• Configuring public folder replication for public folders that do not change
frequently and contain large messages.
• Using public folder referrals for public folders that change frequently, and to
which it is important that users always have access to the latest content.
• Scheduling public folder replication during non-peak hours. In cases of limited
bandwidth and in which users do not need access to a current copy of the public
folder contents, you can schedule public folder replication to occur during non-
business hours.
Note: You can modify public folder referrals by using the Set-
PublicFolderDatabase –id databasename –PublicFolderReferralServerList
‘Servername:Cost’ – UseCustomReferralServerList $True command in the
Exchange Management Shell. This command enables public folder referrals to the
specified servers in different Active Directory sites and assigns a cost to each
server. If you set the UseCustomReferralServerList parameter to true, and do not
add servers to the PublicFolderReferralServerList parameter, public folder
referrals are disabled.
• If the network bandwidth between company locations is not a significant issue, then
the primary considerations for using replication or referrals is server capacity and
client performance. If you have a Mailbox server in a remote site, or if you are
deploying a dedicated public folder server, then you should enable public folder
replication. This provides users with a more positive experience compared to
accessing public folders across a WAN connection. If you do not have a Mailbox
server capacity in the remote site, then use public folder referrals.
• If you have Outlook 2003 or earlier MAPI clients, you should enable replications for
the system folders that these clients require. These folders include the Schedule+
free/busy folders and the offline address book folders. The offline address book
folder includes up to three different versions of the offline address book. Only
replicate the offline address book versions that the Outlook clients in your
organization require.
Designing Client Access to Public Folders
When designing public folder deployment in your organization, you also should plan
for client access. This includes two components: designing access to the public folder
contents based on the messaging client that users utilize, and designing the public folder
hierarchy to ensure that user access to public folders is as efficient as possible.
Designing Messaging Client Access to Public Folders

In Exchange Server 2007, users can access public folders only using MAPI clients such
as Outlook 2007 or earlier Outlook versions. In earlier versions of Exchange server, users
could also access the public folders by using Outlook Web Access or an IMAP4 or
Network News Transfer Protocol (NNTP) client.
In most organizations, users on the internal network are using Outlook to access e-mail
on the Exchange Servers, so these users continue to have access to public folders.
However, organizations rarely deploy Outlook as a MAPI client for users outside the
internal network. To provide access for these users, you have three options:
• You can configure Outlook clients that connect from outside the network to use
Outlook Anywhere. Outlook Anywhere uses RPC over HTTPS to connect to the
Client Access server.
• You can retain public folders on a server running Exchange 2000 Server or Exchange
Server 2003, and provide access to the server through Microsoft Outlook Web
Access. In this configuration, when users connect to the /Public virtual directory on
the Client Access server, they are redirected to the public folder server on the earlier
Exchange Server version and they have access to public folders.
• To provide access to public folders for IMAP4 and NNTP clients, you must leave the
public folders on an earlier Exchange Server version and configure the clients and the
network infrastructure to enable the clients to connect to the Exchange Server hosting
the public folder.
If users are using Microsoft Outlook Web Access, IMAP4, and NNTP primarily to
post messages to public folders, consider mail-enabling the public folder. When you
mail-enable a public folder, this assigns an e-mail address to the folder that enables
users to send messages to the folder using any e-mail client.
Note: If Web access to public folders is important in your organization, consider

moving the public folder content to a Windows SharePoint Services server.
Planning the Public Folder Hierarchy

Exchange Server displays public folders as a hierarchy or tree. If you do not plan this
hierarchy carefully, the public folder structure can become complicated and inconsistent,
making it difficult for users to locate the information they need and making public folder
administration more complicated.
When designing the public folder hierarchy, consider the following guidelines:
Guideline Reason
Create hierarchical structure into Typically, a public folder hierarchy is organized according
logical and consistent groupings that to a company’s business model, so that each top-level
are easy for users to explore and folder represents one department within the company.
access.
Use a consistent and logical naming Users should be able to identify the contents of a public
scheme for public folders. folder from the public folder name.
Create a public folder hierarchy that For example, by assigning the appropriate permissions
enables you to delegate at the top level folders, you can allow users to perform
administrative tasks. tasks such as adding permissions or adding and removing
folders within their department’s top level public folder.
Create a public folder hierarchy that For example, in Exchange Server 2007, you can use
can simplify administrative Exchange Management Shell commands or scripts to
processes. manage public folder settings such as permissions, folder
size and replication. Whenever possible, group public
folders that require the same configuration under a top
level folder, so that you can apply the required settings to
all of the folders in the hierarchy at the same time.
Note: Exchange Server 2007 includes several scripts that you can use
to manage public folders. By default, these scripts are located in
the %programfiles%\Microsoft\Exchange Server\Scripts folder.
Designing Public Folder Permissions
To ensure that public folder infrastructure is easy to manage while providing users with
effective use of public folders, you need to plan the public folder permissions. When
planning public folder permissions, you need to consider administrative and client
permissions.
Designing Administrative Permissions

When designing administrative permissions for public folders, consider the following:
Guideline Reason
Identify a group of administrators Public folders’ administration includes folder creation
who will administer public folders. permissions, assignment to public folders, and defining public
folder replication. This group of administrators should be the
only group with permission to create and configure top level
public folders.
Plan to delegate administrative In most cases, the public folder users understand the public
permissions for lower level folders. folder requirements better than the messaging administrators.
This means you can delegate the public folder administration
tasks such as creating new public folders and assigning
client permissions to advanced users. In many organizations,
each department assigns a user or group of users who can
manage the department’s public folder.
Note: If you want to provide users administrative access to public folders, use the
public folder permission roles. The folder owner role allows users to create new
folders and assign permissions to lower-level folders, but does not allow them to
modify other public folder settings, such as replication or folder size.
Designing Client Permissions

You use roles to manage client permissions to access public folders. A role is a
permissions template that grants clients the permissions they need to access folders and
folder items. Use Microsoft Outlook or the Exchange Management Shell to assign public
folder roles.
Client permissions are applied to a user based on the following rules:
• If the user is explicitly granted permission to the public folder, only those clients
granted permission are applied to the user.
• If the user is a member of a distribution group that has permission to the public folder,
the user’s permissions are the least restrictive of either the group permissions or the
default permissions for the public folder.
• If the user is a member of multiple distribution groups, the user’s permissions are the
least restrictive of any distribution group or the default permissions for the public
folder.
When designing client permissions, consider the following:

Guideline Reason
Create mail-enabled universal You can grant access to public folders for individual users, but
security groups to enable managing groups is more efficient than managing individual users.
public folder permissions. Start by determining the users who require access to public
folders, which folders they require access to, and the level of
access required to the public folders. Then create groups for each
unique set of permissions, assign permission roles to the groups,
and add users to the groups.
Plan for default and In addition to assigning permissions to individual users or groups,
anonymous permissions. you can also assign default and anonymous public folder
permissions.
Default permissions are assigned to all authenticated users. In
Exchange Server 2007, the default group is assigned the Author
permission role. This means that all users can view the folder
contents and create new items in the folder. If you have public
folders containing confidential information, you must modify the
default permission.
Anonymous permissions are assigned to unauthenticated users,
including those without a mailbox and those who are not custom
recipients in the organization. However, an anonymous user is
restricted to accessing public folder content that has been granted
anonymous permissions. Because all Outlook clients must be
authenticated in order to access a user mailbox, you rarely allow
anonymous access to public folders in Exchange Server 2007.
Note: Some organizations enable anonymous access to public folders through

Microsoft Outlook Web Access. To provide this access in Exchange Server 2007,
you must deploy the public folders on an earlier Exchange Server version.
Discussion: Preparing to Transition from Public Folders
Exchange Server 2007 de-emphasizes public folders, especially for organizations with
only Outlook 2007 or later clients. For organizations that currently are not using public
folders extensively, this does not result in any disruption. However, some organizations
make extensive use of public folders. These organizations must carefully plan their
migration away from public folders.
Q What types of issues will the public folder changes in Exchange Server 2007 create
for your organization?
A Answers will vary. For those organizations that do not use public folders, the changes
will have no impact. If organizations currently only allow access to public folders for
MAPI clients, users are not affected. If organizations provide access to public folders
for Microsoft Outlook Web Access, IMAP4, or NNTP clients, they need to plan for
an alternative way to provide content access.
Exchange administrators are affected because they can no longer administer public
folders using a tool like Exchange System Manager. Public folders can be
administered only by using Exchange Management Shell in Exchange Server 2007.
Organizations with written applications that use public folders are not immediately
affected unless the applications use IMAP4 or NNTP to communicate with the public
folder.
Q How will your organization adjust to those changes?

A Answers will vary. Some organizations start exploring options for replacing public
folder access, while others may retain an Exchange Server 2003 server dedicated to
providing public folder access.
Q What options will you explore for migrating content away from public folders?
A The recommended solution for replacing public folders is Windows SharePoint
Services. Windows SharePoint Services provides document libraries that can store
many different types of contents, including messages. Windows SharePoint Services
document libraries enable users to access content using any Web browser, and offer
an intuitive user interface for accessing content and features such as indexing and
filtering to locate information rapidly.
Q What are the implications of using these options for providing access to content that
public folders store currently?
A If your organization has significant amounts of data in public folders, migrating the
content from the public folders to Windows SharePoint Services requires significant
effort. This is particularly true if the public folders have a complicated permissions
structure and you need to replicate the permissions in Windows SharePoint Services.
Additionally, you need to provide some Windows SharePoint Services training for
end users if they have not used it before.
Note: Third-party vendors have created migration tools that allow you to migrate
public folder content to Windows SharePoint Services.
Lesson 4: Designing a Lab Environment
As part of the server design process, you need to design a test lab environment. This test
lab environment can serve many different purposes, including testing proof-of-concept,
functionality, integration, and scalability. For these tests to provide valid results, you
must ensure that you design the test lab environment correctly.
Objectives
• Design a test lab environment.
• Design a pre-production test lab environment.
Designing the Test Lab
Deploying Exchange Server 2007 introduces some significant changes to an

organization’s infrastructure. These changes must be tested before they are deployed into
production. To provide sufficient testing, you should create a test lab early in the design
process.
Purpose of Test Lab

You use the initial test lab for an Exchange Server 2007 deployment primarily for proof-
of-concept and functionality testing. It also provides administrators an opportunity to
learn the new technology.
• Proof-of-concept testing enables testing of a design decision. A design decision for a
particular feature is based on a business requirement. Proof-of-concept testing
ensures the design actually achieves the business requirement.
• Functionality testing ensures that systems perform as expected in a specific situation.
For example, Exchange Server 2007 makes message routing decisions based on
Active Directory sites, so a functional test confirms that messages are routed between
Active Directory sites as anticipated.
• The test lab also provides messaging administrators an early opportunity to become
familiar with the new technology.
Designing the Test Lab Environment

To ensure the organization’s proof-of-concept and functionality testing is valid, the test
lab environment must at least partially replicate the production environment. When
designing the test lab environment, consider the following:
• Duplicate the complexity of the production Active Directory environment. If you are
deploying Exchange Server 2007 in a multi-domain or multi-forest environment, you
should replicate this environment in your test lab. However, you may not need to
duplicate the entire production environment. For example, if your Active Directory
forest contains a forest root domain and five child domains, you can duplicate the
environment’s complexity with a forest root domain and two child domains.
• Include all required server roles. To test a particular concept fully, you may require
all of the server roles that you will deploy in the production environment. This means
the Exchange servers, as well as additional services such as DNS, are required.
• Simulate the network infrastructure. During proof-of-concept and functionality
testing, you are not usually testing the system performance. For example, you are
testing how Exchange Server 2007 routes messages between sites, and not testing the
bandwidth that message routing uses. This means that even if your organization has
multiple locations, you do not necessarily need to configure a test lab in each location.
Tip: If your organization has Exchange Server administrators in multiple locations,

you may choose to configure a test lab in each location and then use the actual
WAN links to test intra-site functionality. If you do, ensure that your test does not
interfere with production activities.
• If you are not doing performance testing, consider using virtualization technology,
such as Microsoft Virtual PC or Microsoft Virtual Server. Running your test lab in a
virtual environment means that you can run multiple test servers on limited hardware.
You can save the virtual machines at any phase in the process or shut down the
virtual machines at any point without saving changes. This means that you can run
multiple tests efficiently in the environment. Note that when using Virtual Server or
Virtual PC, your testing will be limited to the 32-bit version of Exchange 2007.
Designing the Pre-Production Lab
As you progress with the Exchange Server 2007 design, the test lab’s focus changes from
proof-of-concept and functionality testing to testing that provides information on system
scalability and that prepares Exchange administrators to manage the new environment.
Purpose of the Pre-Production Lab

You use the pre-production lab for the following purposes:
Purpose Description
Scalability testing. In the pre-production lab, the focus changes from testing how
Exchange Server 2007 functions to testing how well Exchange
Server 2007 performs in a particular network or server
configuration. During scalability testing, you test how many
mailboxes can be stored on a Mailbox server with a particular
hardware configuration, or test how much network traffic is
created by public folder replication.
Backup and recovery testing. A critical component of pre-production testing is to test the
backup and recovery procedures. These tests define the backup
and restore procedures and test the system capacity.
Preparing build and transition The pre-production lab is also used to create the documentation
to production documentation. that is utilized to deploy the Exchange Servers and to create the
documentation that Exchange administrators need to manage the
system after deployment.
User acceptance testing. User acceptance testing is designed to ensure that the system
addresses the business, functional and non-functional
requirements defined at the beginning of the project. The user
acceptance testing in the pre-production lab provides the final
approval for the design before deployment begins.
Designing the Pre-Production Lab Environment

Because pre-production testing has a different focus than the test lab, the pre-production
lab environment also is different because:
• The pre-production lab should replicate as closely as possible the production
environment at a specific hardware level. For example, to test a Mailbox server and
SAN capacity, use the same hardware and connection to the SAN that is used in
production.
• The software used in the pre-production lab also should replicate as closely as
possible the software deployed in the production environment. This is important
when creating the build documentation, but also is important when performing
scalability and UA testing. For example, antivirus on the Mailbox server may affect
server performance, so you must install this software on the server before performing
scalability tests.
• You can design the pre-production environment to replicate only part of the
production environment. For example, rather than deploying multiple servers in the
same role in the pre-production environment, you can use a single Mailbox server to
test scalability.
Tip: Because the pre-production lab environment must replicate the hardware that
the production environment uses, many organizations order some of the production
hardware early in the design phase to ensure that it is available for testing.
Lab: Designing Exchange Servers

• Plan an Exchange Server deployment.
• Plan test lab requirements.
Lab Setup
lab, you must:
Pa$$w0rd.
it. The 5053A-LON-CL1 computer is a member of the Treyresearch.net domain.
Lab Scenario
Exchange Server 2007. Trey Research currently has three remote sites in addition to their
Corporate Headquarters 10,000 after the • 500 – Outlook Anywhere and mobile client users
new London • 800 – Outlook users connecting through a VPN
office is ready
London (new office) 4,000 • 200 – Outlook Web Access users
(anticipated) • 50 – Outlook Anywhere and mobile client users
If you need to review the Trey Research Active Directory site design and the Trey
Research network perimeter design, review the following documents in the
D:\LabResources folder.
• TR_ProposedADSiteDesign.vsd
• TR_ProposedPerimeterDesign.vsd
Note: The documents in the LabResource folder on LON-CL1 also are available in
the Student workbook appendix.
Exercise 1: Planning an Exchange Server Deployment

In this exercise, you will plan an Exchange Server deployment for Trey Research.
• Server design document to design a proposed server deployment.
1. Review the Trey • Review the following sources of information located in the
Research documentation. D:\LabResources folder:
• Server Design Interview Notes.doc
• Review the table from the Practice in this lesson to identify the
standard server configurations.
2. Modify the • Open the TR_ServerDesign.doc file from the

TR_ServerDesign.doc file D:\Mod03\Labfiles\LabInputs folder.
with a proposed server • Fill in the table for the London headquarters, and the Toronto and
deployment. Chennai locations. For each company location, include:
• The server roles that will be deployed in the location.
• The standard hardware configuration required for the server.
• For Mailbox Servers, identify the number of storage groups
and databases on each server.
• For each server, provide a rationale for the proposed server
deployment.
TR_ProposedServerDesign.doc.
Note: Use the information that was gathered in the Practice for
this module to determine the hardware levels that will be
required for each Exchange Server. Be prepared to discuss your
proposed design with the class.
Discussion Question
After completing the exercise, answer the following:
Q What additional considerations may you need to include in designing the server
deployment?
A Additional information that may be required includes:
• What is the version of Office Outlook client that is deployed in each location?
• If Outlook 2003 or Outlook 2007 is being used, will the clients be configured to
use Exchange Cached Mode or online mode?
• Are public folders used in the organization? If yes, are the public folders being
replicated to all locations? This means that each location will require at least one
additional storage group and database.
• How many Client Access Server clients are connecting concurrently?
• How many e-mail messages are being sent through the Hub Transport servers
between sites, and what is the average message size? How many transport rules
are configured on the Hub Transport servers?
• How many e-mail messages are being sent through the Edge Transport servers to
and from the Internet, and what is the average message size? How much spam do
the Edge Transport servers filter on a daily or hourly basis?
Exercise 2: Defining Test Lab Requirements

In this exercise, you will design the test lab requirements for the Trey Research Exchange
Server 2007 deployment.
To complete this exercise, review the existing Trey Research documentation.
Note: The test lab design should include only the components that you need to test
Exchange Server 2007 functionality and capacity. The test lab does not need to
include the current messaging system.
1. Review the Trey • Review the files located in the D:\LabResources folder to get a
Research clear understanding of the Trey Research current environment.
documentation. • Review the TR_ProposedServerDesign.doc document that you
created in the previous exercise to understand the target state
environment.
2. Design a test lab • Open the TR_TestLabDesign.vsd file from the

environment. D:\Mod03\Labfiles\LabInputs folder.
• Copy the servers’ icons on the TemplateObjects tab to TestLab tab
to create the test lab design.
• Use callouts to define any special configuration requirements for
any of the servers.
TR_ProposedTestLabDesign.vsd.
Note: Be prepared to discuss your proposed design with the

class.
Q What were the critical services that you had to include in the test lab?
A Answers include:
• Deploy domain controllers in the forest root domain and in two child domains.
• Deploy at least two mailbox servers, one of which is running on production level
hardware to perform scalability testing.
• Deploy two Client Access servers, a Hub Transport server, and an Edge
Transport server to test redundancy. At least one server of each server role should
be running on production-level hardware to test scalability.
• Deploy at least one server running multiple Exchange Server roles.
Q How did you deal with not being able to replicate the entire production environment?
A Answers include:
• Include only a sample of the servers that you will deploy in the production
environment.
• Use Virtual Server to run some of the servers that you are not using for
scalability testing.
• Use a single site rather than multiple locations.
the changes.
Lab Shutdown
3. Start the 5053A-LON-CL1 virtual machine. Additionally, you also can start the
Module 4: Designing Security for a
Messaging Environment
Table of Contents
Overview 4-1
Lesson 1: Designing an Administrative Model 4-2
Lesson 2: Designing Message Security 4-9
Lesson 3: Designing Antivirus and Anti-spam
Solutions 4-24
Lab: Designing Security for a Messaging
Environment 4-40
Version 1.2
Module 4: Designing Security for a Messaging Environment 4-1
Overview
A critical consideration when designing a Microsoft® Exchange Server 2007 messaging

solution is ensuring that the messaging system is as secure as possible. This includes
designing an administrative model that allows Exchange Administrators to perform
required tasks without providing them with more administrative rights than necessary.
A second consideration for the security design is message security, which ensures that
messages sent within the organization, and to and from the Internet, meet the
organization’s compliance and security requirements.
A third consideration for to the security design is implementing an antivirus and anti-
spam solution that prevents malicious e-mails from entering the Exchange organization.
Objectives
• Design an administrative model for Exchange Server 2007.
• Design message security.
• Design antivirus and anti-spam solutions.
4-2 Module 4: Designing Security for a Messaging Environment
Lesson 1: Designing an Administrative Model
Exchange Server 2007 provides several options for designing an administrative model
that will provide administrative security in your organization. Exchange Server 2007
separates permissions for the Exchange organization and Active Directory® directory
service more than in previous Exchange Server versions.
Objectives
• Describe the relationship between Exchange Server 2007 and Active Directory
permissions.
• Describe options for planning Active Directory and Exchange permissions.
• Design the administrative security model.
How Exchange Server 2007 and Active Directory Permissions

Relate
When designing an administration model for your organization, you must ensure that
all administrators have only those permissions necessary to perform tasks that are
required for their job. Because Exchange permissions are separate from Active Directory
permissions, Exchange Server 2007 ensures that Active Directory administrators cannot
by default modify Exchange settings and vice versa without being granted explicit
permission to do so.
Exchange Data Categories

Although the Exchange administrative roles are separate from Active Directory
permissions, Active Directory does store all Exchange configuration and recipient
information. This data is divided into the following categories:
• Global Data. Data in the Active Directory configuration partition that is not
associated with a particular Exchange server or with recipients. Modifying global
data generally affects the entire organization and potentially can affect all users.
• Recipient Data. Recipients in Exchange are Active Directory user objects that can
receive or send e-mail messages. The domain partition in Active Directory stores
these recipients.
• Server Data. Data for a specific Exchange server is in the configuration partition in
Active Directory under the specified server’s node. Examples include receive
connectors, virtual directories, per-server settings, and mailbox and storage group
data.
Exchange Server Administrative Roles

To provide access to Exchange configuration information, Exchange Server 2007
provides the following Exchange administrative roles:
• Exchange Organization Administrator role. Provides administrators with full control
of all Exchange organization global data. This role has read access to all recipient
data in Active Directory and write access to Exchange-specific settings for user
accounts.
During the Exchange Setup /PrepareAD phase, a universal security group named
Exchange Organization Administrators is created and assigned to the Exchange
Organization Administrator role. When you install Exchange Server 2007, the
Exchange Organization Administrator role is added as a local Administrators group
member on the computer on which you are installing Exchange.
• Exchange Recipient Administrator role. Provides read access to all user properties
in Active Directory and permissions to modify any Exchange property on an Active
Directory user, contact, group, dynamic distribution list, or public folder object.
During the /PrepareAD phase, a universal security group named Exchange Recipient
Administrators is created and assigned to the Exchange Recipient Administrator role.
• Exchange Server Administrator role. Provides access to local server Exchange
configuration data only, either in the Active Directory or on the physical computer on
which you installed Exchange 2007. Users who are members of the Exchange Server
Administrator role have permissions to administer a particular server, but do not have
permissions to perform operations that impact the Exchange organization globally.
There are no Active Directory groups assigned to this role during Exchange Server
installation. However, you can assign any Active Directory group or user to this
role. When you do so, the group or user is granted permissions to the Exchange
Server object in the Active Directory configuration container, but you must add the
account to the server’s local Administrators group manually. Adding the Exchange
administrators to the local Administrators group provides them with the necessary
permissions to administer the server, but grants them no additional domain
permissions.
• Exchange View-Only Administrator role. Provides read-only access to the entire
Exchange organization tree in the Active Directory configuration container and read-
only access to all of the Windows domain containers that have Exchange recipients.
By default, the Exchange View-Only Administrators Active Directory group is added
to this administrator role.
Note: The separation of permissions is reflected in how you use the administration
tools in an Exchange Server 2007 environment. While you can create user
accounts using the Active Directory Users and Computers snap-in, you only can
view and modify Exchange attributes using Exchange management tools.
Discussion: Options for Planning Active Directory and Exchange

Permissions
To design an Exchange Server 2007 administrative model, you must understand the
requirements for configuring an organization’s administrative permissions and the
associated configuration options that Exchange Server 2007 provides.
Q How has your organization configured Exchange and Active Directory permissions?
A Answers will vary, but there are three models that organizations generally use:
• Unified permissions. A single administrator or group of administrators who
are responsible for administering both Active Directory and the Exchange
organization. This is the most common scenario in small to medium
organizations where one administrator or small administrative team manages
the entire information technology (IT) infrastructure.
• Split permissions. A separation of administrative responsibilities between
Active Directory and Exchange administrators. However, both groups remain
responsible for their administrative area’s entire scope. In this scenario, the
domain administrators have full control of the Active Directory environment
and the Exchange administrators have full control over the entire Exchange
organization. This is a common scenario in larger organizations, which have
separate administrative groups for managing Active Directory and Exchange.
• Delegated permissions. A permissions model in which Active Directory

and Exchange administrators have responsibility over some part of their
administrative area. For example, an Active Directory administrator may be
responsible for a single domain or organizational unit (OU), or the Exchange
administrator may be responsible for one Exchange Server or group of servers.
This delegation also may apply to job functions. For example, an administrator
may be responsible for managing Active Directory user accounts and for
configuring the Exchange recipient properties, but will not have permission to
administer computers or Exchange servers.
• One variation on this option is that you can create a dedicated domain or
forest for the Exchange organization that allows Exchange administrators full
control over the domain or forest that contains the Exchange servers, and the
Exchange environment. However, these Exchange administrators would not have
permissions in the remaining Active Directory environment. Creating a separate
forest to host Exchange Servers is known as a resource forest scenario and it adds
significant complexity to the Exchange environment.
Q If you are running a previous Exchange Server version, how does your organization
have Exchange administrative permissions configured? Will you retain that
configuration when you migrate to Exchange Server 2007?
A In Exchange 2000 Server and Exchange Server 2003, you could assign administrative
permissions using the Exchange Full Administrator role, the Exchange Administrator
role, and the Exchange View-Only Administrator role. You could delegate
permissions for each role at the organizational or administrative group level.
Answers will vary on whether organizations will retain the configuration. Very few
organizations used administrative groups to assign Exchange server permissions, but
because Exchange Server 2007 does not use them, users will need to use server level
permissions if they used administrative groups previously.
Implementing the Administrative Model
Once you understand the best model for your Exchange organization, you can design the
administrative groups required to implement the security design.
Guidelines for Implementing the Administrative Model

To implement the administrative model, use the following guidelines:
• To implement unified permissions, add the appropriate administrators to both Active
Directory administrator groups and Exchange administrator roles. For example, you
can add the Domain Admins group to the Exchange Organization Administrator role.
Note: Whenever possible, use the default Active Directory groups that are pre-
assigned to the Exchange Administrator roles. For example, the Exchange
Organization Administrators group in Active Directory is assigned automatically
to the Exchange Organization Administrator role in Exchange Server. Likewise,
the Exchange Recipient Administrators group in Active Directory is assigned
automatically to the Exchange Recipient Administrator role in Exchange Server.
If you do not use delegated permissions, you should use these default groups.
• To implement split permissions, create Active Directory groups with no Active

Directory permissions and assign them to the appropriate Exchange Administrator
roles.
• To implement delegated permissions, create Active Directory groups for each

unique administrative role that you require. For example, if several administrators
are responsible for administering all objects in an OU, create a group for these
administrators and delegate the Active Directory permissions at the OU level. If
this OU corresponds to an Exchange location and the same administrators are
responsible for administering that location’s Exchange Servers, add the same group
to the Exchange Server Administrator role for each Exchange server in the location.
If one user group will be responsible for administering user accounts and recipients in
the entire organization, create an Active Directory group for these users or add them
to the Account Operators group for each domain, and then add the group to the
Exchange Recipient Administrator role.
Lesson 2: Designing Message Security
Designing message security is an essential part of designing security for your Exchange
Server 2007 organization. Exchange Server 2007 provides several features such as
transport rules, Simple Mail Transfer Protocol (SMTP) connector security, and Domain
Security to provide message-level security.
Objectives
• Define message security requirements.
• Design restrictions to message flow.
• Design SMTP connector security.
• Design secure message routing between partner organizations.
• Design client-based messaging security.
Defining Message Security Requirements
In most organizations, e-mail is a primary tool for exchanging business information, and
many business processes depend upon it. However, SMTP e-mail inherently is not secure
because SMTP message contents are not encrypted or validated. This means that your
confidential information potentially may be exposed through e-mail.
To plan for your organization’s messaging security, you first need to understand what
types of data your organization is sending via e-mail and how you are securing those
messages currently.
Analyze E-mail Message Contents

To collect information about e-mail message contents, you should ask the following
questions:
• Is confidential business information sent by e-mail? This information may include
confidential corporate documentation such as sales projections, salary information,
trade secrets, or intellectual property.
• Is private customer information sent by e-mail? If your organization uses e-mail to
exchange information with customers, you need to analyze the type of information
that you are exchanging. Some information, such as customer queries or orders, may
be confidential. If this information becomes public, the organization’s reputation may
suffer. Additionally, if the customer information includes private information, such as
social security numbers or transactional information, your organization may be liable
legally.
Analyze Message Recipients and Senders

To collect information about message recipients and senders, you should ask the
following questions:
• Are both recipients and senders internal to the organization or is the e-mail sent
externally? In most cases, confidential corporate information is sent to other internal
users. However, those users may be forwarding the information to external e-mail
addresses. In some organizations where users do not have external e-mail access,
they may send e-mail to an external e-mail address, such as a personal one, to enable
them to work outside the office. Customer information almost always is sent outside
the organization.
• Are confidential e-mails sent primarily to a limited number of external organizations
or to a variety of recipients? If confidential e-mails are sent to external recipients, you
need to understand where those messages are going. In some cases, confidential
e-mails may be sent primarily to one or two partner organizations. For example, a
law firm may exchange confidential e-mails with large corporate clients. In other
cases, the confidential e-mails may be sent to thousands of recipients in many
different locations.
Analyze Current Security Mechanisms

Some organizations have some level of Internet e-mail security. In some cases,
organizations use corporate policies to try to restrict what messages are sent to the
Internet. For example, an organization may implement a policy that prohibits e-mails sent
to customers from including the customer’s social security number or credit card number,
or other personal information. Some organizations incorporate technical solutions to
enable security, such as S/MIME, Pretty Good Privacy (PGP), or secure network
connections to secure e-mail.
Organizations that secure e-mail by using policies or technical solutions should analyze
the effectiveness and satisfaction with their current solution by asking the following
questions:
• Are users compliant with e-mail usage policies?
• If the organization policy requires that all customer e-mails with confidential
information be secured using S/MIME, are all users complying with the policy?
If the current security efforts are not effective, then investigate why they are not meeting
the organization’s needs.
Designing Restrictions to Message Flow
One of the options for providing message security is to implement restrictions on what
messages users can send into, and out of, the organization. Exchange Server 2007
provides transport rules that you can use to restrict message flow or to modify messages
in transit by attaching disclaimers or headers to them.
Restricting Message Flow with Transport Rules

You can implement transport rules to restrict message flow in many different ways,
including:
• Implementing Hub Transport rules. The Transport Rules agent on the Hub Transport
server applies Hub Transport rules, which Active Directory stores and which are
applied on all Hub Transport servers in the Exchange organization. You can use
Hub Transport rules to enforce message flow restrictions, such as:
• Preventing inappropriate content from entering or leaving the organization
through the messaging system.
• Filtering the organization’s confidential information that exists within the
messaging system.
• Tracking or archiving messages that specific individuals send or receive.
• Redirecting inbound and outbound messages for inspection before delivery.
• Applying disclaimers to messages as they pass through the messaging system.

When designing the Hub Transport rule implementation, you must define
precisely the messages to which the policies need to apply. In some cases, this
may be easy, such as when you want to apply a transport rule to all messages that
a particular user or group sends.
In other cases, it might require that you use multiple criteria. You can use many
different criteria when selecting conditions and exceptions. For example, to filter
messages for confidential customer information, you can define the criteria that
the transport rule should use to evaluate whether the message contains customer
information. As a best practice, begin your Hub Transport rule deployment by
implementing a few rules at a time and testing them thoroughly.
• Implementing Edge Transport rules. Edge Transport rules are similar to Hub
Transport rules except that the Edge Rules agent, which runs on the Edge Transport
server, enforces them. Because Edge Transport rules are applied at the network
perimeter, you can use them to restrict messages from entering your organization or
to apply policies to messages as they leave your organization.
Active Directory Application Mode (ADAM) stores all Edge Transport rules so they
do not replicate automatically to all Edge Transport servers in your organization. You
can use the cloned configuration feature to duplicate the Edge Transport rule
configuration between servers.
Implementing Message Classifications with Transport Rules

One way to restrict message flow is to implement transport rules that act based on
message classifications. Message classifications are an Exchange Server 2007,
Microsoft® Office Outlook® Web Access, and Microsoft Office Outlook 2007 feature
that enables users to set a classification on a message. The message classification
contains specific metadata that describes the message’s intended use or audience. You
can configure a Hub Transport rule that will use the classification information to
implement message-flow restrictions.
A message classification includes the following information:
• Display name. This field appears in Office 2007 and Outlook Web Access so that
users can use the field to select the appropriate message classification before they
send a message.
• Sender description. This field explains to the sender what the message classification
intends to achieve.
• Recipient description. This field explains to the recipient what the message
classification intends to achieve.
• Locale. This field specifies a culture code to create a locale-specific version of the
message classification.
One option for using message classifications is the Attorney/Client Privilege (A/C
Privileged) message classification. The A/C Privileged message classification is one of
five default message classifications that Exchange 2007 includes. By default, when a user
assigns the A/C Privileged classification to a message, the classification displays for all
organizational recipients, but no transport rule is applied to the message.
However, you can create a Hub Transport rule that enforces the A/C Privileged
classification. For example, if your organization groups all of its attorneys into an
organizational unit called “Legal,” you can configure a transport rule that returns
messages classified as A/C Privileged to the sender if the sender or at least one recipient
on the To or Cc line is not in the Legal group.
You can use message classifications in two ways:
• The message sender can add a message classification manually. A Hub Transport rule
then will apply an action based on this classification.
• A transport rule can add a message classification. For example, if you want to filter
messages that contain customer information, you can configure the transport rule to
scan the message for this information and then have the transport rule apply the
classification.
Exchange 2007 includes five default message classifications, but you can configure
additional ones. Before Outlook 2007 users can set and view message classifications, you
must deploy the message classification configuration files and create an Outlook registry
key on the end users’ computers. The Outlook message classification templates are .xml
files that you must generate after you create and configure the message classifications.
Note: Outlook Web Access in Exchange Server 2007 supports message

classifications without requiring any modifications. For details on how to deploy the
message classification templates to Outlook 2007 clients, see Exchange Server
Help.
Designing SMTP Connector Security
Another option for securing e-mail messages is to modify the default configuration
for SMTP send and receive connectors or create new connectors with more secure
configurations. By default, the SMTP connectors that you use to send Internet e-mail
accept anonymous connections and do not require message encryption.
Options for providing SMTP connector security

To provide additional security for SMTP e-mail, you can use the following options:
• Configure authentication for SMTP receive connectors. If you enable authentication
for receive connectors, you can restrict which users or other SMTP servers can
establish an SMTP connection to them to send e-mail.
• Configure authentication for SMTP send connectors. By configuring authentication
on a send connector, you are configuring your SMTP server to use authentication
when sending messages to another server. If the authentication fails, the message is
not delivered.
• Transport Layer Security (TLS). TLS uses X.509 certificates to encrypt e-mail or to
authenticate one or both servers during an SMTP session.
Guidelines for securing SMTP connectors

As you design SMTP connector security, consider the following:
• If you configure authentication on a receive connector, you ensure that only
authenticated users or servers can send e-mail to the connector. This option is useful
for scenarios in which you want to configure a connector to accept connections only
from a particular partner organization. You can configure the receive connector to
accept connections only from the IP address of the partner organization’s SMTP
server and require authentication. If you use basic or Windows Integrated
authentication, provide the sending organization with the user credentials that the
SMTP server will accept. As a best practice, you should combine authentication with
TLS to ensure that the user credentials are authenticated and that data encryption
occurs.
• You may need to configure authentication on a send connector to meet another
organization’s security requirements. If the other organization requires authentication,
configure the send connector to use the other organization’s SMTP server as a smart
host and then use the user credentials that the other organization or TLS provides to
authenticate the SMTP session.
• TLS encryption ensures that authentication credentials and e-mail messages cannot
be read while in transit. Use this option to provide a level of security beyond
authentication. Before you configure TLS security for SMTP receive connectors, you
must configure the SMTP service with an X.509 certificate trusted by the SMTP
server that will be sending e-mail to your organization. Normally, this will require
that you obtain a server certificate from a public Certification Authority (CA). When
configuring an SMTP send connector to use TLS, your SMTP server must trust the
certificate issued to the destination SMTP server.
• For both SMTP send and receive connectors, you can select the Externally Secured
authentication option if you are certain that there is a trusted network connection
between the servers, such as when you are using a virtual private network (VPN) or a
dedicated network connection between two companies, or when you are using IPSec
to secure the message transfer. This option treats all e-mail messages sent through
this connection as authenticated rather than anonymous messages.
• In most cases, you will need to configure new SMTP connectors to support
authentication and encryption. To send and receive e-mail in most organizations, you
must configure the default SMTP connectors to use anonymous and unencrypted
connections. This is the default configuration for connectors on an Edge Transport
server when you enable edge synchronization. Create a new connector if you are
going to require authentication and encryption for messages from a partner
organization.
• Before you enable either authentication or TLS encryption, you must communicate
with the organizations that will be sending e-mail over the secure connection to
ensure that they configure their SMTP servers to comply with your policies.
• If you deploy an Edge Transport server and implement edge subscriptions, you
should not need to modify the receive connectors on Hub Transport servers. By
default, when you install the Hub Transport server role, two receive connectors exist,
one which will accept only authenticated connections on TCP port 25, and the other
that will accept only authentication connections on TCP port 587. If you enable edge
subscriptions, the connection between the Edge Transport server and the Hub
Transport server are authenticated and all messages are encrypted.
Designing Secure Message Routing Using Domain Security
In addition to configuring the SMTP connectors to enhance message security between

partner organizations, Exchange Server 2007 and Office Outlook 2007 include Domain
Security, a new feature that provides extra security and functionality.
How Domain Security Works

The Domain Security feature provides administrators with a way to manage secured
message paths over the Internet for use with business partners. After you configure these
secured message paths, messages sent over them from an authenticated sender display to
users as “Domain Secured” in the Outlook and Outlook Web Access interface.
Domain Security uses TLS with mutual authentication to provide session-based
authentication and encryption. This functionality enables authentication of all
connections between the partner organizations, and encrypts all messages while they
are in transit on the Internet.
TLS with mutual authentication differs from the usual TLS implementation. Typically,
when you implement TLS, the client verifies a secure connection to the intended server
by validating the server’s certificate, which is received during TLS negotiation. With
mutual TLS, each server verifies the connection with the other by validating a certificate
that the other server provides.
Configuring Domain Security

To set up Domain Security, perform the following steps:
1. On the Edge Transport server, generate a TLS certificates request. You can request
the certificate from an internal private Certification Authority (CA) that your
organization owns and manages or from a commercial CA. Regardless of the CA you
choose, the SMTP server(s) in the partner organization that you use to exchange
messages with your organization must trust the certificate. When you request the
certificate, ensure that the certificate request includes the domain name for all
internal SMTP domains in your organization.
Note: When an SMTP server establishes a TLS session with an Edge Transport
server, the SMTP server validates the Domain Name System (DNS) name in the
server certificate on the Edge Transport server against the DNS name of the e-mail
recipient domain. When you generate the request for the Edge Transport server
certificate, ensure that you include all possible domain names that clients can use
to connect to the server. For example, if you are hosting multiple SMTP domains
that need to be accessible through this connector, you must include all of the
hosted domain names in the certificate request. The Subject Alternative Names
value on the certificate stores the domain name information. You can create a
certificate that contains multiple Subject Alternative Names by using the
DomainName parameter of the New-ExchangeCertificate cmdlet.
2. Import and enable the certificate on the Edge Transport server. After you request the
certificate, you must import the certificate on the Edge Transport server and enable
the certificate for use by the SMTP connectors that send and receive domain-secured
e-mail.
3. Configure outbound Domain Security. To configure outbound Domain Security, use
Exchange Management Shell commands to specify the domains to which you will
send domain-secured e-mail, and then configure the SMTP Send connector to use
domain-secured e-mail.
4. Configure inbound Domain Security. To configure inbound Domain Security, use
Exchange Management Shell commands to specify the domains to which you will
receive domain-secured e-mail, and then configure the SMTP Receive connector to
use domain-secured e-mail.
5. Test domain-secured mail flow. After you configure domain-secured e-mail, you can
test the connection by reviewing the performance and protocol logs. The Domain
Security feature includes the following performance counters under MSExchange
Secure Mail Transport:
• Domain Secure Messages Received
• Domain Secure Messages Sent
• Domain Secure Outbound Session Failures
You can create a new counter log file that contains these performance counters to
monitor the messages sent and received and the failed mutual TLS sessions.
For More Information: For more information on the Domain Security feature, see
the “Domain Security in Exchange 2007” white paper located on the Microsoft
TechNet Web site.
Designing Client Based Messaging Security
Exchange Server 2007 supports client-based solutions for providing messaging security.
Exchange Server 2007 supports both S/MIME and Rights Management Services.
Using S/MIME to Secure E-Mail Messages

One of the client-based solutions for providing message security is Secure/Multipurpose
Internet Mail Extensions (S/MIME). S/MIME uses digital signatures and message
encryption to provide message-level authentication, non-repudiation, data integrity, and
message encryption.
While S/MIME, provides a very high level of security for SMTP messages, there are
several issues that can complicate an S/MIME implementation, including:
• You must install a certificate on each client computer to enable securing e-mail.
There are several issues for which you need to plan regarding certificates:
• Certificate distribution. Because each client computer that will send or receive
e-mail using S/MIME must have a certificate, you must develop a plan for
distributing certificates.
• Certificate trust. You typically use S/MIME to secure e-mail that is sent to
external recipients. The recipients must trust the certificates that you assign to
each computer.
• Public key distribution. To send an encrypted message, the message sender must
have a copy of the recipient’s public key. This means that the message recipient
must have a digital certificate and must provide the certificate with the sender’s
public key. One way to distribute the public key is to send a digitally signed
e-mail. This manual process of distributing public keys makes the entire process
cumbersome.
• Certificate and private key backups. If a user ever loses the private key associated
with their computer’s certificate, the user will not be able to decrypt messages
that were encrypted with the public key associated with the certificate. The local
computer stores the private key, which means it could be lost due to hard-disk
failure or profile corruption. Thus, you must export the private key from each
client computer and save it in safe place.
• You can address many of these certificate issues by implementing a private CA
on a computer running Windows Server 2003, and integrating the CA with Active
Directory. This solution enables automation of many certification management tasks
for internal users. However, unless you configure the private CA as a subordinate CA,
to a trusted public root CA, external clients will not trust the certificates that your CA
issues.
• Another issue with using S/MIME to provide message level security is that it is a
user-based security model. When sending a message, the user must sign or encrypt
the message manually. However, there is no guarantee that users will do this, even if
the message contains confidential information.
• A final issue with using S/MIME to secure messages is that because the messages
entering or leaving the organization are encrypted, and the messages remain
encrypted in the user mailbox, scanning the messages for policy compliance, viruses,
or spam is not possible.
Despite the limitations, S/MIME is the best option for securing e-mail messages sent
from one individual to recipients in other organizations. Most organizations will not want
to set up server-level security for one or two users, so you may need to use S/MIME for
these situations.
Note: Exchange Server 2003 supported S/MIME integration with Outlook Web
Access, where a user could use S/MIME to secure e-mail sent through Outlook
Web Access. Exchange Server 2007 does not have this feature, but it will be
available in Exchange Server 2007 Service Pack 1.
Using RMS to Secure E-mail

Windows Rights Management Services (RMS) for Windows Server 2003 is a technology
that works with RMS-aware applications such as Outlook to protect documents and
e-mail from unauthorized use. With RMS, you can set limitations on what message
recipients can do with the messages that they receive. For example, you can place
restrictions on the messages so that the recipient cannot forward or print the message, or
so that the message expires after a specific time.
To implement an RMS solution, you must install and configure the Windows Rights
Management Services add-on on a computer running Windows Server 2003. All RMS
clients must use RMS aware applications, such as Outlook 2003 or a later version.
RMS is a useful solution for implementing message security for internal users where
users use Outlook 2003 or a later version to read e-mail. However, implementing RMS
for external users and external customers is more difficult because the client computers
must be able to connect to the RMS server to obtain a certificate to enable reading RMS-
protected content. Therefore, Outlook Anywhere users will not be able to access RMS-
protected e-mails while offline, and Outlook Web Access and external users will be able
to access these e-mails only if you make an RMS server Internet accessible.
For more information: Exchange Server 2007 accepts and sends RMS-protected
messages like any other messages but it does not provide any other functionality
directly related to RMS. For technical information about RMS, see the “Technical
Overview of Windows Rights Management Services” white paper.
Lesson 3: Designing Antivirus and Anti-spam

Solutions
Viruses and spam can inflict significant damage on an organization, so a critical

component to consider when you are designing message security for an Exchange
organization is the spam and virus filtering solution you design.
Objectives
• Describe the requirements for an antivirus and anti-spam solution.
• Design an anti-spam solution.
• Apply recommendations for monitoring an anti-spam solution.
• Design antivirus solutions.
• Describe how to integrate Exchange Server 2007 antivirus and anti-spam filtering
using Microsoft Exchange Hosted Services.
• Manage antivirus solutions.
• Design an anti-spam and antivirus solution.
Overview of Antivirus and Anti-spam Solution Requirements
One of the most important issues for any Exchange Server administrator is managing
virus and spam filtering solutions. As an Exchange administrator, you must have constant
awareness of attempts by malicious e-mails to enter your organization. This awareness
includes learning about new techniques that spammers and virus writers use.
Requirements
Many organizations have standard requirements for spam and virus filtering solutions.
Critical factors that you should consider when evaluating these solutions include:
• How often are the antivirus and anti-spam filters updated and are the processes
automated? When a new virus is released on the Internet, it is critical that your
antivirus software is updated before the virus enters your organization. If you
discover a new phishing scheme, it is important that your anti-spam filters are
updated to block the phishing e-mails.
When evaluating an antivirus or anti-spam solution, monitor the speed with which
the vendor provides updates, and ensure that their automated process for distributing
updates works effectively. As a best practice, consider implementing an antivirus
solution that can use multiple scan engines, from multiple vendors, to maximize your
changes of obtaining updates as quickly as possible.
• How does the anti-spam solution provide a balance between false positives and
reducing as much spam as possible? A false positive is a legitimate e-mail message
that the spam-filtering solution incorrectly identifies as spam. One of the most critical
issues in managing an anti-spam solution is the ability to eliminate false positives
while still blocking as much spam as possible. Many anti-spam solutions provide
features such as safe-senders lists or other lists that allow users to define senders
whose messages should not be blocked.
• What options does the solution provide for quarantining potentially malicious
messages? This is particularly important for anti-spam solutions, because this is a
primary method of detecting false positives. At a minimum, the anti-spam solution
should provide a quarantine location that the administrator can monitor for messages
that do not appear to be spam. Some solutions also provide quarantine locations that
users can access to review all messages that were intended for their mailboxes but
which the spam solution filtered instead. Exchange Server 2007 provides a
quarantine mailbox for messages filtered by the content filter, and enables
administrators to resubmit messages from the quarantine mailbox.
• What management and monitoring tools does the solution provide? Antivirus or
anti-spam solutions often include components that run on different computers. The
management tools should provide an efficient means to manage all of these systems.
The solution also should provide an effective monitoring system that can provide
real-time statistics for the messaging administrators, and it should provide alerts
when it detects outbreaks or attacks.
• How well does the solution integrate with your current system? The obvious
requirement is that the anti-spam and antivirus solution work with your messaging
system, but you also should consider additional integration factors. For example,
does the solution provide user-level integration so that you can configure filtering
rules based on your organization’s individual recipients, without necessitating
management of two separate directories? Does the solution integrate with your
administrative model so that you can assign permissions easily to manage and
monitor the system using existing administrative groups?
You also should also document any unique requirements that your organization may have.
For example, if users are using S/MIME frequently to send encrypted e-mail that spam or
virus filters cannot scan, you may need to explore other options for securing this content.
Other organizations may want to ensure that spam filters scan all messages from a partner
organization for viruses, but do not block them.
Designing Anti-Spam Solutions
Designing an anti-spam solution is difficult because if you set all anti-spam features
filters to their most aggressive levels and configure all anti-spam features to reject all
suspicious messages, you are more likely to reject legitimate messages that are not spam.
On the other hand, if you do not set the anti-spam filters at a sufficiently aggressive level
and do not set the spam confidence level (SCL) threshold appropriately for your
organization, you probably will not notice a reduction in spam.
Note: See the Job Aid “Spam Filtering on Edge Transport Servers” located on the
Student Materials CD for a description of spam filtering options and the order in
which spam filters are applied on Edge Transport servers.
Design Considerations for an Anti-Spam Solution

When designing your anti-spam solution, consider the following recommendations.
• Scan for spam at the messaging gateway. To minimize the spam that enters the
internal network, you should try to filter most of it at the SMTP gateway server.
By scanning messages at that server, and rejecting messages that the filters suspect
are spam, you can decrease costs by not delivering and storing suspected spam on
internal servers. The goal is to process and transport as little spam as possible through
the network.
• Scan messages for spam before scanning for viruses. Because anti-spam scanning
blocks a high percentage of incoming Internet messages, it makes sense to scan for
spam before viruses. It is not cost-effective to virus-scan messages that filters will
later identify as spam, because filters will block those messages eventually anyway.
In addition, spam filtering is less resource intensive for messaging servers than virus
filtering is.
• Configure the connection filter agent, recipient filter agent, and sender filter agent
to reject messages. This approach is better than quarantining filtered messages or
assigning metadata, such as anti-spam stamps, to the messages. The connection filter
agent and recipient filter agent automatically block messages that the respective
filters identify. You can configure the action that the Sender Filter agent takes on
inbound e-mail messages. You also should reject messages filtered by real-time block
list (RBL) services and recipient filtering, although the underlying confidence is not
as high as the IP Block list.
• Consider implementing Edge Transport servers as SMTP gateway servers. There are
many third-party, anti-spam solutions available, but Edge Transport servers provide
additional integration with the internal Exchange organization when you enable Edge
Synchronization. For example, if you enable Edge Synchronization, the recipients
and safelist aggregation lists from inside the organization are replicated to ADAM on
the Edge Transport server, which then uses the information to filter spam.
• Implement safelist aggregation. Safelist aggregation enables the Edge Transport
server to make spam-filtering decisions by using the data from the Safe Recipients
Lists or Safe Senders Lists and contact data that Outlook users configure. Safelist
aggregation can reduce the instances of false-positives in anti-spam filtering. When
an Exchange administrator enables and configures safelist aggregation, the Content
Filter agent passes e-mail messages from the safe senders, recipients, or contacts to
the user mailbox without additional processing.
Note: Safelist aggregation data contains both the user’s Safe Senders list and the
user’s Safe Recipients list. When you use the Update-Safelist cmdlet, you can
specify whether to update the Safe Senders List or the Safe recipients list, or both.
However, the safelist aggregation feature only uses Safe Senders list data, and
does not act on Safe Recipients List Data. Therefore, to reduce Active Directory
storage and replication issues, you should not run the Update-Safelist cmdlet with
the Type parameter set to the SafeRecipients or Both values. The default value for
the Type parameter is SafeSenders.
• Implement automatic anti-spam updates. Exchange Server 2007 includes many anti-
spam features that depend on downloaded data to determine whether a message is, or
is not, spam. You must continually update this data, which includes content filter
updates, Microsoft IP Reputation Service data, and spam signature data, to ensure
that the anti-spam features function optimally.
The Exchange Server 2007 Edge Transport server support manual is updated by
default. To enable updates, the administrator must access the Microsoft Update site
to download and install the content filter updates. The content filter update data
is updated and available for download every two weeks. Automatic updates are
available if you have an Exchange Enterprise client access license (CAL) for each
user mailbox or a Forefront Security for Exchange Server license. Manual updates
from Microsoft Update do not include the Microsoft IP Reputation Service or spam
signature data. The Microsoft IP Reputation Service and spam signature data is only
available with Automatic Updates.
• Increase the filtering level over time. When you first implement the anti-spam
solution, you should plan a fairly non-aggressive configuration of the anti-spam
features. This approach lets you minimize the number of false positives. As you
monitor and adjust the anti-spam features, you can become more aggressive about the
type of spam and spam attacks that your organization experiences.
Recommendations for Monitoring the Anti-Spam Solution
It is almost impossible to configure an anti-spam solution so that it functions optimally

immediately after being placed into production. When you first implement the solution,
you are likely to have too many false positives, or too much spam will continue to get
through your defenses. Even if you optimize the configuration, spammers are constantly
trying new techniques to slip messages past your spam filters.
Defining the Monitoring Requirements

The first step in designing the anti-spam monitoring process is to gather the monitoring
requirements. As part of the monitoring process, you should:
• Monitor for false positives. This is probably the most important monitoring to
perform because messages that you filter falsely as spam can disrupt business
processes. Depending on how you configure your anti-spam filters, users may not
be aware that legitimate e-mails are being deleted.
• Monitor for filtering effectiveness. You also should monitor anti-spam filters to
determine whether they are blocking most of the spam messages.
• Monitor the quarantine mailbox. If you configure content filtering to send messages
with a specific SCL to a quarantine mailbox, you must monitor the quarantine
mailbox on a regular basis. This is particularly important when you first implement
content filtering.
• Collect user feedback on the spam filter’s effectiveness. Spam filters most directly
affect users, and they often can provide the most valuable feedback. To collect this
feedback, ensure that the Help Desk personnel track all calls pertaining to spam
filtering and distribute a user survey on a regular basis. One option for collecting user
feedback is to request that they forward all spam messages to a spam collection alias.
Designing the Monitoring Process

After you establish the monitoring requirements, you need to design a monitoring process.
As part of the monitoring process design, you should:
• Identify the administrators who are responsible for monitoring the spam solution and
provide them with tools for monitoring it. Exchange Server 2007 provides several
scripts in the %programfiles%\Microsoft\Exchange Server\Scripts folder that enable
collection of agent log information. These scripts provide information such as the IP
addresses or domain names with the most blocked spam messages or which
recipients are receiving the most spam messages.
• Establish guidelines for how frequently administrators should monitor the system.
Some anti-spam solutions provide real-time monitoring, while others provide tools
for verifying the solution status at various points in time. You should ensure that
administrators monitor the system frequently enough to rapidly identify any issues.
• Establish a change-control process for modifying spam filters. If the monitoring
shows that the filters are identifying too many messages as false positives, or if a new
type of spam message is bypassing your filters, you should have a change-control
process in place to modify the spam filters. In some scenarios, this may require
immediate action. In other scenarios, you may have additional time to implement a
solution. You should include both scenarios in your change-control process.
Working with Anti-Spam Stamps

Exchange Server 2007 enables anti-spam stamps to help you diagnose spam-related
problems by applying diagnostic metadata to messages as they pass through the anti-
spam filters. When the Edge Transport server scans a message, it assigns an anti-spam
stamp to it, which you can view to determine why a message was, or was not, filtered.
The anti-spam stamp includes various data, including:
• The sender ID evaluation
• Phishing confidence level
• Spam confidence level
• Custom weight level that assigns a value based on whether the message contains
words on the approved or unapproved content-filter word list
• Time stamps that indicate a significant delay between when the message was sent and
received
• Stamps based on other spam-filtering features
You can view a message’s anti-spam stamp by opening the message in Outlook 2007 and
viewing the Internet headers section in the message options.
Designing Antivirus Solutions
One of the most common ways in which viruses spread from one organization to
another is through e-mail. Thus, one of the primary means of protecting the Exchange
organization is to ensure that you stop all messages containing viruses at the messaging
environment’s perimeter.
Guidelines for Designing an Antivirus Solution

When designing your organization’s antivirus solution, consider the following guidelines:
• Implement a defense-in-depth approach for dealing with viruses. Applying the
defense-in-depth model means that you will implement defenses against viruses at
multiple organizational levels, including:
• Client computer-based solutions. Install and maintain client-side antivirus
software on all client computers that connect to your network, including remote
clients. Additionally, you should enable the anti-spam and anti-phishing features
available in messaging clients such as Microsoft® Office Outlook® 2007 and
Office Outlook 2003, and the anti-phishing features in Microsoft Internet
Explorer® 7.
• Exchange Server-based solutions. Install server-side antivirus software on every
Hub Transport server in your organization to scan all messages as they pass
through them. Many organizations also deploy antivirus software on Mailbox
servers to scan the mailbox databases. Antivirus software on the Mailbox servers
uses the Microsoft Virus Scanning API (VSAPI) to scan mailbox databases.
• Internet edge-based solutions. You also should deploy antivirus and anti-spam
software on the SMTP server, or Edge Transport server, that is accessible directly
from the Internet. This software scans files as they enter the organization, thereby
stopping the viruses and spam before they get into, or out of, the network.
• Delete, rather than clean, infected messages. Although it is possible for some
antivirus solutions to remove a detected virus from a message and preserve its
contents, such attempts may not be completely effective. Therefore, sending these
messages through the system presents a potential liability. For this reason, you should
delete infected messages.
• Strip attachments of certain file types. By stripping all attachments that contain
executable content, you can help protect an environment from unknown or recently
released malware that e-mail attachments transmit and for which signature files are
not yet available or deployed. A best practice is to implement attachment stripping at
the e-mail gateway layer and to match the gateway-layer attachment stripping policy
with the attachment blocking policy that the client enforces.
• Scan both incoming and outgoing e-mail for viruses. Although scanning incoming
e-mail is a primary method for keeping a messaging environment free of viruses, you
must also ensure that internal users do not send viruses in outgoing e-mail.
• Implement an antivirus solution that can take advantage of new Exchange
Server 2007 features, including two new ones that antivirus vendors can use to
optimize antivirus solutions:
• Transport agents for antivirus scanning. In an Exchange Server 2007
environment, all messages must pass through a Hub Transport server, and
inbound and outbound messages will pass through an Edge Transport server, if
you deploy one. On the transport servers, you can use transport agents to scan
messages and apply policies to them. This also applies to antivirus scanning.
Antivirus vendors can create transport agents that specifically scan for viruses.
• Antivirus stamping. Antivirus stamping helps reduce the number of times a
message is scanned as it is sent through an organization. This feature works by
stamping messages that an antivirus solution scans with the name and version of
the antivirus engine that performed the scan and the scan’s results. The antivirus
stamp travels with the message as it proceeds through the organization, and other
Exchange servers use it to determine if virus scanning is necessary for a message.
By reducing the number of times a virus needs scanning, you can reduce the use
of server resources that scanning requires.
Forefront Security for Exchange Server

Forefront Security for Exchange Server (formerly called Microsoft Antigen for
Exchange) is a Microsoft antivirus solution that integrates with Exchange Server 2007. It
provides advanced protection, optimized performance, centralized management, and
other features, such as:
• Support for multiple anti-virus engines. Forefront Security for Exchange Server
includes industry-leading, anti-virus engines from global security firms such as
Kaspersky Labs, CA, and Sophos. You can use as many as five scanning engines at
once and in different combinations across the server system. Forefront Security for
Exchange Server automatically downloads the latest signatures and selects the
optimal combination of engines to use that ensure a high protection level and reduce
exposure to any given threat.
• Layered protection. Forefront Security for Exchange Server provides protection
at multiple checkpoints in the messaging infrastructure, including Exchange
Server 2007 Edge Transport, Hub Transport, and Mailbox servers.
• Forefront Security for Exchange Server utilizes the transport agents and virus
scanning API technologies of Exchange Server 2007.
• Centralized management of remote installation, engine, and signature updating,
reporting and alerts through the Forefront Server Security Management Console.
For more information: For additional information on the Forefront Security for
Exchange Server features, see the Microsoft Forefront Security for Exchange
Server: Features Web site.
Integrating Antivirus and Anti-Spam Filtering Using Exchange

Hosted Services
Microsoft Exchange Hosted Services is a subscriber-based service that offers managed

message-related services, including e-mail and instant message archival, content and
policy enforcement, protection against spam and viruses, disaster recovery, and e-mail
encryption and continuity.
Services Provided by Microsoft Exchange Hosted Services

The services that Microsoft Exchange Hosted Services provide fall into four broad
categories:
• Exchange Hosted Archive. The law requires that many organizations retain certain
messages. Because of the amount of business that many organizations conduct via
e-mail, they probably would like to preserve electronic records in much the same way
as paper records. Exchange Hosted Services provides a messaging archive solution
that organizations can use to ensure that the Exchange Hosted Services data center
archives messages that meet specified criteria. The archived messages are accessible
to the organization’s users.
• Exchange Hosted Continuity. As organizations increasingly rely on e-mail
communication, the impact of losing message-related services becomes critical.
Exchange Hosted Services ensures continuous access to messaging services during
network outages. All Internet messages are sent first to the Exchange Hosted Services
messaging servers, and these messages can be queued at the service location for five
days if the organization’s mail servers are not available. Users can access the
messages at the Exchange Hosted Services location. The Exchange Hosted Services
location can store all messages sent to the organization from the Internet or internally
for 30 days.
• Exchange Hosted Filtering. Exchange Hosted Services provides complete filtering

services to block unwanted e-mail messages from entering the organization.
Exchange Hosted Services uses at least three different antivirus engines to scan
all messages. Exchange Hosted Services also applies anti-spam filters and policy
enforcement based on the organization’s requirements for inbound and outbound
messages.
• Exchange Hosted Encryption. Organizations can use Exchange Hosted Encryption to
send secure e-mail messages to recipients in other organizations. Exchange Hosted
Encryption uses Identity-Based Encryption (IBE) technology, which uses a
recipient’s e-mail address as the public key rather than requiring a client certificate
on each client. When a user sends a secure e-mail message, the message is sent
directly from the client to a gateway server at the Exchange Hosted location. The
message is encrypted using Transport Layer Security (TLS). Then, a private key for
the recipient is created and stored at the Exchange Hosted Services location. Upon
receiving an encrypted message, the recipient completes a two-step authentication
process through e-mail answerback to verify the recipient’s identity. After
completing this process, the recipient can decrypt, view, and reply to the message
using a clientless, browser-based method named Zero Download Messenger (ZDM).
The encrypted message remains accessible in the recipient’s e-mail inbox.
For more information: For additional information on Microsoft Exchange Hosted

Services, see the Microsoft Exchange Hosted Services Web site.
Integrating Exchange Hosted Services with Exchange Server 2007

When you subscribe to Exchange Hosted Services, it modifies the mail exchange (MX)
resource record in Domain Name System (DNS) to point to the Exchange Hosted
Services SMTP servers. The MX resource record then routes all inbound messages to one
of the Exchange Hosted Services data centers, where the messages are filtered for viruses
and spam, and policies are applied to the messages. The messages are forwarded, using
secure SMTP e-mail, to your organization’s message servers. Users can access e-mail
using their regular e-mail clients or directly on the Exchange Hosted Services servers if
the local messaging service fails.
As a security best practice, you should configure the SMTP gateway server on your
network to accept only SMTP connections from Exchange Hosted Services messaging
servers. This prevents anyone from sending messages directly to your organization.
Managing Antivirus Solutions
Managing an antivirus solution must be a priority for messaging administrators. Virus

writers are developing new viruses constantly that exploit new vulnerabilities or that use
new techniques to bypass an antivirus solution. Thus, it is critical that you conduct daily
monitoring and management of your antivirus solution.
Guidelines for Managing Antivirus Solutions

To manage your organization’s antivirus solutions, you should:
• Develop clearly defined policies and processes for managing antivirus solutions.
These policies and processes should identify which administrators are responsible
for daily monitoring tasks and how frequently they should perform these tasks. The
policies and processes also should define the action to take if a virus outbreak occurs.
• Automate as many processes as possible. For example, one of the critical components
in managing an antivirus system is ensuring that antivirus software is up-to-date and
running on all servers at all times. Develop an automated process that verifies the
version of the antivirus signature files and scanning engines that you have deployed
on the servers, and that updates the servers if the files are not current. Ensure that the
automated processes also include a means by which you can alert messaging
administrators if the processes fail. You should configure all anti-virus systems to
update daily, and configure all critical systems, such as the Internet edge SMTP
servers, to update several times daily.
• Regularly monitor anti-virus software sites for information on new viruses and virus
outbreaks.
• Monitor daily statistics for the volume of processed e-mail, and the number of
detected viruses. A sharp increase in the number of infected messages may indicate
that a new virus has been released, which may require extra vigilance.
• Develop a user education process. Most viruses require user action to initiate an
attack. Therefore, your antivirus management strategy should include a user
education plan that will teach them about viruses and how to deal with suspicious
e-mails. Educating users includes making them aware of current threats, as well as
the importance of keeping their computer systems up-to-date with the latest signature
files and security updates. If you educate users, they may help prevent a virus from
spreading if it infects their system.
• Consider using a solution such as Microsoft Exchange Hosted Services, which offers
the advantage of enabling anti-spam and antivirus solution management from outside
the organization by a group of administrators dedicated to this task. In most
organizations, messaging administrators are busy and it is easy to delay the daily task
of monitoring the antivirus system, especially if they have identified no new viruses
for some time.
Discussion: Designing Anti-Spam and Antivirus Solutions
Exchange Server 2007 provides new features and tools to deal with spam and viruses. As
you design your Exchange Server 2007 deployment, you must consider how you will
integrate these features into your design.
Q Will you be deploying anti-spam filtering using an Edge Transport server in
Exchange Server 2007? What is the reasoning behind your decision?
A Answers will vary. Many organizations already have a very good anti-spam solution
in place and may be hesitant to change to a different system. Edge Transport servers
may provide some features that other spam filtering solutions do not support.
However, other solutions also provide features that are not available with an Edge
Transport server. In some cases, organizations may consider maintaining the current
system and adding an Edge Transport server to take advantage of the ways that the
Edge Transport server can integrate with Active Directory through edge
synchronization.
Q How will you modify your antivirus solution when you deploy Exchange
Server 2007?
A Answers will vary. When you deploy an antivirus solution in Exchange Server 2007,
you should consider replacing or supplementing the Microsoft Virus Scanning API
(VSAPI)-based scanning on Mailbox servers with transport agent-based scanning on
Hub Transport and Edge Transport servers.
Lab: Designing Security for a Messaging

Environment

• Design an administrative model.
• Design messaging security.
• Design antivirus and anti-spam solutions.
Lab Setup
lab, you must:
• Log on to the virtual machine as TreyResearch\Administrator with a password
of Pa$$w0rd.
Note: This course provides two additional virtual machines. 5053A-LON-DC1 is

configured as a domain controller in the TreyResearch.net domain and has a
standard Exchange Server 2007 installation. 5053A-LON-Edge1 is a stand-alone
Lab Scenario
research and investment and is planning to upgrade from Microsoft Exchange 2000
Server to Exchange Server 2007. Trey Research currently has three remote sites and their
Exercise 1: Designing an Administrative Model

In this exercise, you will design an administrative model for Trey Research.
• Active Directory and Exchange Server design
• Security requirements documentation
• Administrative Requirements section in the Security
Requirements.doc
• TR_Info.vsd
2. Modify the • Open the TR_SecurityPolicies.doc file from the

TR_SecurityPolicies.doc file D:\Mod04\Labfiles\LabInputs folder.
with a proposed • Fill in the Administrative Groups table. In the table, provide:
administrative plan.
• The name and domain for each administrative group that
you will need to configure.
• The Active Directory permissions assigned to each group.
• The Exchange Server Administrator role to which each
group will be assigned (if necessary).
• Additional comments on group configuration.
• Save the file as: D:\Mod04\Labfiles\LabOutputs\
TR_ProposedSecurityPolicies.doc.

class.
Q What are the complications of designing an organization’s administrative model with
multiple levels and groups of Exchange and Active Directory administrators?
A One of the potential complications is that it can be very difficult to assign the exact
permissions for each group of administrators. In Active Directory, you can assign
permissions based on organizational units. In Exchange Server 2007, you can assign
permissions at the organization level and at the server level, but you need to ensure
that the OU configuration corresponds to the Exchange Server deployment.
Q How does the proposed Trey Research design vary from your organization’s
administrative design?
A Answers will vary. Small organizations are likely to have a single group of
administrators responsible for Active Directory and Exchange Server 2007. Large
organizations may have a much more complicated administrative structure.
Exercise 2: Designing Message Security

In this exercise, you will design a messaging security implementation for Trey Research.
• Message Security Requirements section in the Security
Requirements.doc
• TR_Info.vsd

TR_SecurityPolicies.doc D:\Mod04\Labfiles\LabInputs folder, or continue working with the
file with a proposed TR_ProposedSecurityPolicies.doc file.
message security plan. • Fill in the Message Security Components table. In the table, provide:
• The type of component you will need to configure.
• The configuration details for each component.
Note: Be prepared to discuss your proposed design with the class.
Note: The answers to the practices and labs are on the Student Materials CD.
Q How did you address the need to exchange secure e-mail between Trey Research and
Contoso Ltd.?
A The design calls for the Domain Security solution to ensure that all e-mail messages
are encrypted and connections are authenticated.
Q Does your organization have a requirement for the domain security solution? What
barriers will there be to adopting this solution?
A The Domain Security solution requires that you negotiate with the partner
organization to ensure that their Exchange Servers also are configured to support
Domain Security. This may be an issue in some organizations.
Exercise 3: Designing Antivirus and Anti-Spam Solutions

In this exercise, you will design an antivirus and anti-spam implementation for Trey
Research.
• Virus and Spam Filtering Requirements in the Security
Requirements.doc
• TR_Info.vsd

TR_SecurityPolicies.doc D:\Mod04\Labfiles\LabInputs folder, or continue working with the
file with a proposed TR_ProposedSecurityPolicies.doc file.
administrative plan. • Fill in the Anti-Spam and Antivirus Solution Components table. In the
table, provide:
• The type of component you will need to configure.
• The configuration details for each component.
Discussion Question
Q How did you design the antivirus and anti-spam solution for Trey Research? How
does this compare to the solution you would implement for your organization?
A Answers for the Trey Research design are in the TR_ProposedSecurityPolicies.doc
file in the LabAnswers folder. Organizations will have varying requirements for
designing the antivirus and anti-spam solutions.
the changes.
Lab Shutdown
Module 5: Designing Messaging Policies
Table of Contents
Overview 5-1
Lesson 1: Designing Exchange Recipient and
Message Policies 5-2
Lesson 2: Designing Mobile Device Policies 5-18
Lesson 3: Designing Messaging Policies for
Compliance 5-25
Lab: Designing Messaging Policies 5-39
Version 1.2
Module 5: Designing Messaging Policies 5-1
Overview
One of the components in your Microsoft® Exchange Server 2007 design is designing
messaging policies for your organization. Policies that you can create include those
related to the administration of Exchange management objects and to managing message
delivery. In many organizations, some of the most important policies that you develop
will relate to managing messaging compliance.
Objectives
• Design policies for Exchange recipients and message delivery.
• Design policies for mobile devices.
• Design messaging policies for compliance.
5-2 Module 5: Designing Messaging Policies
Lesson 1: Designing Exchange Recipient and

Message Policies
When you design the Exchange Server 2007 messaging solution, you may have to design
policies for managing a variety of Exchange objects. For example, you may need to
define policies for naming servers that are running Exchange Server and for naming
management objects, to ensure consistent messaging system administration. You also
may need to specify the maximum storage limits for mailbox databases and policies
related to scheduling meetings or to maximum message size. Additionally, you may need
to plan for exceptions to your policies.
Objectives
• Design a naming convention for Exchange objects.
• Design a calendar and resource management strategy.
• Design mailbox size policies.
• Design message delivery policies.
• Design client access policies.
• Design a process for dealing with policy exceptions.
Discussion: Designing Naming Conventions for Exchange

Objects
The naming conventions that organizations use vary greatly, and there are no standards
for naming Exchange objects. Your goal should be to create effective and consistent
naming conventions that work well for your organization.
Q What are the naming conventions for your organization’s Exchange objects?
A The naming conventions for Exchange objects will vary greatly between
organizations. Some general suggestions include:
• Considerations for naming Exchange Servers. Develop a consistent and
descriptive naming scheme that clearly identifies the server location and role,
and which includes a unique identifier. For example, for the first Hub Transport
server you deploy in London, consider using a name like LON-Hub-01. This
name identifies the location (London), the server role (Hub Transport server),
and includes a sequential number for identifying additional servers that have the
same role in the same location.
• Considerations for designing alias and Simple Mail Transfer Protocol (SMTP)
domain names. All users’ e-mail addresses are comprised of an alias and SMTP
domain names.
By default, when you install Exchange Server 2007, the only accepted SMTP
domain for the organization is the forest root’s domain name. In some
organizations, you do not need to modify the default configuration.
However, some organizations do not use the forest root domain name as their
SMTP domain. These organizations may have an external Internet presence using
an SMTP domain name that is different from the internal forest name. For these
organizations, the user’s SMTP address should be the same as the company’s
SMTP domain.
To modify the domain name component for a user’s e-mail address, you need to
add the required SMTP domain name as an accepted domain and then manually
configure the user’s e-mail address or configure an e-mail address policy to
assign an e-mail address to some or all users.
When designing the alias part of the user name, you need to choose whether you
will use the same name with which users log on. Both the user logon name and
the alias must be unique in the organization and this name should be easy for
users to remember. However, some organizations also consider using the logon
name as the SMTP alias to be a security risk.
By default, the user logon name is assigned as the alias when you create a user’s
SMTP address. If you need to modify the default setting, you can modify the
default e-mail address policy or create a new e-mail address policy. In the policy,
you can specify any combination of the user’s first and last names as the alias.
For example, you can configure a policy that specifies Firstname.Lastname, or
FirstinitialofFirstnameLastname as the alias.
• Considerations for naming Exchange management objects. For all Exchange

management objects, make sure that the naming scheme is intuitive, descriptive,
and that you apply it consistently. For example, apply these considerations when
creating the following objects:
• Resource mailboxes. Include the resource mailbox location. For example, the
name should indicate in which city the mailbox is located, as well as which
building and on which floor of the building. In the mailbox attributes, add
additional information, such as meeting-room size, equipment in the room,
and other characteristics. Use consistent naming formats for the additional
attributes to ensure that users get consistent results when they search for the
resource mailboxes.
• Policies. Exchange Server 2007 enables you to create policies, such as e-mail
address policies, Exchange ActiveSync mailbox policies, Unified Messaging
mailbox policies, and managed folder mailbox policies. Policies are designed
to simplify the simultaneous application of changes to large numbers of
recipients. When you design the policy names, ensure that the name clearly
identifies to whom the policy applies and each policy’s purpose.
• Public folders. When you design the public folder naming format, consider
both the public folder hierarchy and the public folder names. Normally, the
public folder hierarchy is organized by geographical location or department
name. Under the top-level public folders, ensure that you use clear,
descriptive names that indicate the folder’s content or purpose. This ensures
that users can quickly browse to the folder for which they are searching.
• Storage groups and databases. A large Exchange Server 2007 organization
may have hundreds of storage groups and mailbox or public folder databases.
When you design the naming format for these objects, ensure that the name
reflects the location for the object, such as the server that contains the object
or the geographic location, and include some description of the object. For
example, you may choose to include the characters EXEC for all mailbox
databases that contain executive mailboxes.
Q How effective is the naming convention?

A Answers will vary. In large, well-managed organizations, the naming conventions are
likely to be enforced very strictly. In smaller organizations, there may be more
flexibility.
Q Will you change the naming convention during the migration to Exchange Server
2007? What issues do you expect to encounter if you change the naming convention?
A Answers will vary. Naming conventions that include these features may need to be
changed because some features, such as routing and administrative groups, are no
longer relevant in Exchange Server 2007.
Designing a Calendar and Resource Management Strategy
Exchange Server 2007 provides various resource mailboxes, such as meeting rooms and
equipment. You can invite these resources to meetings as a way of reserving the meeting
room or equipment. Exchange Server 2007 provides several options for managing those
users who can book meetings using resource mailboxes.
Options for Configuring Auto Acceptance Settings

Exchange Server 2007 enables a variety of settings when configuring resource mailbox
settings. For example, you can use the Set-MailboxCalendarSettings command in the
Exchange Management Shell to configure the following settings:
Setting Description
AllowConflicts Specifies whether to allow meeting requests that conflict. The
default configuration is false, which prevents overlapping
appointments for a resource.
AllowRecurringMeetings Specifies whether to allow meetings that happen regularly. The
default is true, which allows you to books rooms and equipment
for recurring meetings such as weekly status meetings.
AllRequestInPolicy Specifies whether to allow all users to submit in-policy requests.
The default is true, which allows all users to request appointments
with the resource, if the request meets all specified requirements,
such as no conflicts. A resource mail delegate still must approve
all requests, unless AllBookInPolicy is true.
AllBookInPolicy Specifies whether to approve in-policy requests automatically
from all users. The default is true, which allows all users to book
appointments with the resource, if the request meets all specified
requirements, such as no conflicts.
(continued)
Setting Description
AllRequestOutOfPolicy Specifies whether to allow all users to submit out-of-policy
requests. The default is false, which prevents all users from
requesting appointments that do not meet specified requirements,
such as no conflicts.
BookInPolicy Specifies a list of users for whom requests that meet the specified
requirements are booked automatically without approval from a
resource mailbox delegate.
RequestOutOfPolicy Specifies a list of users who can submit appointment requests
that do not meet specified requirements, such as no conflicts. A
resource mailbox delegate still must approve all requests.
TentativePendingApproval Specifies whether to mark pending requests as tentative on the
calendar. The default is true, which marks appointment requests
as tentative until they are approved. When this value is false,
pending appointments are not displayed on the calendar.
MaximumDurationInMinutes Specifies the maximum length of the appointment that the
resource will accept.
Tip: You can use Microsoft® Office Outlook® Web Access to modify the auto
accept settings for a resource mailbox. To do this, open the resource mailbox using
an account that has full access to the mailbox, and then access the Resource
Settings option on the Options page.
Considerations for Developing a Resource Booking Policy

When designing the resource booking policy, you must consider:
• Who can schedule a resource and whether all users should be able to book a
resource for a meeting. You may accept this as the default for most resources in
the organization, but consider restricting who can book heavily used or important
resources. For example, if you use a resource room mailbox to manage the schedule
for a large conference room, you may want to restrict who can book meetings in the
conference room.
• When users can schedule the resource. You may want to set restrictions on what time
of day meetings can be booked with a resource, or set restrictions on meeting length
or meeting recurrence.
• The automatic acceptance policy for the meeting resource. By default, all resource
mailboxes are configured to accept all new appointment requests as tentative, which
requires that a user approve the request. Because the meeting is set to tentative, this
also enables other users to book the meeting resource for the same time. By changing
the AutomateProcessing attribute for the resource mailbox, you modify the default
behavior. The default value is configured as AutoUpdate. If you set the value to
AutoAccept, the resource mailbox accepts all meetings from authorized users
automatically and prevents other users from booking the resource at the same time.
Designing Mailbox Size Policies
One of the important policies that you must define for an Exchange Server 2007
organization is the mailbox size policy. To design an organization’s mailbox sizes, you
must understand the business requirements and the constraints for mailbox size limits.
Business Requirements for Mailbox Size Limits

To determine the business requirements for mailbox size limit, begin by reviewing the
organization’s current mailbox size restrictions and the number of users who are exempt
from the standard size restrictions. Review the average mailbox size for the organization,
and determine whether the current mailbox size is sufficient to meet the organization’s
requirements. If the organization is planning to increase the current mailbox size limit,
you can determine the new mailbox size limit based on the organization’s requirements.
One of the factors that you need to consider when designing the mailbox store policies is
the organization’s message storage requirement. In some organizations, users must delete
all messages after a certain time. In other organizations, users must retain messages for
several years, because the organization does not have an archive solution.
Note: If the organization requires that users store messages for an extended time,
consider implementing an archiving solution. An archiving solution provides a
location outside the user mailbox in which to store e-mail messages where users
can still access them. The archive solution can prevent users from accidentally
deleting important messages.
Mailbox Size Constraints

A Mailbox server’s capacity to store mailboxes is an important constraint in designing
the mailbox size policy. One option for calculating an organization’s maximum possible
mailbox size is to define the maximum storage capacity that the organization can afford
to purchase for the mailbox servers, and then divide that amount by the number of
mailboxes.
When designing the maximum mailbox size, you must consider the disk space that each
mailbox uses. The actual disk space that is used to store mailbox databases includes the
database whitespace, database dumpster, and content indexing.
Note: For detailed information on the actual disk space used for mailbox
databases, see Module 3: “Designing Exchange Servers,” in this course.
In most organizations, hard disk capacity is not the most important factor in determining
the maximum mailbox size. In most cases, the backup and restore capacity for the
Mailbox servers is more important when designing the mailbox size policy. The total
available hard-disk space does not determine the maximum mailbox size, but rather, how
fast you can back up and restore the mailbox, and the recovery requirements that your
organization’s service level agreement (SLA) specifies.
For example, if the SLA specifies that you should restore any failed mailbox database
within two hours, and if your backup system can restore only 50 gigabytes (GB) of data
per hour, you should have a maximum database size of 100 GB.
Note: You also should consider the time it will take to initiate the backup procedure
when designing the database size based on the time it takes to recover the
database. For example, you need to consider the time it takes to locate and load
the backup tape and the time it will take to repair any failed hardware components
that caused the database failure.
Managing Mailbox Size Limit Warnings

When you design the mailbox policy, consider how you will manage a user mailbox that
is approaching the maximum message size. Exchange Server 2007 enables you to send a
warning message to the user, block the user from sending messages, or block the user
from sending and receiving messages when the mailbox reaches a certain size.
As a general guideline, consider sending warning messages when a user’s mailbox
reaches 80 percent of its maximum size, and then prevent the user from sending e-mail
messages when the mailbox reaches 90 percent. You may choose not to prevent users
from receiving e-mail messages at any value less than the maximum mailbox size,
because if that happens, important messages might not be delivered.
Note: You can modify the Exchange Server 2007 quota messages using the Set-
SystemMessage command. For more information, see “How to Manage Quota
Messages” on the Microsoft TechNet Web site.
Designing Message Delivery Policies
In addition to mailbox sizes, you also should plan the size limits for messages sent within
your organization and to external users.
Collecting Requirements for Message Size Limits

As you plan the message size limits for your Exchange 2007 organization, consider the
• What is the network bandwidth between company locations, and between company
locations and the Internet? The amount of available bandwidth is often the most
important constraint when designing message delivery restrictions. If you have slow
network connections between company locations, you should decrease the allowable
message size or schedule larger message delivery during non-business hours.
• What are the company requirements for sending and receiving e-mail? Organizations
may have very different requirements for sending and receiving e-mail. For example,
an organization that works with large graphic or multimedia files may require large
message size limits.
• Are there special users in your Exchange 2007 organization who must send or receive
messages that are larger than the specified allowable message size?
Options for Configuring Size Limits

You can set the following limits on message size:
• Organizational limits. These limits apply to all Hub Transport servers that exist in the
organization and to all messages sent within the organization.
• Connector limits. These limits apply to any messages that are sent through the
specified Send connector, Receive connector, or Foreign connector for message
delivery. Connectors are defined on Hub Transport servers or Edge Transport servers.
• Server limits. These limits apply to a specific Hub Transport server or Edge
Transport server. The specified message limits are not stored in Active Directory®
directory service. You can set the specified message limits independently on each
Hub Transport server or Edge Transport server.
• User limits. These limits apply to a specific user object, such as a mailbox, contact,
distribution group, or public folder.
For a message to be delivered, the message size must not exceed the message size
restriction for all Exchange 2007 components that will handle the message during
message transfer. For example, a message that an internal user sends to a recipient on the
Internet must be smaller than: the organizational limit; the limit set on any Hub Transport
or Edge Transport server that may handle the message; the connector limit set for the
SMTP send connector that delivers the message from the Hub Transport server to the
Edge Transport server, and from the Edge Transport server to the Internet SMTP server;
and the message size limit for the individual user’s mailbox.
Considerations for Designing Message Size Restrictions

Considerations for designing message size restrictions include:
• If you have a few users who must be able to send larger messages than other users,
set the message size limit for the organization and the Hub Transport servers at the
maximum message size. Next, use an Exchange Management Shell cmdlet or script
to configure the maximum size for user mailboxes. For most users, set the message
size restriction at less than the maximum size.
• If you have limited bandwidth to a partner organization or to the Internet, consider
setting the message size limit high inside the organization, but configure a smaller
size for the SMTP send and receive connectors that send and receive messages from
the Internet or the partner organization.
• If you have an office location that has a very slow network connection to other
locations, consider setting the office’s maximum message size limit on the Hub
Transport server to a lower value than you have in the rest of the organization. Be
aware that this may increase user dissatisfaction, because that location’s users will
not receive some messages delivered to users in other offices.
• Ensure that the maximum message size limit for the SMTP connector that receives
inbound Internet e-mail does not exceed the organization’s internal message size
limit. Messages that exceed the size limit should be dropped at the organization’s
initial entry point so that the message delivery does not consume system resources.
Designing Client Access Policies
Exchange Server 2007 provides a wide variety of client access options including Post
Office Protocol version 3 (POP3), Internet Message Access Protocol version 4rev1
(IMAP4), Microsoft Office Outlook® Web Access, Outlook Anywhere, and Exchange
ActiveSync. All of these clients access the Exchange mailboxes through the Client
Access server role. As part of your design, you need to consider which client access
options you will allow and how you will configure them.
Considerations for Enabling Client Access Methods

The first step in designing a client access policy is to determine which client access
options you will enable and which you will block. You should enable each option only if
your organization requires it.
• Outlook Web Access. By default, Outlook Web Access is installed and enabled in an
Exchange 2007 organization that has the Client Access server role installed. Outlook
Web Access provides access to a user mailbox using a Web browser, which means
that you may not need to deploy messaging clients. Most organizations enable
Outlook Web Access because it is easy to deploy and configure.
• Outlook Anywhere. Outlook Anywhere requires that Outlook 2003 or Outlook 2007
is installed on the client computer, and that both the Client Access server and the
client are configured to use remote procedure call (RPC) over HTTP for the
communication between the two computers. Outlook Anywhere provides the
advantage of using the full Outlook client and provides a secure connection to the
Exchange Server.
• Exchange ActiveSync. By default, Exchange ActiveSync is enabled in Exchange

Server 2007. If users require access to their e-mail using a mobile device, then you
will need to configure Exchange ActiveSync.
• POP3 and IMAP4. By default, POP3 and IMAP4 are installed but not enabled when
you install the Client Access server role. You can enable them by starting the POP3
and IMAP4 services. POP3 and IMAP4 enable a variety of clients, including third-
party clients, to connect to the Exchange server. POP3 and IMAP4 access provides
less functionality than Outlook Web Access or Outlook Anywhere. Because of this,
many organizations do not enable clients to access Exchange servers using POP3 or
IMAP4.
Comparing Outlook Web Access and Outlook Anywhere

Outlook Web Access and Outlook Anywhere are the two options most commonly used to
enable external access to Exchange mailboxes. When designing your client access
policies, consider the following:
• Outlook Web Access provides the easiest option for accessing Exchange Server
mailboxes because users only require a Web browser to access e-mail. Outlook Web
Access also provides a full feature set, including access to the calendar and the
scheduling assistant, tasks, contacts, and the user mailbox. The primary limitation
with Outlook Web Access is that it does not provide offline mailbox access. In
Exchange Server 2007, users cannot access public folders through Outlook Web
Access unless a computer running Exchange 2000 Server or Exchange Server 2003
is storing the public folder.
Additionally, Outlook Web Access’s wide accessibility raises security concerns for
some organizations. Users can access their mailbox from a public computer that may
not be secure. For example, the computer may be running a key stroke logger that
may compromise the user’s password. Additionally, if you do not implement forms-
based authentication, the user may remained logged into their mailbox after they have
left the computer. Lastly, when a user downloads an attachment to the computer, the
attachment may be accessible to other users on the computer.
• Outlook Anywhere requires Outlook 2003 or Outlook 2007 on the client computer.
Outlook Anywhere provides all of the functionality that Outlook Web Access
provides, while also enabling offline access and access to public folders. Outlook
Anywhere may also provide a higher level of security than Outlook Web Access
because you can limit access to the user mailbox to a specific laptop computer that
you can manage with policies. The biggest disadvantage of using Outlook Anywhere
is that the user must carry a laptop computer with them.
Both Outlook Web Access and Outlook Anywhere provide complementary features, and
many organizations deploy both options. As part of designing your organization’s client
access strategy, you will need to consider whether to enable access for both types of
clients and determine configuration settings for each.
Setting Policies for Outlook Web Access

Exchange Server 2007 provides several configuration options for managing access for
Outlook Web Access users. These configuration options include:
• Configuring SSL for secure communication. By default, the Outlook Web Access
virtual directory in Exchange Server 2007 is configured to require Secure Sockets
Layer (SSL) for all connections. The default certificate installed on the Client Access
server is a self-signed certificate. You should remove the default certificate and
install a certificate from a trusted certification authority (CA) to ensure that users can
access the site without being prompted to accept the security certificate. When you
request the certificate from the CA, ensure that you use a fully qualified domain
name (FQDN) for the certificate that matches the FQDN that users will connect to
when accessing Outlook Web Access.
• Configuring authentication. The Client Access server supports several types of
authentication for Outlook Web Access. The most secure option is forms-based
authentication, which uses a cookie-based authentication system. This cookie is
configured to timeout after a specified period of client inactivity, so that the user
credentials do not remain valid on the client computer. The user can log out of
Outlook Web Access at any point, which removes the cookie from the computer
memory.
• Configuring access to attachments. With Exchange Server 2007, you also can
configure the types of attachments that users can download with Outlook Web
Access. You can block access to attachments based on file extension or Multipurpose
Internet Mail Extensions (MIME) type. If you allow users to download and view
attachments, be aware that the attachments will be stored on the local computer.
As an alternative to allowing users to download attachments, you can configure
WebReady Document Viewing. When you require WebReady Document Viewing,
the feature converts attachments with supported file extensions or MIME types to
HTML and displays them to the user, who can read them, but not download or edit
them. If your organization requires a high level of security for message attachments,
consider implementing WebReady Document Viewing.
Designing Policy Exceptions
Valid exceptions will exist for almost every policy. Most organizations allow exceptions
for personnel for whom a policy limits their ability to do their job. For example, if a user
needs to send and store large attachments as part of their job, the organization likely will
approve an exception to this user’s message size and mailbox size policies.
Creating a Process for Exception Approval

The most important part of planning for policy exceptions is to create a process for
approving or rejecting those exceptions before the request occurs. If a user asks for an
exception to a policy and you do not have an approval process, it will be very difficult to
say no. If you do have an approval process, you can just refer the user to the process.
To begin this process, decide for which policies you will allow exceptions and those for
which you will not. For example, you may decide that you will allow exceptions to
mailbox size and message size policies, but not to Outlook Web Access attachment
policies.
The next step is to design the approval process for getting policy exceptions approved.
In most cases, the person approving the exception should not be the same person who
implements the change. You should base most policy exceptions on some business
rationale, which means that the person who approves the change should understand the
business process clearly that the policy exception will affect.
Once you determine who the approver will be, you need to develop a process for users
to follow to get their requests approved. If the organization has an intranet site that most
users utilize, you may choose to create a Web page from which users can make their
requests. If you use a Web page, you can automate the sending of the request to the
exception approver. To ensure prompt resolution of all exception requests, make certain
that users are aware of how to request a policy exception.
As the final step in enabling policy exceptions, design a process for implementing the
policy after approval. Ensure that only properly authorized personnel can make the
changes. Normally, the Exchange administrators will implement the change, but ensure
that they are aware of the process for exception approval and how to confirm that an
exception was approved.
Lesson 2: Designing Mobile Device Policies
Many organizations provide their employees with the option to access their Exchange
mailboxes with mobile devices. However, this can raise security concerns because mobile
devices may contain a large amount of confidential information, and also can be lost or
stolen easily. Therefore, it is essential to define some security policies for managing
mobile devices.
Objectives
• Describe the options for managing mobile devices.
• Design security policies for mobile devices.
• Design policies for device management.
Options for Managing Mobile Devices
One of the most common ways for users to access their Exchange mailboxes is with
mobile devices, such as a cell phone or personal digital assistants (PDAs). However,
these mobile devices can present a serious security risk. Exchange Server 2007 provides
several options for managing these devices.
Requirements for Mobile Device Policies

Mobile clients, such as Exchange ActiveSync clients, have unique security requirements.
Mobile clients are susceptible to being lost or stolen, because the devices are small and
portable. At the same time, these devices may contain highly confidential information
because company executives often carry them. The storage cards that fit into mobile-
device expansion slots can store increasingly large amounts of data. While this data-
storage capacity is important to the mobile device user, it also heightens the concern
that unauthorized users may be able to access the data.
Using Exchange ActiveSync Policies to Manage Mobile Devices

Exchange Server 2007 provides Exchange ActiveSync policies as one option for securing
mobile devices. You can set security restrictions on the device by configuring the policy
and applying it to a user mailbox. These security restrictions include configuring
requirements for password length and complexity, and configuring whether users can
download attachments to their devices.
When you apply the policy to a mailbox, the Exchange ActiveSync policy downloads
automatically to the mobile device the next time it connects to the Client Access server.
Managing Mobile Devices

You also can manage mobile devices with the Exchange Management Console or the
Exchange Management Shell. In most cases, you will use these tools when a user reports
that their device has been lost or stolen. These tools enable you to:
• View a list of all mobile devices for each user.
• Send a remote wipe command to the mobile device, which will remove all data on
the mobile device and set the device back to the factory default settings.
• Delete an old or unused partnership between devices and users.
You also can manage other settings to ensure that the connections are secure from the
mobile device to the Client Access server. At a minimum, you should configure a server
certificate from a trusted CA on the Client Access server and configure Microsoft Server
ActiveSync to require SSL for all connections. Additionally, you can configure the
virtual directory to require client certificates for authentication. When you enable this
option, only clients with approved certificates will be able to connect to the Client Access
server using Exchange ActiveSync.
You can manage which types of devices can connect to the Client Access server. To
support features such as Exchange ActiveSync mailbox policies, the mobile client must
be running Microsoft® Windows® Mobile 5.0 with the Messaging and Security Feature
Pack, or a later version of Windows Mobile. If you want to ensure that the policies are
applied to all mobile clients, you can prevent connections from all devices that do not
meet this minimum requirement.
You also can manage Exchange ActiveSync access for individual user accounts. By
default, all users are enabled for Exchange ActiveSync, but you can disable this setting
on each user mailbox.
Designing Exchange ActiveSync Policies
One of the most important ways to implement mobile device security in Exchange
Server 2007 is to use Exchange ActiveSync policies. You can configure password
policies for mobile devices by configuring Exchange ActiveSync policies.
Exchange ActiveSync Policy Options

When you configure Exchange ActiveSync policies, you can configure settings such as:
• Password complexity requirements, password length, password expiration, and the
time-out value before the user must re-enter the password.
• Whether to allow users to download attachments to their mobile devices.
• Whether to require data encryption on mobile devices.
• The number of times users can enter the wrong password before their device is
locked or wiped.
• Whether to store the device’s recovery password on an Exchange server. If you select
this option, the password can be viewed from either Outlook Web Access or the
Exchange Management Console.
Considerations for Configuring Exchange ActiveSync Policies

Balance usability with security when configuring Exchange ActiveSync policies. For
example, you can configure a policy that requires a very high security level by requiring
long, complex passwords that users need to change frequently. Also, you can configure a
very low lockout value for incorrect passwords. However, as you increase the security
level required by a policy, users are more likely to experience usability issues. With
highly secure password policies, the device lockout incidences will increase, Exchange
administrators are likely to spend more time recovering or resetting passwords, and user
dissatisfaction will increase. If you configure a lower level of security, user satisfaction
will increase but so do the chances of a serious security breach. As part of the design
process, you will need to negotiate a security level that is acceptable to the organization.
Consider configuring different policies for different users. For example, if you have one
group of users that carry highly confidential information on their mobile devices, or if
they have access to highly confidential e-mail, you can configure a policy with higher
security settings for this group. You can create as many policies as required and use an
Exchange Management Shell command to assign the policy to multiple users
simultaneously.
You also should consider enabling remote file access through Exchange ActiveSync,
rather than allowing users to download attachments. If a user is running a compatible
mobile device, the user will be able to view a file from an internal file share rather than
downloading the file to their mobile device.
In addition to setting Exchange ActiveSync policies, you also may need to define other
policies regarding the data that users can store on a device. For example, you can block
users from receiving e-mail attachments on the mobile devices, but the user can transfer
data to the device through a cradle or a USB connection. As part of managing mobile
devices, you will need to define corporate policies that define the data that users can store
on the devices.
Designing Policies for Device Management
Exchange Server 2007 also provides the option to wipe a mobile device remotely if it
appears to be a security issue. For example, if a device is lost or stolen, you may choose
to wipe the device to ensure that unauthorized users cannot access corporate data via the
device. Both the Exchange administrator and the device user can initiate the remote wipe.
Considerations for Implementing Remote Wipe Policies

When you choose to wipe a mobile device remotely, it returns the device to its factory
default condition the next time that the device synchronizes to the Exchange server.
Performing a remote wipe of a lost or stolen device can protect the device’s data and
ensure that the device cannot be used to access the user’s mailbox.
Note: The remote wipe does not delete the data that is stored on a memory card in
the computer. To protect this data, you should require encryption for all data that is
stored on the mobile device.
However, remotely wiping a device that has been temporarily lost can cause user
dissatisfaction. This means that you need to design policies for when an administrator
will wipe a mobile device or for when users can wipe their own devices.
When defining policies for performing a remote wipe, you must:

• Define a policy for when Exchange administrators will wipe a device remotely.
This policy should identify who can perform the remote wipe and under what
circumstances. For example, you may develop a policy that allows Help Desk
personnel to wipe a mobile device remotely, but only with the approval of a Help
Desk manager or an Exchange administrator. You also should develop a reporting
procedure for users who have lost or stolen devices, so they know how to report the
missing device.
• Develop policies and procedures for rebuilding wiped devices or rebuilding
new devices. It is very easy to wipe a mobile device, but more difficult to rebuild
the device and restore any lost data. To make this process efficient, you should
make procedures available so that users can back up and restore their data and
configuration information. You also should provide training to Help Desk personnel
to support users during this process.
• Develop policies for allowing users to wipe their own devices. Exchange Server 2007
also allows users to wipe their own devices, or to remove the partnership between a
device and the Exchange mailbox. This option is available on the Outlook Web
Access Options page. Allowing users to wipe their own devices can decrease the
administrator time that is required to manage mobile devices, because users can
remove associations with devices they no longer use. If your organization
implements a policy that prevents users from managing their own devices, you can
prevent users from wiping their own devices by removing this option in the Outlook
Web Access segmentation settings.
Lesson 3: Designing Messaging Policies for

Compliance
One of the most important components in planning an Exchange Server 2007

organization’s messaging policies is the compliance policies that you will create. These
policies are required to ensure that your organization complies with legislation and
policies that either governments or internal organizational requirements enforce.
Objectives
• Describe how Exchange Server 2007 can address corporate requirements for
messaging policies and compliance.
• Design policies for messaging records management.
• Design policies for message journaling.
• Manage the Journal mailbox.
• Design message archiving policies.
• Design a user communication plan for messaging policies.
Overview of Messaging Policies and Compliance Requirements
Governments all over the world have passed legislation to regulate and protect the
disclosure of personal information, financial information, and organizational security.
For example, the United States has passed several laws, such as the Sarbanes-Oxley Act
of 2002 (SOX) and the Gramm-Leach-Bliley Act (Financial Modernization Act), which
focus on securing and protecting the privacy of financial and personal information.
The Europe Commission has implemented several directives that define protection
requirements for personal data. Most other countries have passed similar laws to secure
personal information and electronic documents that organizations collect and use.
Effect of Regulatory Requirements

Regulatory requirements have a direct affect on how organizations deploy and configure
their messaging environment, and require that organizations review their message
security and retention requirements.
Most organizations communicate and share information primarily by e-mail both
within the organization and with users external to the organization. Ensuring regulatory
compliance has proven to be a challenge for many organizations. It typically is difficult
to implement policies to control the information that can be sent by e-mail, implement
retention policies, and enforce security requirements for sending e-mail outside the
organization.
Complying with Regulatory Requirements

To comply with legislative requirements, organizations have to develop messaging
standards and policies. These standards and policies determine how the organization
addresses customer privacy, financial information, and the security of corporate
intellectual property. Specific legal requirements depend mainly on the organization’s
business type and the country in which the organization is located. However, common
polices deal with the types of information that users can send by e-mail, how long users
need to retain certain types of e-mail, and specific security regulations for sending e-mail
outside of the organization.
Corporate Policies
In addition to complying with government legislation, many organizations maintain
internal corporate policies to protect information within the company. For example, an
investment organization may not allow e-mail communication between two specific
organizational departments. Organizations also may define requirements for policies such
as e-mail deletion or disclaimer text.
Exchange Server 2007 provides several tools and features, such as Messaging Records
Management, Transport Rules, and Journaling Policies that organizations can use to
address many of the legal and corporate requirements for managing information security.
Designing Policies for Messaging Records Management
Messaging records management policies deal primarily with other message retention
issues. By implementing messaging records management policies, you can ensure that
certain messages are deleted in user mailboxes and that certain messages are retained for
an extended period.
Note: Messaging records management requires an Exchange Enterprise Client

Access License (CAL) for each mailbox on which it is enabled.
Messaging Records Management Options

You can use messaging records management settings to:
• Configure retention policies, which enable you to define how long content will
remain in users’ mailboxes. These policies are configurable by content age and by
message type (for example, voice mail or appointments), and can be applied to any of
the default folders or custom folders in user mailboxes.
• Use messaging records management policies to delete messages in user mailboxes.
For example, if you apply these policies to a special, managed default folder named
Entire Mailbox folder, the policy is applied to all messages in the user mailbox,
except those in managed custom folders.
• Configure journaling settings so that copies of all messages in the specified folder are
sent to another recipient. The recipient must exist in the global address list (GAL),
but can be at any location with an SMTP e-mail address, including another Exchange
Server mailbox or Windows SharePoint Services document library. Data sent to such
a repository is stamped with a label to preserve its classification information.
Considerations for Configuring Managed E-Mail Folders and Content

Settings
When configuring managed e-mail folders and content settings, consider the following:
• Use content settings to manage mailbox size limits. For example, you can configure a
policy that deletes messages in the Deleted Items folder or the Sent Items folder after
a specified time.
• Use meaningful names and descriptions when creating managed e-mail folders. Users
should be able to determine quickly what a particular folder is for and the retention
period assigned to it.
• Plan managed content settings carefully. You can apply only one content setting to a
specific folder, so you cannot apply different content settings for different groups. If
you create a content setting for a specific user group, the same settings are applied to
all policies that include that folder.
Note: You can apply multiple content settings to a managed folder, but only if the
content settings apply to different message types. For example, you can configure
a content setting that applies to messages and another that applies to calendar
items on the same folder.
Considerations for Configuring Policies

When configuring managed folder policies, consider the following:
• When designing the policies, begin by identifying the organization’s user groups who
have unique messaging records management requirements, and then create a policy
that will apply to them. A single policy can include many different managed folders,
and the same managed folders can be applied to different policies. Each policy that
you create can be a unique combination of the available managed folder settings.
• Consider configuring a default policy that applies to all users. If you want to use
messaging records management policies to limit mailbox size, configure a default
policy that is applied to all user accounts. Create additional policies for those users
that require different permissions. Only one policy can be applied to a user account.
• Consider running the managed folder assistant during non-business hours. Running
the process in a large organization can consume significant server resources.
• Develop a process for implementing custom managed folders. To implement custom
managed folders, the Exchange administrators must create the folder and assign the
policy to the appropriate user accounts. Normally, Exchange administrators create
these folders based on a business requirement for message retention. Ensure that you
have a process in place that business managers can use to request and gain approval
for these folders.
Note: When you implement managed custom folders, users must move messages
into the managed e-mail folders for the content settings to apply. This means that
you must provide user training to educate users about why they need to move
messages into these folders. You also may need to provide training on how to
configure Outlook rules to move messages automatically into the correct folders.
Designing Policies for Message Journaling
Exchange Server 2007 provides two types of messaging journaling: premium and
standard. With premium message journaling, you can save a copy of every message sent
by, or to, specific users. With standard journaling, you can save a copy of every message
sent to, or from, a specific mailbox store. Premium journaling is available only if you
have purchased Exchange Enterprise Client Access Licenses (CALs). Standard journaling
is available with Standard CALs.
Considerations for Developing Journaling Rules

As part of designing the Exchange Server 2007 organization, you need to develop
policies regarding:
• Recommendations for the types of messages that should be journaled. In most cases,
regulatory or corporate requirements determine the messages to journal. For example,
a regulatory requirement may be that you retain all messages that contain any
customer transactional information for a specified period.
To implement journaling, you must ensure that all messages with this type of
information are sent to a particular recipient and then configure a rule that will
journal all messages sent to the recipient. If only a specific group of users sends
these messages, you can create a distribution list that includes those users, and then
configure the rule to journal all messages sent by the distribution list’s members.
Corporate requirements also may specify which messages must be journaled. For
example, the company may require that all messages sent to or from the legal
department are journaled. You can configure a distribution group for the legal
department and configure a rule to journal all messages sent to and from the
distribution group.
• Recommendations for where the messages will be journaled. In Exchange

Server 2007, the journal mailbox can be any SMTP address. This means that you
can configure another mailbox as the journal mailbox. You also can specify a
public folder or configure a custom recipient with the SMTP address for a
Windows SharePoint Services document library or a third-party archive solution.
When designing the journal mailbox location, consider that the mailbox may increase
in size very rapidly if you are journaling messages for multiple recipients. If this is
the case, you may choose to dedicate a mailbox database or even an entire mailbox
server for storing journal mailboxes.
• When designing the journal mailbox location, consider how users will access the
journaled messages. If the messages are being journaled only for regulatory or
forensic reasons, you can use a mailbox or SharePoint document library that is
accessible only to those users who require access. If many users need daily access to
the journaled messages, consider using a SharePoint document library as the journal
location. Users can access the document library easily, and it provides indexing for
rapid searching.
You can configure a single journal location for all messages that are journaled or
configure multiple journal locations with each rule user. As a best practice, consider
using separate journal mailboxes for each journaling rule.
• Recommendations for journaling in multiple site organizations. If your organization
has multiple locations, you need to include this factor in your planning. Within an
Exchange Server 2007 organization, Hub Transport servers apply journal rules.
Because Active Directory stores the journal rule configuration, the same journal rules
are applied on all Hub Transport servers in the organization and all journal reports
are sent to the same mailbox. In this scenario, you should place the journal mailboxes
in a central location that has the necessary server, and backup and restore, capacities
to handle a large number of additional messages. When designing the network
connections between company locations, consider the impact that message journaling
will have on network utilization.
Note: If you do not want journal rules to be applied to a specific Hub Transport
server, you can disable that server’s journaling agent.
Managing the Journal Mailbox
In a large organization or if you configure journaling for a large number of users, the
journal mailbox can grow very rapidly. Additionally, the journal mailbox may contain
highly confidential information that should not be accessible to most users. This means
that you will need to develop policies for managing the journal mailbox.
Considerations for Managing the Journal Mailbox Size

When you configure a journaling mailbox to accept journal reports, you must determine
the maximum size of the journaling mailbox. As with any other mailbox, the maximum
size depends on the data that the mailbox will store, the hardware resources that are
available, and the disaster recovery capabilities for the server that contains the journaling
mailbox. In addition to these considerations, you also must consider what will occur if a
journaling mailbox exceeds the configured mailbox quota.
When you configure the Prohibit send and receive at (KB) storage quota on a
journaling mailbox, the journaling mailbox accepts journal reports until it reaches the
configured storage quota. When the mailbox exceeds the prohibit send and receive
storage quota, it stops accepting journaling reports. When this happens, non-delivery
reports (NDRs) are not sent to users or administrators, but rather are queued on Hub
Transport servers. To reduce the possibility that your journaling mailbox will reject
journal reports because it has reached the configured storage quota, you should configure
your journaling mailbox’s prohibit send and receive storage quota to the maximum size
allowable for your hardware resources and disaster-recovery capabilities. If you are
backing up the mailbox on a daily basis, consider using a messaging records management
rule to remove backed up messages routinely.
Tip: If you set limits on the journal mailbox, you also can set an alternative
journaling mailbox. When you do this and the journal mailbox reaches the
maximum size, the NDRs for failed messages are sent to the alternative
journal mailbox. To configure the alternative journal mailbox, use the
Set-TransportConfig –JournalingReportNdrTo alternateSMTPAddress cmdlet.
Considerations for Managing Journal Mailbox Security

Security is another important consideration when managing the journal mailbox.
Journaling mailboxes may contain very sensitive information. You must secure
journaling mailboxes because they collect messages that are sent to and from recipients in
your organization, and because these messages may be part of legal proceedings or may
be subject to regulatory requirements. You should create policies that govern who can
access you organization’s journaling mailboxes and limit access to only those individuals
who have a direct need for access. Ensure that legal representatives approve your plan to
make sure that your journaling solution complies with all the laws and regulations that
apply to your organization.
Designing Message Archiving Policies
Message archiving is when you save a copy of a message in a location outside the
Exchange messaging system. Archiving may be part of your organization’s security
requirement for business or forensic purposes. Your organization also may require it to
maintain a history of messages while not enlarging user mailboxes.
Exchange Server 2007 does not provide a message archiving solution, but provides
several features that you can use to implement message archiving.
Considerations for Implementing Message Archiving

When you are planning to implement archiving, the first step is to implement a data-
storage solution that can store the e-mail messages that will be removed from the
messaging system. In a large organization, or if you choose to archive all messages sent
in the organization, you may require several terabytes of storage. Because message
archival usually is implemented to retain rather than rapidly access messages, your
primary consideration for choosing a storage location is cost rather than easy access.
The second step for implementing archiving is to determine how you will move messages
to the archive. Exchange Server 2007 provides several options for sending copies of
messages to an alternate location:
• Implement archiving as part of the journal rule implementation. For example, when
you configure a journal rule, you can send the journal reports to an SMTP address
that represents the archive location.
• Implement archiving by implementing journaling at the mailbox database level.
When you do this, a copy of every message sent to or from the mailbox database is
sent to the archive location.
• Implement archiving by using transport rules that will send copies of messages to an
archive location. You can configure transport rules to send messages to the location
based on criteria such as sender or recipient, message classification, or message
contents.
The third step for implementing archiving is to enable access to the message archive after
the message is removed from the user mailbox. If you are using a Windows SharePoint
Services document library as the archive location, users can access the archive through a
Web browser. When planning for access to the messages, ensure that appropriate security
is applied to all messages to prevent unauthorized access.
The final step in implementing an archive solution is to remove messages from the user
mailboxes. One of the primary purposes for implementing an archive solution is to reduce
the storage space requirements on Exchange mailbox servers. Therefore, you must ensure
that messages are deleted in the databases over time. You can use messaging records
management rules to implement this part of the solution.
Note: As a best practice, you should consider implementing a third-party archive

solution. Many of these solutions provide data storage, as well as additional
options for sending messages to the archive, providing archive access, and
deleting messages in user mailboxes.
Discussion: Designing a User Communication Plan for

Messaging Policies
Your organization’s users will be affected when you implement messaging policies.
Implementing some messaging policies, such as messaging records management or
mobile devices polices, will have an immediate impact on users as they see new folders
appear in their inboxes or as they are required to use a password to access their mobile
devices. Other policies, such as those implementing message journaling, may be more
transparent to users. However, users should be aware of the policies that you are applying.
To ensure compliance and provide users with the rationale for messaging policies, you
need to develop a communication plan that communicates messaging environment
changes to users.
Q How do you communicate changes to the IT environment to users?
A Answers will vary. Some organizations have very formal processes for informing and
training users, while other organizations have informal processes. Depending on the
type of policy you are implementing, you should design a user communication plan
that will identify and inform the appropriate users.
Q What information would you include in a communication plan?

A Answers will vary, but should include:
• The communication plan should identify which changes are based on legal or
compliance requirements. These requirements usually are non-negotiable and
must be enforced in the entire organization, and users need to be made aware of
the requirements.
• The communication plan should identify the business rationale for policies that
you are implementing to enhance business processes. In most cases, users will
better adjust to the change if they understand the need for it.
• As part of the communication plan, you should include steps that users must take
to ensure compliance. You may need to include some user training to ensure that
all users understand what the organization expects of them.
• You also can provide suggestions for how users can automate the process of
compliance. For example, you could provide information on how to use Inbox
rules to move messages to the custom managed folders in a messaging records
management solution.
Q How will you ensure that users follow messaging policies? For example, messaging
records management policies that use managed custom folders require that all users
move messages into the correct folders.
A If you are implementing the policies for regulatory or legal reasons, it is essential that
all users comply with the policies. As part of the communication plan, include
information on how you are monitoring compliance and indicate the results of non-
compliance.
Lab: Designing Messaging Policies
After completing this lab, you will be able to design messaging policies.
Lab Setup
lab, you must:
• Log on to the virtual machine as TreyResearch\Administrator with a password
of Pa$$w0rd.
Lab Scenario
Now that you know the target state for the Trey Research Exchange Server 2007
organization, you need to complete the design by developing messaging policies. This
happens late in the design process to ensure that the policies you design match the
Exchange Server 2007 organizational design.
Exercise 1: Designing Messaging Policies

In this exercise, you will design a messaging policy solution for Trey Research.
Scenario
To prepare for this exercise, review the Trey Research requirements for implementing the
Exchange 2007 organization
1. Review the Trey Research • Review the following document located in the D:\LabResources
documentation. folder:
• Policy_Requirements.doc
2. Modify the TR_Policies.doc • Open the TR_Policies.doc file from the

file with proposed mailbox D:\Mod05\Labfiles\LabInputs folder.
and message policies. • Fill in the Mobile Client Policies table. In the table, provide:
• The type of policy you are configuring
• Policy settings
• Additional comments
TR_Proposed_Policies.doc.
3. Modify the TR_Policies.doc • In the TR_Proposed_Policies.doc file, fill in the Mailbox and
file with proposed mobile Message Policies table. In the table, provide:
client policies. • The type of policy you are configuring
• Policy settings
TR_ProposedPolicies.doc.
4. Modify the TR_Policies.doc • In the TR_Proposed_Policies.doc file, fill in the Compliance

file with proposed compliance Policies table. In the table, provide:
policies. • The type of policy you are configuring
• Policy settings
TR_Proposed_Policies.doc.

class.
Q How did you design the messaging policies for the Trey Research organization?
A Use the TR_Proposed_Policies in the D:\Mod05\Labfiles\LabAnswers folder to
discuss the answers.
Q What compliance policies might your organization require?

A Answer will vary. Most organizations must deal with compliance issues related to
privacy and the use of customer or employee information. In some organizations,
these issues may be easy to resolve. In other organizations, especially organizations
that work in the medical, legal, or financial fields, the requirements will be very
complex.
Q Will the Exchange Server 2007 features address all of the requirements?
A Answers will vary. For organizations with simple requirements, Exchange Server
2007 is likely to provide all required functionality. Organizations with very complex
requirements likely will need to add third-party products to the environment.
Q How will you address policy requirements that Exchange Server 2007 features do not
meet?
A Answers will vary. Students should explore third-party products, especially when
addressing archiving and providing options that are more complex for message
journaling or applying transport rules. Additionally, a technical solution might not
address some requirements and organizations will need to explore the use of written
corporate policies to enforce these requirements.
Lab Shutdown
After you complete the lab, you must shut down the 5053A-LON-CL1 virtual machine
and discard any changes.
Important: If the Close dialog box appears, ensure that Turn off and delete
changes is selected, and then click OK.
Module 6: Designing Coexistence and
Interoperability Strategies with Other
Messaging Systems
Table of Contents
Overview 6-1
Lesson 1: Overview of Coexistence and
Interoperability with Other Messaging Systems 6-2
Lesson 2: Designing a Coexistence Strategy with
Previous Exchange Versions 6-7
Lesson 3: Designing an Interoperability Strategy
with Other Messaging Systems 6-22
Lab: Designing Coexistence and Interoperability
Strategies with Other Messaging Systems 6-33
Version 1.2
Module 6: Designing Coexistence and Interoperability Strategies with Other Messaging Systems 6-1
Overview
Almost all companies are using a messaging system currently. Some companies use
a previous Microsoft® Exchange Server version, some use non-Exchange systems,
and some use hosted messaging services that third parties provide. When you deploy
Exchange Server 2007 in an organization that hosts its own messaging systems, you will
be replacing the current messaging system with Exchange Server 2007.
In all but the smallest organizations, you most likely will implement Exchange
Server 2007 over a period of time. Therefore, while you are implementing Exchange
Server 2007, you must plan a strategy for coexisting with the organization’s current
messaging system.
Objectives
• Describe the Exchange coexistence and interoperability scenarios and terminology.
• Design a coexistence strategy with previous Exchange Server versions.
• Design an interoperability strategy with other messaging systems.
6-2 Module 6: Designing Coexistence and Interoperability Strategies with Other Messaging Systems
Lesson 1: Overview of Coexistence and

Interoperability with Other Messaging Systems
When you decide to implement an Exchange Server 2007 messaging system in your
organization, you may need to maintain both your previous messaging system and
Exchange Server 2007 for some time. While you are upgrading the system, users still
need to send e-mail and schedule meetings. The Exchange Server 2007 implementation
should disrupt normal business processes minimally, if at all.
Objectives
• Describe the coexistence and interoperability scenarios.
• Describe a coexistence and interoperability strategy.
Scenarios for Coexistence and Interoperability with Other

Messaging Systems
When designing a coexistence and interoperability strategy, you must first understand the
available options. Your choices depend on your current environment and the timeline that
your migration requires.
Coexistence and Interoperability Options

Exchange Server 2007 supports two options for integrating messaging systems—
coexistence and interoperability.
• In a coexistence scenario, you install Exchange Server 2007 into an Exchange
organization that contains computers running Exchange 2000 Server or Exchange
Server 2003. In this scenario, all Exchange servers are members of the same forest,
and all servers share the same Exchange organization configuration information and a
global address list (GAL).
This is the easiest and least disruptive scenario for integrating Exchange-based
messaging systems, because the different Exchange versions share configuration and
recipient information automatically. However, this option is available only if your
organization is running Exchange 2000 Server or Exchange Server 2003 currently.
• In an interoperability scenario, you create a new Exchange Server 2007 organization

in parallel to your current messaging system, and then implement processes for
sending messages and sharing information between the two messaging systems. You
must use this option if your organization is running a non-Exchange messaging
system or running Exchange Server 5.5. You also can choose this option if your
organization is running Exchange 2000 Server or Exchange Server 2003, but you
want to install Exchange Server 2007 in a new, different organization. New
organizations typically are deployed when the existing organization is designed
poorly or you need to make significant changes due to corporate restructuring.
Configuring interoperability is significantly more complicated than configuring
coexistence. By default, the two messaging systems share no information. Therefore,
you must configure all of the connections between the systems.
Note: If you have Exchange Server 5.5 servers installed in your Exchange
organization currently, you have the option of upgrading to Exchange 2000 Server
or Exchange Server 2003 and then installing Exchange Server 2007 into the
organization. Alternatively, you can create a new Exchange Server 2007
organization and configure interoperability between the organizations.
Discussion: Components of a Coexistence and Interoperability

Strategy
When you deploy two messaging systems in your organization, you must ensure that you
disrupt users as little as possible. All users should be able to exchange messages with
users on both messaging systems and all users should have access to the same directory
information.
Q What functionality or information do messaging systems need to share when both are
in use?
A In most coexistence or interoperability scenarios, you must configure integration for
at least the following information:
• E-mail message flow. While you are running two messaging systems, users must
be able to send e-mail to other organizational users, and to and from users on the
Internet. Message flow should be transparent to users—they should not need to
know, nor should it matter, on which messaging system the recipient’s mailbox is
located.
• Global Address List (GAL).To simplify the process of sending messages
between messaging systems, you must ensure that the GAL is synchronized
between the messaging systems.
• Calendar information. To facilitate scheduling of meetings between the two

messaging systems, you must ensure that Free/Busy information is replicated
between the two organizations.
• Public folder contents. If the organization stores important information in public
folders, you may need to replicate the public folder contents between the
messaging systems.
Q What factors determine the relative importance of implementing shared functionality

or sharing each type of information?
A When evaluating the extent to which you need to integrate the two messaging
systems, you must:
• Balance ease of implementation with importance. In some cases, you may not
have any choice about implementing a certain integration feature because of its
importance. For example, in most scenarios, configuring message flow and
sharing GAL information between the systems is critical, so you must provide
this functionality even if it is difficult to implement. In other cases, you may have
more of a choice. If an integration feature is easy to implement, you are more
likely to implement it even though it may not be critical. For example, sharing
public folder or calendar information in a coexistence scenario is easy to
implement, so you are more likely to implement these functions than you would
be in an interoperability scenario, where this becomes quite complicated.
• You also should consider how long the two messaging system will need to be
integrated. In some companies, you will be able to complete a migration to
Exchange Server 2007 rather quickly, so you may not need to develop a complete
coexistence strategy. However, in large companies, it can take months, or even
years, to migrate from one messaging system to another. In these scenarios, you
need to ensure as much functionality as possible during the coexistence phase.
Lesson 2: Designing a Coexistence Strategy with

Previous Exchange Versions
You can use a coexistence strategy only when you install Exchange Server 2007 servers
into an existing Exchange 2000 Server or Exchange Server 2003 organization. The most
complicated part of designing a coexistence strategy is creating a message routing
topology between the messaging systems. As part of the coexistence strategy, you also
will need to design a system for integrating calendar information, offline address-book
information, and public folder information between the messaging systems.
Objectives
• Design message flow in a coexistence scenario.
• Design calendar availability between Exchange Server versions.
• Design a solution for offline address book access.
• Design a solution for providing public folder access.
• Design an Exchange Server administration plan in a coexistence scenario.
• Design a coexistence implementation plan.
Designing Message Flow
One of the core components in a coexistence strategy is designing message routing

between Exchange Server 2007 and the existing Exchange organization.
Documenting the current message routing configuration

The first step in designing message routing between the Exchange systems is to
document the message routing configuration in the previous Exchange version:
• Exchange 2000 Server and Exchange Server 2003 use routing groups to manage
message routing between company locations. To prepare for an Exchange
Server 2007 implementation, you must document the routing groups, the locations of
Exchange servers, and the routing group connectors and To Connector configuration.
As part of this documentation, you should describe how messages are routed between
the routing groups, including redundant paths, and how messages are routed to the
Internet.
• You also should document the Simple Mail Transfer Protocol (SMTP) namespace for
all domains for which the Exchange organization is authoritative.
• Because Exchange Server 2007 message routing is based on Active Directory®
directory services sites, you also must document the Active Directory site
configuration and compare it to the routing group configuration.
Integration of message routing between Exchange versions

To support coexistence between Exchange versions, all servers running Exchange
Server 2007 are added automatically to a single routing group when you install
Exchange Server 2007. The Exchange Server 2007 routing group is recognized in
Exchange System Manager in Exchange Server 2003 or Exchange 2000 Server as
Exchange Routing Group (DWBGZMFD01QNBJR) within Exchange Administrative
Group (FYDIBOHF23SPDLT). The Exchange Server 2007 routing group includes all
Exchange 2007 servers, regardless of the Active Directory site in which they reside.
Important: You should never modify the default configuration for the Exchange
Server 2007 routing group. It is not supported to move servers from this routing
group to another routing group, rename the Exchange Server 2007 routing group,
or manually add Exchange 2003/2000 Servers to the Exchange Server 2007
routing group.
When you install the first Exchange Server 2007 Hub Transport server in an existing
Exchange organization, you must specify an Exchange 2000 Server or Exchange
Server 2003 bridgehead server that will operate as the first routing group connector’s
bridgehead server. The routing group connector links the routing group where the
Exchange 2000 Server or Exchange Server 2003 resides with the Exchange Server 2007
routing group.
The Hub Transport server that you are installing, and the Exchange 2000 or
Exchange 2003 bridgehead that you select, are configured as the source and target servers
on two reciprocal routing group connectors. The selected bridgehead server is added
automatically to the membership of the ExchangeLegacyInterop universal security group,
and is granted the permissions that are required to send e-mail to, and receive e-mail from,
Exchange Server 2007. This routing group connector creates a single connection point
between Exchange Server 2003 and Exchange Server 2007.
Optimizing message routing between the messaging systems

When you install the first Hub Transport server in the existing Exchange organization,
message routing is enabled between the two messaging systems. However, all messages
will flow through the single routing group connector that you configured during
installation. When designing the message routing topology, you should consider:
• Adding additional Hub Transport servers and Exchange 2000 or 2003 servers as
bridgehead servers to the default routing group connector. This provides redundancy
if one of the servers is unavailable and load balancing.
• If your organization has multiple locations and multiple routing groups, you should
create additional routing group connectors to optimize message routing. If you use
only the default routing group connector that is created during the Hub Transport
server installation, it routes all messages from Exchange Server 2007 recipients to
Exchange 2000 or 2003 recipients through the Active Directory site where the Hub
Transport bridgehead server is located. The messages then go across the routing
group connector and through the Exchange 2000 or 2003 routing group connectors to
recipients on Exchange 2000 or 2003 servers.
To optimize message routing, consider creating a new routing group connector in
each routing group as you deploy a Hub Transport server in the corresponding Active
Directory sites. In this way, you can send messages between the messaging systems
without routing them to another company location. You must use Exchange
Management Shell to manage routing group connectors.
• If you implement multiple routing group connectors between the two Exchange
versions, you also must suppress link state updates on Exchange 2000 Server or
Exchange Server 2003. Servers running Exchange Server 2003 and Exchange 2000
Server maintain a link state routing table that determines how a message is routed
inside the organization. If a particular routing group is inaccessible by using the
lowest cost route, the routing group master updates the link state table to show the
link’s state as down.
Exchange Server 2007 Hub Transport servers do not use link state routing, and
Exchange Server 2007 cannot propagate link state updates. When no Hub Transport
server in a site is available, the Hub Transport server does not recalculate the route.
If multiple paths exist between the Exchange Server 2007 routing group and any
Exchange Server 2003 routing group, minor link state updates must be suppressed to
make sure that message looping does not occur when a route is recalculated.
We recommend that you suppress minor link state updates for each server running
Exchange Server 2003 or Exchange 2000 Server. This enables the servers that are
running Exchange Server 2003 or Exchange 2000 Server to queue at the failure point
rather than recalculating the route.
Note: For more information on configuring minor link state updates, see the “How
to Suppress Link State Updates” page of the Microsoft TechNet Web site.
Designing Calendar Integration
Exchange Server 2007 uses the Availability service to provide availability information
for Microsoft Office Outlook 2007 and Outlook Web Access users. Previous Exchange
Server versions used system folders to provide this functionality. You must ensure that
your design addresses this difference when planning the coexistence between your two
messaging systems.
How the Availability Service works

In Exchange Server 2007, the Availability service collects availability information from
Exchange Server 2007 Mailbox servers and the system folders that previous Exchange
Server versions use, as follows:
1. When you select users you want to invite to a meeting in the Scheduling Assistant in
Office Outlook 2007 or Exchange Server 2007 Outlook Web Access, the client sends
a request to the URL provided to the client during AutoDiscover. The URL identifies
a Client Access server that is running the Availability service. The request includes
all users who are invited to a meeting, including resource mailboxes.
2. The Availability service on the Client Access server queries Active Directory to
determine the location of the user mailboxes. For any mailboxes in the same site as
the Client Access server, the request is sent directly to the user’s Mailbox server to
retrieve the user’s current Free/Busy information.
3. If the mailbox is not in the same site as the Client Access server that receives the
client request, the Client Access server that receives the request proxies it to a Client
Access server in the site that contains the user’s mailbox. The Client Access server in
the destination site extracts the availability information from the Mailbox server and
replies to the requesting Client Access server.
4. If the mailbox for one of the invited users is on a computer running Exchange 2000
Server or Exchange Server 2003, the Availability service queries the system folder
that contains the user’s Free/Busy information.
5. The Availability service combines the Free/Busy information for all invited users and
presents it to the Office Outlook 2007 or Outlook Web Access client.
In a coexistence scenario, the availability information for users with mailboxes on

Exchange Server 2007 Mailbox servers is stored in the system folders that Outlook 2003
and older Outlook clients use. This means that these clients can access Free/Busy
information for all users from the public folders.
Optimizing the Availability Service Integration

Calendar sharing is enabled by default in a coexistence scenario. However, to optimize
calendar access in this scenario, you should consider the following:
• You must deploy Client Access servers in each Active Directory site in which you
deploy Exchange Server 2007 Mailbox servers even if there are no Outlook 2007
clients deployed in the site. The Client Access server is required to provide
availability information for users who use Outlook Web Access on servers running
• If your organization has multiple locations, you should ensure availability in
each Active Directory site of at least one replica of the system folders containing
Free/Busy information for Outlook 2003 or older clients. If you remove
Exchange 2000 or Exchange 2003 mailbox servers from an Active Directory site,
but do not configure an Exchange Server 2007 Mailbox server in the site with a
system folder replica, then the Client Access server must connect to another site,
across a WAN link, to obtain Free/Busy information for users with mailboxes on
Exchange 2000 or 2003 servers.
Designing Offline Address List Access
Another difference between Exchange 2000 Server, Exchange Server 2003 and Exchange
Server 2007 is how the offline address book is distributed to Outlook 2007 clients. In
Exchange 2000 Server and Exchange Server 2003, a system folder stores the offline
address book and clients must connect to the folder to download it. Outlook 2007 clients
connecting to an Exchange Server 2007 Client Access server will use a Web service to
download the offline address book.
How Offline Address Book Coexistence Works

To plan coexistence between the offline address book downloads for different Exchange
versions, you must understand how Exchange Server 2007 offline address book Web
publishing works:
1. One Mailbox server in the Exchange organization is responsible for offline address
book updates. The Microsoft Exchange File Distribution service copies the offline
address book data from the Mailbox server to the offline address book distribution
point. The File Distribution service runs on a Client Access server and copies offline
address book data and Unified Messaging configuration data to Client Access servers.
2. On each Client Access server, an offline address book virtual directory is configured.
This virtual directory points to the directory, C:\Program Files\Microsoft\Exchange
Server\ExchangeOAB on the Client Access server. This folder contains the offline
address books that are copied from the Mailbox servers.
3. Office Outlook 2007 will locate the closest Client Access server with an offline
address book copy during Autodiscover. The offline address book is distributed to
Office Outlook 2007 by using HTTPS and the Background Intelligent Transfer
Service (BITS) protocol. BITS enables resumable downloads and the ability to
download the offline address book without Office Outlook running.
Offline address book Web publishing integrates seamlessly with the offline address book
in previous Exchange Server versions. Outlook 2007 downloads the offline address book
from the Web service and all other clients download the offline address book from the
system folder.
In an Exchange 2000 Server or Exchange Server 2003 organization, one of the Exchange
servers performs daily updates of the offline address book. When you deploy an
Exchange Server 2007 Mailbox server in your organization, you can use the Exchange
Server 2007 management tools to move this role to a server running Exchange
Server 2007.
Optimizing Offline Address Book Distribution

To optimize offline address book availability in a coexistence scenario, consider the
following guidelines:
• Consider deploying Client Access servers in each site if the site has Outlook 2007
clients, even if you are not planning to deploy a Mailbox server for some time. By
deploying the Client Access server in the site, the Outlook 2007 clients can use the
local Client Access server to download the offline address book, rather than
connecting to a Client Access server in a remote site.
• Ensure that the system folder containing the offline address book is replicated
to Exchange Server 2007 Mailbox servers in those sites where users are running
Outlook 2003 or older Outlook versions. If you have a site that does not contain any
servers running Exchange 2000 Server or Exchange Server 2003 with a public folder
store, ensure that you configure one of the servers running Exchange Server 2007
with a public folder database and that the required system folders are replicated to
the server. If you do not replicate the system folders to the site, clients will need to
connect to a public folder replica in another site to download the offline address book.
Designing Public Folder Availability
Another issue that may arise in a coexistence scenario is public folder access. You must
consider how users access public folders and provide access between Active Directory
sites when designing the public folder access solution.
Designing Public Folder Availability

In Exchange Server 2007, public folders are accessible only to users with an Outlook
client using MAPI. Previous Exchange Server versions provided access to public folders
to Outlook Web Access, Internet Message Access Protocol version 4rev1 (IMAP4),
and Network News Transfer Protocol (NNTP) clients. If users are accessing public
folders currently using these clients, maintain a replica of the public folders on a server
running Exchange Server 2003. When users connect to the /Public virtual directory on a
Exchange Server 2007 Client Access server, and a public folder replica exists on a server
running Exchange 2000 Server or Exchange Server 2003, the public folder data will be
retrieved from the public folder replica.
For IMAP4 and NNTP clients, provide access to the public folder through an
Exchange 2000 or 2003 front-end server, or by allowing the clients to connect directly to
the Exchange 2000 or Exchange 2003 back-end server that hosts the public folder.
In most cases, users utilize Outlook Web Access, IMAP4, or NNTP clients to access
public folders from outside the organization. You also may consider other options to
enable users to access this content in an Exchange Server 2007 environment. You should
consider:
• Providing users with an Outlook client that is configured to use Outlook Anywhere,
as the MAPI requests and data are tunneled through a HTTPS connection so the
client connection from the Internet remains secure while still enabling access to
public folders.
• Migrating the public folder data to another system, such as Windows SharePoint
Services. If you move the public folder data to Windows SharePoint Services, you
can make the Windows SharePoint Services server accessible to the Internet, and
users can access the data using any Web browser. You can also enable users to access
the information on a Windows SharePoint Services site by using Outlook Web
Access if you enable WebReady Document viewing or direct file access to the
Windows SharePoint Services site.
Designing public folder replication and referrals

Another consideration when designing a coexistence strategy for public folders is
providing access to public folder replicas between Active Directory sites. When you
install a server running Exchange Server 2000 or Exchange 2003 Server, the default
configuration includes a public folder store. When you install an Exchange Server 2007
Mailbox server, no public folder database is configured on the server by default.
If users require access to public folders in an Active Directory site that does not contain
any servers running Exchange Server 2000 or Exchange 2003 Server, configure at least
one Mailbox server in the site with a public folder database. When you configure this
database, the server will participate in public folder hierarchy replication so that all users
can view the Active Directory site’s public folder hierarchy. If you do not configure this
database, the client must connect to a server with a different site’s public folder database
to view the public folder hierarchy.
After adding the public folder database to the Exchange 2007 server, you can replicate
any public folder between servers running Exchange Server 2000 and Exchange 2003
Server, and the Exchange Server 2007 Mailbox server.
An Exchange Server 2007 environment by default enables public folder referrals between
Active Directory sites. It also enables public folder referrals across the routing group
connector that is created by default when you install the organization’s first Hub
Transport server. You can enable or disable public folder referrals across the connectors
as you create additional routing group connectors.
Designing Exchange Server Administration
To design the Exchange Server 2007 administrative strategy in a coexistence scenario,

you must first understand the differences between how Exchange Server 2007 and
previous Exchange Server versions assign administrative permissions.
Comparing administrator delegation

Exchange 2000 Server and Exchange Server 2003 provide predefined security roles
for delegating Exchange administrative permissions. These roles are a collection of
standardized permissions that can be applied at either the organizational or administrative
group level. In Exchange 2000 Server and Exchange Server 2003, there is no clear
separation between administration of users and groups by the Windows Active Directory
administrators and Exchange recipient administrators.
Exchange Server 2007 provides a separation of administrator permissions between
Active Directory and Exchange, and provides new administrator roles that are similar to
the built-in Windows Server security groups. By default, Exchange Server 2007 grants
permissions to Exchange administrators to the Active Directory attributes that they need
to administer Exchange organization or server properties and to the Exchange-specific
recipient properties
By default, Active Directory groups are assigned to each of the Exchange Administrator
roles when you run Exchange Server 2007 setup with the /PrepareAD switch. To
configure Exchange Server 2007 administrative permissions, you can add users to the
pre-defined Active Directory groups or you can assign new Active Directory groups to
the Administrator roles.
Replicating Exchange Administrative Designs

Due to the differences in how administrative permissions are designed in Exchange
Server 2007 compared to previous Exchange versions, you cannot directly replicate the
Exchange 2000 or Exchange 2003 administrative design in Exchange Server 2007. One
of the main differences that you will need to plan for is that Exchange Server 2007 does
not use administrative groups for delegating permissions.
The following table describes some options for creating an Exchange Server 2007
administrative design that emulates an Exchange 2000 Server or Exchange Server 2003
design:
Exchange 2000 or Exchange 2003
Exchange Server 2007 equivalent
administrative option
Assign Exchange Full Administrator role at Add users or groups to the Exchange Organization
the organization level Administrator role.
Assign Exchange Administrator role at the Exchange Server 2007 does not have a role
organization level equivalent to the Exchange Administrator role.
Add users or groups to the Exchange Organization
Administrator role.
Assign Exchange View Administrator role Add users or groups to the Exchange View-Only
at the organization level Administrator role.
Assign Exchange Full Administrator role at Add users or groups to the Exchange Server
the administrative group level Administrator role for each Exchange 2007 server in
the area that the administrative group defines.
Assign Exchange View Administrator role Exchange Server 2007 does not have an equivalent
at the administrative group level option. The Exchange View-Only Administrator role
has view-only permission throughout the entire
organization.
Assign recipient administrators with Add users and groups to the Exchange Recipient
Exchange View Administrator role and Administrator role.
Active Directory permissions If the users or groups need permission to create
user and group accounts, assign the appropriate
permissions in Active Directory.
Using Administrative Tools in a Coexistence Scenario

In addition to designing permissions delegation in Exchange Server 2007, you also
must consider the administrative tools that are used to administer the different Exchange
Server versions. You must use Exchange Server 2007 administration tools to manage all
Exchange Server 2007 settings. After installing an Exchange Server 2007 server, you
should configure any global settings using Exchange Server 2007 tools.
You can continue to manage Exchange 2000 and 2003 objects and recipients using
the Exchange System Manager and Active Directory Users and Computers. However,
mailboxes that are located on Exchange 2000 and Exchange 2003 servers also are
displayed in the Exchange Server 2007 Exchange Management Console, with which you
also can manage mailbox properties.
For more information: For detailed information on which settings you can
configure using either the Exchange 2000 or Exchange 2003 Exchange System
Manager or the Exchange Server 2007 administration tools, see the “Microsoft
Exchange Server TechCenter” page of the Microsoft TechNet Web site.
Designing the Implementation Plan for Coexistence
In a transition upgrade, you will install Exchange Server 2007 servers into an existing
Exchange 2000 Server or Exchange Server 2003 organization, and then gradually move
all data and functionality from the current messaging system to Exchange Server 2007.
Implementation steps
When installing Exchange Server 2007 into an existing Exchange 2000 Server or
Exchange Server 2003 organization, complete the following steps:
1. Document the configuration for the existing messaging environment before you
start the transition process. The easiest way to capture most information about your
Exchange organization, Active Directory, and other settings and configuration
information is to scan the organization using the Microsoft Exchange Server Best
Practices Analyzer Tool (ExBPA). ExBPA versions 2.7 and later include an
Exchange Server 2007 Readiness Check scan that you can use to assess your
organization’s Exchange Server 2007 readiness.
2. Prepare the Active Directory forest for the installation of servers running
Exchange Server 2007. To do this, run Exchange Server 2007 setup with the
/PrepareLegacyExchangePermissions switch. This step is required so that the
Exchange 2003 or Exchange 2000 Recipient Update Service functions correctly after
you update the Active Directory schema for Exchange Server 2007. Additionally,
run setup with the /PrepareAD switch. This applies the Exchange Server 2007
modifications to the Active Directory schema and creates the administrative groups
that Exchange Server 2007 uses.
3. Deploy the Client Access server role. You must deploy the Client Access server
role in each Active Directory site that contains or will contain a Mailbox server.
When you deploy the Client Access server role, all non-MAPI clients, including
clients accessing mailboxes on servers running Exchange 2000 Server or Exchange
Server 2003, can use the Client Access server.
4. Because the Exchange Server 2007 routing topology is very different from those in
Exchange Server 2003 and Exchange 2000 Server, you should transition all of a
routing group’s servers to Exchange Server 2007 simultaneously in the following
order:
a. Deploy and configure Hub Transport servers. You must install and configure a
Hub Transport server before you can establish mail flow. A Hub Transport server
can coexist with servers running Exchange 2000 Server or Exchange 2003 Server
that are designated as their routing group’s bridgehead servers. However, the
Exchange Server 2007 Hub Transport server cannot operate as a bridgehead
server for routing group connectors between Exchange 2000 Server or
Exchange Server 2003 routing groups, so you must retain the previous
bridgehead servers as long as there are mailboxes or public folders
Exchange 2000 or Exchange 2003 servers in the routing group.
b. Deploy and configure Mailbox servers. When you deploy Mailbox servers, you
can move mailboxes from Exchange Server 2003 and Exchange 2000 Server to
Exchange Server 2007. To move mailboxes to Exchange Server 2007, you can
use either the Move-Mailbox cmdlet or the Move Mailbox Wizard. Also, you
must move public folders and system folders to the Exchange Server 2007
Mailbox servers.
5. Deploy and configure Unified Messaging servers. You can install and configure a
Unified Messaging server after you deploy and configure a Client Access server, Hub
Transport server, and Mailbox server.
You can deploy and configure Edge Transport servers at any point during the
upgrade. You deploy the Edge Transport server outside the Exchange organization in
a perimeter network. You can install the Edge Transport server to provide spam and
virus filtering for an existing Exchange organization without upgrading any
Exchange servers. However, functionality such as edge synchronization requires
Exchange Server 2007 Hub Transport servers.
Lesson 3: Designing an Interoperability Strategy with

Other Messaging Systems
You may need to devise a strategy for integrating Exchange Server 2007 with other
Exchange Server messaging systems, or for deploying Exchange Server 2007 in a new
Exchange organization while retaining the current Exchange organization. In these
scenarios, you must configure the message routing between the existing system and
Exchange Server 2007. You can do this by using Simple Mail Transfer Protocol (SMTP)
connectors. To synchronize the Global Address List (GAL) between the two messaging
systems, you can use tools such Lightweight Directory Access Protocol (LDAP) and
Microsoft Identity Integration Server (MIIS). Exchange Server 2007 also supports a
connector that you can use for interoperability with Lotus Notes.
Objectives
• Design message flow strategy with unique SMTP namespaces.
• Design message flow strategy with the same SMTP namespace.
• Design for global address list coexistence between messaging systems.
• Design a strategy for calendar coexistence between organizations.
• Design a coexistence strategy by using connectors.
Designing Message Flow Strategy with Unique SMTP

Namespaces
In an interoperability scenario, the two messaging systems share no information by

default, and no message routing is configured automatically. In most cases, the first step
you take to enable interoperability is to configure message routing between the two
messaging systems.
The easiest way to enable message routing in an interoperability scenario is to use SMTP
to send messages between the organizations. Almost all messaging systems support
SMTP, so all you have to do is configure message routing between the two systems.
Configuring Message Routing with Unique SMTP Namespaces

In the simplest interoperability scenario, each messaging system will have a unique
SMTP address space. In this situation, all you need to do to configure message routing
is configure SMTP send and receive connectors to send messages between the
organizations. To do this:
1. Configure a SMTP send connector on an Exchange Server 2007 Hub Transport
server. Configure the SMTP send connector with the address space of the other
messaging system and configure the connector to use one of the SMTP servers in the
other messaging system as a smart host. You also should configure the SMTP send
connector to use authentication and configure the destination SMTP server to require
authentication.
2. Configure an SMTP receive connector on the Hub Transport server that will receive
messages from the other messaging system. This connector should be configured to
require authentication.
3. On the non-Exchange Server 2007 messaging system, configure the SMTP servers to
send all messages with the Exchange Server 2007 organization’s SMTP address
space to the Hub Transport server with the appropriate receive connector. Configure
the SMTP server to use authentication.
Note: You must add the account that you will use to authenticate the connection to
the Hub Transport server to the ExchangeLegacyInterop security group in the
Exchange Server 2007 organization.
Depending on the network topology, you can deploy a single SMTP connector or
multiple ones. In a small company or a company with a single location, a single
connector will provide the required functionality and is easier to manage. In a company
with multiple locations, configure multiple connectors so that messages can be sent from
one messaging system to another without having to cross a WAN connection.
For more information: For detailed information on how to configure the

SMTP connectors between an Exchange Server 2007 organization and an
Exchange 2000 or Exchange 2003 organization, see the “Configuring Cross-Forest
Connectors” page on the Exchange TechCenter Web site.
Designing Message Flow Strategy with the Same SMTP

Namespace
The message routing scenario can be more complicated if both messaging systems share
a common SMTP namespace. This is a common scenario because an organization likely
will use the same namespace in Exchange Server 2007 as in the previous messaging
system.
Configuring Message Routing with the Same SMTP Namespace

To enable message routing in a common SMTP namespace scenario:
1. Configure message routing between the two messaging systems.
2. Configure the shared SMTP domain name as an internal relay accepted domain in
the Exchange Server 2007 organization. When you configure an SMTP domain as an
internal relay accepted domain, the Exchange Server 2007 Edge Transport servers or
Hub Transport servers will accept messages intended for that domain. If an internal
mailbox matches the recipient address, the message will be delivered to the mailbox.
If no internal mailbox matches the recipient address, the message will be forwarded
across a Send connector to the other messaging system.
3. Configure all inbound and outbound Internet messages to flow through the Exchange
Server 2007 messaging system. To do this, configure an Edge Transport server using
an edge subscription. On the legacy messaging system, configure the SMTP server
that is responsible for outbound routing to use a Hub Transport server as its smart
host, and configure the server to use authentication when connecting to the Hub
Transport server. If the connection is authenticated, the Hub Transport server
will accept messages from the internal relay domain and deliver the messages to
Exchange Server 2007 mailbox users, or relay messages for Internet recipients to the
Edge Transport server for delivery.
Designing Global Address List Synchronization
One of the most significant complications in an interoperability scenario is that there is

no easy way to synchronize the GAL between the two messaging systems. At the same
time, it is important that you synchronize the GAL to make it easy for users to send
e-mail to users in the other messaging system.
Implementing GAL synchronization

To enable address lookups when users need to send e-mail between the two systems, you
must create custom recipients or mail-enabled contacts in each messaging system for the
other messaging system’s recipients. When you do this, the custom recipient or contact
appears in the GAL and messages sent to the recipient are routed automatically to the
other messaging system.
In a small organization, you can update the recipients manually in the two organizations.
If you are migrating a group of users from one system to another, you can delete the
users accounts in the non-Exchange Server 2007 messaging system and delete the mail-
enabled contact in Exchange Server 2007. You then create new accounts in Exchange
Server 2007 and create a custom recipient in the non-Exchange Server 2007 messaging
system that uses the SMTP address of the Exchange Server 2007 organization user.
In a large organization where you may be moving hundreds of mailboxes at a time,

manually maintaining the GAL requires significant administrative effort and increases the
chance of errors. Large organization will need to use tools to automate the GAL
synchronization process, such as:
• LDAP replication scripts. If both messaging systems are LDAP compliant, you
can create custom scripts to manage the required users. For example, if you create a
spreadsheet that lists all of the users that are migrating in one group, you can use the
LDAP script to delete the appropriate objects in each messaging system and create
the new objects for all migrated users.
• Microsoft Identity Integration Server 2003—Identity Integration Feature Pack. The
Identity Integration Feature Pack provides automated directory synchronization
between Active Directory, Active Directory Application Mode (ADAM), Microsoft
Exchange 2000 Server, and Exchange Server 2003. You can use the IIFP only if you
are designing interoperability with an Exchange 2000 or Exchange 2003 organization.
IIFP automates creating and deleting each directory’s objects as you migrate
mailboxes. Implementing and configuring IIFP requires specialized knowledge.
• Microsoft Identity Integration Server 2003. The full MIIS version provides directory
synchronization for a much broader range of recipient repositories. For example, you
can use MIIS to enable directory synchronization with a messaging system using
Lotus Domino or Novell GroupWise. Like the IIFP, MIIS automates the directory
synchronization, but requires additional technical expertise.
Designing Calendar Interoperability
The third critical component in an interoperability strategy is sharing calendar

information between message systems. If you do not provide this feature, users will need
to use alternate means to schedule meetings with recipients whose mailboxes are on other
messaging systems.
Options for sharing calendar information

Exchange Server 2007 provides two options for sharing calendar information with other
messaging systems:
• If both organizations are running Exchange Server 2007 and using Office
Outlook 2007, you can use the Availability Service in Exchange Server 2007 to share
Free/Busy and calendaring information between organizations. This option is useful
when designing calendar sharing in a complex organization with multiple forests and
Exchange organizations, but usually is not applicable to an upgrade scenario.
• If the non-Exchange Server 2007 messaging system is running Exchange 2000 Server
or Exchange Server 2003, you can install a computer running Exchange Server 2003
in the Exchange Server 2007 organization and then use the Microsoft Exchange
Server Inter-Organization Replication (IORepl) tool to replicate the Free/Busy
system folders between the two organizations. However, IORepl has not been tested
against, and is therefore not supported with, Exchange Server 2007.
Note: You can use the IORepl tool to replicate contacts and public folder
information between disjointed Exchange organizations. You cannot install a server
running Exchange Server 2003 into an existing Exchange 2007 organization. If
you plan to use the IORepl tool to replicate Free/Busy information, you must
install Exchange Server 2003 and then upgrade the organization to Exchange
Server 2007.
Alternatives to sharing calendar information

Because of the complexity of sharing calendar information between an Exchange
Server 2007 organization and other messaging systems, you may want to consider other
options for providing this functionality, including:
• Configuring some users with mailboxes on both messaging systems. Arrange for
these users to schedule meetings that include users on both messaging systems.
• Using a calendar in Windows SharePoint Services to schedule meetings that include
users in both messaging systems. When you configure a calendar in Windows
SharePoint Services, you can configure alerts that will notify users when meetings
have been scheduled in the calendar. This does not provide access to Free/Busy
information for users, so this may be most useful for regularly scheduled meetings.
Designing an Interoperability Strategy by Using Connectors
Connectors can simplify the process of enabling interoperability between messaging

systems because messaging connectors provide the tools to configure message transfer,
GAL synchronization, and Free/Busy information synchronization between messaging
systems.
Benefits of using connectors

Connectors provide three important types of functionality:
• Configure message routing between the messaging systems. During interoperability,
users must be able to route and receive e-mail messages from other corporate users
and with Internet recipients. The connector creates the message routes required
between the messaging systems.
• Synchronize directory information to maintain consistent and current address
book information. When you first configure a connector, it will create the required
recipients in both messaging systems and configure them with the appropriate
addresses. As you move user accounts from one system to the other, the connectors
upgrade recipients in both messaging systems automatically.
• Synchronize calendar information to provide all users with current Free/Busy
information. Many companies use a messaging system’s calendaring component as
the primary way to schedule meetings, so this functionality must be available during
coexistence. The connector enables synchronization of Free/Busy information
between the two messaging systems.
Microsoft Transporter Suite for Lotus Domino

The only connector that is compatible with Exchange Server 2007 is the Microsoft
Transporter Suite for Lotus Domino. This connector provides directory synchronization
and Free/Busy lookups between Lotus Domino 6 or 7 and Exchange Server 2007 and
Windows Server 2003 Active Directory. SMTP is used as the mail routing transport
between Lotus Domino 6 or 7 and Exchange Server 2007.
Microsoft provides the Exchange Server 2003 Connector for Lotus Notes, the Exchange
Server 2003 Calendar Connector, and the Exchange Server 2003 Connector for Novell
Groupwise with Exchange Server 2003. If you are migrating from Novell Groupwise
to Exchange Server 2007, you may want to consider implementing an Exchange
Server 2003 server to host the Connector for Novell Groupwise.
Lab: Designing Coexistence and Interoperability

Strategies with Other Messaging Systems

• Design a coexistence strategy with Exchange 2000.
• Design an interoperability strategy.
Lab Setup
lab, you must:
• Log on to the virtual machine as LON-CL1\Administrator with a password of
Pa$$w0rd.
server and has the Exchange Server 2007 Edge Transport Server role installed.
The 5053A-LON-CL1 computer is a member of the Treyresearch.net domain.
Lab Scenario
You are a messaging engineer for Trey Research, an enterprise-level organization
with multiple locations. Trey Research is an international corporation involved in
technology research and investment, and is planning to upgrade from Exchange 2000
Server to Exchange Server 2007. Trey Research currently has three remote sites and their
two new office locations during the upgrade.
Corporate 10,000 after the new • 500 – Outlook Anywhere and mobile client users
Headquarters London office is ready • 800 – Outlook users connecting through a VPN
London (new office) 4,000 (anticipated) • 200 – Outlook Web Access users
San Diego 500 • 50 – External POP3 client users
Former head office
of A. Datum
Corporation
• 200 –Outlook users connecting through a VPN
Trey Research will implement a phased Exchange Server 2007 deployment over several
months, which means that the Exchange Server 2007 servers must coexist with the
Exchange 2000 Servers during the deployment. The first Exchange Server 2007 servers
will be deployed in London, followed one month later by a server deployment in Toronto.
As soon as you deploy the Exchange Server 2007 servers, you should move all possible
functionality to them. Additionally, you should optimize message routing between the
two messaging systems.
The Exchange Server 2007 deployment in Tokyo will start about two months after the
Exchange Server 2007 server deployment in London and Toronto.
Users in London and Tokyo use public folders extensively. Approximately 100 public
folders are configured with replicas on Exchange 2000 servers in both offices. Other Trey
Research offices very rarely access the public folders’ information.
The company office in San Diego is the former head office of A. Datum Corporation,
which Trey Research purchased six months ago. The San Diego office is running a
POP3/SMTP based messaging system. Currently, all messages between the A. Datum
office and the rest of Trey Research are sent through the Internet. The companies send
confidential e-mails back and forth, so you must change this traffic routing as soon as
you deploy the Exchange 2007 servers in Toronto so that all messages are sent across
the WAN connection between the company locations rather than through the Internet.
Additionally, you should not allow any inbound or outbound SMTP e-mail directly from
the San Diego office to and from the Internet. You should route all Internet SMTP traffic
to and from A. Datum through Toronto. The A. Datum location will be one of the last
offices to migrate to Exchange Server 2007. However, the migration must not disrupt
e-mail flow between the A. Datum location and the rest of Trey Research.
All of the users at A. Datum have an e-mail address of alias@Adatum.com. Users
need to maintain the A. Datum addresses while also getting new addresses of
alias@TreyResearch.net. You must implement this address change early in the migration,
before you deploy any Exchange Server 2007 servers in San Diego. Additionally, some
of the A. Datum employees are going to move to London or Toronto and must maintain
both e-mail addresses.
Another project is deploying Outlook 2007 clients to users in all company locations. You
must optimize any coexistence strategies for the new Outlook version. The project to
deploy Outlook 2007 to all desktops is expected to take about 18 months.
Within the next 12 months, the organization plans to migrate all existing users to
Exercise 1: Designing a Coexistence Strategy with

Exchange 2000 Server
In this exercise, you will design a coexistence strategy between an Exchange Server 2007
messaging system and an Exchange 2000 Server messaging system.
Review the following files located in the D:\LabResources folder:
• TR_RoutingGroups.vsd
1. Review the Trey Research • Review the lab scenario.

documentation. • Review the following files located in the D:\LabResources
folder:
• TR_RoutingGroups.vsd
2. Modify the TR_ • Open the TR_CoexistenceStrategy.vsd file from the

CoexistenceStrategy.vsd D:\Mod06\Labfiles\LabInputs folder.
file with a proposed • In the Visio file, describe the coexistence strategy for London
administrative plan. and Toronto. Your design should answer the following
questions:
• What Exchange Server 2007 server roles will you deploy
in each location? In what order will you deploy them?
• How will message routing in the organization change as
you deploy the Exchange Server 2007 servers? How will
you address the requirement to optimize message
routing?
• How will you address the requirement to optimize the
environment for Outlook 2007 clients?
• How will you configure public folder replication between
London and Toronto?
TR_CoexistenceStrategy.vsd.

class.
Q If you implemented this design, what messaging services, if any, would it disrupt? At
what point would the disruption occur?
A This design should result in no disruptions in messaging services.
Q How would the user experience change during this period of coexistence? How
would you communicate changes to users?
A The only change users should experience is when they are upgraded from
Outlook 2003 to Outlook 2007, or when they access their user mailboxes through
Outlook Web Access and the mailbox has moved to an Exchange 2007 server.
Depending on the organization, you may consider providing some user training on
the Outlook version, or providing some documentation that highlights the differences
between the two Outlook versions.
Exercise 2: Designing an Interoperability Strategy

In this exercise, you will design an interoperability strategy between Exchange
Server 2007 and a legacy messaging system.
1. Review the Trey • Review the lab scenario.

Research documentation. • Review the following files located in the D:\LabResources folder:
2. Modify the TR_ • Open the TR_InteropStrategy.vsd file from the

InteropStrategy.vsd file D:\Mod06\Labfiles\LabInputs folder.
with a proposed • In the Visio file, describe the interoperation strategy for the Trey
administrative plan. Research Exchange Server 2007 organization and the legacy
messaging system in San Diego. Your design should answer the
• Changes to the message routing configuration—how will
connectors need to be configured to enable message routing?
• Changes to the e-mail address configuration.
TR_InteropStrategy.vsd.

class.
Q What functionality will not be available between the two messaging systems? What
options would you suggest for dealing with this?
A The scenario does not provide any option for automating the GAL synchronization
between the messaging systems. This will be a significant task because of the large
number of Trey Research users that you must add to the legacy messaging system’s
GAL. You may consider only adding users from the Trey Research to whom users in
A. Datum are likely to send e-mail.
Additionally, there is no option currently for updating Free/Busy information

between the messaging systems. Users in A. Datum currently do not have this
functionality, so you may not need to provide this option during the interoperability
period.
the changes.
Lab Shutdown
Module 7: Designing an Exchange
Server 2007 Upgrade Strategy
Table of Contents
Overview 7-1
Lesson 1: Overview of Available Upgrade Strategies 7-2
Lesson 2: Designing a Transition from Previous
Versions of Exchange 7-7
Lesson 3: Designing a Migration from Other
Messaging Systems 7-22
Lab: Designing an Upgrade Strategy 7-31
Version 1.2
Module 7: Designing an Exchange Server 2007 Upgrade Strategy 7-1
Overview
In most upgrade scenarios, you must plan for a period of coexistence between
Microsoft® Exchange Server 2007 and an existing messaging system. However, the
goal at most upgrade projects’ end is to move all services and data from the previous
messaging system to Exchange Server 2007, and to remove the existing messaging
system. This module details on how to complete an existing messaging system’s upgrade
to Exchange Server 2007.
Objectives
• Describe the Exchange upgrade terminology and strategies.
• Design a transition strategy for upgrading from previous Exchange Server versions.
• Design a migration strategy for upgrading from other messaging systems.
7-2 Module 7: Designing an Exchange Server 2007 Upgrade Strategy
Lesson 1: Overview of Available Upgrade Strategies
When planning an upgrade strategy, you will have many decisions to make regarding
moving services and data from the current messaging system to Exchange Server 2007.
The available options for performing these actions vary depending on your current
messaging environment and your project’s goals.
Objectives
• Define the upgrade terminology.
• Describe the upgrade strategies.
Upgrade Terminology
Before starting your Exchange upgrade design, you must understand the terminology
associated with the various upgrades.
The following terminology describes the various upgrade scenarios:
• Upgrade. An upgrade is an implementation of a newer Microsoft Exchange version
that replaces a current messaging system. You perform an upgrade anytime you
implement Exchange Server 2007 and move content from a previous messaging
system.
• Transition. In this scenario, you upgrade an existing Microsoft Exchange
organization to Exchange Server 2007. To perform the transition, install Exchange
Server 2007 servers into an existing Microsoft Exchange 2000 Server or Microsoft
Exchange Server 2003 organization, and move data and functionality from the
existing Exchange servers to new Exchange Server 2007 servers. Microsoft supports
a transition upgrade only from Exchange 2000 Server and Exchange Server 2003 to
• Migration. In this scenario, you upgrade from a non-Exchange messaging system to

Exchange Server 2007, or from an existing Microsoft Exchange organization to a
new Exchange organization, without retaining any of the existing organization’s
Exchange configuration data. In a migration, you install a new Exchange Server 2007
organization, and migrate the current messaging system’s data and services to
Exchange Server 2007. Microsoft supports a migration upgrade from previous
Exchange Server versions to Exchange Server 2007, and from non-Exchange
messaging systems to Exchange Server 2007.
Note: To upgrade an Exchange Server 5.5 organization to Exchange Server 2007,

you must perform a migration. Alternatively, you can upgrade the Exchange Server
5.5 organization completely to Exchange 2000 Server or Exchange Server 2003,
and then perform a transition upgrade to Exchange Server 2007.
• In-Place Upgrade. In an in-place upgrade, you upgrade a single computer that is

running a previous Exchange Server version to a newer version of Exchange Server.
Exchange Server 2007 does not support in-place upgrades.
Upgrade Strategies
When planning an Exchange Server 2007 upgrade, you can choose between several
options for the upgrade process. Choosing the best option for your organization depends
on your current environment, your organization’s requirements for migrating data to the
new system, and your project timeline.
Choosing a Single Phase or Multiphase Upgrade

Your first choice when planning the upgrade is to decide whether to use a single phase or
multiphase upgrade:
• Single phase upgrade. In a single phase upgrade, you replace your existing messaging
system with Exchange Server 2007, and move all required data and services to the
new system without configuring any integration between the two systems.
You typically perform this type of upgrade on a weekend, during which you shut
down the entire messaging system and replace the current system with Exchange
Server 2007 by Monday morning, when users return to work. In this scenario, there is
no period of coexistence or interoperability.
While this upgrade is the fastest option, it also introduces significant risk if the
upgrade fails. This scenario is feasible only for small organizations that must replace
just a few servers and for whom there are a limited number of users to migrate.
• Multiphase upgrade with coexistence. In a multiphase upgrade, you upgrade one
server or site at a time to Exchange Server 2007. Because you spread this incremental
upgrade over a longer period, you decrease your organization’s risk. However, this
scenario also means that you must plan for coexistence or interoperability. This is the
best approach for medium to large organizations because of their complexity.
Planning the Upgrade Scope

When planning your upgrade, you must determine what information and functionality
you want to move from the existing system to Exchange Server 2007.
In almost every case, you will move all functionality that your current messaging system
provides to Exchange Server 2007. For example, you will move the message routing
functionality, spam and virus filtering, and client access functionality.
You also may want to migrate ancillary information to Exchange Server 2007, which
may include migrating the following: user accounts and all recipient details that the
global address list (GAL) contains; the contents of the user mailboxes; free/busy
information; and public folders.
In other cases, you may want to migrate only the messages that the user mailboxes store.
For example, if you are migrating from a Post Office Protocol version 3 (POP3)
messaging system, there is very little information that the messaging system stores other
than the contents of the user mailboxes. In this scenario, you may not need to migrate any
mailbox contents, because users will have all of their messages stored locally in a POP3
client data file.
Lesson 2: Designing a Transition from Previous

Versions of Exchange
You can use a transition upgrade strategy only when you install servers running
Exchange Server 2007 into an existing Exchange 2000 Server or Exchange Server 2003
organization. In a transition upgrade, you gradually replace all of the services that the
current Exchange servers provide with the same or similar functionality offered by
Exchange 2007 servers.
Objectives
• Prepare an existing organization for Exchange Server 2007.
• Design a plan to maintain features that Exchange Server 2007 does not support.
• Prepare Active Directory for Exchange Server 2007.
• Design a Client Access server role deployment in a transition.
• Design a Hub Transport server role deployment in a transition.
• Design a Mailbox server role deployment in a transition.
• Design an Edge Transport server role deployment in a transition.
Confirming the Exchange Organization Readiness for Exchange

Server 2007
You must assess and document your existing environment before you start upgrading
your organization to Exchange Server 2007. You should document existing settings and
configuration information for your Exchange organization, the Active Directory®
directory service, and your network.
Using the Exchange Server 2007 Readiness Check

The easiest way to capture most information about your Exchange organization, Active
Directory, and other settings and configuration data, is to scan the organization using the
Microsoft Exchange Server Best Practices Analyzer Tool (ExBPA). ExBPA version 2.7
and later includes an Exchange Server 2007 Readiness Check that you can use to scan
and assess your organization’s readiness for Exchange Server 2007.
Note: You can download the latest version of the EXBPA from the “Microsoft
Exchange Best Practices Analyzer v2.7” page of the Microsoft Download Center
Web site. By default, the EXBPA also always checks for updates to the EXBPA
whenever you start the tool.
The checks that ExBPA scan performs are similar to the prerequisite checks that the
Exchange Server 2007 Setup program implements. However, ExBPA scan examines
Active Directory and the existing Exchange organization rather than just the local
computer. The scan also performs a deep analysis of each existing Exchange 2000 Server
and Exchange Server 2003 server to verify that they have the necessary updates and
configuration in place to support Exchange Server 2007.
ExBPA report lists the following issues:

• Critical. A configuration problem that prevents you from deploying Exchange
Server 2007. An example of this is an Exchange 2003 server that is not running
Service Pack 2.
• Warning. A configuration item that may prevent customers from having the best
possible experience with Exchange Server 2007. A warning also may reflect some
functionality that is not available in Exchange Server 2007. For example, if you have
deployed a two-node active/active cluster in Exchange Server 2003, you will get a
warning in the ExBPA report.
ExBPA provides other information about the Exchange organization including:

• Reporting the number of Active Directory trees, domains, sites, administrative groups,
routing groups, Exchange 5.5 servers, Exchange 2000 servers, Exchange 2003
servers, total mailboxes, Windows 2000 Active Directory servers, Windows 2003
Active Directory servers, and Windows 2003 SP1 Active Directory servers.
• Categorizing the existing Exchange organization as Simple, Standard, Large, or
Complex. This helps guide you to the best starting point for upgrade documentation.
The following table lists some issues that ExBPA may identify that you need to resolve
before starting the Exchange upgrade:
Issue Suggested resolution
The Schema Master is not running Upgrade the schema master to the correct operating
Windows 2003 SP1 or later. system version.
One or more Active Directory domains are Resolve any issues related to why the domain
not in native mode. functional level has not been raised to the required
level, and then raise the domain functional level.
One or more Active Directory sites do not Upgrade at least one global catalog server in each
have a global catalog server running site to the correct operating system version.
Windows 2003 SP1 or later.
One or more Active Directory Connectors The Active Directory Connector is used to replicate
exist in the organization. information between Exchange 5.5 and Active
Directory. Ensure that this connector is no longer
required and remove it from the server.
Maintaining Features Not Supported by Exchange Server 2007
Exchange Server 2007 does not support some features that were available in previous
Exchange Server versions.
Exchange Server 2003 Features Not Supported in

Exchange Server 2007 does not support the following Exchange Server 2003 features, so
if you require them, you must keep at least one Exchange 2003 server in your
organization:
• Novell GroupWise connector
• Network News Transfer Protocol (NNTP)
• Microsoft Office Outlook® Mobile Access
• Inter-Organization Replication tool to share Free/Busy and public folder data across
forests
Exchange 2000 Server Features Not Supported in

Exchange Server 2007 does not support the following Exchange 2000 Server features, so
if you require them, you must keep at least one Exchange 2000 server in your
organization:
• Microsoft Mobile Information Server
• Instant Messaging service
• Exchange Chat Service
• Exchange 2000 Conferencing Server
• Key Management Service
• cc:Mail connector
• MS Mail connector
Note: In addition to these Exchange features, your organization also may have
installed third-party software or services that integrate with Exchange. Ensure that
these services are compatible with Exchange Server 2007 or update them to
versions that are compatible with Exchange Server 2007, or retain a previous
Exchange version that is compatible.
Preparing Active Directory for Exchange Server 2007
Before you can start the upgrade process, you must prepare Active Directory for the
Exchange Server 2007 deployment. To do this, you must run Exchange Server 2007
setup using the /PrepareLegacyExchangePermissions command and the /PrepareAD
command.
Changes made by the PrepareLegacyExchangePermissions

command
You must run the setup /PrepareLegacyExchangePermissions command so that the
Exchange Server 2003 or Exchange 2000 Server Recipient Update Service functions
correctly after you update the Active Directory schema for Exchange Server 2007. In
Exchange Server 2003 and Exchange 2000 Server, the Recipient Update Service updates
some mailbox attributes, such as the proxy address, on mail-enabled user objects. The
Recipient Update Service has permission to modify these attributes because the computer
account for the server on which the Recipient Update Service runs is in the Exchange
Enterprise Servers group.
When you extend the Active Directory schema in preparation for Exchange Server 2007,
the schema is modified so that the server running Recipient Update Services no longer
has the required permissions to update the recipient properties. Running the
/PrepareLegacyExchangePermissions command modifies the permissions to ensure that
the server can continue to modify recipient properties.
For more information: For more information on the

/PrepareLegacyExchangePermissions command, see the “Preparing Legacy
Exchange Permissions” page of the Microsoft TechNet Web site.
Note: You must install the prerequisite software on the computer where you run
setup. The prerequisite tools are Microsoft .NET Framework 2.0, Microsoft
Management Console 3.0, Microsoft Windows PowerShell, and the .NET
Framework 2.0 hotfix described in Knowledge Base article 926776 on the Microsoft
Help and Support Web site.
Changes made by the PrepareAD command

After running setup with the PrepareLegacyExchangePermissions parameter, you should
run setup with the /PrepareAD command. This command makes the following changes to
enable coexistence between Exchange versions:
• Creates the Active Directory universal security group ExchangeLegacyInterop. This
group receives permissions that allow the Exchange 2003 and Exchange 2000 servers
to send e-mail to the Exchange 2007 servers.
• Creates the Exchange Server 2007 Administrative Group, which is called Exchange
Administrative Group (FYDIBOHF23SPDLT).
• Creates the Exchange Server 2007 Routing Group, which is called Exchange Routing
Group (DWBGZMFD01QNBJR).
Note: You can use a 32-bit operating system and the 32-bit version of
Exchange Server 2007 installation files to prepare your organization for Exchange
Server 2007.
Designing the Client Access Server Role Deployment
The Client Access server role provides similar functionality to that which a front-end
server in Exchange 2000 Server and Exchange Server 2003 provides. You must deploy
the Client Access server role in every Active Directory site that includes an Exchange
Server 2007 Mailbox server.
Effect of Deploying the Client Access Server Role

The Client Access server role can coexist with Exchange Server 2003 and Exchange
2000 Server front-end and back-end servers in the same Exchange organization and in the
same Active Directory site. If you deploy a Client Access server, all users will be able to
use the Client Access server to access their mailboxes, even if their mailbox is located on
an Exchange 2000 or Exchange 2003 back-end server.
Note: You cannot use an Exchange Server 2003 or Exchange 2000 Server
front-end server to access mailboxes on Exchange Server 2007 Mailbox server.
Additionally, because Exchange Server 2007 does not support Microsoft Outlook®
Mobile Access, users will not able to access their mailboxes through the Client
Access server.
Each user’s Outlook Web Access experience depends on their mailbox’s location.
For example, if the user’s mailbox is located on an Exchange Server 2003 back-end
server and they access the mailbox through a Client Access server, they will see
the Exchange 2003 version of Outlook Web Access. Users will see the Exchange
Server 2007 version of Outlook Web Access only if their mailbox has been moved to
an Exchange Server 2007 Mailbox server.
The Outlook Web Access URL used to access Outlook Web Access depends whether
the user’s mailbox is located on an Exchange 2003 back-end server or on an Exchange
Server 2007 Mailbox server. If the mailbox is located on an Exchange 2003 back-end
server, the URL is typically https://<servername or FQDN>/Exchange. If the mailbox
is located on an Exchange Server 2007 Mailbox server, the URL is typically
https://<servername or FQDN>/owa. If the users connect to the /Exchange virtual
directory and their mailbox is located on an Exchange 2007 server, their Web browser
will be redirected automatically to the /owa virtual directory.
Users will be able to access public folders through Outlook Web Access only if a replica
of the public folder remains on an Exchange 2000 or Exchange 2003 server. To access
the public folders, users must connect to the /public virtual directory.
Considerations for Implementing Client Access Servers

The Client Access server role should be the first Exchange Server 2007 server role that
you deploy in each Active Directory site. Implementing the Client Access server does not
disrupt any current functionality and does not require any immediate client configuration
changes.
In most cases, you can implement Client Access servers without moving any data
from the Exchange 2000 or Exchange 2003 front-end servers. If you are using a server
certificate for secure sockets layer (SSL) on the front-end server, and you are using the
same fully qualified domain name on the Client Access server, you should migrate the
certificate to the new server.
You can start removing Exchange 2000 and Exchange 2003 front-end servers after
you install the Client Access servers. Other than access to Outlook Mobile Access and
Exchange ActiveSync, which is Microsoft Systems Management Server (SMS) based, all
of the functionality that the front-end servers provide is available on the Client Access
servers.
Designing the Hub Transport Server Role Deployment
The Exchange Server 2007 Hub Transport server role replaces the functionality that
the bridgehead servers provide in an Exchange 2000 Server or Exchange Server 2003
organization. However, because of significant changes to the transport and routing in
Exchange Server 2007, you cannot simply replace each bridgehead server with a Hub
Transport server.
Considerations for Deploying Hub Transport Servers

A Hub Transport server can coexist with Exchange 2003 and Exchange 2000
bridgehead servers in the same location. However, a Hub Transport server cannot
operate as a bridgehead server on a routing group connector between Exchange 2000 or
Exchange 2003 routing groups, and an Exchange 2000 or Exchange 2003 bridgehead
server cannot route messages between Exchange Server 2007 servers in two different
Active Directory sites.
This means that when you deploy the Hub Transport servers, you are creating a parallel
system for routing messages. The Exchange Server 2007 Hub Transport servers will
route messages only to other Exchange Server 2007 Hub Transport servers in other
Active Directory sites, and the Exchange 2003 and Exchange 2000 bridgehead servers
will route messages only to other bridgehead servers in other routing groups.
The link between the parallel message routing paths is a routing group connector that you
create between the two Exchange versions. When you deploy the first Hub Transport
server in an Exchange 2000 Server or Exchange Server 2003 organization, this creates a
routing-group connector automatically that routes messages between the two Exchange
versions. When you deploy a Hub Transport server in another site, you also may
configure additional connectors to provide more efficient message routing. If you create
an additional routing group connector, also disable minor link state updates to prevent
message looping.
Because the message routing topologies are separate in Exchange Server 2007 and in
previous Exchange Server versions, you cannot remove the last Exchange 2000 or
Exchange 2003 bridgehead servers from a routing group until you remove all of its
mailboxes and public folders from the back-end servers. When you are not storing
any more data on the previous Exchange versions, you can delete the routing group
connectors for the routing group, uninstall Exchange server on the bridgehead servers,
and delete the routing groups.
Designing the Mailbox Server Role Deployment
Most of the work in transitioning an organization to Exchange Server 2007 involves

implementing Mailbox servers, and moving mailbox and public folder data to the new
servers.
Deploying Mailbox Servers

After you deploy the Client Access and Hub Transport servers in an Active Directory site,
you can introduce the Exchange Server 2007 Mailbox server role, and it can coexist with
Exchange 2003 and Exchange 2000 mailbox servers in the same routing group or Active
Directory site.
After you deploy the Mailbox servers, you can move mailboxes from Exchange
Server 2003 and Exchange 2000 Server to Exchange Server 2007. To move mailboxes to
Exchange Server 2007, you must use the Exchange Server 2007 management tools, using
either the Move-Mailbox cmdlet in the Exchange Management Shell or the Move
Mailbox Wizard in the Exchange Management Console.
You also can configure replication to move public folders to the Exchange Server 2007
Mailbox servers. To do this, you can use either Exchange 2000 Server or Exchange
Server 2003 Exchange System Manager or the Set-PublicFolder cmdlet in the Exchange
Management Shell. After you replicate the public folders to the Exchange 2007 servers,
you can remove the public folder replicas from previous Exchange versions.
If you are supporting Outlook clients older than Outlook 2007, you also must migrate
the offline address book folders and the Free/Busy system folders to the Exchange
Server 2007 Mailbox servers.
In Exchange Server 2007, you have the option of not using public folders. You only
can remove all public folder databases from the organization if you do not have any
Outlook 2003 or older clients and if interoperability with Lotus Notes is not required.
Additionally, if you configure any offline address books for public folder distribution,
you cannot remove the last public folder database. If your organization meets all of these
prerequisites, you can delete all public folder databases on the Exchange Server 2007
servers after you remove the last Exchange 2000 Server or Exchange Server 2003 servers.
After you have moved all data from the Exchange 2000 or Exchange 2003 Mailbox
servers to Exchange Server 2007 Mailbox servers, you can remove the previous
Exchange versions by uninstalling them.
For more information: For detailed steps on removing Exchange Server 2003 and
Exchange 2000 Server computers from an Exchange Server 2007 organization,
see the Release Notes for Exchange Server 2007 Web site.
Designing the Edge Transport Server Role Deployment
You can deploy the Edge Transport server role at any point during the transition process.
You can deploy the Edge Transport server role before deploying any other Exchange
Server 2007 servers or after you deploy other Exchange Server 2007 servers.
Implementing the Edge Transport Server Role

You can add an Edge Transport server to an existing Exchange organization without
upgrading the internal Exchange servers or making organizational changes. Because the
Edge Transport server role does not use Active Directory, you do not have to perform any
Active Directory preparation steps before you install the Edge Transport server.
When you deploy an Edge Transport server before you deploy other Exchange 2007
servers, the Edge Transport server functionality becomes limited and your administrative
effort to configure the server increases. You cannot use features such as the recipient
lookups for spam filtering or safelist aggregation, because you cannot create an Edge
Subscription before you deploy a Hub Transport server.
Configuring Internet Message Routing

If you cannot enable Edge Synchronization, you must configure messaging routing on the
internal Exchange bridgehead servers and the Edge Transport server manually rather than
using the Edge Subscription to configure the settings based on the internal Active
Directory configuration. You will need to:
• Configure the Exchange 2000 or Exchange 2003 bridgehead servers to use the Edge
Transport server as a relay for outbound Internet messages. To do this, configure the
appropriate Simple Mail Transfer Protocol (SMTP) connector to send messages to
the Internet using the IP address of the Edge Transport server as a smart host.
• For inbound Internet messages, ensure that your organization’s mail exchange (MX)
records reference the IP addresses of the Edge Transport servers.
• Configure SMTP connectors to enable message routing between the Edge Transport
servers and the Exchange 2000 or Exchange 2003 bridgehead servers, and between
the Edge Transport servers and Internet SMTP servers. At a minimum, you must
configure an SMTP send connector for sending e-mail and an SMTP receive
connector receiving e-mail from the Exchange 2000 or Exchange 2003 servers, and
configure a send connector for sending e-mail to Internet recipients. By default, a
receive connector is configured on the Edge Transport server that will accept
messages from the Internet SMTP servers.
• Configure the accepted domains. The accepted domain setting specifies the SMTP
domains that the organization uses. You must configure these domains manually on
the Edge Transport server if you do not have the option of configuring an edge
subscription.
Note: When you implement Edge Synchronization between Edge Transport

servers and Hub Transport servers, many of the configuration settings on the Edge
Transport server will be overwritten with settings configured on the Hub Transport
server. These settings include the SMTP send connectors and the accepted
domains.
Lesson 3: Designing a Migration from Other

Messaging Systems
In a migration scenario, you first deploy the Exchange Server 2007 messaging
environment. You then move relevant data and configuration information from the
existing messaging system to Exchange Server 2007. The migration may be from
previous Exchange Server versions in a different organization or from another
messaging system.
Objectives
• Design a solution for migrating message routing to Exchange Server 2007.
• Design a solution for migrating directory information to Exchange Server 2007.
• Design a solution for migrating data from another messaging system to Exchange
Server 2007.
• Design a solution for migrating away from Lotus Domino to Exchange Server 2007.
Migrating Message Routing to the Exchange Server 2007

Organization
The first step to migrate to Exchange Server 2007 typically involves moving all message
routing functionality from the current messaging system to Exchange Server 2007. This
may include Internet message routing, spam and virus filtering, secure e-mail for specific
recipients, and message routing between company locations.
Implementing the Message Routing Migration

To migrate message routing from the current messaging environment to Exchange
Server 2007, you should:
1. Deploy the Exchange Server 2007 infrastructure. In a migration scenario, you can
deploy the Exchange Server 2007 environment without immediately integrating
the Exchange Server 2007 system with the existing messaging system. In a
small organization, you may be able to deploy the entire Exchange Server 2007
infrastructure before migrating the message routing. In a large organization, you may
need to deploy only a portion of the Exchange Server 2007 environment initially.
2. Configure and test message routing on the Exchange Server 2007 servers. You can
configure message routing on the Exchange Server 2007 servers without adversely
affecting the production environment because you deploy it in parallel with the
current messaging system. You should configure message routing to and from the
Internet. If you are planning to use an Edge Transport server to provide spam filtering,
deploy the server and configure Internet message routing. Then, create test mailboxes
on the Exchange Server 2007 system and confirm that message routing works as
expected.
3. When you are sure that message routing on the Exchange Server 2007 system is
configured correctly, configure message routing between the Exchange Server 2007
organization and the existing messaging system. To do this, you must configure
SMTP send connectors to send messages from one or more Hub Transport servers or
Edge Transport servers to the existing messaging system, and SMTP receive
connectors to accept messages from the non-Exchange Server 2007 messaging
system. On the non-Exchange Server 2007 messaging system, configure the SMTP
servers to forward all messages to the Exchange Server 2007 Hub Transport server or
Edge Transport servers. Test message flow between the messaging systems.
Note: If the two messaging systems share the same SMTP address space, you will
need to configure the accepted domains and SMTP connectors as described in
Module 6, “Designing Co-Existence and Interoperability Strategies with Other
Messaging Systems,” in this course.
4. When you are sure that messages will flow between the two messaging systems,
modify the Internet message routing configuration so that all inbound and outbound
Internet messages are sent through the Exchange Server 2007 system. To ensure that
all inbound messages flow through the Exchange Server 2007 system, configure
the MX records on the Internet Domain Name System (DNS) servers to use the
Exchange Server 2007 Edge Transport servers. To ensure that all outbound messages
are sent through the Exchange Server 2007 servers, configure the internal message
routing to send all outbound messages from the non-Exchange messaging system to
the Edge Transport server.
5. As you remove the non-Exchange Server 2007 messaging servers, remove any
affected message routing functionality from the existing messaging system.
Migrating Directory Information to the Exchange Server 2007

Organization
In a migration scenario, one of the first issues that you must address is how to migrate the
existing messaging system’s directory information to Exchange Server 2007. The two
messaging systems do not share directory information by default.
Identifying the Directory Information to Migrate

You first must identify the types of directory information you want to migrate. In
some cases, the messaging system that you are migrating from may contain minimal
information about each recipient and the organization may not require the information in
the Exchange Server 2007 environment. In these scenarios, you may only need to create
new user accounts in Active Directory and populate the user properties.
In most cases, however, you will need to migrate additional information about the
recipients in the directory. Most organizations use their messaging system directories to
store details about each user account, including phone numbers, office locations, and
organizational information. You also may need to migrate other recipients, such as
custom recipients or distribution lists.
Migrating Directory Information

In a small or medium sized organization, you may be able to migrate directory
information by using Lightweight Directory Access Protocol (LDAP) tools or scripts. If
the source directory is LDAP compliant or if it supports a directory export tool, you can
export all of the user information into a file, such as a comma separated value (.csv)
file. You then can modify the file to use the Active Directory or Exchange Server 2007
attributes, and then use a tool such as the Csvde.exe utility or an Exchange Management
Shell script to import the information into the Exchange Server 2007 environment.
If you are migrating user information from another forest to the Exchange Server 2007
forest, you can use a tool such as the Active Directory Migration Tool version 3.0
(ADMT v3) to move contacts or distribution groups from one Exchange organization or
Active Directory forest to another.
In larger organizations, you can use the GAL Synchronization feature in Microsoft
Integration Identity Server (MIIS) 2003 or in the Identity Integration Feature Pack 1a
for Microsoft Windows Server Active Directory to synchronize directory information
between Active Directory forests or between an Active Directory forest and another
messaging system. This feature creates mail-enabled contacts that represent recipients
from other forests or messaging systems, thereby allowing users to view them in the GAL
and send mail.
To enable GAL Synchronization in MIIS, you create management agents that import
mail-enabled users, contacts, and groups from the source directory into a centralized
metadirectory. In the metadirectory, mail-enabled objects are represented as contacts.
Groups are represented as contacts without any associated membership. The management
agents then export these contacts to an organizational unit in the domain’s forest that
contains the Exchange Server 2007 organization.
Migrating Data to the Exchange Server 2007 Organization
Migrating data, such as mailbox data and public folder data, in a migration scenario is
significantly more difficult than in a transition scenario because you are moving data
between Exchange organizations or between messaging systems. As a best practice, you
should consider using third-party tools to migrate this data.
Identifying the Data to Migrate

The first step is to determine which data you want to move. In almost all migration
scenarios, you have to move the contents of mailboxes from one system to the other.
Additionally, you may need to move shared data from public folders. If the two
messaging systems are going to interoperate for some time, you also may need to
synchronize Free/Busy information between the two systems.
Migrating Data between Exchange Organizations

If you are migrating from a messaging system, such as Exchange Server 2003 or
Exchange 2000 Server, you can use the Exchange Server 2007 Move-Mailbox cmdlet to
move mailboxes from one Exchange organization to another. When you run the Move-
Mailbox cmdlet, you can specify credentials that are valid in the source organization and
that can extract information from user mailboxes.
Note: For detailed information on how to configure the Move-Mailbox cmdlet to use
credentials from another forest, see Exchange Server Help.
If you need to migrate public folder data from a source Exchange organization to the
Exchange Server 2007 organization, you must use the Inter-Organization Replication tool.
However, Exchange Server 2007 does not support the Inter-Organization Replication tool,
so you must have an Exchange Server 2003 server in each forest in order to use it. If this
is not an option, you can export the data manually in the source organization’s public
folders and import it into public folders on the Exchange Server 2007 organization.
To migrate Free/Busy information between the two forests, you have two options:
• If you are using any Outlook version other than Outlook 2007, you must use the
Inter-Organization Replication tool to synchronize the system folder containing the
free/busy data between the Exchange organizations. This requires at least one
Exchange Server 2003 server in the Exchange Server 2007 organization.
• If you are running only Outlook 2007 clients, you can configure the Availability
service to request Free/Busy information across Exchange organizations. However, in
this scenario, both organizations must be running Exchange Server 2007.
Note: At product release, Exchange Server 2007 only provides the Transporter
Suite for Domino for migrating data from non-Exchange messaging systems to
Exchange Server 2007. Because of the complication of moving data in this
migration scenario, you should consider using third-party migration tools to simplify
the process.
Migrating from Lotus Domino
Migrating from one messaging system to another in an enterprise environment can be

very complicated. This is particularly true if the current messaging system is Lotus
Domino, because many organizations running Lotus Domino also have implemented
custom applications on the messaging system.
Microsoft Transporter Suite for Lotus Domino

Microsoft Transporter Suite for Lotus Domino is used for interoperability and migration
from Lotus Domino to Active Directory, Exchange Server 2007, and Windows
SharePoint Services 3.0.
Note: For more information on Microsoft Transporter Suite for Lotus Domino, see
the “Resources for Interoperability and Migration from Lotus Domino” page of the
Microsoft TechNet Web site.
Microsoft Transporter Suite for Lotus Domino includes the following components:
• Directory Connector. Synchronizes users, groups, and Domino mail-in database
information between Active Directory® directory service and the Domino Directory.
• Free/Busy Connector. Allows IBM Lotus Notes and Microsoft Office Outlook users
to perform free/busy lookups against both Lotus Domino and Microsoft Exchange
Server 2007 servers when scheduling meetings.
• Directory Migration. Creates Active Directory accounts for Domino Directory users.
• Mailbox Migration. Migrates mail, calendar, and task information from Lotus
Domino mail databases to Exchange Server 2007 mailboxes.
• Application Migration. Migrates Lotus Domino application information to Microsoft
Windows SharePoint Services and SharePoint Server 2007.
Implementing the Transporter Suite for Lotus Domino

You can install the Transporter Suite on any Microsoft® Windows® XP or Windows
Server 2003 computer. Additionally, you need to install Microsoft Management Console
3.0 and Windows PowerShell on the computer. You must also install the Lotus Notes 6.x
or 7.x client on the computer.
You must install the Directory Connector and Free/Busy connector on an Exchange
Server 2007 Hub Transport server or Mailbox server. To support the Free/Busy connector,
you also must install the Exchange MAPI client on the computer.
Note: Exchange Server 2007 does not install any MAPI client components by
default. You can download the Microsoft Exchange Server MAPI Client and
Collaboration Data Objects 1.2.1 from the “Microsoft Exchange Server MAPI Client
and Collaboration Data Objects 1.2.1” page of the Microsoft Download Center Web
site.
You can use Transporter Suite to configure interoperability between Lotus Domino 6.x
and 7.x and Exchange Server 2007, and to migrate users, data, and applications from
Lotus Domino 5.x, 6.x, and 7.x to Exchange Server 2007.
Note: One important difference between Transporter Suite for Lotus Domino and
the Connector for Lotus Notes that Exchange Server 2003 provided is that the
current versions uses SMTP for message routing between the messaging systems.
In previous versions, all messages were routed through the Lotus Notes client
installed on the migration server.
Transporter Suite includes a user interface that is similar to the Exchange Management
Console and that adds several additional Windows Powershell cmdlets. You can use both
tools to view information about Lotus Domino objects, to configure synchronization
between the messaging systems, and to complete the migration from Lotus Domino to
Lab: Designing an Upgrade Strategy

• Review the Exchange Server 2007 design.
• Design an upgrade strategy.
Lab Setup
lab, you must:
Pa$$w0rd.
Lab Scenario
The Trey Research headquarters and two remote locations are running Exchange 2000
Server and Outlook 2000. Trey Research will be adding two new locations, and within
the next six months, plans to migrate all existing users to Exchange Server 2007 and
Outlook 2007. Much of the Exchange Server 2007 messaging system design is complete.
The A. Datum location continues to run a POP3/SMTP messaging system, which you
need to migrate to Exchange Server 2007 and integrate with the rest of the Exchange
organization. The A. Datum domain already has been deployed as a separate tree in the
Trey Research forest.
Exercise 1: Discussion: Reviewing the Exchange Server 2007

Design
In this exercise, you will review the Exchange Server 2007 design in preparation for
designing the upgrade strategy. Review the following documents:
• TR_ProposedCoexistenceStrategy.vsd
• TR_ProposedInteropStrategy.vsd
• TR_ProposedServerDesign.doc
• TR Proposed Security Policies.doc
Note: You can review the documents in the LabAnswers folder for each module.
Alternatively, you can review the lab answers that you created during the labs.
Q Is the design missing any components?
A Answers may vary. Most of the important design decisions have been considered in
the labs so far, but students may identify additional factors or components that they
feel should be considered.
Q Are there any design decisions that you would like to reconsider?
A Answers may vary. All of the labs so far have focused on individual design
components, and this exercise provides a high-level view of the decisions made thus
far. By reviewing the integration of various components, students may decide to
modify their designs.
Exercise 2: Designing an Upgrade Strategy

In this exercise, you will design an upgrade strategy for the Trey Research organization.
Tasks Supporting Information
• Based on the review of • Open the TR_UpgradeStrategy.doc file from the

the Exchange Server D:\Mod07\Labfiles\LabInputs folder.
2007 target state design, • In the Word file, describe the upgrade strategy for the Trey Research
create an upgrade organization. Your design should answer the following questions:
strategy for migrating from
• In what order will you upgrade the Trey Research locations?
the current environment to
Why did you choose this order?
the target state design.
• In what order will you deploy the servers in each location? Why
did you choose this order?
• How will you move functionality from Exchange Server 2000 to
Exchange Server 2007?
• How will you move data to the Exchange 2007 servers?
• How will you address the directory synchronization
requirements, calendaring integration, and offline address book
requirements?
• How will you implement the POP3/SMTP migration to Exchange
Server 2007?
• What additional considerations need to be included in the
upgrade strategy?
TR_ProposedUpgradeStrategy.doc.
Q Based on what you know about the Trey Research organization, what would be a
reasonable time line for completing this migration?
A Answers will vary. Because this upgrade does not require any client reconfigurations
for users, except in San Diego, the organization could pursue a fairly aggressive time
line. Estimates for completing the upgrade should range from three to 12 months.
Q What are the factors that will affect the time line?
A Factors that will impact the upgrade time line include:
• Project budget
• Resource availability (both personnel and hardware)
• Test requirements
the changes.
Lab Shutdown
Module 8: Obtaining Approval for a
Messaging Infrastructure Design
Table of Contents
Overview 8-1
Lesson 1: Preparing to Obtain Approval 8-2
Lesson 2: Presenting and Finalizing a Design 8-10
Lab: Obtaining Approval for a Messaging
Infrastructure Design 8-18
Course Evaluation 8-22
Version 1.2
Module 8: Obtaining Approval for a Messaging Infrastructure Design 8-1
Overview
After you finish the design of the Microsoft® Exchange Server 2007 messaging system,
the final step is to gain design approval. During this final step before implementation, you
must be prepared to manage final changes to the project requirements or to project
constraints. These changes also may require that you change your design.
Objectives
• Prepare for the design approval meeting.
• Present and finalize an Exchange Server 2007 design.
8-2 Module 8: Obtaining Approval for a Messaging Infrastructure Design
Lesson 1: Preparing to Obtain Approval
In most organizations, the design approval process for a large project, such as a new
messaging system, will take a significant amount of time and may involve several
meetings with project stakeholders. At these meetings, you will present the system design,
and provide a plan for implementing the design. Your goal in these meetings is to provide
the stakeholders with the information that they need to make the decision to proceed with
the implementation.
Objectives
• Create a design document.
• Create an implementation plan.
• Identify design reviewers.
Creating a Design Document
Most organizations have different expectations for the format that is used for the
design document. Some organizations prefer to use a Microsoft® Office PowerPoint®
presentation that provides a fairly high-level overview of the design components. Other
organizations require detailed documents that provide complete information for the
configuration of all messaging system components. Most design documents include the
following components:
• Executive summary
• Summary of the current environment and requirements
• Target state design
• Tradeoff decisions
Executive Summary
The primary audience for the executive summary is usually information technology (IT)
management or the project sponsor. This audience typically is not interested in the
solution’s technical details, but is interested in whether the solution meets the business
and technical requirements defined at the project’s inception. This means that the
executive summary usually focuses on how the messaging system design will address
those business and technical requirements.
In some cases, IT management or business sponsors may need to make tradeoff decisions
during the design review process. If these decisions are required, the executive summary
should include an overview of the issues and include links to the location in the design
document where the issue is discussed in detail.
Summary of the Current Environment and Requirements

Typically, a design document will provide an overview of the current messaging
environment. Whenever possible, this information should be displayed in graphical or
table format to simplify the content’s review.
The design document also summarizes the business and technical requirements for
the project. You define these requirements at the beginning of the design process,
but it is useful to review the requirements during the design review to ensure that
the requirements are still valid and that the design meets the requirements. A clear
understanding of the requirements also ensures that any tradeoff decisions focus on the
requirements rather than the technical solution.
Target State Design

The majority of the design document consists of the actual messaging system design. In
most cases, you should include a high-level overview of the target state design. You can
discuss this overview during the design review meeting.
You also must provide detailed configuration information in the design document. The
audience for this detailed information is the organization’s technical specialist. There
may be several technical reviewers, each of whom will review only part of the solution.
For example, the storage infrastructure specialists will review only the part that has an
impact on the storage infrastructures.
Because the technical details take significant time to review, they generally are reviewed
outside of the design review meeting. If there are important details that all stakeholders
need to review, you should consider highlighting those details during the design’s
presentation.
Tradeoff Decisions
In almost all design meetings, you will need to make tradeoff decisions or make decisions
that may not be acceptable to all stakeholders. For example, the project may be able to
meet all requirements, but only with a budget increase or by extending the schedule. In
some cases, there also may be conflicting requirements. For example, the business
sponsor may have a requirement that all users have access to their mailboxes by using a
mobile client, while the security officer may have significant security concerns with this
requirement.
Whenever possible, you should try to resolve these tradeoff decisions before the design
review meeting. Resolving these types of issues can take significant time and the meeting
time may be consumed with very detailed discussions with only some stakeholders. If
you have resolved these issues, you should highlight the design components that required
these decisions, and describe how the design resolves the issue.
In some cases, decisions may need to be made at the design review meeting. Your design
document should describe clearly the decisions that need to be made, the options that are
available when making the decisions, and the reasons for choosing each option. In most
cases, these decisions will require some level of requirement tradeoff or a project
constraint renegotiation. By providing the stakeholders with the information they need,
you can expedite the decision-making process.
Creating an Implementation Plan
As part of the design review meeting, you also may need to provide an implementation
plan. Usually, the detailed implementation plan is created after the design is accepted.
However, you may need to present a high-level overview of the implementation plan.
This is particularly necessary if the design decisions are going to disrupt regular business
processes.
Implementation Plan Components

Different organizations use different formats for implementation plans, but most plans
contain the following components:
• Reference to the current state and target state design. The implementation plan
provides the steps for migrating from the current to the target state environment, so it
should include references to the documents that describe the design. The stakeholders
who review the implementation plan may be different than those who review the
design, so you cannot assume that all stakeholders have this knowledge.
• High-level implementation steps. The high-level steps should describe:
• The office locations that each step of the plan affects.
• Which servers or services will be deployed or removed, and in which order
deployment will occur.
• A tentative schedule for when the configuration changes will be made.
• Test plan. The implementation plan should provide high-level overview of the testing
that has occurred to create the plan, and the additional testing that needs to occur to
finalize it.
• Anticipated impact on the current environment. This a critical component of the

implementation plan. All stakeholders need to be aware of when the changes will
occur, and how they will affect current functionality.
• Rollback plan. The implementation plan should include a plan for rolling back a
deployment if a disruption occurs. The rollback plan should identify clearly the
scenarios where a rollback plan would be implemented and provide the steps for
completing each scenario’s rollback.
• References to build documentation and transition-to-production documentation.
In most cases, you will create these detailed documents after the design and the
implementation plan receive approval, but you should update the implementation
plan with references to the documents. The implementation plan should be the one
document that all members of the deployment team use to locate the appropriate
information.
• Training plan. The implementation plan should include a training plan for training all
users that the new deployment impacts. In an Exchange Server 2007 deployment plan,
you will need to provide training for the messaging administrators who will manage
the system after deployment, for help desk personnel to ensure they are familiar with
new or changed procedures, and users who may need to deal with a new user
interface.
• Communications plan. As part of the implementation plan, you should include a
communication plan that describes how to inform users who the deployment affects.
• Project dependencies. The project may be dependant on the organization’s other
projects. The dependency may be that the other project must complete before the
Exchange Server 2007 deployment can begin. In other cases, the projects may not be
dependant, but personnel or budget constraints may mean that the schedule for
projects cannot overlap.
Identifying Design Reviewers
The final step in preparing for the design review is identifying the project stakeholders
who will review and approve the design. The stakeholders on an Exchange Server 2007
implementation project include the following:
• Business sponsors. The business sponsor is responsible for delivering a messaging
system that meets the requirements designed for the organization. The sponsor also
usually is responsible for the project budget. This means that the sponsor must be part
of any design review meeting that has functionality or budget implications.
• Technical stakeholders. The implementation of an Exchange Server 2007 messaging
system will impact almost all of the organization’s network and server operations.
Thus, the people who are responsible for these operations are important stakeholders
in the design process. You should include the following administrators in the design
review:
• Network administrators
• Storage system administrators
• Security administrators
• Server administrators
• Desktop deployment and management administrators
• Other stakeholders. Within a large organization, there may be several other

stakeholders that need to review the design. These include:
• Security officers. A messaging system deployment can impact an organization’s
security in many different ways.
• Compliance and audit departments. Because of the new functionality that
Exchange Server 2007 provides that can be used to ensure messaging compliance,
the compliance audit departments should be involved in setting the requirements
for the Exchange Server 2007 deployment and should review the design.
Lesson 2: Presenting and Finalizing a Design
The final step in preparing the design for an Exchange Server 2007 implementation
is presenting the design for approval. During this final step, you may need to make
modifications to the design in response to feedback that you collect during the design
review meetings.
Objectives
• Present a design document for review.
• Describe strategies for overcoming obstacles to obtaining approval.
• Revise a design based on stakeholder feedback.
• Identify a process for changing the design after approval.
Presenting a Design Document for Review
After the design and the high-level implementation plan are complete and you have
identified the stakeholders who will review the design, you are ready to present the
design for approval. For a small project, you may be able to complete the review process
in a single meeting. For a complex project, however, with many requirements and
constraints, this process may extend out several weeks.
Design Review Process

The design review process can involve several different formats. These include:
• Initial design review meetings. Almost all design reviews include at least one
meeting. The business sponsor and other senior managers representing the
stakeholder groups usually attend the initial meeting, which typically focuses on
the business requirements, budget discussions, and project tradeoffs. This meeting
rarely involves any review of technical details.
During this initial meeting, it is critical that you present the design’s information in
a format that meets the audience requirements. Business sponsors and IT managers
usually are not interested in technical details, but they are very interested in business
requirements, budgets, and schedules. This means that you need to present the
implications of the technical decisions that you made during the design process in
terms that are meaningful to participants. Often, the best way to do this is to list the
business requirements briefly that were identified at the project’s inception and
describe how the design addresses the business requirements.
• Additional design review meetings often are necessary to finalize the design’s details.
These meetings often focus on one part of the design or one aspect in the deployment
plan. For example, each technology group may require a separate meeting to discuss
the technical details relevant to that group.
• Document review. Because an Exchange Server 2007 design will include many
technical details, some of the design review likely will occur via document review.
Technical specialists usually take this approach because they need to validate the
design’s technical details. After the document review is complete, the technical
specialists may need to meet with the design team to review their findings.
Tip: For information on creating effective presentations, see the book “Beyond
Bullet Points: Using Microsoft® PowerPoint® to Create Presentations That Inform,
Motivate, and Inspire” published by MS Press.
Discussion: Overcoming Obstacles to Obtaining Approval
During the design review process, one or more reviewers may raise issues with the design.
There are many possible reasons why they raise these issues, and you need to be prepared
to address them.
Q What factors may prevent a design from being accepted?
A There are many possible reasons why a design is not accepted initially. These
include:
• Budget issues. In some cases, the solution that meets all the business
requirements may exceed the project’s budget or the project’s budget may be cut
after project initiation.
• Technical issues. The design’s technical review may identify errors or raise new
issues that the design does not cover.
• Security issues. The security review may identify concerns with the solution’s
security or the solution may require additional security.
• Scheduling issues. The project timeline may interfere with other projects or
business processes. For example, many organizations have a year-end freeze
period, where you may not be able to make a significant change to the
infrastructure one month before and after the fiscal year ends.
Q How would you address these factors?

A The best way to address an issue will depend on the issue being raised. Some general
guidelines include:
• Understand the organization’s requirement or expectation for presentations and
for documentation. Organizations can have very different expectations for what
type of information is presented during a design review. If these expectations are
not met, this can delay the review process. Ensure that you present the
information that reviewers expect to see in the format they expect.
• Be prepared with alternative suggestions. As you plan for the design review, try
to anticipate the questions that you will hear. By anticipating the questions, you
can prepare alternative suggestions that can address the issues.
• Be prepared for tradeoff discussions regarding budget. If the project’s budget is
too high, you should be prepared to provide alternatives for meeting the budget.
For example, be prepared to describe the budget implications that result from
removing a certain feature or by not addressing a requirement in the design.
Q What factors improve the chances of a design being accepted?

A These factors include:
• Ensuring that you present all information in the format that stakeholders expect.
• Developing a process for dealing with disagreement that allows room for
negotiation.
• Listening carefully to stakeholder concerns and trying to understand the
underlying reason for the concerns.
Revising a Design
The design review meetings may require a design revision. As long as your design is
accurate technically, the most significant design revisions at this point are likely to
involve tradeoff discussions.
Deciding Which Design Revisions to Implement

Organizations have different processes for accepting design documents. Some
organizations required unanimous support from all stakeholders, while others require
that a simple majority of stakeholders agree.
In most situations, one or more stakeholders likely will have veto power over the
decisions made by the other stakeholders. In many cases, this person is the business
sponsor. Because this person is responsible for the project budget, they will have a great
deal of power in deciding whether a project will be implemented.
In many organizations, the security officer also has veto power over a project or a project
component. If the organization has clearly defined security requirements that the project
does not meet, the security officer likely will not approve the project.
If the design review process identifies an issue that the organization finds unacceptable
due to its decision-making process, you must modify the design to meet the requirements.
Implementing the Design Changes

If the design review meetings identify design changes that need to be made, you should:
1. Ensure that you understand the required change clearly. You may need to meet
separately with the stakeholder who raised the issue to identify the rational for the
change request and to understand what change is required. As part of this meeting,
you also should identify the criteria that must be met for the stakeholder to accept the
design.
2. Define the scope of the design change. In some cases, the design change may not
have any budget or schedule implications and may be relatively easy to implement.
In other cases, a design change may require extensive research and testing to ensure
that the change can be implemented and to ensure that the change does not impact
other design aspects.
3. Modify the design to accommodate the change and resubmit the design for review.
When you submit the modified design for review, ensure that you identify clearly
which parts of the design you changed and how you made the required changes.
Additionally, identify the impact that the change has on other design components.
Implementing Design Changes After Approval
After all of the design reviews are complete and you have addressed all requests for plan
modifications, the design is ready for approval. This marks the end of the project’s design
phase. However, typically it does not mean the end of the changes to the design
document.
Developing a Design Change Control Process

Even after the design receives sign off, it still may be subject to change. To ensure that
you manage and document the design changes, you should implement a design change
process. In the design change process, you should:
• Define the circumstances that will prompt a design revision. In some cases, detailed
testing during deployment may require a design modification. In other cases,
constraints such as budget, schedule, or personnel availability may require the
design’s modification or delay the implementation of some aspect of the design. In
most organizations, new business requirements will not be considered after the
design receives sign off.
• Define who will modify the design. If the person who created the original design is
still working on the project, that person normally makes the design changes. If that
person is not available, the design change process should define who will make the
modifications.
• Define how change requests are processed and approved. In most cases, the same
stakeholders that approved the design originally need to be informed about the design
changes made after buyoff. If the design changes affect only a small part of the
design, then only the stakeholders responsible for that part may need to approve the
changes.
Lab: Obtaining Approval for a Messaging

Infrastructure Design

• Present a messaging infrastructure design.
• Discuss the characteristics of an effective design review process.
Lab Setup
lab, you must:
Pa$$w0rd.
a standard installation of Exchange Server 2007. 5053A-LON-Edge1 is a stand-
alone server and has the Exchange Server 2007 Edge Transport Server role
installed on it. The 5053A-LON-CL1 computer is a member of the Treyresearch.net
domain.
Lab Scenario
You have completed the design of the Trey Research Exchange Server 2007 deployment,
and you now are ready to present your proposed solution to the project’s business and
technical stakeholders. You should be prepared to negotiate changes to the messaging
infrastructure design.
Exercise 1: Presenting a Messaging Infrastructure Design

In this exercise, you will present your Exchange Server 2007 design to the Trey Research
project stakeholders. The following stakeholders will be at the design review meeting:
• Business sponsor
• Active Directory® directory service administrator
• Security officer
• Network administrator
Note: The instructor will assign students to act as each of the stakeholders and will
provide information on the perspective each stakeholder will take in the meeting.
Your presentation of the Exchange Server 2007 design should include the following four
components:
• Active Directory and message routing design
• Exchange Server 2007 server design and deployment
• Messaging system security and messaging policies
• Upgrade strategies for implementing Exchange Server 2007
Note: The instructor will assign one of the components to each group of students
or to individual students.
1. Prepare your presentation of • Review the documents located in the LabAnswers folder for the
the Exchange Server modules that correspond to the design component that has been
infrastructure design. assigned to you. Prepare a three-minute presentation that will
provide a high-level description of the component design.
2. Present the Exchange Server • Present the design for each of the four design components to the
design. stakeholders at the meeting.
3. Respond to stakeholder • After the design presentation, the stakeholders will be given a
questions. chance to respond and to ask questions. Respond to the
stakeholder questions and comments related to your part of the
design.
• Participate in the negotiations to address any design changes
that need to be made based on stakeholder comments or
questions.
Exercise 2: Discussion: Characteristics of Effective Design

Review Processes
In this exercise, you will discuss the characteristics of an effective design review process.
Q Describe examples of design review processes that were effective. Provide examples
of design review processes that were not effective.
A Answers will vary depending on the student experience.
Q What are the characteristics of an effective design review process? What are the
characteristics of an ineffective design review process?
A Answers will vary. In general, design review processes are most effective when all of
the stakeholders are engaged throughout the process. If there are design or tradeoff
decisions that need to be made, the stakeholders involved in the decision should be
aware of the issues well before the final design review. If possible, you should have
resolved these issues prior to the meeting.
Q What strategies have you used or seen for dealing with stakeholder buyoff and
approval?
Q What strategies have you used or seen for dealing with design changes?
Lab Shutdown
Course Evaluation
Your evaluation of this course will help Microsoft understand the quality of your learning
experience.
Please work with your training provider to access the course evaluation form.
Microsoft will keep your answers to this survey private and confidential, and will use
your responses to improve your future learning experience. Your open and honest
feedback is valuable and appreciated.
Appendices
Table of Contents
Version 1.2
Jens Johannsen, Directory Services Manager
The company just finished upgrading all of the Active Directory® directory service
domain controllers to Windows Server® 2003, Service Pack 1. The company has
indicated that there is not budget for any further Active Directory changes, so any
modifications we make as part of this project must have no budget implications.
One change that we have been considering is removing the Chennai domain controller.
The office currently does not have a secure server room. There was a project in place to
build the server room, but that project’s budget is in jeopardy. Any input you could
provide to this decision would be appreciated greatly.
Karim Manar, Messaging specialist
We currently are having some messaging problems at the London location. Quite often,
when I look at the server queues on the Exchange Servers, I see that there are many
messages in the categorizer queue. Users also complain that when they try to view the
global address list, it can take more than 10 seconds for it to appear. All of the other
network locations seem to be fine.
We have had some past problems with the bridgehead servers in London, Toronto, and
Tokyo. The problem shows up when there is a network outage to one of the other offices.
If the outage lasts for more than a few minutes, it seems like we get hundreds of
messages in the bridgehead server queues and then it can take a long time for the server
to deliver the messages once we restore the network connection. Compounding this
problem in London is the fact that this is the only location where we are accepting
inbound SMTP e-mail for the Trey Research Company. We need to make sure that
messages get sent out of these sites even if the final destination site is not available.
As you have already heard, we have many employees using Microsoft Office Outlook®
Web Access. We would really like to make sure that the experience for the Outlook Web
Access users is as positive as possible.
Jonas Brandel, Network Operations Manager
We have been monitoring network traffic by protocol for the last year and have noticed a
very big increase in the network bandwidth that Simple Mail Transfer Protocol (SMTP)
traffic uses. In your design, you need to make sure that e-mail messages always are sent
the network connections with the highest bandwidth. Also, make sure that you take
advantage of any other ways in which you can save on bandwidth that e-mail uses.
We are just taking over managing the San Diego network, so we are not sure what
network changes we will need to make there. From what I understand, we may need to
wait on some firewall changes until after we get rid of the current messaging system.
Zheng Mu, Network Specialist
Our department is responsible for the company’s firewall configurations. With every
company location having its own Internet connection, this can be a real challenge. Right
now, we are allowing HTTPS access to some Exchange Servers in London, Toronto, and
Tokyo. This configuration is working okay, but we do not want to open up any more
messaging ports in any location. Additionally, we currently are allowing incoming and
outgoing SMTP traffic through our firewalls only in London, because that is the only
location where we have a spam-filtering solution in place. We would be open to changing
this, but would need to know that the e-mail messages are being scanned for viruses and
spam in all locations where we allow SMTP traffic.
As part of the Exchange Server 2007 design process, the analysts assigned to the project
have identified the following policy requirements.
Mailbox and Message Policies

• The available network bandwidth between company locations is limited. The
largest message sent by most organizational users is 5 MB.
• The graphics department regularly sends messages with 10 MB attachments. The
graphics personnel are located in London, Toronto, and Tokyo. These messages
must be delivered within the organization.
• The current limit for sending and receiving e-mail to the Internet is 2 MB. Many
users in the organization have concerns about this limit and would like, at the
minimum, to double this limit. With the changes made to the delivery of messages
to and from the Internet, the organization has agreed to meet this expectation.
• As a general rule, the design should allow for 20% buffer when designing
message size policies.
• All users must have a maximum mailbox size of 150 MB. Executives and
managers must have a maximum mailbox size of 300 MB.
• All users should receive a warning when their mailbox reaches 80% of the
maximum mailbox size and we should prevent them from sending e-mail when
their mailbox reaches 90% of the maximum size.
• Users should be able to recover items in their mailboxes for seven days after the
message is deleted from the deleted items folders. Executives should be able to
recover these types of messages for 21 days.
• All users in the entire organization should be able to book meetings using any
resource mailboxes, such as meeting rooms and equipment mailboxes. When
users book a meeting, they should get an e-mail saying that the meeting has been
accepted. A meeting room should accept no duplicate meetings. The only
exceptions to this policy are two meeting rooms in London that are used for video
conferences. Any member of the Sales team in the organization should be able to
book the meeting room, but a member of the Sales Support team in London must
accept the meeting requests.
Mobile Messaging Requirements

• All executives and many managers would like to use mobile devices to access
the Exchange mailboxes. Up to this point, users have not been able to access their
e-mail using mobile devices. There is a very strong demand to make this feature
available. Many executives see this as the primary benefit of implementing the
new e-mail system.
• As access to e-mail from mobile devices becomes available, the business
departments are expecting many users will want to have the same level of access.
Providing this access is a high priority for most business departments.
• The security officer is concerned about making mobile device access available for
all users. He has specified the following security requirements:
o All users who will be accessing e-mail on the Exchange server must be
required to have an alphanumeric password that is at least six characters
long.
o Users who want to download attachments to the device must have
encryption enabled on the device, and we must configure the device to
lock after five failed logon attempts.
o Exchange administrators must be able to remotely wipe any mobile
devices.
• All executives and managers must be able to download attachments to their
mobile devices. Other users do not require this functionality.
• The Exchange administrators do not want to be involved every time that a user
gets a new mobile device, but also do not want users to have many mobile devices
associated with their mailbox.
Compliance Requirements
• The corporation reviews its sales and marketing approach every six months. All
members of the Sales and Marketing teams are involved in the reviews. During
the review process, a significant amount of e-mail is sent between team members.
Retaining this e-mail for historical data is important, but these emails should not
be retained in user mailboxes for more than nine months. When the messages are
removed from the user mailboxes, they should be easily accessible to all members
of the Sales and Marketing teams, but should not be accessible to other users in
the organization.
• All messages sent to and from the Legal team must be retained in a secure
location.
• In order to decrease the size of user mailboxes, all messages in user mailboxes
that are more than 12 months old should be deleted and placed in the deleted
items folder. All messages more than six months old in the Deleted Items folder
and Sent Items folder should be deleted. This policy should apply to all users.
• Members of the Executive group should have the option of saving messages in
their mailbox indefinitely.
Madeleine Kelly, CEO

The Board of Directors has just initiated a three-year plan that will result in Trey
Research doubling in size. Some of this growth is going to come from internal growth
by expanding our current businesses, but the plan also calls for a very aggressive
acquisitions strategy. Much of my time for the next three years will be spent identifying
potential acquisitions around the world and negotiating partnerships or takeovers.
Whatever messaging solution you create has to be very flexible and easily expandable.
Karen Toh, Vice President – Europe

My biggest complaint with the current e-mail system is that it is technically obsolete.
One of the groups I manage is our International Sales Team. There are only 50 people
on the team, but they are constantly traveling throughout the world researching business
opportunities. This team makes more money for this company than any other group of
people. They are also very knowledgeable about technology, and they say that our current
system is archaic compared to what other companies are using. This team wants the latest
and greatest in technology. This team needs to be able to access their e-mail from
anywhere in the world, at any time.
Thorsten Scholl, CIO

In the last five years since I became CIO, our e-mail system has changed from being a
useful tool for business to being a critical part of our business processes. Everybody
notices when e-mail is not available. To give you an example, a couple of months ago all
of the e-mail servers in London were unavailable for six hours due to a virus outbreak. A
couple of months before that, one of the servers in Toronto failed, and we couldn’t send
any e-mail to and from Toronto for eight hours while the hardware vendors fixed the
issue. This happened right in the middle of critical business negotiations where we had to
be able to exchange documents rapidly. In both cases, the CEO and every other member
of the executive staff called me on my cell phone while I was at home. The most
important requirement I have for this e-mail system is availability – this system has to be
available always.
Erik Andersen, Vice President – North America
The organization’s Security and Compliance Department is based in Toronto, so they
report to me. The head of that department tells me that the rules for how we do business
and, especially, how we handle confidential or private information are changing all the
time. Just about every country has laws regulating what we can do with private customer
information, but the rules are often not the same. This gets very complicated for an
international organization like ours where some of that information is crossing country
borders. We need a messaging solution that we can use to enforce some of the
compliance requirements.
Gareth Chan, Vice President – Asia

Trey Research is establishing a very important partner relationship with Contoso, Ltd.
Contoso, Ltd., is a high-tech research organization, and we working on some very
confidential projects with them. We need to make sure that no one on the Internet can
view all of the e-mail that we are sending between our company and Contoso, Ltd.
Carol Philips, IT Manager

My biggest concern with this project is the budget. This company has a history of setting
very high expectations for a project and then not providing the budget to do the job right.
So, whatever design you come up with, we are going to have to be very conscious of the
budget.
Jonas Brandel, Network Operations Manager

The Network Operations department is responsible for managing all of the WAN links,
the local LANs, and the firewalls. One of the restrictions that the Security department
placed on us recently is that we cannot allow any unencrypted traffic through our internal
firewalls. We can accept unencrypted traffic into our perimeter network, but not to the
internal network.
Zheng Mu, Network Specialist

I can provide you with a Microsoft Visio® diagram that has all of our WAN connections
and our connections to the Internet. Our network right now is quiet reliable, but we don’t
have much available bandwidth between company locations.
Jens Johannsen, Directory Services Manager

The company just finished upgrading all of the Active Directory® directory service
domain controllers to Windows Server® 2003, Service Pack 1. As part of the upgrade,
we did a thorough review of our whole Active Directory design. We don’t anticipate
making any more changes to the Active Directory configuration for a while.
Sabine Royant, Messaging Services Manager
One of our biggest problems right now is all of the mobile users that we have to support.
We have quite a few users using Outlook® Web Access, and that seems to be working
pretty well, although I do have some security concerns with using Outlook Web Access.
Many of our users work at home, and most of them are using Post Office Protocol
version 3 (POP3) clients. I also have security concerns with these clients, but a bigger
problem for them is functionality. Users complain that they can’t easily access their
calendar information or send meeting requests. And we have more and more people
asking for access to their e-mail through cell phone devices.
Karim Manar, Messaging Specialist

We currently have a mailbox size limit of 50 MB for all users. However, this limit is
much too small, and a lot of people have been able to convince their managers to approve
an increase is size for their mailboxes. At this point, almost half of the people in the
company have an exception on their mailbox limits, most of these limits are at 100 MB.
Andrew Ma, Messaging Specialist

We currently have four administrative groups in our Exchange organization. We have an
administrative group for North America, one for Europe, and one for Asia. The extra
administrative group contains all of the routing groups. In each location, we have a group
of Exchange administrators that have full administrative permissions for their
administrative group, but do not have any permission in the other administrative groups.
In London, we have a group of senior messaging specialists who have full control over all
administrative groups. This group is also the only group that has administrative
permissions over the routing administrative group.
We also have a routing group for each of the big company locations: the routing group in
Toronto is called TorontoRG, and then we have LondonRG and TokyoRG. I can send
you the Visio with all of the Exchange Servers in each location. We have a routing group
connector between TorontoRG and LondonRG and between LondonRG and TokyoRG.
Administrative Requirements
The TreyResearch.net forest is made up of five domains – see TR_Info.vsd.
The TreyResearch.net domain is a dedicated root domain that contains only the
default domain objects.
The EU.TreyResearch.net domain includes all accounts for users, groups, and
computers in the London offices. The user and group accounts for the two
offices are grouped into organizational units (OUs) based on organizational
departments.
The AS.TreyResearch.net domain includes all accounts for users, groups, and
computers in the Tokyo and Chennai offices. All accounts for users, groups, and
computers in the Tokyo office are located in the Tokyo OU, and all accounts for
users, groups, and computers in the Chennai office are located in the Chennai
OU.
The NA.TreyResearch.net domain includes all accounts for users, groups, and
computers in the Toronto office.
The domain controllers for the Adatum.com domain are both located in San
Diego, and the domain includes all accounts for users, groups, and computers in
the San Diego office.
The Trey Research Active Directory and Exchange server configuration is configured
currently as follows:
The Toronto, Tokyo, and London locations are each configured as
administrative groups for Exchange 2000 Server.
A central team of messaging administrators in London belongs to a group named
ExOrgAdmins in the EU.TreyResearch.net domain. This team can modify
settings for the entire Exchange organization. This team also provides third-level
support for all messaging issues in the entire company. This team does not
require access to Active Directory® directory service beyond the permissions
needed to administer the Exchange organization.
Three experienced Active Directory administrators belong to a group named
ADAdmins in the TreyResearch.net domain. These administrators are the only
users that can make changes to the Active Directory configuration, such as
creating new domains or making schema changes.
In each domain, a central team of administrators is able to manage all objects in
the domain. Currently, the Toronto, London, and Tokyo locations have a group
of Exchange administrators that are responsible for managing the Exchange
Servers in their location. These groups are called ExTORAdmins,
ExLON1Admins, and ExTOKAdmins, respectively. These administrators have
full control over the Exchange servers in their offices. They are able to view the
properties for Exchange servers in other locations, but cannot modify any
settings on Exchange servers in other office locations. This group of
administrators should also have full control over all Active Directory objects for
the local domains. This model of delegating Exchange permissions should be
duplicated as Exchange Server 2007 is implemented in these locations and in the
second site in London, and then in San Diego and Chennai.
In each of London, Toronto, and Tokyo, one group of administrators is
responsible for managing user and group accounts. These administrators can
manage, create, and delete user accounts, and can manage user mailboxes and
mail-enabled groups. These administrators should only be able to manage user
accounts in these offices. The administrators belong to the ReLONAdmins,
ReTORAdmins, and the ReTOKAdmins groups, respectively.
As we deploy Exchange Servers are deployed in San Diego and Chennai, a
group of administrators in each office should be able to create and delete user
accounts, and manage user mailboxes and mail-enabled groups only for users in
those offices.
Message Security Requirements

Before any message is sent to a recipient on the Internet, a disclaimer that has
been approved by the Legal department must be added to the message.
Messages sent to Internet recipients from members of the Sales team must have
a different disclaimer added to the message.
Messages with a Company Internal classification must be blocked from being
sent to the Internet. If a user tries to send a message with this classification to
the Internet, they should receive a response indicating they are not allowed to
send messages with this classification to the Internet.
A small group of senior executives and a few board members make up a
Strategic Acquisitions team. These users should be able to send each other
messages that are clearly marked as Acquisitions Confidential, and the messages
should not ever be sent to users who are not on this team.
Trey Research has formed a strategic partnership with Contoso Ltd. The central
office for Contoso Ltd. is located in New York. Because much of the e-mail
send between Trey Research and Contoso contains confidential e-mail, all
messages sent between the organizations must be as secure as possible. When
viewing an e-mail sent between the companies, users should be able to
determine that the message has been secured while in transit.
Trey Research uses a law firm based in Brussels to deal with international
regulations related to their business. All network traffic between the two firms is
sent through a virtual private network. Trey Research needs to ensure that all
messages sent to the law firm in Brussels are sent through the VPN and that all
messages coming from the law firm through the VPN are accepted without spam
filtering.
All users in the Trey Research organization should have the option of sending
secure e-mail to any recipients on the Internet. However, the network
administrators at Trey Research should not have be heavily involved in
managing the certificates required to enable and manage secure e-mail. At the
same time, it is important that the users can implement and use secure e-mail
with as few problems as possible.
Virus and Spam Filtering Requirements

All messages that are sent to Trey Research must be scanned for viruses and
filtered for spam before the messages enter the network.
The messaging administrators at Trey Research have identified two third-party
organizations on the Internet that provide lists of SMTP servers on the Internet
that are known spammers. As well, they have identified one organization that
provides a list of SMTP servers that are known not to be spammers. The
messaging administrators would like to use the lists that these organizations
provide when configuring their anti-spam filters.
Messages sent from partner organizations such as Contoso, Ltd. and the law firm
in Brussels should never be identified as spam.
The messaging administrators are planning on using content filters to block
spam messages, but are concerned that too many false positives will be filtered
if they enable content filtering.
Trey Research has several distribution lists that include over 200 recipients.
Users from the Internet should not be able to send e-mail to any of these
distribution lists.
The messaging administrators at Trey Research are concerned about the number
of messages coming into the organization with spoofed SMTP domain names.
They want to reduce the number of these messages.
Many users are using the Safe Senders list in Outlook to ensure that messages
from the users on the Safe Senders list are not identified as spam. The Exchange
Servers should be able to use this information to ensure that messages from
these users are not blocked before they get to the user mailboxes.
All messages sent between users in the Exchange organization or sent to the
Internet should be scanned for viruses when the message is sent. Messages
should be scanned only once for viruses inside the organization.
All messages being sent to the Internet should be scanned for viruses as the
message leaves the organization.
If users receive a virus from an external messaging system or by downloading
the virus from a Web site, we need to detect the virus as soon as possible to
avoid infecting other systems.
At a minimum, we should update antivirus files on all systems daily, and the
antivirus files on all systems that receive e-mail directly from the Internet should
be updated four times per day. If the antivirus files on any messaging server are
more than two update cycles out of date, the messaging administrators should
receive an alert.
Thorsten Scholl, CIO

For me, high availability is the most important part of your server design. You need to
ensure that if a single server fails, or if a single component on a server fails, the failure
affects as few people as possible. Ideally, a server failure should affect no one. I know
that is a bit unrealistic in some cases, but it is a goal toward which we can aim.
We also need to ensure that your design can be scaled easily to a larger size. I think it is
realistic that all of our office locations will grow by 30% over the next three years. We
will be buying more companies, so prepare for that, as well.
Carol Philips, IT Manager

We have deployed a very good Storage Area Network (SAN) at London, Tokyo, and
Toronto. This SAN has fully redundant systems and provides a very high level of
availability. For the Mailbox servers we are deploying in these offices, the SAN needs to
store the data. As far as I am concerned, the SAN provides enough availability so that we
do not have to do anything additional for these servers. We plan to install one of these
SANs at the new London office, as well.
For the mailbox servers in the other offices, we are going to need to provide redundancy
for the mailbox databases. These servers all use Directly Attached Storage (DAS). Like I
said before, I am worried about the budget, so do whatever you can to provide high
availability without deploying too many additional servers.
Most of our organization’s users are using Microsoft® Office Outlook® 2002 or Outlook
2003. We have started a project to deploy Windows Vista™ with Office 2007, but it will
take at least 18 months to complete. Additionally, we will be deploying new client
computers in our future London and Chennai offices.
Karim Manar, Messaging Specialist

We currently have a mailbox size limit of 50 MB for all users. However, this limit is
much too small and many people have been able to convince their managers to approve a
size increase. Almost half of the people in the company currently have an exception on
their mailbox limits, with the limit at 100 MB. During a meeting last week, the CIO
mentioned that when we get to Exchange Server 2007, we would set up a mailbox size
limit of 150 MB for all users and a 300 MB limit for executives or other exceptional
cases. About 10% of the users will fall into the exceptional category.
I have some concerns with increasing the mailbox size to this limit. We have a good SAN
and we can buy good DAS solutions for the locations where we don’t have a SAN.
However, the back-up system in all of our offices doesn’t have as much capacity as we
would like. In the main offices, we can restore only about 100 GB per hour of data, and
in our branch office we can only restore about 30 GB per hour. According to the service
level agreement (SLA) that we have in place, we are supposed to restore any failed
database within an hour of failure.
From LondonSite2
Tokyo
To
Toronto
TorontoSite
LondonSite
TokyoSite
SanDiegoSite
ChennaiSite
Note: All sites are linked by the

DefaultIPSiteLink site link with no
changes to the default configuration.
External firewall rules:

- Allow SMTP traffic to SMTP gateway server
- Allow HTTPS to internal firewall
External firewall rules: - Allow SMTP traffic from SMTP gateway server
- Allow HTTPS to internal firewall
Internal firewall rules:
Internal firewall rules: - Allow SMTP traffic from SMTP gateway server
- Allow HTTPS to internal front-end to internal bridgehead server External firewall rules:
server - Allow HTTPS to internal front-end server - Allow HTTPS to internal firewall
- Allow SMTP traffic from internal bridgehead
server to SMTP gateway server Internal firewall rules:
- Allow HTTPS to internal front-end
server
To LondonSite2
Tokyo
To
Toronto
TorontoSite
LondonSite
TokyoSite
SanDiegoSite
ChennaiSite
Firewall rules:
- Allow inbound and outbound SMTP
traffic and inbound POP3 traffic
Firewall rules:
- Allow outbound Web traffic only
TreyResearch.net
Adatum.com
EU.TreyResearch.net AS.TreyResearch.net NA.TreyResearch.net
Domains
LON-MSG-BE2 LON-MSG-BE3 LON-MSG-BE4 LON-MSG-BE5
Mailbox server Mailbox server Mailbox server LON-MSG-BE6
Mailbox server Mailbox server
1 Storage Group 1 Storage Group 1 Storage Group 1 Storage Group
5 Mailbox stores 5 Mailbox stores 5 Mailbox stores 1 Storage Group
5 Mailbox stores 5 Mailbox stores
Avg 25 GB per Avg 25 GB per Avg 25 GB per Avg 25 GB per
store store store Avg 25 GB per
store store
LON-MSG-BE1
Mailbox server LON-MSG-PF1
1 Storage Group Public folder server
5 Mailbox stores 1 Storage Group
Avg 25 GB per 1 Public folder store
store 110 GB
Back-end server Back-end server Back-end server

Back-end server Back-end server
Back-end server Back-end server
LON-MSG-BH1
LON-MSG-FE1 Bridgehead
Front-end server server
Front-end server Bridgehead server
London Messaging Detail

LON-MSG-BH1
Bridgehead Server
TOR-MSG-BH1 TOK-MSG-BH1
LON -
LondonRG
10
T
or R
Cost
Cost GC
10
ok RG
Lon-T
C
Bridgehead Server Tor-Tok RGC Bridgehead Server

Cost 10
TorontoRG TokyoRG
Index
designing, 4-3
A for Edge Transport server, configuring, 2-33
Active Directory for public folders, 3-50
forest and domain topology, 1-34 administrative roles, 4-4
global data, 4-3 documenting, 1-37
infrastructure, 1-33 to 1-34 anonymous permissions for public folders, 3-51
infrastructure, impact on deployment, 1-19 anti-spam solutions
inventorying, 7-9 designing, 4-27 to 4-29
messaging systems and, 1-33 determining appropriate level for, 4-27
migrating to, 1-35 false positives, 4-30
recipient data, 4-3 filtering level, increasing, 4-29
server data, 4-3 monitoring, 4-30 to 4-31
Active Directory design owners requirements for, 4-25 to 4-26
defined, 2-3 running before antivirus solutions, 4-27
multiple teams of, 2-4 stamping messages, 4-31
responsibilities of, 2-3 updating, 4-28
working with, 2-4 user feedback on, 4-30
Active Directory domains antivirus solutions
configurations for, 2-8 automating, 4-37
dedicated for Exchange servers, 2-9 cleaning vs. deleting messages, 4-33
defined, 2-8 designing, 4-32 to 4-33
Windows 2000 native mode as minimum level for, Forefront Security for Exchange Server, 4-34
2-9 monitoring, 4-38
Active Directory forests policies and processes, developing, 4-37
boundary of, 2-5 requirements for, 4-25 to 4-26
deploying Exchange Server without, 2-5 stripping e-mail attachments of executables, 4-33
design owners for, 2-4 transport agents, 4-33
domain configuration within, 2-8 user education and, 4-38
Free/Busy information, migrating, 7-28 with Exchange Hosted Services. See Exchange
multiple, 2-6 to 2-7 Hosted Services
multiple trees in, 2-10 archiving e-mail messages. See message archiving
resource, 2-5 to 2-7 attachments, e-mail. See e-mail attachments
single, 1-8, 2-6 Attorney/Client Privilege message classification, 4-14
Active Directory sites authentication, 2-19
as hub sites. See hub sites for Outlook Web Access (OWA), 5-15
Client Access servers and, 2-11 with Domain Security. See Domain Security
configuration, designing, 2-13 Availability service
dedicated for Exchange servers, 2-13 function of, 6-11 to 6-12
design, modifying, 2-13 in coexistence scenarios, 6-12
Exchange Server deployment in, 2-14 to 2-15
Hub Transport servers and, 2-12 B
Mailbox servers and, 2-11, 2-14 back pressure
Unified Messaging servers and, 2-12, 2-15 application of, 3-26
ActiveSync. See Exchange ActiveSync configuring, 3-26
administrative models, 1-44 defined, 3-25
implementing, 4-7 to 4-8 resources monitored by, 3-25
administrative permissions bandwidth, 1-30
delegation, in coexistence scenario, 6-17
I-2 Index
Best Practices Analyzer Tool. See ExBPA (Microsoft Outlook Web Access with, 2-17
Exchange Server Best Practices Analyzer Tool) Outlook Web Access with multiple, 2-18
bridgehead servers, 7-16 ports, locking down, 3-31
business requirements processors, recommended number of, 3-29
and service level agreements (SLAs), 1-8 redirecting users to, 2-18
communication and, 1-14 securing, 3-31 to 3-32
defined, 1-3 when to deploy, 7-15
examples of, 1-3 client environment, profiling, 1-39 to 1-40
exceptions to, by group, 1-14 client permissions for public folders, 3-51
external, 1-3 coexistence of messaging systems
for mailbox size limits, 5-8 administrative permissions, 6-17
for mailbox sizes, 3-5 calendar sharing, 6-12
for public folders, 3-41 to 3-42 implementing, 6-20 to 6-21
identifying, 1-13 to 1-14 message routing configuration, 6-8 to 6-10
importance of, 1-4 offline address books, 6-13 to 6-14
in design phase, possible changes to, 1-14 public folders, 6-15 to 6-16
summarizing, 1-50 scenario for, 6-3
business sponsors, 1-16. See also stakeholders compliance policies, 5-27
constraints. See project constraints
C content conversion, disk I/O impact of, 3-30
content indexing, effect on mailbox database size
Cached Exchange Mode, 3-6
limitations, 3-11
calendars
contract specifying function. See functional
in coexistence scenarios, 6-12 specification
in interoperability scenarios, 6-29 to 6-30 corporate policies, 5-27
CAs (certificate authorities), implementing, 4-22 cross-forests (Active Directory), 2-6 to 2-7
CCR for public folders, 3-44
cell phones. See mobile devices
certificate authorities (CAs). See CAs (certificate
D
authorities) defense-in-depth model for virus protection, 4-32 to
change control processes, 1-46 to 1-47 4-33
classifying e-mail messages, 4-13 to 4-14 delegated permissions, 4-6
Client Access servers implementing, 4-8
Active Directory sites and, 2-11 deploying
client connection proxies, 2-16 Client Access servers, 3-31, 7-14 to 7-15
combining with other server roles on single domain controllers, 2-20
computer, 3-35 to 3-36 domains, 2-8
defined, 7-14 Edge Transport servers, 2-32 to 2-34, 7-20
deploying, 7-14 to 7-15 Exchange Server, centralizing, 2-13
deployment design, 3-31 Exchange Server, in Active Directory sites, 2-14 to
design recommendations, 3-29 to 3-30 2-15
designing, information needed for, 3-28 Hub Transport servers, when upgrading Exchange
disk I/O impact of, 3-30 Server, 7-16 to 7-17
functions performed by, 3-29 Mailbox servers, 7-18 to 7-19
high availability for, 3-32 design change control process, 8-17
IMAP4/POP3 services on, 3-31 design documents
impact on user satisfaction, 3-28 business requirements, 8-4
Internet client access to, 2-16 components of, 8-3
legacy interaction, 7-14 to 7-15 executive summary, 8-3 to 8-4
memory configuration, 3-29 presenting for review, 8-11 to 8-12
mobile device policies, 5-20 reviewers, identifying, 8-8 to 8-9
on internal vs. perimeter network, 3-31 revising, 8-15 to 8-16
target state design, 8-4
Index I-3
design owners for Active Directory. See Active multiple, for availability, 2-36
Directory design owners processors, recommended number of, 3-23
design tradeoffs, 8-5 securing, 2-33 to 2-34
devices, mobile. See mobile devices subscriptions. See edge subscriptions
direct attached storage (DAS), 1-42 when to deploy, 7-20
directory information, migrating to Exchange Server EdgeTransport.exe.config file, 3-26
2007, 7-25 to 7-26 e-mail attachments
disk paging. See paging Outlook Web Access policies for, 5-15
distribution groups stripping of executables, 4-33
expansion servers for, 2-6, 2-28 e-mail clients. See also MAPI clients; also POP3 clients
message size limits on, 5-11 e-mail folders, managed. See managed e-mail folders
DNS (Domain Name System), 1-31 e-mail messages
infrastructure, 1-31 analyzing contents, for security purposes, 4-10
DNS Mail Exchange (MX) records, 1-31 anti-spam stamps, 4-31
domain controllers antivirus stamps, 4-33
configuration of, 1-34 classifications, setting, 4-13 to 4-14
Exchange Server location of, 2-19 encrypting, 4-36
planning deployment of, 2-20 filtering services, 4-36
upgrading to 64-bit hardware, 2-20 recipients, analyzing, 4-11
Domain Name System (DNS). See DNS (Domain Name restricting flow of. See message flow restrictions
System)
securing, with RMS, 4-22 to 4-23
Domain Security
securing, with S/MIME, 4-21 to 4-22
configuring, 4-19 to 4-20
size limits, 5-10 to 5-12
function of, 4-18
storage requirements, effect on mailbox size limits,
performance counters, 4-20 5-8
domains e-mail protocols, 1-40
Active Directory. See Active Directory domains encrypting
defined, 2-8 Client Access server traffic, 3-32
forest root. See forest root domain e-mail messages, 4-36
ESP (Exchange Server Stress and Performance) tool,
E 3-14
ExBPA (Microsoft Exchange Server Best Practices
edge subscriptions
Analyzer Tool), 1-36, 7-8 to 7-9
Exchange 2000 Server, features not supported in
defined, 2-35 Exchange Server 2007, 7-11
designing, 2-36 Exchange ActiveSync
for Hub Transport servers, 2-36 disabling for individual mailboxes, 5-20
for multiple Active Directory sites, 2-36 mobile device management with, 5-19
SMTP send connectors and, 2-41 policy configuration, 5-22
Edge Transport rules, 4-13 policy options, 5-21
Edge Transport servers remote file access through, 5-22
administrative permission configuration, 2-33 usability issues with high-security policies, 5-22
as relay for Internet messages, 7-21 whether to enable, 5-14
as SMTP gateway servers, 4-28 Exchange Hosted Archive, 4-35
attack surface, reducing, 2-33 Exchange Hosted Continuity, 4-35
certificate requests, generating, 4-19 Exchange Hosted Encryption, 4-36
deploying, 2-32 to 2-34, 7-20 Exchange Hosted Filtering, 4-36
firewall rules for, 2-33 Exchange Hosted Services
function provided by, 2-32 defined, 4-35
hard disk configuration, 3-24 integrating with Exchange Server, 4-36
memory requirements, 3-23 services provided by, 4-35 to 4-36
message size limits on, 5-11 Exchange Organization Administrator role, 4-4
I-4 Index
Exchange Recipient Administrator role, 4-4

Exchange Server
G
as 64-bit application, 3-8 GAL Synchronization, 7-26
as site-aware application, 2-11 global address list (GAL) synchronization, 6-27 to 6-28
authentication, 2-19 global catalog servers
coexisting with other messaging systems. See configuration of, 1-34
coexistence; interoperability of messaging upgrading to 64-bit hardware, 2-20
systems global catalogs, planning placement of, 2-20
configuration, documenting, 1-36 global data, 4-3
dedicated Active Directory site for, 2-13 Group Policy configuration, 1-34 to 1-42
dedicated domain for, 2-9
deploying in Active Directory sites, 2-14 to 2-15
H
deployment, centralized, 2-13
high availability
domain controller location, 2-19
for Client Access servers, 3-32
I/O footprint, 3-8
for public folders, 3-44
in multi-tree forest, 2-10
Hosted Services. See Exchange Hosted Services
memory utilization, 3-17
hub sites
message delivery optimization, 2-25
for message routing, 2-27
naming, 5-4
site link costs and, 2-28
on Windows domain controllers, contraindication of,
2-20 when to use, 2-28
unsupported features from previous versions, 7-10 to Hub Transport rules, 4-12 to 4-13
7-11 Hub Transport servers. See also message routing
upgrading to 2007 version. See upgrading to Active Directory sites and, 2-12
Exchange Server 2007 bridgehead servers and, 7-16
versions, coexisting in same organization. See combining with other server roles on single
coexistence of messaging systems computer, 3-35 to 3-36
Exchange Server 2003, features not supported in deploying, when upgrading Exchange Server, 7-16 to
Exchange Server 2007, 7-10 7-17
Exchange Server Administrator role, 4-4 designing, information needed for, 3-22 to 3-23
Exchange Server Stress and Performance (ESP) tool, failure handling, 2-29 to 2-30
3-14 hard disk configuration, 3-24
Exchange View-Only Administrator role, 4-4 journaling agent, disabling, 5-32
load balancing, 2-30
F memory requirements, 3-23
feature constraints, 1-12. See also project constraints message size limits on, 5-11
Fibre Channel, 3-12 multiple, for availability, 2-30
filtering spam. See anti-spam solutions processors, recommended number of, 3-23
firewalls round-robin usage of, 2-24
for Client Access servers, 3-32 virus scanning on, 4-33
rules for Edge Transport servers, 2-33
Forefront Security for Exchange Server, 4-34 I
forest root domain, 2-8 IMAP4 clients, public folder access by, 3-49
forests, Active Directory. See Active Directory forests IMAP4 services
formal service level agreements (SLAs), 1-8 on Client Access servers, 3-31
functional requirements whether to enable, 5-14
defined, 1-5 implementation plan for messaging systems, 8-6 to 8-7
summarizing, 1-50 inbound message flow, 2-39 to 2-40. See also message
use cases, 1-5 routing
functional specification informal service level agreements (SLAs), 1-8
defined, 1-6 information technology (IT) requirements, 1-20
importance of, 1-6 policies and processes, 1-21
Index I-5
infrastructure, defining performance levels. See service dumpster size, 3-6

level agreements (SLAs) naming, 5-5
Internet clients, Client Access server access by, 2-16 recovery storage groups, effect on size limitations,
Internet SCSI (iSCSI), 3-12 3-11
interoperability of messaging systems size limitations, 3-10 to 3-11
calendars, 6-29 to 6-30 size limitations, effect of LCR/CCR on, 3-20
connectors and, 6-31 to 6-32 white space, controlling, 3-6
global address list (GAL) synchronization, 6-27 to Mailbox servers. See also mailboxes
6-28 Active Directory sites and, 2-11, 2-14
message routing, 6-23 to 6-26 backup and restore capacity, effect on mailbox size,
scenario for, 6-4 5-9
combining with other server roles on single
computer, 3-35 to 3-36
J deploying, 7-18 to 7-19
Jetstress tool, 3-14 function provided by, 3-2
journal mailbox LCR for, 3-19 to 3-20
alternative, specifying, 5-34 memory, configuring, 3-17 to 3-18
location of, 5-32 memory, estimating required, 3-17
securing, 5-34 processor cores, recommended number of, 3-16
size management, 5-33 public folder design, 3-43 to 3-44
journaling storage groups, maximum number of, 3-9
corporate requirements and, 5-31 mailboxes, 5-32. See also Mailbox servers; also
disabling on specific Hub Transport servers, 5-32 resource mailboxes
in multiple-site locations, 5-32 business requirements for size, 3-5
policies, designing, 5-31 to 5-32 data, migrating to Exchange Server 2007, 7-27 to
standard vs. premium, 5-31 7-28
for journaling. See journal mailbox
message size limits on, 5-11
L
moving to Exchange Server 2007, 7-18
latency, 1-30
moving, transaction log storage and, 3-10
LCR
retention policies, 5-28
size limit warnings, 5-9
server performance and, 3-19 to 3-20
size limitations, business requirements for, 5-8
LDAP (Lightweight Directory Access Protocol),
size limitations, recommended maximum, 3-11
migrating directory information with, 7-26
size, calculating limitations for, 3-6 to 3-7
legacy servers, integrating. See upgrading to Exchange
Server 2007 size, calculating maximum, 5-9
legal requirements for messaging policies. See size, effect of POP3 clients vs. MAPI clients, 3-7
compliance policies size, effect on Cached Exchange Mode, 3-6
load balancing size, effect on cost, 3-5
for Client Access servers, 3-32 size, managing with content settings, 5-29
with Hub Transport servers, 2-30, 2-36 managed e-mail folders
LoadGen, 3-13 configuring, 5-29
Lotus Domino, migrating to Exchange Server 2007, policies for, 5-29
7-29 to 7-30 MAPI clients, 3-7
LUNs (logical unit numbers), impact on disk I/O, 3-19 memory
Exchange Server 2007 utilization, 3-17
M for Client Access servers, 3-29
for Edge Transport servers, 3-23
Mail Exchange (MX) records, 1-31
for Hub Transport servers, 3-23
mailbox databases
for servers with multiple server roles, 3-35
backup design, effect on size limitations, 3-10
for Unified Messaging servers, 3-34
content indexing, effect on size limitations, 3-11
storage group effect on, 3-17 to 3-18
I-6 Index
message archiving, 4-35 Microsoft Exchange Hosted Services. See Exchange

defined, 5-35 Hosted Services
implementing, 5-35 to 5-36 Microsoft Exchange Load Generator (LoadGen), 3-13
message flow restrictions, 4-12 to 4-13 Microsoft Exchange Server Best Practices Analyzer
message journaling. See journaling Tool. See ExBPA (Microsoft Exchange Server Best
Practices Analyzer Tool)
message routing. See also Hub Transport servers
Microsoft Exchange Server Jetstress tool, 3-14
configuration, default, 2-24 to 2-25
Microsoft Outlook. See Outlook
configuring, 7-21
Microsoft Transporter Suite for Lotus Domino, 6-32,
costs, configuring, 2-27
7-29 to 7-30
default topology, modifying, 2-28
migrating to Exchange Server 2007, 7-4. See also
expansion servers for distribution groups, 2-6, 2-28 upgrading to Exchange Server 2007
failure, planning for, 2-29 to 2-30 from Lotus Domino, 7-29 to 7-30
hub sites for, 2-27 mailbox data, 7-27 to 7-28
in coexistence scenarios, 6-8 to 6-10 mobile devices
in interoperability scenarios, 6-23 to 6-26 managing, 5-20
inbound flow, designing, 2-39 to 2-40 policy requirements, 5-19
lowest-cost calculation, 2-25 remote wipe policies, 5-23 to 5-24
migrating to Exchange Server 2007, 7-23 to 7-24 restoring after remote wiping, 5-24
outbound flow, designing, 2-37 to 2-38 securing, with Exchange ActiveSync, 5-19
path determination of, 2-25 to 2-26 monitoring
routing tables for, 2-26 anti-spam solutions, 4-30 to 4-31
single paths vs. multiple paths, 2-43 antivirus solutions, 4-38
to network perimeter, 2-41 to 2-43
transport rules for, 4-12 to 4-14
with multiple recipients in different sites, 2-25
N
messaging infrastructure. See infrastructure name resolution services, 1-31. See DNS (Domain
Name System)
messaging protocols. See e-mail protocols
naming
messaging records management, 5-28
databases, 5-5
messaging statistics, 1-40 to 1-41 Exchange Servers, 5-4
messaging systems
policies, 5-5
access to during network outages, 4-35
public folders, 5-5
Active Directory and. See Active Directory
resource mailboxes, 5-5
business requirements. See business requirements
SMTP domains, 5-4
client environment. See client environment
storage groups, 5-5
design documents. See design documents
network attached storage (NAS), 1-42
design tradeoffs, 8-5
network infrastructure
directory information, migrating to Exchange Server
2007, 7-25 to 7-26 deployment impact, 1-19
functional requirements. See functional requirements elements of, 1-29 to 1-30
implementation plan, 8-6 to 8-7 network outages, messaging service access during, 4-35
integrating with existing, 1-38 network perimeter, routing messages to, 2-41 to 2-43
multiple in same organization. See coexistence of NNTP clients, public folder access by, 3-49
messaging systems; interoperability of messaging nonfunctional specifications, 1-6
systems
review process, 8-11 to 8-12 O
rollback plan, 8-7
offline address books in coexistence scenarios, 6-13 to
storage, 1-42
6-14
training plan, 8-7
organizational needs. See business requirements
user requirements. See user requirements
outbound message flow, 2-37 to 2-38. See also message
Microsoft Antigen for Exchange. See Forefront Security routing
for Exchange Server
SMTP send connectors, configuring, 2-38
Index I-7
Outlook Post Office Protocol version 3 (POP3) clients. See

Cached Exchange Mode, 3-6 POP3 clients
user usage profiles, 3-16 PrepareAD command, 7-13
Outlook Anywhere PrepareLegacyExchangePermissions command, 7-12
public folders and, 3-48 processors
vs. Outlook Web Access (OWA), 5-14 to 5-15 configuration, recommended, 3-16
whether to enable, 5-13 for Client Access servers, recommended number of,
Outlook Web Access (OWA) 3-29
authentication, configuring, 5-15 for Edge Transport servers, recommended number
of, 3-23
designing, 2-16
for Hub Transport servers, recommended number of,
e-mail attachment policies, 5-15
3-23
policies for, 5-15
for Mailbox servers, recommended number of, 3-16
proxy, enabling between multiple sites, 2-17
for servers with multiple server roles, recommended
public folder access, 7-15 number of, 3-35
security concerns, 5-14 for Unified Messaging servers, recommended
SSL, requiring, 5-15 number of, 3-34
URL for, 7-15 project constraints
vs. Outlook Anywhere, 5-14 to 5-15 defined, 1-11
whether to enable, 5-13 feature, 1-12
with Client Access server, 2-17 negotiating, 1-12
with multiple Client Access servers, 2-18 resource, 1-11
schedule, 1-11
P project stakeholders. See stakeholders
protocol logging, disk I/O impact of, 3-30
paging, disk I/O impact of, 3-30
protocols. See e-mail protocols
parameters, project. See project
public folders
PDAs. See mobile devices
administrative permissions, 3-50
perimeter networks, deploying Client Access servers
on, 3-31 business requirements, 3-41 to 3-42
permissions client access, planning for, 3-48 to 3-49
administrative. See administrative permissions client permissions, 3-51
anonymous. See anonymous permissions dedicated servers for, 3-44
client. See client permissions for non-MAPI users, 3-48 to 3-49
delegated, 4-6 hierarchy, 3-45
delegated, implementing, 4-8 hierarchy, planning, 3-49
split, 4-5 high availability for, 3-44
split, implementing, 4-7 in coexistence scenarios, 6-15 to 6-16
unified, 4-5 in Outlook Web Access (OWA), 7-15
unified, implementing, 4-7 LCR/CCR for, 3-44
phones. See mobile devices Mailbox server design for, 3-43 to 3-44
physical network infrastructure. See network mail-enabling, 3-49
infrastructure message size limits on, 5-11
policies. See also specific policies moving to Exchange Server 2007, 7-18
exceptions to, approval process for, 5-16 to 5-17 naming, 5-5
naming, 5-5 referral, 3-45 to 3-47
POP3 clients, effect on mailbox size, 3-7 removing, when upgrading, 7-19
POP3 services replication, 3-44 to 3-47
on Client Access servers, 3-31 scripts for, 3-49
whether to enable, 5-14 public key distribution, 4-21
ports
Client Access server configuration, 3-31 Q
Edge Transport server configuration, 2-33 queue at point of failure, 2-29
I-8 Index
journal mailboxes, 5-34

R mobile devices, with Exchange ActiveSync, 5-19
RAID, 3-13 SMTP connectors, 4-16 to 4-17
recipient data, 4-3 security. See also Domain Security
recovery storage groups, 3-11 analyzing, 4-11
regulatory requirements for messaging policies. See security requirements
compliance policies
high-level, impact on usability, 5-22
remotely wiping mobile devices, 5-23 to 5-24
identifying, 1-22 to 1-23
replication of public folders, 3-44 to 3-47
negotiating, 1-23
requirements document
security risks
components of, 1-49 to 1-50
identifying, 1-22 to 1-23
defined, 1-48
of Outlook Web Access (OWA), 5-14
resource constraints, 1-11. See also project constraints
Send connectors. See SMTP send connectors
resource forests, 2-5 to 2-7
Serial ATA (SATA) disks, 3-12
resource mailboxes
Serial Attached SCSI (SAS), 3-12
acceptance policy, configuring, 5-7
server equipment, deployment impact, 1-18
auto-accept settings, 5-6 to 5-7
server roles. See also individual roles
booking policy, designing, 5-7
combining on single computer, 3-35 to 3-36
service level agreements (SLAs)
naming, 5-5
business requirements and, 1-8
recurring meetings, allowing, 5-6
defined, 1-7
resource monitoring. See back pressure
documenting, 1-47
retention policies, 5-28
formal vs. informal, 1-8
revising messaging system design, 8-15 to 8-16
negotiating, 1-8
risk management processes, 1-47
performance categories, 1-7
RMS (Windows Rights Management Services)
types of, 1-8
defined, 4-22
Service locator (SRV) records, 2-19
securing e-mail messages with, 4-22 to 4-23
site-aware applications, 2-11
roles
sites, Active Directory. See Active Directory sites
defined, 3-51
64-bit code, 1-42
64-bit hardware
rollback plan, 8-7
Exchange Server as, 3-8
routing groups
upgrading domain controllers to, 2-20
documenting configuration, 1-37
SLAs. See service level agreements (SLAs)
number of, reporting, 7-9
SMTP domains, naming, 5-4
routing messages. See message routing
SMTP e-mail
namespaces, documenting, 1-37
S security risks, 1-23, 4-10
S/MIME SMTP gateway servers
certificate installation, 4-21 to 4-22 Edge Transport servers as, 4-28
securing e-mail messages with, 4-21 to 4-22 integrating with Exchange Hosted Services, 4-36
safelist aggregation, 4-28. See also anti-spam solutions spam prevention at, 4-27
schedule constraints, 1-11. See also project constraints SMTP receive connectors
Schema Master configuration, 1-34 authentication, configuring, 4-15
scripts for public folder management, 3-49 configuring for inbound message flow, 2-40
Secure/Multipurpose Internet Mail Extensions SMTP send connectors
(S/MIME). See S/MIME authentication, configuring, 4-15
securing configuring for outbound message flow, 2-38
Client Access servers, 3-31 to 3-32 connector scope, configuring, 2-43
Edge Transport servers, 2-33 to 2-34 edge subscriptions and, 2-41
e-mail messages, with RMS, 4-22 to 4-23 spam, preventing. See anti-spam solutions
e-mail messages, with S/MIME, 4-21 to 4-22
Index I-9
split permissions, 4-5

implementing, 4-7
U
sponsors. See business sponsors Unified Messaging servers
SRV records. See Service locator (SRV) records Active Directory sites and, 2-12, 2-15
stakeholders concurrent calls supported by, 3-34
determining which to consult, 1-17 configuration, designing, 3-34
identifying, 8-8 to 8-9 designing, information needed for, 3-34
interest in project, 1-16 features of, 3-33
types of, 1-17 memory configuration, 3-34
statistics, profiling, 1-40 to 1-41 processors, recommended number of, 3-34
storage architecture design, 3-12 unified permissions, 4-5
evaluating performance of, 3-13 to 3-14 implementing, 4-7
storage area networks (SANs), deployment impact, 1-19 upgrading to Exchange Server 2007
storage groups defined, 7-3
designing, 3-9 to 3-10 readiness for, checking, 7-8 to 7-9
for recovery. See recovery storage groups scope of, planning, 7-6
maximum number of, 3-9 single-phase vs. multiphase, 7-5
memory requirements and, 3-17 to 3-18 use cases, 1-5
naming, 5-5 user accounts, 1-44
single databases in, 3-9 user requirements
transaction log logical unit numbers (LUNs), 3-9 identifying, 1-24 to 1-25
subscriptions (Edge Transport servers). See edge importance of, 1-25
subscriptions
V
T viruses, preventing. See antivirus solutions
technological requirements, 1-18 to 1-19. See also vision statement, 1-49
business requirements; also functional requirements volume mount points for logical unit number (LUN)
test lab representation, 3-9
designing, 3-56
for pre-production, 3-57 to 3-58 W
purpose of, 3-55
WebReady Document Viewing, 5-15
TLS (Transport Layer Security)
Windows Clustering integration, 1-43
certificate request, generating, 4-19
Windows Rights Management Services (RMS). See
with mutual authentication, 4-18 RMS (Windows Rights Management Services)
topology maps, 1-29
tradeoffs in messaging system design, 8-5
training plan for messaging systems, 8-7
transaction logs
backup design, 3-9 to 3-10
logical unit numbers (LUNs), 3-9
storage, planning, 3-9 to 3-10
transition upgrades, 7-3. See also upgrading to
Transport Layer Security (TLS). See TLS (Transport
Layer Security)
transport rules, 4-12 to 4-14
transport servers. See Edge Transport servers; Hub
Transport servers
troubleshooting processes, 1-45

(MOC 5053A) Designing A Messaging Infrastructure Using Microsoft Exchange Server 2007

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

(MOC 5053A) Designing A Messaging Infrastructure Using Microsoft Exchange Server 2007

Uploaded by

Copyright:

Available Formats

5053A

All other trademarks are property of their respective owners.

Product Number: 5053A

Part Number: X13-66119

Module 1: Gathering Requirements for a Messaging Infrastructure

Module 2: Designing Active Directory and Message Routing

Module 3: Designing Exchange Servers

Module 4: Designing Security for a Messaging Environment

Module 5: Designing Messaging Policies

Module 6: Designing Coexistence and Interoperability Strategies with Other

Module 7: Designing an Exchange Server 2007 Upgrade Strategy

Module 8: Obtaining Approval for a Messaging Infrastructure Design

© 2007 Microsoft Corporation. All rights reserved.

All other trademarks are property of their respective owners.

The following materials are included with your kit:

To provide additional comments or feedback on the course, send e-mail to

Microsoft Learning Product Types

Microsoft Learning offers the following instructor-led products. Each is specific to a

• iWorker courses or Information Worker Courses are scenario-based courseware

Microsoft Learning Product Types (continued)

Microsoft Learning develops Official Microsoft Learning Product (OMLP) courseware

Additional Recommended Learning Products

Microsoft Learning Information

Microsoft Certification Program

Microsoft Learning offers a variety of certification credentials for developers and IT

Related Certification Exams

MCSA on Microsoft Windows Server™ 2003

Additional Information: See the Microsoft Learning Web site at

Acquiring the Skills Tested by an MCP Exam

About This Course

This course requires that you meet the following prerequisites:

• Must already know how to use:

Process for Designing a Messaging Infrastructure

Module 1, “Gathering Requirements for a Messaging Infrastructure,” discusses how to

Course Outline (continued)

Module 5, “Designing Messaging Policies,” discusses how to design messaging policies

Virtual Machine Environment

Virtual Machine Configuration

Course Hardware Level

Demonstration: Using Microsoft Virtual Server

Virtual Server Demonstration

© 2007 Microsoft Corporation. All rights reserved.

All other trademarks are property of their respective owners.

Lesson 1: Gathering Business Requirements

What Are Business Requirements?

Organizations invest in technology to solve business problems or to provide new

Importance of Business Requirements

What Are Functional Requirements?

Functional requirements define a technology’s expected behavior by describing a

Note: In addition to functional specifications, every design has nonfunctional

Defining Service Level Agreements

Service level agreements (SLAs) are understandings reached between an organization

Discussion: Identifying Regulatory and Organizational

E-mail is a primary method of communication in many organizations and typically is

• Sarbanes-Oxley Act of 2002 (SOX)

• Canada: The Personal Information Protection and Electronic Documents Act

Q What additional compliance requirements does your organization have?

Identifying Project Constraints

Types of Project Constraints

Negotiating Project Constraints

Gathering Business Requirements

Identifying Business Requirements

Considerations for Identifying Business Requirements