O F F I C I A L

M I CRO S O F T

L EA RN I N G

PRO DU C T

10233B
Designing and Deploying Messaging
Solutions with Microsoft Exchange
Server 2010 SP2

ii

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2

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.
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.
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
may be 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.
2012 Microsoft Corporation. All rights reserved.
Microsoft and the trademarks listed at http://www.microsoft.com/about/legal/en/us/IntellectualProperty
/Trademarks/EN-US.aspx are trademarks of the Microsoft group of companies. All other trademarks are
property of their respective owners

Product Number: 10233B

Released: 03/2012

MICROSOFT LICENSE TERMS

OFFICIAL MICROSOFT LEARNING PRODUCTS
MICROSOFT OFFICIAL COURSE Pre-Release and Final Release Versions

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. These license
terms also apply to any updates, supplements, internet based services and support services for the Licensed
Content, unless other terms accompany those items. If so, those terms apply.
BY DOWNLOADING OR USING THE LICENSED CONTENT, YOU ACCEPT THESE TERMS. IF YOU DO NOT ACCEPT
THEM, DO NOT DOWNLOAD OR USE THE LICENSED CONTENT.
If you comply with these license terms, you have the rights below.
1.

DEFINITIONS.
a. Authorized Learning Center means a Microsoft Learning Competency Member, Microsoft IT Academy
Program Member, or such other entity as Microsoft may designate from time to time.
b. Authorized Training Session means the Microsoft-authorized instructor-led training class using only
MOC Courses that are conducted by a MCT at or through an Authorized Learning Center.
c. Classroom Device means one (1) dedicated, secure computer that you own or control that meets or
exceeds the hardware level specified for the particular MOC Course located at your training facilities or
primary business location.
d. End User means an individual who is (i) duly enrolled for an Authorized Training Session or Private
Training Session, (ii) an employee of a MPN Member, or (iii) a Microsoft full-time employee.
e. Licensed Content means the MOC Course and any other content accompanying this agreement.
Licensed Content may include (i) Trainer Content, (ii) software, and (iii) associated media.
f.

Microsoft Certified Trainer or MCT means an individual who is (i) engaged to teach a training session
to End Users on behalf of an Authorized Learning Center or MPN Member, (ii) currently certified as a
Microsoft Certified Trainer under the Microsoft Certification Program, and (iii) holds a Microsoft
Certification in the technology that is the subject of the training session.

g. Microsoft IT Academy Member means a current, active member of the Microsoft IT Academy
Program.
h. Microsoft Learning Competency Member means a Microsoft Partner Network Program Member in
good standing that currently holds the Learning Competency status.
i.

Microsoft Official Course or MOC Course means the Official Microsoft Learning Product instructorled courseware that educates IT professionals or developers on Microsoft technologies.

j.

Microsoft Partner Network Member or MPN Member means a silver or gold-level Microsoft Partner
Network program member in good standing.

k. Personal Device means one (1) device, workstation or other digital electronic device that you
personally own or control that meets or exceeds the hardware level specified for the particular MOC
Course.
l. Private Training Session means the instructor-led training classes provided by MPN Members for
corporate customers to teach a predefined learning objective. These classes are not advertised or
promoted to the general public and class attendance is restricted to individuals employed by or
contracted by the corporate customer.
m. Trainer Content means the trainer version of the MOC Course and additional content designated
solely for trainers to use to teach a training session using a MOC Course. Trainer Content may include
Microsoft PowerPoint presentations, instructor notes, lab setup guide, demonstration guides, beta
feedback form and trainer preparation guide for the MOC Course. To clarify, Trainer Content does not
include virtual hard disks or virtual machines.
2.

INSTALLATION AND USE RIGHTS. The Licensed Content is licensed not sold. The Licensed Content is
licensed on a one copy per user basis, such that you must acquire a license for each individual that
accesses or uses the Licensed Content.
2.1

Below are four separate sets of installation and use rights. Only one set of rights apply to you.

a. If you are a Authorized Learning Center:

i. If the Licensed Content is in digital format for each license you acquire you may either:
1. install one (1) copy of the Licensed Content in the form provided to you on a dedicated, secure
server located on your premises where the Authorized Training Session is held for access and
use by one (1) End User attending the Authorized Training Session, or by one (1) MCT teaching
the Authorized Training Session, or
2. install one (1) copy of the Licensed Content in the form provided to you on one (1) Classroom
Device for access and use by one (1) End User attending the Authorized Training Session, or by
one (1) MCT teaching the Authorized Training Session.
ii. You agree that:
1. you will acquire a license for each End User and MCT that accesses the Licensed Content,
2. each End User and MCT will be presented with a copy of this agreement and each individual
will agree that their use of the Licensed Content will be subject to these license terms prior to
their accessing the Licensed Content. Each individual will be required to denote their
acceptance of the EULA in a manner that is enforceable under local law prior to their accessing
the Licensed Content,
3. for all Authorized Training Sessions, you will only use qualified MCTs who hold the applicable
competency to teach the particular MOC Course that is the subject of the training session,
4. you will not alter or remove any copyright or other protective notices contained in the
Licensed Content,

5. you will remove and irretrievably delete all Licensed Content from all Classroom Devices and
servers at the end of the Authorized Training Session,
6. you will only provide access to the Licensed Content to End Users and MCTs,
7. you will only provide access to the Trainer Content to MCTs, and
8. any Licensed Content installed for use during a training session will be done in accordance
with the applicable classroom set-up guide.
b. If you are a MPN Member.
i. If the Licensed Content is in digital format for each license you acquire you may either:
1. install one (1) copy of the Licensed Content in the form provided to you on (A) one (1)
Classroom Device, or (B) one (1) dedicated, secure server located at your premises where
the training session is held for use by one (1) of your employees attending a training session
provided by you, or by one (1) MCT that is teaching the training session, or
2. install one (1) copy of the Licensed Content in the form provided to you on one (1)
Classroom Device for use by one (1) End User attending a Private Training Session, or one (1)
MCT that is teaching the Private Training Session.
ii. You agree that:
1. you will acquire a license for each End User and MCT that accesses the Licensed Content,
2. each End User and MCT will be presented with a copy of this agreement and each individual
will agree that their use of the Licensed Content will be subject to these license terms prior
to their accessing the Licensed Content. Each individual will be required to denote their
acceptance of the EULA in a manner that is enforceable under local law prior to their
accessing the Licensed Content,
3. for all training sessions, you will only use qualified MCTs who hold the applicable
competency to teach the particular MOC Course that is the subject of the training session,
4. you will not alter or remove any copyright or other protective notices contained in the
Licensed Content,
5. you will remove and irretrievably delete all Licensed Content from all Classroom Devices and
servers at the end of each training session,
6. you will only provide access to the Licensed Content to End Users and MCTs,
7. you will only provide access to the Trainer Content to MCTs, and
8. any Licensed Content installed for use during a training session will be done in accordance
with the applicable classroom set-up guide.
c. If you are an End User:
You may use the Licensed Content solely for your personal training use. If the Licensed Content is in
digital format, for each license you acquire you may (i) install one (1) copy of the Licensed Content in
the form provided to you on one (1) Personal Device and install another copy on another Personal
Device as a backup copy, which may be used only to reinstall the Licensed Content; or (ii) print one (1)
copy of the Licensed Content. You may not install or use a copy of the Licensed Content on a device
you do not own or control.

d. If you are a MCT.

i. For each license you acquire, you may use the Licensed Content solely to prepare and deliver an
Authorized Training Session or Private Training Session. For each license you acquire, you may
install and use one (1) copy of the Licensed Content in the form provided to you on one (1) Personal
Device and install one (1) additional copy on another Personal Device as a backup copy, which may
be used only to reinstall the Licensed Content. You may not install or use a copy of the Licensed
Content on a device you do not own or control.
ii.

Use of Instructional Components in Trainer Content. You may customize, in accordance with the
most recent version of the MCT Agreement, those portions of the Trainer Content that are logically
associated with instruction of a training session. If you elect to exercise the foregoing rights, you
agree: (a) that any of these customizations will only be used for providing a training session, (b) any
customizations will comply with the terms and conditions for Modified Training Sessions and
Supplemental Materials in the most recent version of the MCT agreement and with this agreement.
For clarity, any use of customize refers only to changing the order of slides and content, and/or
not using all the slides or content, it does not mean changing or modifying any slide or content.

2.2 Separation of Components. The Licensed Content components are licensed as a single unit and you
may not separate the components and install them on different devices.
2.3 Reproduction/Redistribution Licensed Content. Except as expressly provided in the applicable
installation and use rights above, you may not reproduce or distribute the Licensed Content or any portion
thereof (including any permitted modifications) to any third parties without the express written permission
of Microsoft.
2.4 Third Party Programs. The Licensed Content may contain third party programs or services. These
license terms will apply to your use of those third party programs or services, unless other terms accompany
those programs and services.
2.5 Additional Terms. Some Licensed Content may contain components with additional terms,
conditions, and licenses regarding its use. Any non-conflicting terms in those conditions and licenses also
apply to that respective component and supplements the terms described in this Agreement.
3.

PRE-RELEASE VERSIONS. If the Licensed Content is a pre-release (beta) version, in addition to the other
provisions in this agreement, then these terms also apply:
a. Pre-Release Licensed Content. This Licensed Content is a pre-release version. It may not contain the
same information and/or work the way a final version of the Licensed Content will. We may change it
for the final version. We also may not release a final version. Microsoft is under no obligation to
provide you with any further content, including the final release version of the Licensed Content.
b. Feedback. If you agree to give feedback about the Licensed Content to Microsoft, either directly or
through its third party designee, you give to Microsoft without charge, the right to use, share and
commercialize your feedback in any way and for any purpose. You also give to third parties, without
charge, any patent rights needed for their products, technologies and services to use or interface with
any specific parts of a Microsoft software, Microsoft product, or service that includes the feedback. You
will not give feedback that is subject to a license that requires Microsoft to license its software,
technologies, or products to third parties because we include your feedback in them. These rights

survive this agreement.

c. Term. If you are an Authorized Training Center, MCT or MPN, you agree to cease using all copies of the
beta version of the Licensed Content upon (i) the date which Microsoft informs you is the end date for
using the beta version, or (ii) sixty (60) days after the commercial release of the Licensed Content,
whichever is earliest (beta term). Upon expiration or termination of the beta term, you will
irretrievably delete and destroy all copies of same in the possession or under your control.
4.

INTERNET-BASED SERVICES. Microsoft may provide Internet-based services with the Licensed Content,
which may change or be canceled at any time.
a. Consent for Internet-Based Services. The Licensed Content may connect to computer systems over an
Internet-based wireless network. In some cases, you will not receive a separate notice when they
connect. Using the Licensed Content operates as your consent to the transmission of standard device
information (including but not limited to technical information about your device, system and
application software, and peripherals) for internet-based services.
b. Misuse of Internet-based Services. You may not use any Internet-based service in any way that could
harm it or impair anyone elses use of it. You may not use the service to try to gain unauthorized access
to any service, data, account or network by any means.

5.

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
allows you to use it in certain ways. Except as expressly permitted in this agreement, you may not:

install more copies of the Licensed Content on devices than the number of licenses you acquired;

allow more individuals to access the Licensed Content than the number of licenses you acquired;

publicly display, or make the Licensed Content available for others to access or use;

install, sell, publish, transmit, encumber, pledge, lend, copy, adapt, link to, post, rent, lease or lend,
make available or distribute the Licensed Content to any third party, except as expressly permitted
by this Agreement.

reverse engineer, decompile, remove or otherwise thwart any protections or disassemble the
Licensed Content except and only to the extent that applicable law expressly permits, despite this
limitation;

access or use any Licensed Content for which you are not providing a training session to End Users
using the Licensed Content;

access or use any Licensed Content that you have not been authorized by Microsoft to access and
use; or

transfer the Licensed Content, in whole or in part, or assign this agreement to any third party.

6.

RESERVATION OF RIGHTS AND OWNERSHIP. Microsoft reserves all rights not expressly granted to you in
this agreement. The Licensed Content is protected by copyright and other intellectual property laws and
treaties. Microsoft or its suppliers own the title, copyright, and other intellectual property rights in the
Licensed Content. You may not remove or obscure any copyright, trademark or patent notices that
appear on the Licensed Content or any components thereof, as delivered to you.

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.

LIMITATIONS ON SALE, RENTAL, ETC. AND CERTAIN ASSIGNMENTS. You may not sell, rent, lease, lend or
sublicense the Licensed Content or any portion thereof, or transfer or assign this agreement.

9.

SUPPORT SERVICES. Because the Licensed Content is as is, we may not provide support services for it.

10.

TERMINATION. Without prejudice to any other rights, Microsoft may terminate this agreement if you fail
to comply with the terms and conditions of this agreement. Upon any termination of this agreement, you
agree to immediately stop all use of and to irretrievable delete and destroy all copies of the Licensed
Content in your possession or under your control.

11.

LINKS TO THIRD PARTY SITES. You may link to third party sites through the use of the Licensed Content.
The third party sites are not under the control of Microsoft, and Microsoft is not responsible for the
contents of any third party sites, any links contained in third party sites, or any changes or updates to third
party sites. Microsoft is not responsible for webcasting or any other form of transmission received from
any third party sites. Microsoft is providing these links to third party sites to you only as a convenience,
and the inclusion of any link does not imply an endorsement by Microsoft of the third party site.

12.

ENTIRE AGREEMENT. This agreement, and the terms for supplements, updates and support services are
the entire agreement for the Licensed Content.

13.

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.

14.

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.

15.

DISCLAIMER OF WARRANTY. THE LICENSED CONTENT IS LICENSED "AS-IS," "WITH ALL FAULTS," AND "AS
AVAILABLE." YOU BEAR THE RISK OF USING IT. MICROSOFT CORPORATION AND ITS RESPECTIVE
AFFILIATES GIVE NO EXPRESS WARRANTIES, GUARANTEES, OR CONDITIONS UNDER OR IN RELATION TO
THE LICENSED CONTENT. YOU MAY HAVE ADDITIONAL CONSUMER RIGHTS UNDER YOUR LOCAL LAWS
WHICH THIS AGREEMENT CANNOT CHANGE. TO THE EXTENT PERMITTED UNDER YOUR LOCAL LAWS,
MICROSOFT CORPORATION AND ITS RESPECTIVE AFFILIATES EXCLUDE ANY IMPLIED WARRANTIES OR
CONDITIONS, INCLUDING THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT.

16.

LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. TO THE EXTENT NOT PROHIBITED BY
LAW, YOU CAN RECOVER FROM MICROSOFT CORPORATION AND ITS SUPPLIERS ONLY DIRECT
DAMAGES UP TO USD$5.00. YOU AGREE NOT TO SEEK TO RECOVER ANY OTHER DAMAGES, INCLUDING
CONSEQUENTIAL, LOST PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES FROM MICROSOFT
CORPORATION AND ITS RESPECTIVE SUPPLIERS.
This limitation applies to
o
anything related to the Licensed Content, services made available through the Licensed Content, or
content (including code) on third party Internet sites or third-party programs; and
o
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 Qubec, Canada, certaines des clauses dans ce
contrat sont fournies ci-dessous en franais.
EXONRATION 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 pril. Microsoft naccorde aucune autre garantie
expresse. Vous pouvez bnficier 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, dadquation un usage particulier et dabsence de contrefaon sont exclues.
LIMITATION DES DOMMAGES-INTRTS 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 prtendre aucune indemnisation pour les autres dommages, y
compris les dommages spciaux, indirects ou accessoires et pertes de bnfices.
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 rclamations au titre de violation de contrat ou de garantie, ou au titre de responsabilit
stricte, de ngligence ou dune autre faute dans la limite autorise par la loi en vigueur.
Elle sapplique galement, mme si Microsoft connaissait ou devrait connatre lventualit dun tel dommage.
Si votre pays nautorise pas lexclusion ou la limitation de responsabilit pour les dommages indirects,
accessoires ou de quelque nature que ce soit, il se peut que la limitation ou lexclusion ci-dessus ne sappliquera
pas votre gard.
EFFET JURIDIQUE. Le prsent contrat dcrit certains droits juridiques. Vous pourriez avoir dautres droits prvus
par les lois de votre pays. Le prsent contrat ne modifie pas les droits que vous confrent les lois de votre pays
si celles-ci ne le permettent pas.
Revised December 2011

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2

xi

Acknowledgments
Microsoft Learning would like to acknowledge and thank the following for their contribution towards
developing this title. Their effort at various stages in the development has ensured that you have a good
classroom experience.

Stan Reimer Content Developer

Stan Reimer is president of S. R. Technical Services Inc, and he works as a consultant, trainer and author.
Stan has extensive experience consulting on Active Directory and Exchange Server deployments for some
of the largest companies in Canada. Stan is the lead author for two Active Directory books for Microsoft
Press, and is currently working on an Exchange Server 2010 Best Practices book, also for Microsoft Press.
For the last six years, Stan has been writing courseware for Microsoft Learning, specializing in Active
Directory and Exchange Server courses. Stan has been an MCT for 11 years.

Byron Wright Content Developer

Byron Wright is a partner in a consulting firm, where he performs network consulting, computer systems
implementation, and technical training. Byron is also a sessional instructor for the Asper School of
Business at the University of Manitoba, teaching management information systems and networking. Byron
has authored and co-authored a number of books on Windows servers, Windows Vista, and Exchange
Server, including the Windows Server 2008 Active Directory Resource Kit.

Andrew J. Warren Content Developer

Andrew Warren (MCSE, MCITP, and MCT) has more than 22 years of experience in the IT industry, many of
which have been spent in writing and teaching. He has been involved as the subject matter expert (SME)
for the 6430B course for Windows Server 2008 and the technical lead on a number of other courses. He
also has been involved in TechNet sessions on Microsoft Exchange Server 2007. Based in the United
Kingdom, he runs his own IT training and education consultancy.

Siegfried Jagott Technical Reviewer

Siegfried Jagott is a Principal Consultant and Team Lead for the Messaging and Collaboration team in
Siemens IT Solutions located in Munich, Germany. He has planned, designed, and implemented some of
the worlds largest Windows and Exchange Server infrastructures for international customers. Additionally,
he hosted a monthly column for Windows IT Magazine called Exchange & Outlook UPDATE: Outlook
Perspectives. He writes for international magazines and lectures about Windows and Exchange Serverrelated topics. He received an MBA from Open University in England, and is a Microsoft Certified Systems
Engineer (MCSE) since 1997.

xii

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2

Contents
Module 1: Introduction to Designing a Microsoft Exchange Server 2010 Deployment
Lesson 1: Gathering Business Requirements
Lesson 2: Identifying Additional Requirements
Lesson 3: Introduction to Service Level Management
Lesson 4: Analyzing the Current Messaging Environment
Lesson 5: Overview of Microsoft Office 365
Lab: Introduction to Designing an Exchange Server 2010 Deployment

1-3
1-12
1-24
1-36
1-52
1-59

Module 2: Designing Microsoft Exchange Server 2010 Integration with the Current
Infrastructure
Lesson 1: Designing the Network Infrastructure
Lesson 2: Designing the AD DS Infrastructure
Lesson 3: Designing the DNS Infrastructure
Lesson 4: Planning Exchange Server Administration
Lab: Designing Exchange Server Integration with the
Current Infrastructure

2-3
2-16
2-32
2-40
2-55

Module 3: Planning and Deploying Mailbox Services

Lesson 1: Overview of Mailbox Services in Exchange Server 2010
Lesson 2: Designing Mailbox Servers
Lesson 3: Designing Recipient Management
Lesson 4: Designing a Public Folder Architecture
Lab: Planning and Deploying Mailbox Services

3-3
3-8
3-21
3-37
3-51

Module 4: Planning and Deploying Client Access Services in Microsoft Exchange Server 2010
Lesson 1: Overview of the Client Access Server Role
Lesson 2: Designing Client Access Server Deployment
Lesson 3: Designing Client Access
Lesson 4: Designing Client Access Policies
Lab: Planning and Deploying Client Access Services in
Exchange Server 2010

4-3
4-14
4-34
4-48
4-57

Module 5: Planning and Deploying Message Transport in

Microsoft Exchange Server 2010
Lesson 1: Designing Message Routing for Exchange Server 2010
Lesson 2: Designing Hub Transport Servers
Lesson 3: Designing the Message Routing Perimeter
Lab: Planning and Deploying Message Transport in
Exchange Server 2010

5-3
5-13
5-29
5-44

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2

Module 6: Planning and Deploying Messaging Security

Lesson 1: Designing Message Security
Lesson 2: Designing Antivirus and Anti-Spam Solutions
Lab: Planning and Deploying Messaging Security

6-3
6-16
6-32

Module 7: Planning and Deploying Messaging Compliance

Lesson 1: Designing Transport Compliance
Lesson 2: Designing AD RMS Integration with Exchange Server 2010
Lesson 3: Designing Message Journaling and Archiving
Lesson 4: Designing Messaging Records Management
Lab: Planning and Deploying Messaging Compliance

7-3
7-12
7-20
7-30
7-37

Module 8: Planning and Deploying High Availability

Lesson 1: Introduction to High Availability Planning in
Exchange Server 2010
Lesson 2: Designing High Availability for Mailbox Databases
Lesson 3: Designing High Availability for Other Server Roles
Lesson 4: Designing Site Resilience
Lab: Planning and Deploying High Availability

8-3
8-14
8-25
8-32
8-45

Module 9: Planning a Disaster Recovery Solution

Lesson 1: Planning for Disaster Mitigation
Lesson 2: Planning Exchange Server Backup
Lesson 3: Planning Exchange Server Recovery
Lab: Planning a Disaster Recovery Solution

9-3
9-17
9-27
9-41

Module 10: Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting
Lesson 1: Planning Exchange Server Monitoring
Lesson 2: Planning Exchange Server Troubleshooting
Lab: Planning Exchange Server 2010 Monitoring and Troubleshooting

10-3
10-19
10-27

Module 11: Upgrading to Microsoft Exchange Server 2010

Lesson 1: Overview of Upgrading to Exchange Server 2010
Lesson 2: Planning the Upgrade from Exchange Server 2003 to
Exchange Server 2010
Lesson 3: Planning the Upgrade from Exchange Server 2007 to
Exchange Server 2010
Lab: Upgrading to Microsoft Exchange Server 2010

11-3
11-12
11-28
11-41

xiii

xiv

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2

Module 12: Integrating Microsoft Exchange Server 2010 with Other Messaging Systems
Lesson 1: Designing Exchange Server 2010 Integration with Other
Messaging Systems
Lesson 2: Designing Exchange Server 2010 Integration with
Federated Partners
Lesson 3: Designing Exchange Server 2010 Integration with
Office 365
Lesson 4: Designing Single Sign-On for Office 365
Lab: Integrating Exchange Server 2010 with Other Messaging Systems

12-3
12-15
12-22
12-35
12-40

Appendix A: Unified Messaging in Microsoft Exchange Server 2010

Lesson 1: Planning the Unified Messaging Infrastructure
Lesson 2: Planning the Unified Messaging Configuration
Lesson 3: Planning the Unified Messaging Integration with Office
Communications Server

A-3
A-17
A-29

Lab Answer Keys Appendix

Module 1 Lab: Introduction to Designing an Exchange Server 2010
Deployment
Module 2 Lab: Designing Exchange Server Integration with the
Current Infrastructure
Module 3 Lab: Planning and Deploying Mailbox Services
Module 4 Lab: Planning and Deploying Client Access Services in
Exchange Server 2010
Module 5 Lab: Planning and Deploying Message Transport in
Exchange Server 2010
Module 6 Lab: Planning and Deploying Messaging Security
Module 7 Lab: Planning and Deploying Messaging Compliance
Module 8 Lab: Planning and Deploying High Availability
Module 9 Lab: Planning a Disaster Recovery Solution
Module 10 Lab: Planning Exchange Server 2010 Monitoring and
Troubleshooting
Module 11 Lab: Upgrading to Microsoft Exchange Server 2010
Module 12 Lab: Integrating Exchange Server 2010 with Other
Messaging Systems

L1-1
L2-11
L3-19
L4-35
L5-45
L6-55
L7-65
L8-75
L9-93
L10-91
L11-99
L12-103

About This Course

xv

About This Course

This section provides you with a brief description of the course, audience, suggested prerequisites, and
course objectives.

Course Description
This course teaches you how to design and deploy an Exchange Server 2010 messaging system. You will
learn how to identify business and technical requirements for the design and then translate those needs
into specific Exchange Server 2010 configuration options. This course discusses how to design various
features of Mailbox, Hub Transport, and Client Access server roles. Some features that are discusses
include message transport, security, high availability, disaster recovery, upgrades, and coexistence with
other messaging systems.

Audience
This course is intended for the IT Pro audience who is responsible for the Exchange Server messaging
environment in an enterprise. He or she is the senior administrator, or engineer who acts as a technical
lead over a team of administrators. This person is a third level of support in addition to the Exchange
Recipient Administrator, which is the first level and the Exchange Server Administrator, which is the
second level. In an effort to ensure that end users have the best possible messaging experience, this
person also evaluates new technologies and tools.
The candidate is responsible for the planning and deployment of the Exchange Servers in an enterprise
environment. He or she should have a minimum of two years of experience administering, deploying,
managing, monitoring, upgrading, migrating, and designing Exchange Server.

Student Prerequisites
This course requires that you meet the following prerequisites:

At least two years of experience working with Microsoft Exchange Server

At least six months of experience working with Exchange Server 2010 or Exchange Server 2007

At least two years of experience administering Windows Server, including Windows Server 2008

At least two years of experience working with Active Directory Domain Services (AD DS)

At least two years of experience working with name resolution, including Domain Name Service (DNS)

Experience working with certificates, including Public Key Infrastructure (PKI) certificates

Experience working with Microsoft Windows PowerShell

Course Objectives
After completing this course, students will be able to:

Gather the information required to design a messaging system.

Design the integration of Exchange Server with the current infrastructure.

Design the deployment of the Mailbox server services in Exchange Server 2010.

Design the Client Access server deployment.

Design the Hub Transport server and Edge Transport server deployments.

Plan and deploy messaging security.

Plan and deploy a messaging policy and compliance solution.

xvi

About This Course

Plan a highly available Exchange Server 2010 deployment.

Plan a disaster recovery solution in Exchange Server 2010.

Develop a plan for monitoring and troubleshooting the Exchange Server environment.

Plan and implement a transition from Exchange Server 2003 or Exchange Server 2007 to Exchange
Server 2010.

Integrate Exchange Server 2010 with other messaging systems and with federated partners.

Course Outline
This section provides an outline of the course:
Module 1, Introduction to Designing a Microsoft Exchange Server 2010 Deployment. Before you can
begin designing your organizations 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. By understanding this, you will learn how to begin designing your organizations new
messaging system.
Module 2, Designing Exchange Server 2010 Integration with the Current Infrastructure teaches you
what networking components must be in place, and how they must be configured to properly support
Exchange Server 2010.
Module 3, Planning and Deploying Mailbox Services explains how the mailbox services design includes
the physical design of the Mailbox servers, including the storage system. You will also learn how it
includes the design of recipient management and public folder architecture.
Module 4, Planning and Deploying Client Access Services in Microsoft Exchange Server 2010. The
messaging clients access the Exchange Server mailboxes through the Client Access server role. Because of
the importance of this server role, you must understand how it works, and how to design the Client Access
server deployment. This module describes how to design the Client Access server role deployment in
Exchange Server 2010
Module 5, Planning and Deploying Message Transport in Microsoft Exchange Server 2010. After you
have defined the business requirements of your organization and have a good understanding of the
current network environment, the next step is to design message routingboth within the organization,
and between the organization and other organizations connected to the Internet. This module describes
how to design message routing.
Module 6, Planning and Deploying Messaging Security. In this module you will learn about ensuring
that the messaging system is as secure as possible. This includes planning for message security, which
ensures that messages sent within the organization, and to and from the Internet, meet the organizations
compliance and security requirements. A second consideration for planning the security is implementing
an antivirus and anti-spam solution that prevents malicious e-mails from entering the Exchange Server
organization.
Module 7, Planning and Deploying Messaging Compliance teaches you how Microsoft Exchange Server
2010 provides a wide range of messaging compliance features that you can use for more than just simple
messaging and calendaring. You will also learn how you can use messaging compliance features to
control message transport, apply Rights Management Services (RMS), implement journaling and archiving,
and manage messages.

About This Course

xvii

Module 8, Planning and Deploying High Availability describes how high availability ensures that
messaging systems built on Exchange Server 2010 can survive the failure of a single server, or even
multiple servers.
Module 9, Planning a Disaster Recovery Solution explains how to ensure that you meet SLA
requirements by planning how Microsoft Exchange Server 2010 will be backed up and restored.
Module 10, Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting describes how
to perform routine monitoring, and where necessary, make adjustments to your Microsoft Exchange
Server 2010 servers. By understanding how to implement a monitoring program and knowing what and
how to monitor, you can optimize your Exchange servers.
You will also learn how to troubleshoot problems with Exchange Server 2010. Planning an effective
troubleshooting methodology and familiarization with the troubleshooting tools helps you to quickly and
efficiently resolve even complex problems.
Module 11, Upgrading to Microsoft Exchange Server 2010 provides an overview of the options that
organizations have when choosing to implement Exchange Server 2010, and provides details on how to
upgrade an existing Microsoft Exchange Server 2003 or Exchange Server 2007 organization to Exchange
Server 2010.
Module 12, Integrating Microsoft Exchange Server 2010 with Other Messaging Systems. Integration
with other messaging systems is useful when you are migrating from a legacy messaging system to
Exchange Server 2010. Integration with federated partners that are also using Exchange Server 2010
allows you share information with partner organizations. Integration with Exchange Online allows you to
expand the messaging system in your organization without adding additional servers. In this module you
will learn about how to integrate Exchange Server 2010 with other messaging systems.
Appendix A, Unified Messaging in Microsoft Exchange Server 2010 describes how to plan the Unified
Messaging 2010 infrastructure, configuration, and integration with Office Communications Server 2007.

xviii

About This Course

Course Materials
The following materials are included with your kit:

Course Handbook A succinct classroom learning guide that provides all the critical technical
information in a crisp, tightly-focused format, which is just right for an effective in-class learning
experience.

Lessons: Guide you through the learning objectives and provide the key points that are critical to
the success of the in-class learning experience.

Labs: Provide a real-world, hands-on platform for you to apply the knowledge and skills learned
in the module.

Module Reviews and Takeaways: Provide improved on-the-job reference material to boost
knowledge and skills retention.

Lab Answer Keys: Provide step-by-step lab solution guidance at your finger tips when its
needed.

Course Companion Content on the http://www.microsoft.com/learning/companionmoc/ Site:

Searchable, easy-to-navigate digital content with integrated premium on-line resources designed to
supplement the Course Handbook.

Modules: Include companion content, such as questions and answers, detailed demo steps and
additional reading links, for each lesson. Additionally, they include Lab Review questions and answers
and Module Reviews and Takeaways sections, which contain the review questions and answers, best
practices, common issues and troubleshooting tips with answers, and real-world issues and scenarios
with answers.

Resources: Include well-categorized additional resources that give you immediate access to the most
up-to-date premium content on TechNet, MSDN, Microsoft Press

Student Course files on the http://www.microsoft.com/learning/companionmoc/ Site: Includes the

Allfiles.exe, a self-extracting executable file that contains all the files required for the labs and
demonstrations.

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

[email protected]. To inquire about the Microsoft Certification Program, send e-mail
to [email protected].

About This Course

Virtual Machine Environment

This section provides the information for setting up the classroom environment to support the business
scenario of the course.

Virtual Machine Configuration

In this course, you will use Hyper-V deployed on Windows Server 2008 to perform the labs.
Important: At the end of each lab, you must revert the virtual machine back to the state the virtual
machine was in before the lab started. To revert a virtual machine, perform the following steps: 1. In
Hyper-V Manager, right click the virtual machine name and click Revert. 2. In the Revert dialog box,
click Yes.

The following table shows the role of each virtual machine used in this course:
Virtual machine

Role

10233B-VAN-DC1

Domain controller in the Adatum.com domain

10233B-VAN-EX1

Exchange 2010 server in the Adatum.com domain

10233B-VAN-EX2

Exchange 2010 server in the Adatum.com domain

10233B-VAN-EX3

Exchange 2010 server in the Adatum.com domain

10233B-VAN-EDG

Exchange 2010 Edge Transport server

10233B-VAN-CL1

Client computer in the Adatum.com domain

10233B-NYC-DC1

Domain controller in the Contoso.com domain

10233B-NYC-SVR2

Member server in the Contoso.com domain

Software Configuration
The following software is installed on each VM:

Windows Server 2008 R2 Enterprise

Windows 7

Exchange Server 2010

Microsoft Office 2007, Service Pack 2

Classroom Setup
Each classroom computer will have the same virtual machine configured in the same way. All of the
aforementioned virtual machines are deployed in each student computer.

xix

xx

About This Course

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.

Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) processor

Dual 120 GB hard disks 7200 RM SATA or better*

8 GB RAM

DVD drive

Network adapter

Super VGA (SVGA) 17-inch monitor

Microsoft Mouse or compatible pointing device

Sound card with amplified speakers

*Striped
In addition, the instructor computer must be connected to a projection display device that supports SVGA
1024 x 768 pixels, 16-bit colors.

1-1

Module 1
Introduction to Designing a Microsoft
Exchange Server 2010 Deployment
Contents
Lesson 1: Gathering Business Requirements

1-3

Lesson 2: Identifying Additional Requirements

1-12

Lesson 3: Introduction to Service Level Management

1-24

Lesson 4: Analyzing the Current Messaging Environment

1-36

Lesson 5: Overview of Microsoft Office 365

1-52

Lab: Introduction to Designing an Exchange Server 2010 Deployment

1-59

1-2 Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Module Overview

Before you can begin designing your organizations new messaging system, you must first understand
why your organization plans to deploy the messaging system, and understand 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.
After completing this module, you will be able to:

Describe the business requirements gathering process.

Identify additional requirements.

Describe service level management.

Analyze the current messaging environment.

Describe Office 365 and Exchange Online.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-3

Lesson 1

Gathering Business Requirements

In this lesson, you will gather business requirements for a Microsoft Exchange Server 2010 deployment.
Identifying business requirements helps determine the benefits of, and rationale for, the deployment
project.
After completing this lesson, you will be able to:

Describe the importance of business requirements.

Define the functional business requirements for a project.

Define service level agreements (SLAs).

Identify types of regulatory and organizational compliance requirements.

Identify project constraints.

1-4 Introduction to Designing a Microsoft Exchange Server 2010 Deployment

What Are Business Requirements?

Organizations invest in technology to solve business problems, or to provide new opportunities. Business
requirements typically dictate reasons for an organizations 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
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 organizationsuch as government or business

partnersmay impose requirements. For example, government regulations may require archival of
certain email for a specified time, or business partners may enforce specific security requirements for
email communication between locations.

Avoid disruptions to business processes. A current technology may meet most business requirements.
However, if the current technology 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
significantly increased the business potential for many organizations.

Importance of Business Requirements

A technology deployment is more likely to address an organizations needs if business requirements are
defined clearly and concisely at the projects inception. Additionally, it is easier to measure a projects
success if the project team is knowledgeable about the business problems that the project must solve.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-5

What Are Functional Requirements?

Functional requirements define a technologys expected behavior by describing a systems 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.
Note For example, an organization may define a business requirement that all email to
and from a partner organization must be secure. The resulting functional requirement is
that the servers running Exchange Server 2010 and handling email sent between the two
organizations must be configured to require encryption for all messages.
Note A use case typically accompanies each functional requirement. A use case describes
an activity performed within the organization, and the activitys intended outcome. For
example, a use case might specify steps that a user inside the organization must follow
when sending an email 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 email) 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 specificationwhich serves as a contract between the
customer and the design teamdescribes the proposed solution in exacting detail, and forms the basis
for project plans and schedules. The customer is the technology consumer, and is usually the business
sponsor and user.

1-6 Introduction to Designing a Microsoft Exchange Server 2010 Deployment

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 customers expectations.

Provides in-depth project details to help the team determine if it is building the correct solution. 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
specifications. 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 specifications include system availability, maintainability, performance,
reliability, and scalability.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-7

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 are never 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 projects success.

1-8 Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Negotiating SLAs
SLAs have a significant impact on a projects scope and budget, so it is important to define them at the
projects 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
quite 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 would likely be prohibitive.
Thus, the organization may negotiate a more acceptable performance level at a more reasonable cost.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-9

Discussion: Identifying Regulatory and Organizational Compliance

Requirements

Email is often used to communicate significant amounts of 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:
Question: In what type of business does your organization participate? What are the
legislated compliance requirements for your organization?

Question: What additional compliance requirements does your organization have?

Question: 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?

Question: 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?

1-10

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Identifying Project Constraints

Project constraints define the projects 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 projects 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. 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 mobile device access to Exchange Server mailboxes.
However, if the proposed solution cannot address this requirement, the project might be canceled.
Additionally, requiring email 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-11

Negotiating Project Constraints

The project team must identify constraints early in the project, as these constraints can significantly
impact the solution design.
The project team and business sponsors often negotiate project constraints, 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.

1-12

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

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 projects design by limiting or strictly
defining which business requirements the project can address.
After completing this lesson, you will be able to:

Identify additional stakeholders for a project.

Define technology requirements.

Identify IT requirements.

Identify security requirements.

Identify user requirements.

Resolve conflicting requirements.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-13

Typical Stakeholders

Who Are Stakeholders?

A project stakeholder is anyone who sponsors a project, or has interest in the projects completion. The
business sponsor is one of the most important stakeholders for most projects. The business sponsor
typically provides the projects business requirements and budget. However, a large projectsuch as
deploying a new messaging systemwill significantly impact an entire organization, and many people
throughout the organization must have input into the projects design.
A stakeholders 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 products deployment or future support.

A project such as an Exchange Server 2010 deployment can have several additional stakeholders besides
the project sponsor, including:

IT personnel. The Exchange Server 2010 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
Domain Services (AD DS) 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 email, and the integration of email into many business processes.

Messaging users. A new technology often affects users directly, and they may have different
requirements than a business sponsor.

1-14

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

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 technologys
deployment will affect.

4.

Gather additional information, if necessary, to verify the description documents 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 groups representatives.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-15

Defining Technology Requirements

IT personnel are one of the most important stakeholder groups in an Exchange Server 2010 deployment.
Typically, they have a thorough understanding of the current technology environment. This means that
they understand the current environments limitations, and can detail the projects necessary
technological requirements.

What Are the Technology Requirements?

Every organization has technology requirements that affect an Exchange Server 2010 deployment. One of
the most important considerations in a deployment project is the current technology infrastructure. In
almost all cases, the Exchange Server 2010 deployment must integrate with the existing environment.
Components to consider in the existing infrastructure include:
1.

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 2010 deployment
project or budget. Therefore, available equipment may impact deployment.

2.

Storage technologies. Most large organizations have implemented SANs 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 2010 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 2010 project must implement
alternative storage solutions. Exchange Server 2010 provides options such as continuous cluster
replication (CCR) for providing data redundancy, and supports new technologies such as Internet
small computer system interface (iSCSI).

1-16

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

3.

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 projects 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 2010 to support Volume Shadow Copy Service (VSS) backups and features (such as CCR)
when planning the Exchange Server integration into the current backup solution.

4.

Network infrastructure. The Exchange Server 2010 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.

5.

Active Directory infrastructure. Exchange Server 2010 is integrated tightly with AD DS, but it can
operate in almost any Windows Server 2008 Active Directory environment. However, the Active
Directory configurationsuch as the site configurationand the locations of the domain controller
and global catalog server can impact Exchange Server 2010 performance significantly. If the Active
Directory environment is not designed for optimal performance, redesigning the Active Directory
configuration or modifying an optimal Exchange Server design may be necessary.

6.

Data center configuration and location. Some organizations place all their servers in a single location,
or data center, while other organizations may choose to distribute servers across multiple data
centers. This may be for a variety of reasons, including: to provide primary data center redundancy to
take advantage of potential cost-savings of operating the data center in a low-cost region, or because
the original data center is no longer large enough to house the required servers. To some extent,
branch offices that include one or more servers can also be considered data centers. If your
organization has multiple data centers or larger branch offices, this will impact your Exchange Server
deployment plan.

7.

User distribution. In small organizations, the design of your Exchange Server infrastructure does not
need to consider user distribution; they are all probably located in a single office. However, if you are
planning to implement Exchange Server in an organization that supports thousands of users, the
chances are that they will be distributed across multiple locations. In addition, even in small
organizations, users need to access their email and related services from home, or from a remote
network. It is important that when you plan your Exchange Server implementation, you consider
carefully how your users are distributed, and from where they typically access email. These
considerations have an impact on the location and number of Exchange Server roles that you must
deploy.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-17

Identifying IT Requirements

In addition to requirements of the current technological environment, an Exchange Server 2010

deployment project may need to be compatible with current IT policies and processes. Business
requirements typically drive adoption of new technologies. However, the IT departmentwhich can
include messaging administrators, messaging engineers, and help desk personnelis responsible for
actual technology deployment and operation, and therefore, is an important project stakeholder.

Identifying IT Department Requirements

A projects business requirements may differ from IT department needs. When discussing the project with
IT representatives, ask the following questions:
1.

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.

2.

What are the current IT pain points that the project may address? IT departments often have longstanding 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 2010 design.

3.

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.

1-18

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Identify IT Policies and Processes

The Exchange Server 2010 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
purchasing all network and server components, the Exchange Server 2010 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-19

Identifying Security Requirements

Another essential stakeholder group consists of those who create and enforce an organizations 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 projects 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 organizations security risks? There are many possible answers to this question,
including:

Email clients are at risk from viruses and other malware that may be spread through the email
system.

Authentication traffic and message-access traffic are at risk for capture when users access their
mailboxes with Microsoft Office Outlook Web App for Exchange Server 2010. 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 email 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.

1-20

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

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 Outlook Web
App traffic.

What gaps exist between security requirements and current solutions? One of the most difficult
security gaps to address is with SMTP email. Virtually all SMTP email is sent in clear text, or is
Multipurpose Internet Mail Extensions (MIME) encoded. Organizations can implement features such
as Secure MIME (S/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 is 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 and receive information about their account via email.
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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-21

Identifying User Requirements

Another important stakeholder group in an Exchange Server 2010 deployment is the messaging system
users.

Identifying User Requirements

User requirements may differ from business sponsor requirements. For example, the business sponsor
is most likely to be interested in the functionality that the system provides, while users typically are
interested in the systems ease of use, or how it enables 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 users currently utilize email?

Is there email 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?

1-22

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Note User requirements are very important to a messaging systems ultimate success or
failure. If the first user experience with a new system is negative (possibly 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-23

Discussion: Dealing with Conflicting Requirements

As you gather all of the requirements for the Exchange Server 2010 deployment, it is likely that you will
identify conflicting requirements. For example, certain business requirementssuch as the budgetmay
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.

Discussion Questions
Based on your experience, consider the following questions:
Question: What examples have you seen where requirements conflicted?

Question: One of the most common scenarios for incompatible requirements occurs
between security and business requirements. How can security requirements be balanced
with other requirements?

Question: What guidelines would you suggest for addressing conflicting requirements?

1-24

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Lesson 3

Introduction to Service Level Management

Service level management is the process of defining and monitoring service levels. This is an essential tool
to ensure that an organizations IT provider meets business needs. Availability is one of the most
commonly monitored services within an organization. An SLA defines the requirements for service
availability and other service characteristics. You should base all of the objectives that an SLA lists and that
service level management monitors, on business requirements. As you devise SLAs, you should consider
disaster recovery.
After completing this lesson, you will be able to:

Describe SLAs.

Describe service level management.

Describe high availability.

Define business requirements and service level management.

Define disaster recovery requirements.

Create SLAs.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-25

What Are Service Level Agreements?

An SLA is an agreementwhich typically is signedbetween an IT group and an organization. It is

important to define an SLA early, because it documents the service expectations and requirements that an
organization expects the IT service provider to deliver. An SLA might be written for the availability of a
specific system component, a specific service, or an entire system.
A successful SLA might result from hours of negotiation, but the final agreement might be a single-page
document that you discuss at a SLA Review. An SLA is successful if it delivers what is requested, offers a
simple representation of the services complexity and component architecture, documents measures on
performance, and is in a suitable format. If the SLA meets its objectives, it does not need to be a complex
document.

SLA and System Design

It is important to define SLAs before designing and implementing an information system. You should
design the system to meet SLAs. A more highly-available system typically has a higher cost than a less
available system, and you can factor in the cost when negotiating SLA agreements.
When negotiating an SLA, initial demands typically are high. However, when faced with the actual costs
associated with extreme high availability, the organization typically reduces its demands to more
reasonable levels.

Internal SLAs
An internal SLA is between the IT department and other departments in the same organization.
An internal SLA between two departments within one organization rarely has legal consequences, but
does describe the relationship, expectations, and timescale for service deliveries. Thus, it is binding
because it represents an agreement between two parties who should make every attempt to meet the
documented service levels.

1-26

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

The internal parties are accountable for what they do and do not achieve as outlined in the SLA. There
may be repercussions within the organization when an agreed-upon service is not fulfilled, even though
the document is not a legal contract. ITs status may suffer, for example, if there are issues on chargeable
services, or if the costs of providing an agreed-upon service cannot be justified.
Note: The IT Infrastructure Library (ITIL) refers to an internal SLA agreement as an operational level
agreement (OLA).

External SLA
External SLAs are more formal, legally-binding contracts than internal SLAs. An external SLA may have
more structure because it usually includes cost and bonus clauses, and sometimes includes penalty
clauses. However, an external SLA always includes the services specific cost and deliverables, which often
include availability and security services.
Additionally, an external SLA typically involves a stated cost that will apply if changes in service criteria
occur. For example, if support hours from a service desk outsourced under an SLA increase, then costs for
the increased availability of staff and services are incurred. These costs typically pass on to the contracting
organization. However, such costs likely are justifiable, because business revenues will most likely have
increased as a result of longer service hours.
If an external SLA must be legally binding, it should be checked by a qualified legal professional, either
from an internal legal department or an external legal counsel. In other words, you should not enter into
an SLA contract without confirming the contracts legal implications, including the definition and
description of costs, bonuses, penalties, and the reasons for contract termination.

Informal SLA
Not all SLAs are contracts with formal terms and conditions. In some cases, service level expectations are
based on a verbal agreement between the IT provider and the organization. This is an informal SLA, and
often these types of agreements develop over time through casual conversations with the IT provider. An
internal agreement is usually informal.
While an informal SLA avoids the negotiation process that a formal SLA requires, the undocumented
nature of an informal SLA can lead to the customer misunderstanding the SLA terms and conditions. The
IT provider can publish an informal SLA to the entire organization to help minimize misunderstandings.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-27

What Is Service Level Management?

Service level management is the process of defining and managingvia monitoring, reporting, and
reviewingan organizations required and expected service levels. It aligns business needs with delivery of
IT services. The goal of service level management is to successfully deliver, maintain, and improve IT
services in a cost-effective manner.

Service Level Management Tasks

The following table describes the tasks involved in service level management.
Task

Description

Create a service
catalog

Written in business language, a service catalog is the definitive guide to the services
available to the business. It provides end-to-end descriptions of the service
components used to deliver services, and the IT functionality that the business uses.
This information creates and defines the SLA within each area, since the SLA is
developed according to the priority and business requirements of the service.

Negotiate SLAs

An SLA is a mutually agreed-upon and negotiated agreement between the IT

provider and the business. An SLA and availability requirements are important parts
of service level management, but must not be viewed as an endpoint when
providing IT services.

Monitor the
service levels

Services are monitored and measured, according to SLA criteria, to ensure

compliance. Service-level monitoring entails continual measurement of mutually
agreed-upon service-level thresholds, and the initiation of corrective actions if the
thresholds are breached. Without this process, the value of the SLA diminishes.

1-28

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

(continued)
Task

Description

Report the
service level

Using the service catalog and the SLA, reports should be designed and scheduled. If
required, real-time SLA criteria monitoring should be conducted. The thresholds,
alerts, notifications, and actions for real-time criteria monitoring should be
considered, and service performance measured against them. You can complete a
service-level review at required intervals with the customer department
representative, using reports produced from historical data and the monitoring
function.

Review the
service level
agreement

The SLA review provides an opportunity to review performance against SLA

objectives, and more importantly, to gather perceptions and opinions from business
representatives on any service changes. If any service levels are perceived to be
breached, but are not highlighted by the service review or reports, there might be
issues with the SLA criteria and objectives. Issues might include providing additional
resources to support new services or service levels, if these resources were not
initially considered. You should work with the business representatives to identify
any issues from the previous period, and any current issues that you need to address
before the next review.

Monitoring, Reporting, and Reviewing

It is critical that you perform the monitoring, reporting, and reviewing tasks in the service level
management process. Without these tasks, the value of an SLA is reduced significantly. For example, if you
do not perform monitoring, you can never be sure that you are adhering to the SLA. The level of service
provided may be below negotiated levels, and no corrective actions are taken. If the SLA is not updated to
reflect business changes, then the existing SLA may no longer be relevant, and additionally, the SLA may
not evaluate new business processes and systems appropriately.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-29

What Is Availability?

Availability refers to a level of service that applications, services, or systems provide, and is expressed
as the percentage of time that a service or system is available. Highly available systems have minimal
downtime, whether planned or unplanned, and are available more than 99 percent of the time,
depending on the needs and the budget of the organization. For example, a system that is unavailable
for 8.75 hours per year would have a 99.9 percent availability rating.
To improve availability, you must implement fault-tolerance mechanisms that mask or minimize how
service component failures and dependencies impact the system. You can achieve fault tolerance by
implementing redundancy to single points of failure.

Defining Availability Requirements

Service availability is a complex issue that spans many disciplines. You can take many different approaches
to deliver the required availability levels, and each approach has its own cost implications.
Availability requirements must be expressed so that there are no misunderstandings about the
implications. Miscommunication concerning service level expectations between the customer and the IT
organization can result in inappropriate business decisions, such as unsuitable investment levels and
customer dissatisfaction.

Different Availability Requirements

One requirement for 99.5 percent availability can be different from another requirement for 99.5 percent
availability. One requirement may state the availability of the hardware platform alone, while another may
state the availability of complete end-to-end service. Even the definition for complete end-to-end service
availability can vary. It is important to understand how each availability requirement is to be measured.
For example:

If all hardware and software on the primary server are functioning correctly and the application is
ready to accept all user connections, then does the solution provide 100 percent availability?

1-30

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

If there are 100 users, but 25 cannot connect because of a local network failure, then does the
solution still provide 100 percent availability? In this situation, the solution meets the 100 percent
availability expectations of 75 percent of the users, but for the rest of the users, it does not. How do
we consider this as part of the availability since all of the users are not affected?

If only one user out of 100 can connect and process work, is only 1 percent available?

If all 100 users can connect, but the service is degraded with only two out of three customer
transactions being available, or performance is poor, how does this affect availability measurements?

The availability measurement period also can have a significant effect on the definition of availability. For
example, a requirement for 99.9 percent availability over a one-year period allows 8.75 hours of
downtime, whereas a requirement for 99.9 percent availability over a rolling four-week window allows
only 40 minutes of downtime per period.

Outages
It also is necessary to identify and negotiate downtime periods for planned maintenance activities,
service pack updates, and software updates. These are scheduled outages, and typically not included as
downtime when calculating the systems availability. You typically calculate availability based on
unplanned outages, such as a system crash. However, you have to negotiate exactly which outages you
consider to be downtime.
For example: Service Availability of 99.9%:
Contoso, Ltd has 100 databases. Over a four week period, 100 databases are down for 1 hour each.
Thats a total downtime of 60*100=6,000 database minutes of downtime. Given that four weeks
consist of 40,320 minutes, the total number of database minutes in Contoso during the period was
100*40,320=4,032,000 database minutes. If we divide 6,000 by 4,032,000 we get .0015 downtime, which
is a database availability of 99.85 percent.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-31

Business Requirements and Service Level Management

Business requirements help IT providers understand business processes. IT systems exist to support
business processes. However, many times the IT provider is isolated from the business processes that need
support. If the IT provider understands the processes that various business units use, then the provider is
better able to anticipate and meet the organizations business requirements. Service level management
provides the interface between the organization and the IT provider, so that the IT provider can deliver
solutions in line with the business requirements at an acceptable cost.
You should interview stakeholders and other key positions within the organization to determine business
requirements, which should include: requirements for usage, business processes, mission-critical
applications, and plans for growth.

Priority Definition
You can effectively support business requirements by negotiating each services priority. This identifies
where to target resources.
Some measures that can help you define the services priorities are:

The number of impacted users, and the impacts severity.

The number of impacted external customers of the organization, and the impacts severity.

The number of other services affected, and the impacts severity.

For example, consider the loss of an internal messaging system. This would be considered a major
problem for many users. Furthermore, if the organizations business processes use the messaging system
to communicate extensively with external customers, it likely is an even higher priority than if only internal
users are affected.

1-32

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Budget Negotiation
It is important to set the correct expectations for all stakeholders when discussing service level
management. Stakeholders might have unrealistic expectations for availability, and must be prepared to
provide the budget to ensure desired availability levels.
In many cases, the first draft of availability requirements that you present includes almost no downtime.
The costs to provide high availability can be significant. And the costs tend to increase for systems with
very high availability. For example, it is relatively inexpensive to update a system from 99.9 percent
availability to 99.99 percent availability. It is much more expensive to update a system from 99.99 percent
availability to 99.999 percent availability.
You must include the cost of availability requirements as part of negotiating an SLA. In many cases, a
lower level of availability is acceptable when the actual cost of availability is known.
However, you may be able to negotiate increased budget levels if a potential service outage is more costly
than the budget change required for increased availability.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-33

Disaster Recovery and Service Level Management

In addition to accepted availability levels, an SLA must include acceptable recovery times after a disaster
occurs. A disaster can be the loss of any IT system, and can range from hardware and software failures, to
data corruption, to the loss of an entire data center.
To plan for recovery from a disaster, prepare a disaster recovery plan. This plan contains detailed steps
that will help you recover from a disaster. In most cases, there are multiple methods to recover from
disaster. The acceptable recovery time that is defined in the SLA for each system involved determines the
methods you include in the disaster recovery plan. The SLA describes how to recover all necessary data
and services, and the maximum acceptable time that recovery should take.

Designing for Disaster Recovery

You should negotiate an SLA when developing any new IT system. You also need to determine the
disaster recovery plans during the initial development of any new IT system. The options for disaster
recovery are a direct result of an overall system design. Failure to address disaster recovery concerns
during the design process can result in future expensive and disruptive changes.
Disaster recovery planning can include:

Implementing redundant hardware in servers.

Storing backup data offsite.

Maintaining local copies of recent backups.

Maintaining spare hardware in the event of a disaster.

Synchronizing data between two servers.

Synchronizing data between two data centers.

1-34

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Creating Service Level Agreements

When developing an SLA, it is important to start by examining the documented services that the service
catalog makes available, as well as any existing performance metrics you gather when establishing the
baseline setup. When you complete baseline setting, the discussion can focus on whether the services are
adequate, or if they need improvement. You also can clarify the businesss service level priorities.
An SLA must include:

Availability definitions, such as:

Responsiveness requirements

Allowed downtimeplanned and unplanned

Allowed recovery time

Data-loss tolerance

Security requirements

A process for problem resolution escalation

Actions to take if the SLA is not met

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-35

Requirements for SLA Objectives

The following table lists the SLA objectives you must include:
Objective

Reason

Support business
objectives

If an SLA does not map to the business objectives, it can work against the
organizations plans for the future by using scarce resources on unnecessary
tasks. One example of a business objective matching an SLA requirement is:
recovery of all customer support applications within one day to support the
business objective of 95 percent customer retention for each year.

Be specific and
measurable

If an SLA objective is not specific and measurable, it is impossible to impartially

judge whether it is met. This leads to confusion and misunderstanding
between the IT provider and the business areas it serves.

Be attainable

If an SLA objective is not attainable, then it should be abandoned. Consider

everything when deciding whether an objective is attainable. In some cases,
attaining the objective might be as simple as adjusting the time allocated for
maintenance. In other cases, an increased budget may be required.

Bring value to the

organization

Consider the impact of attaining the SLA objectives. Organizational resources

are scarce, and the allocation of those resources must be made based on the
service level priority in question. It does not make sense to waste staff time and
budget on low-value objectives that are expensive to attain.

1-36

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Lesson 4

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 2010 deployment.
After completing this lesson, you will be able to:

Analyze the physical network infrastructure.

Analyze the name resolution services infrastructure.

Analyzing the Active Directory infrastructure.

Analyze an existing messaging infrastructure.

Identify the usage statistics for a messaging system.

Identify additional infrastructure requirements.

Analyze administrative models and processes.

Analyze a change control process.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-37

Analyzing the Physical Network Infrastructure

To determine how your existing network will support an Exchange Server 2010 messaging environment,
build a complete picture of your network infrastructureincluding 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 2010 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 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 (Kbps). 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 can be
transmitted in a set time period over the network. You can use this information, the current
applications using the network, and the number of users at various sites and their use patterns, 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

1-38

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

connectivity, and factor in the latency introduced by the distances between sites. 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 is
expected to generate.

Firewall configuration requirements. Depending on your deployment plan, you should determine any
firewall configuration requirements for the 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-39

Analyzing the Name Resolution Services Infrastructure

Name resolution services translate network addresses to computer names, and vice versa. The DNS
provides the required name resolution services for AD DS, and for internal and external name resolution.
Exchange Server 2010 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 exchanger (MX)
resource 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 (SRV) resource records?

Who maintains and administers the organizations 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
Directoryintegrated?

What resource records are stored in DNS? For example, have the Sender ID records been configured?
How are the mail exchanger (MX) resource records configured? Have the pointer (PTR) resource
records been configured for internal and external zones?

1-40

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Analyzing the Active Directory Infrastructure

AD DS planning and administration is tied closely with messaging service delivery. In many organizations,
the same team is responsible for both. For messaging systems, AD DS 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 AD DS, which means that the most
important design and service decisions have already been made.

Active Directory Infrastructure

There are some specific points that you should investigate in existing Active Directory deployments. These
points include the following:

Active Directory Site Configuration. Unlike Exchange 2000 Server and Exchange Server 2003,
Exchange Server 2010 does not require configuration of a separate routing topology. Exchange
Server 2010 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 2010 into your
current Active Directory structure, you must understand the following:

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-41

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 2010, or if your implementation requires a forest-to-forest trust
between forests containing Exchange Server 2010, the minimum Active Directory forest
functional level for each forest must be Windows Server 2003. The Active Directory domain
functional level must be the Microsoft Windows 2000 Server native or Windows Server 2003 for
all domains in the Active Directory forest in which you will install Exchange Server 2010.

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 2010
must be running either the latest 32-bit or 64-bit edition of Windows Server 2003, or the latest 32-bit
or 64-bit edition of Windows Server 2008.

Group Policy configuration. Many organizations use Active Directory Group Policy to provide
centralized management and security of users, groups, computers, and other directory objects.
Document the organization of servers in AD DS and how Group Policy is applied to the organizational
units that contain server computer accounts.

Schema master configuration. Because Exchange Server 2010 requires an update to the Active
Directory schema, it is important to document who controls both the schema master and the
associated rights to make schema modifications. To support Exchange Server 2010, the domain
controller that is the schema master must be running either the latest 32-bit or 64-bit edition of
Windows Server 2003, or the latest 32-bit or 64-bit edition of Windows Server 2008.

Migrating to AD DS
If your organization is migrating to AD DS 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 update 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?

1-42

Introduction to Designing a Microsoft Exchange Server 2010 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 2010 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, your current Active
Directory environment, and other required settings, is to use the Microsoft Exchange Best Practices
Analyzer (ExBPA) tool. The ExBPA provides an extensive transition report to assist in preparing to deploy
Exchange Sever 2010. You can also use the Microsoft Exchange Server Profile Analyzer tool, which assists
you in determining your typical user profile. This information can help with the process of server sizing or
capacity planning.

Additional Information About the Messaging Environment

In addition to the information that ExBPA and Exchange Server Profile Analyzer tools provide, you
also should document other information that you can use to roll back to a previous environment or
configuration, should the need arise. This information is also useful as reference material for comparing
your existing environment to the intended Exchange Server 2010 environment. Consider documenting the
following additional information:

Exchange Server hardware and software version. This 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 rolessuch as front-end servers
or SMTP gateway configurationsdedicated bridgehead servers, mailbox servers, and public folder
servers.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-43

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 groups 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 email domains.

Load-balancing configuration. If you currently implement Network Load Balancing (NLB), document
the configuration so that you can easily migrate the settings to the new messaging infrastructure.

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 2010 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
Server 2010 servers into the environment. This means that only servers running Exchange Server 2003
or Exchange Server 2007 can exist in the organization.

If your organization includes Exchange Server version 5.5, you must perform an upgrade to Exchange
Server 2003 before moving to Exchange Server 2010. To move messaging services and data from
Exchange Server 2003 to Exchange Server 2010, you must use the move mailbox functionality in
Exchange Server 2010.

1-44

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

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

To facilitate planning for processor and memory configurations for your intended messaging
environment, you must determine how users connect to your current 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 users requirements or location. Consider the following when
determining the client environment:

What operating system are the clients running? Some Office Outlook features are only available
on Windows Vista. Older clients or Macintosh systems may provide lower functionality. For
using the messaging system, UNIX and Linux clients may be restricted to Internet message access
protocol version 4 (IMAP4), Post Office Protocol version 3 (POP3), or Office Outlook Web App.

How many client computers exist, and where are they located on the network? These two factors
have a profound influence on the users 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 the new messaging system deploys, and you can plan the deployment accordingly.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-45

Which client protocols are used to access email?

Depending upon user requirements, many organizations deploy one or more of the following
client protocols:

Messaging API (MAPI) clients

Hypertext Transfer Protocol/Secure (HTTPS) (Outlook Web App)

POP3/IMAP4

Outlook Anywhere (formerly known as remote procedure call (RPC) over HTTPS)

Microsoft Exchange ActiveSync or other mobile messaging clients

Microsoft Web Distributed Authoring and Versioning (WebDAV) (Entourage clients)

Profiling Messaging Statistics

A number of messaging statistics are useful for determining your current messaging environments 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: For additional documentation about the Microsoft Exchange Server Profile
Analyzer, see the Microsoft Exchange Server Profile Analyzer (32 bit) page on the Microsoft Download
Center website.
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 are listed in
the following table.
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

1-46

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

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 environments 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 architecture of Exchange Server 2010 provides new performance and scalability
opportunities. The increased memory that 64-bit makes available means that Exchange Server
2010 has tremendously different performance characteristics than Exchange Server 2003. 64-bit
code also reduces substantially the disk input/output (I/O) required for Exchange Server 2010.

Todays larger Exchange deployments typically require a high-performance SAN-based storage

solution to ensure scalability. With Exchange Server 2010s ability to use large amounts of
memory, the disk I/O throughput is reduced dramatically.

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
changes and improvements related to high availability and clustering in Exchange Server 2010.

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, antispam and antivirus solutions, backup solutions, and third-party high-availability solutions.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-47

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 structures use and configuration to ensure that it is adequate for the
new Exchange Server 2010 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 2010.

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.

1-48

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Analyzing Administrative Models and Processes

Your organizations 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 scenarios, 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 with another team such as the human resources or
corporate security departments.

Business unit structure. It is not necessary to explore exhaustively the interrelationships between an
organizations 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 this 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-49

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 2010
deployment.

1-50

Introduction to Designing a Microsoft Exchange Server 2010 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 of and approve 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 whom to contact to provide troubleshooting and
recovery procedures.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-51

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.

1-52

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Lesson 5

Overview of Microsoft Office 365

Microsoft Office 365 delivers the same office productivity and collaboration tools found in Microsoft
Officebut through the cloud. When designing your Exchange Server 2010 deployment, it is important to
consider whether you can use all or part of Office 365 to enhance your messaging infrastructure.
After completing this lesson, you will be able to:

Describe Microsoft Office 365 features.

Describe Exchange Online.

Describe the Exchange Online design considerations.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-53

What Is Microsoft Office 365?

Microsoft Office 365 provides your users with the tools to email, communicate, and share documents
through the Internet (or in a Cloud) without the requirement for your organization to purchase servers.
It provides your users with virtually anywhere-access to your their productivity applications and
collaboration tools. On the users client devices, Office 365 is implemented with software with which your
users are familiar: Office Word, Excel, OneNote, and PowerPoint. In addition, Office 365 provides email
and related services with Exchange Online.
For administrators, a cloud-based administrative console enables you to configure user accounts, grant
rights, manage permissions, and manage your Office 365 deployment.
Note Microsoft Office 365 replaces the Business Productivity Online Suite (BPOS). Existing
BPOS customers can transition to Office 365.
Office 365 consists of the following online services:

Microsoft Office Professional Plus. Provides users with access to the latest versions of all the Office
desktop applications. Combined with Office Web Apps, users can access their content from almost
anywhere.

Microsoft Exchange Online. Provides email, calendar, and contacts. Users can connect with a variety of
mobile devices, or use either Microsoft Office Outlook 2007 or Office Outlook 2010. Exchange Online
also helps to provide for improved message hygiene through the use of anti-spam and antivirus
software.

Microsoft SharePoint Online. Microsoft SharePoint Server technology is provided as an online

service and allows your users to create a website based on SharePoint to display your information on
the Internet.

Microsoft Lync Online. Enables your users to connect to their contacts with instant messaging (IM),
video calls, and online meetings.

1-54

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Microsoft Office Web Apps. Enables users to create, view, share, and edit their Microsoft Office
documents on the web. Users can use a wide variety of computing devices to access their content.
Note Devices require an Internet connection and a supported browsers such as Internet
Explorer.

Office 365 is available in a number of subscription plans for different types and sizes of organizations.
These are:

Microsoft Office 365 for professionals and small businesses. Designed for organizations with no more
than 25 users and provides the foundation Office 365 services: email, calendar, and website services.

Microsoft Office 365 for midsize businesses and enterprises. Designed for any size organization that
requires the more advanced features of Office 365, such as:

Advanced IT configuration and control

Office Professional Plus

AD DS

Advanced archiving

Dedicated administrator support

Microsoft Office 365 for education. Provides a similar user experience to that of Office 365 for midsize
businesses and enterprises, but tailored for educational establishments.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-55

What Is Exchange Online?

With Exchange Online, your users can access their email and related content from either Microsoft Office
Outlook, a supported web browser, or from a range of mobile devices.
Exchange Online has the following features:

Extensive client support. Users can access Exchange Online content by using Microsoft Office Outlook,
including Outlook Anywhere, compatible web-browsers, or from POP client devices.

Mobility. Mobile access is provided with the following features:

Push email support

Calendar and contacts through Exchange ActiveSync

Compatible with many devices

Mobile device security policies, including PIN lock and remove device wipe

Emails, calendars, and contacts. Features include:

25 GB mailboxes and the ability to send messages up to 25 MB

The ability to federate with other Exchange Online organizations to share free/busy calendar data

A shared company directory, distribution groups, and shared contacts

Voicemail. Exchange Online voicemail is compatible with both on-premises PBX phone systems and
Lync Server 2010. In addition, Exchange Online provides voicemail preview, call answering rules, and
company auto-attendant.

Data protection. Exchange Online is backed by an SLA that guarantees 99.9% uptime. In addition,
continuous data backup between is provided between globally-redundant datacenters. At the more
local level, deleted item retention and deleted mailbox recovery are both provided.

1-56

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Security. To help to provide for message hygiene, Microsoft Forefront Online Security for Exchange is
used to help to protect against virus and spam. In addition, continuous intrusion monitoring and
detection is provided, and all connections to the Exchange Online environment are implemented over
HTTPS to help keep access more secure.

Archiving and compliance. Exchange Online has built-in email archiving and provides you with the
ability to search multiple user mailboxes at once. Exchange Online provides policies to automatically
expire email data or to preserve it for compliance purposes. In addition, flexible transport rules can be
used for applying disclaimers and other policies to email in transit.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-57

Design Considerations for Exchange Online

If your organization has decided to implement Exchange Online, this will impact the design of your
Exchange Server deployment.
For example, you must consider whether you will implement Exchange Online only, or whether you intend
to deploy a hybrid solution in which both Exchange Online and an on-premises Exchange Server
environment will coexist; this is an important decision as it greatly impacts the other design decisions that
you make.
Note Even if you intend to implement Exchange Online only, but have an existing onpremise Exchange Server environment from which you plan to migrate, this will require a
hybrid solution during the migration phase of the deployment project.
Deploying a hybrid solution requires additional design considerations and deployment steps. For example,
a hybrid solution requires:

At least one Exchange Server 2010 server in your existing messaging infrastructure.
Note If you currently have either Exchange Server 2003 or Exchange Server 2007 servers,
get an Exchange Server 2010 Hybrid Edition license key from Microsoft support; this key
enables you to install Exchange Server 2010, and is used only to connect your Exchange
Server 2003 and Exchange Server 2007 servers to Exchange Online.

A single AD DS forest. Multiple forests are not currently supported.

Optionally, single sign-on. This enables your users to use their company network credentials to access
their online mailboxes. To enable single sign-on, you must deploy Active Directory Federation
Services (AD FS) version 2.0.

1-58

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Directory synchronization. This enables AD DS to replicate with the directory services within Exchange
Online. The directory synchronization tool has certain limitations:

It must be installed on a 32-bit server.

It cannot be installed on a domain controller.

A suitable transport pipe. You must configure the necessary send and receive connectors to enable
messages to flow between the Exchange Online and on-premise Exchange environments.

Digital certificates. Self-signed certificates can be used to help to secure communication between
client-side applications and the Exchange Online environment, but for some purposes, you must
implement public certificates.
Note Module 12 expands on these concepts.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-59

Lab: Introduction to Designing an Exchange Server 2010

Deployment

Lab Setup
For this lab, you do not require any virtual machines.

Lab Scenario
You are a messaging engineer for A. Datum Corporation, an enterprise-level organization with multiple
locations. A. Datum is an international corporation involved in technology research and investment, and is
planning to upgrade from Exchange Server 2003 to Exchange Server 2010. A. Datum 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
Corporate
Headquarters

12,000 currently
10,000 after the new
London office is ready

1,000 Outlook Web Access users

500 Outlook Anywhere and mobile client users
800 Office Outlook users connecting through a virtual
private network (VPN)

London (new
office)

4,000 (anticipated)

200 Outlook Web Access users

50 Outlook Anywhere and mobile client users

San Diego
Former head
office of
Trey Research

500

50 POP3 client users

Vancouver

6,000

800 Outlook Web Access users

100 Outlook Anywhere and mobile client users

1-60

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

(continued)
Location

Internal users

Mobile users

Tokyo

5,000

1,000 Outlook Web Access users

200 Outlook Anywhere and mobile client users
200 Office Outlook users connecting through a VPN

Chennai (new
office)

800 (anticipated)

200 Outlook Web Access users

50 Office Outlook users connecting through a VPN

A. Datum has deployed a single Active Directory forest with a dedicated root domain named
Adatum.com, and three child domains in the same tree. These domains are:

EU.Adatum.com

NA.Adatum.com

AS.Adatum.com

Additionally, the organization has deployed a domain named TreyResearch.net in the San Diego location.
This domain is configured as a separate tree in the Adatum.com forest.

Adatum_Info.vsd
Domains:

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-61

Domain Controller Locations:

London Messaging Detail:

1-62

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Tokyo Messaging Detail:

Vancouver Messaging Details:

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-63

Requirements Interview Notes Document

Madeleine Kelly, CEO
The Board of Directors has just initiated a three-year plan that will result in A. Datum 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 anywhere in the world, and negotiating partnerships or takeovers.
Whatever messaging solution you create has to be very flexible and easily expanded.

Karen Toh, Vice President Europe

My biggest complaint with the current email 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
tell me 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 email from anywhere in
the world at any time.

Marcel Truempy, CIO

In the last 5 years since I became CIO, our email system has changed from being a useful tool for business
to being a critical part of our business processes, and everybody notices when email is not available. To
give you an example, a couple of months ago all of the email servers in London were unavailable for 6
hours due to a virus outbreak. A couple of months before, one of the servers in Vancouver failed, and we
couldnt send any email to and from Vancouver for 8 hours while the hardware vendors came in to fix the
hardware. This happened right in the middle of some 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
email system is availability this system has to be available always.

Scott MacDonald, Vice President North America

The Security and Compliance Department for the organization is based in Vancouver, 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

A. Datum is establishing a very important partner relationship with Contoso, Ltd. Contoso, Ltd is a hightech research organization, and we are working on some very confidential projects with them. We need to
make sure that all of the email that we are sending between our company and Contoso, Ltd cannot be
viewed by anyone else on the Internet.

Carole Poland, 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.

1-64

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Shane DeSeranno, Network Operations Manager

The Network Operations department is responsible for managing all of the wide area networks (WAN)
links, the local area networks (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.

Jason Carlson, Network Specialist

I can provide you with a Visio diagram that has all of our WAN connections and our connections to the
Internet. Our network right now is quiet reliable, but we dont have much available bandwidth between
company locations.

Tzipi Butnaru, Directory Services Manager

The company just finished upgrading all of the Active Directory domain controllers to Windows Server
2008, Service Pack 1. As part of the upgrade, we did a thorough review of our whole Active Directory
design. We dont anticipate making any more changes to the Active Directory configuration for a while.

Conor Cunnigham, 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 App. A lot of our users work at home, and most of them are
using POP3 clients. I also have security concerns with these clients, but a bigger problem for them is
functionality. Users complain that they cant easily access their calendar information or send meeting
requests. And we have more and more people asking for access to their email through cell phone devices.

Andreas Herbinger, Messaging Specialist

We currently have a mailbox size limit of 50 megabytes (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, and most of these limits are at 100 megabytes (MB).

Luca Dellamore, 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 (LondonAG, VancouverAG, and TokyoAG). The
extra administrative group contains all of the routing groups (RoutingGroupAG). 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 (LondonExAdmins,
VancouverExAdmins, and TokyoExAdmins). In London, we have a group of senior messaging specialists
who have full control over all administrative groups (EnterpriseExAdmins). 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 Vancouver is
called VancouverRG, 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 VancouverRG and
LondonRG, and between LondonRG and TokyoRG.
We use two SMTP namespaces: adatum.com and TreyResearch.net.
Note Your instructor may choose to perform this lab as a group discussion rather than an
individual activity.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-65

Exercise 1: Evaluating an Existing Messaging Infrastructure

Scenario
In this exercise, you will complete two sections of a messaging infrastructure checklist.
To complete this exercise, review the existing A. Datum documentation:

Diagrams describing the A. Datum environment

Interview notes from meetings with various personnel at A. Datum

The main tasks for this exercise are as follows:

1.

Review A. Datum documentation.

2.

Complete the appropriate sections in the Current Network Infrastructure Analysis document.

3.

Complete the appropriate sections in the Current Messaging Infrastructure Analysis document.
Note

You may not be able to fill in all of the information in the documents.

Task 1: Review A. Datum documentation

Review the following information:

Adatum_Info.vsd

Requirements interview notes document

1-66

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Task 2: Complete the appropriate sections in the Current Network Infrastructure

Analysis document

Complete the Current Network Infrastructure Analysis document.

A. Datum Current Network Infrastructure Analysis

Document Reference Number: JC310110/1
Document Author
Date

Jason Carlson
31st January 2010

Active Directory Infrastructure - Sites

Active Directory site name

Directory servers in each site

LondonSite

RD-LON-DC1
RD-LON-DC1
EU-LON-DC1
EU-LON-DC2

Additional notes

Active Directory Infrastructure Forest and domain topology

Forest

Additional notes

Domains in each forest

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-67

Task 3: Complete the appropriate sections in the Current Messaging Infrastructure

Analysis document

Complete the relevant sections of the following document.

A. Datum Current Messaging Infrastructure Analysis
Document Reference Number: JC310110/2
Document Author
Date

Jason Carlson
31st January 2010

Exchange Server Configuration

Server name

Exchange
version and
SP level

Server
role

Location

LON-MSG-FE1

Exchange
Server 2003

Frontend
server

London

1-68

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

(continued)
A. Datum Current Messaging Infrastructure Analysis
Exchange Server Configuration
Additional notes

Exchange Organization information

Configuration

Settings

Administrative
groups
Administrator
groups
Routing
groups
SMTP
namespaces
Additional notes

Results: After this exercise, you should have completed the appropriate sections in the Current Messaging
Infrastructure Analysis document.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-69

Exercise 2: Creating a Requirements Document

Scenario
In this exercise, you will complete a requirements document for A. Datum Corporation.
The main tasks for this exercise are as follows:
1.

Discuss the questions.

2.

Complete the appropriate sections in the Project Requirements Analysis document.

3.

Discuss the components that you will need to include in the Exchange Server design to meet the
company requirements.
Note

You may not be able to fill in all of the information in the documents.

Task 1: Discuss the questions

Discuss as a group. You will incorporate your answers in to the requirements documentation.
1.

What are A. Datum Corporations requirements and pain points?

2.

How can Exchange Server 2010 help address the requirements?

Task 2: Complete the appropriate sections in the Project Requirements Analysis

document
You will complete these sections as a group.

Complete the relevant section of the following document.

A. Datum Project Requirements Analysis
Document Reference Number: JC310110/3
Document Author
Date

Jason Carlson
31st January 2010

Summary of business requirements

This section provides a summary of the information collected during the business requirements
analysis task. It is important to clearly define the needs that must be addressed so that the
organization can perform its business tasks more effectively and efficiently:

Summary of functional requirements

This section lists the functional requirements identified during the requirements analysis task. The
functional requirements define how the proposed technology will address the projects business
requirements. This section may be quite extensive, as it relates to many areas such as: performance,
security, manageability, usability, availability, and scalability:

1-70

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

(continued)
A. Datum Project Requirements Analysis
Summary of additional requirements
This section lists the additional requirements identified during the requirements analysis task.
Additional requirements may include data related to additional stakeholders, required technology,
and user requirements:

Project priorities and constraints

This section outlines the identified project priorities and constraints. During the requirements
analysis task, specific priorities should have been identified related to the schedule, resources, or
features that must, or must not, be included in the project:

Task 3: Discuss the components that you will need to include in the Exchange Server
design to meet the company requirements
You will complete these sections as a group.

Discuss the following questions:

1.

What components will you need to include in the Exchange Server 2010 deployment to meet the
business requirements?

2.

What components will you need to include in the Exchange Server 2010 deployment to meet the
technical and additional requirements?

Results: After this exercise, you should have completed the A. Datum Project Requirements documents.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-71

Exercise 3: Discussion: Real-World Best Practices for Setting Budget

Expectations
Scenario
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.
The main task for this exercise is to answer the following questions.

Task: Answer the following questions

Question: What information is required to set the preliminary budget?

Question: How do you resolve scenarios where addressing all of the requirements will cost
significantly more than the proposed budget?

Results: After this exercise, you should have answered the preceding questions.

1-72

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Exercise 4: Discussion: Refining the Scope of SLA Requirements

Scenario
Humongous Insurance is a large provider of life, disability, and health insurance. There are three locations
in the United States that perform administrative functions: New York, Los Angeles, and Dallas. Each office
has approximately 400 people. All users in these locations access their email internally by using the full
Office Outlook client, but occasionally also need to remotely access to their mail.
The Active Directory forest consists of a single domain (humongousinsurance.com) with each physical
location configured as a site. Each site has a single domain controller, a file server, and several application
servers that are used for specialized insurance software. Each domain controller is configured as a global
catalog server.
New York serves as a central hub for network communication. There is a 10-megabits per second (Mbps)
link from New York to Los Angeles, and another 10-Mbps link from New York to Dallas. Finally, there is a
10-Mbps Internet connection in New York. Other locations do not have direct Internet connectivity.
There are 85 independently owned sales offices throughout the United States. The sales offices are not
part of the humongousinsurance.com Active Directory forest. The software that the sales offices use to fill
out policy information sends applications as an encrypted attachment in email. As part of the Exchange
Server 2010 rollout, users in these offices will be given Humongous Insurance email accounts.
The initial plan for Exchange Server 2010 implementation includes configuring a single Exchange Server in
each physical location to service that locations users. The Exchange Server in New York will also service
the sales offices. Each Exchange server will perform the roles of Mailbox server, Hub Transport server, and
Client Access server. An additional Exchange server in New York will perform the Edge Transport server
role.
The chief information officer (CIO) and chief operating officer (COO) created the first draft of high
availability requirements for the new Exchange Server 2010 system. These requirements are the starting
point for SLA development. In the role of the projects technical lead, review this information and
determine what additional information is necessary to create a useful SLA.
In this exercise, you will refine the scope of SLA requirements.

High Availability Information Requirements document

Authors: Marcel Truempy (CIO) and Gregory Weber (IT Steering Committee Chairman)
The availability requirements for Exchange Server 2010 are:

All users must be able to access their mailboxes at all times.

Messages must be delivered inside the organization within minutes.

Users must be able to send and receive email from the Internet at all times.

If an Exchange Server fails, users should experience very little disruption in service, and no mail
messages should be lost.

Requests for restored mailboxes and messages must be processed as soon as possible.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-73

The main tasks for this exercise are as follows:

1.

Review the high availability requirements document that the CIO and COO have created.

2.

Create a list of additional information necessary to create the SLA.

3.

Discuss your solution with the class.

Task 1: Review the high availability requirements document that the CIO and COO
have created

Review the requirements documentation.

Task 2: Create a list of additional information needed to create the SLA

1.

Working with group members, brainstorm a list of other information that is required to create the
SLA.

2.

Complete the relevant section of the following document.

A. Datum Refining the Scope of SLA Requirements
Document Reference Number: JC310110/4
Document Author
Date

Jason Carlson
31st January 2010

Questions

Task 3: Discuss your solution with the class

Participate in the discussion led by your instructor.

Results: After this exercise, you should have completed the High Availability Information document.

1-74

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

To prepare for the next module

When you finish the lab, start the virtual machines that will be required for the next lab. To do this,
complete the following steps:
1.

On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2.

In Hyper-V Manager, click 10233B-NYC-DC1, and in the Actions pane, click Start.

3.

In the Actions pane, click Connect. Wait until the virtual machine starts.

4.

Log on using the following credentials:

5.

User name: Administrator

Password: Pa$$w0rd

Domain: Contoso

Repeat steps 2 to 4 for virtual machines 10233B-NYC-SVR1.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 1-75

Module Review and Takeaways

Review Questions
1.

In relation to functional requirements, what is a use case?

2.

What are the key areas addressed by an SLA?

3.

What are some typical project constraints?

4.

A. Datum has 50 databases. In a five week period, each database is unavailable for 30 minutes each.
What is the percent service availability as measured by the proportional uptime of the databases?

5.

What would the database unavailability need to drop toper databaseto achieve 99.99% uptime?

Best Practices
Supplement or modify the following best practices for your own work situations:

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 projects success.

As much as possible, ensure that your messaging solution addresses the needs of your usersif the
first user experience of a new system is positive, the system is more likely to be accepted.

1-76

Introduction to Designing a Microsoft Exchange Server 2010 Deployment

It is critical that the monitoring, reporting, and reviewing tasks in the service level management
process are performed; without these tasks, the value of an SLA is reduced significantly

Ensure that the information you collect that relates to your existing infrastructure remains current;
that is, it includes any planned changes to the environment that may impact the Exchange Server
2010 deployment.

2-1

Module 2
Designing Microsoft Exchange Server 2010 Integration
with the Current Infrastructure
Contents
Lesson 1: Designing the Network Infrastructure

2-3

Lesson 2: Designing the AD DS Infrastructure

2-16

Lesson 3: Designing the DNS Infrastructure

2-32

Lesson 4: Planning Exchange Server Administration

2-40

Lab: Designing Exchange Server Integration with the

Current Infrastructure

2-55

2-2 Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Module Overview

You will seldom deploy Microsoft Exchange Server 2010 into an organization with no pre-existing IT
infrastructure. Consequently, it is important that you understand what networking components must be in
place, and how they must be configured in order to properly support Exchange Server 2010.
After completing this module, you will be able to:

Design the network infrastructure.

Design the Active Directory infrastructure.

Design the Domain Name System (DNS) infrastructure.

Plan Exchange Server 2010 administration.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-3

Lesson 1

Designing the Network Infrastructure

Exchange Server relies heavily on a number of underlying network components. Thoroughly

understanding the configuration of these components helps to ensure that your Exchange Server
organization operates optimally.
After completing this lesson, you will be able to:

Identify the network requirements for Exchange Server deployments.

Identify the Internet access considerations for client access.

Identify the network considerations for client access.

Identify the network considerations for message routing.

2-4 Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Identifying the Network Requirements for Exchange Server 2010

Deployments

The four network cornerstones of a successful Exchange Server 2010 deployment are: Active Directory
Domain Services (AD DS), DNS, an appropriately configured routing infrastructure, and Internet
connectivity.

AD DS
Exchange Server 2010 uses AD DS to store configuration information, and to share directory data with
Windows servers.
If your organization already has AD DS implemented, you must understand the changes that you must
make to AD DS to support Exchange Server 2010.
If your organization does not currently have AD DS implemented, then you can consider making less
constrained design decisions when planning your Exchange Server 2010 deployment; however, you must
consider how best to migrate from your existing directory service.
When you begin planning your Exchange Server 2010 deployment, consider the following facts relating to
AD DS:

Schema and related changes. When you deploy Exchange Server 2010, you must make certain
schema and configuration changes to AD DS. In larger organizations, you must plan for these
changes carefully. For example: support teams that are involved in the process of making schema
changes may differ from support teams involved in deploying and maintaining the messaging
infrastructure. There may also be applications deployed within the organization that will be impacted
by the required schema changes. In smaller organizations, these changes may have a less significant
impact on users or installed applications. In addition, smaller organizations often use a single team of
support staff for all infrastructure projects.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-5

Site configuration. Exchange 2000 Server and Exchange Server 2003 both used routing groups as a
means for determining the optimum delivery path for messages within an organization. Exchange
Server 2010 uses the AD DS site configuration. The current site configuration might be entirely
suitable for optimizing message delivery, but it may also not be. You may need to reconfigure the
existing site configuration to better support the Exchange Server 2010s needs. This may involve
modifying the AD DS site configuration directly, or overlaying an Exchange Server 2010 specific site
configuration.

Placement of domain controllers and global catalog servers. Exchange Server 2010 requires access to
both domain controllers and global catalog servers in order to perform various functions, including
message routing and delivery, distribution list expansion, and accessing address lists and email
address policies. You must ensure that you deploy sufficient domain controllers and global catalog
servers in each site.

DNS
DNS supports a number of critical functions in any messaging solution. For example, DNS is responsible
for:

Enabling messaging servers in remote organizations to resolve the name and IP address of servers
within your organization that are responsible for handling inbound Simple Mail Transfer Protocol
(SMTP) email.

Enabling messaging servers in your organizations to resolve the name and IP address of servers within
other organizations that are responsible for handling their inbound SMTP email.

Supporting the resolution of names to IP addresses for internal SMTP communications between Hub
Transport servers within your organization.

Supporting the resolution of names to Edge Transport server IP addresses, or other SMTP relays, for
Hub Transport servers within your organization.

Supporting the resolution of names to Hub Transport server IP addresses, for the Edge Transport
servers or other SMTP relays within your organization.

Providing site location information about Exchange Server 2010 services. This also requires AD DS.

Routing Topology
The purpose of an AD DS site is to define a geographic boundary that represents a collection of servers
and services that are connected with high-speed, low-latency network devices. Typically computers within
an AD DS site need not be too concerned about the availability of network bandwidth. When computers
in a different geographic location are connected to the first location, if the devices that interconnect them
introduce too much latency, or do not provide sufficient bandwidth, the AD DS administrators create a
new AD DS site for the new location. The administrators also configure the site connections between the
two sites. These site connectors are a logical representation of the underlying network devices that
interconnect the two locations. They define a cost and an AD DS replication interval and schedule.
Both Exchange Server 2007 and Exchange Server 2010 use the existing AD DS site configuration to make
message routing decisions. Therefore it is important that the existing site configuration is properly
configured, and that the necessary Exchange Server 2010 services are deployed to each site. The existing
routing topology and the AD DS site configuration that maps to it may not be ideally suited to supporting
your Exchange Server 2010 deployment.

2-6 Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Internet Connectivity
Email is a critical communications tool. Without email, an organizations functionality is impaired. Most
organizations use email as a primary external communications mechanism. The Internet provides the
mechanism through which this communication is routed. Your organization probably already has a
connection to the Internet, and you must consider the current configuration when planning the Exchange
Server 2010 deployment.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-7

Identifying the Internet Access Considerations for Client Access

Many organizations allow their employees to access their email and related data from locations other
than the corporate intranet. However, often there is no single way in which employees access this data.
For example, some users may choose to use a web browser to access their email, while others use mobile
devices such as a mobile phone installed with Windows Mobile. In addition, the computers with which
users access their data might not be managed computers, and consequently, security issues might be
more of a concern.
When planning client access from the Internet, you must consider the following factors:

Device types. The type of device with which a user accesses their remote messaging data will vary.
Some users will use a web browser, others will use Windows Mobile devices, while others will use an
email client that supports protocols such as Post Office Protocol 3 (POP3) or Internet Message Access
Protocol 4 (IMAP4). You must understand the security implications and protocols used by each of
these devices, and these implications on your organization.

DNS configuration. It is important that remote client computers and devices are able to resolve
designated names, in order to access messaging services. For example, the external URL name of the
Client Access server role for a remote user must resolve to the appropriate reverse proxy interface in
the corporate perimeter network. Likewise, since an email program is configured with the name of a
remote POP3 server for mail retrieval, the client computer must have a mechanism for resolving the
name to the appropriate IP address.
Note It is tempting to use IP addresses when configuring email clients, rather than using
server fully qualified domain names (FQDNs). Avoid this practice, as it creates additional
management issues. For example, if the server providing an email client service changes,
you must update the configuration of all affected client computers. Additionally, digital
certificates that are provided to enable authentication and encryption between clients and
servers are configured with a subject name that matches the designated servers published
FQDN; if an IP address is used, this will at best raise an error on the client, and at worst,
prevent email retrieval.

2-8 Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Firewall ports. Understanding the type of device and the protocol being used by the client enables
you to configure the firewalls that separate the clients from the Exchange Server 2010 server. Your
aim should always be to open a port only if its use is unavoidable. Remember that in addition to the
external Internet-facing firewall and the internal perimeter network firewall, you must consider the
Windows firewall configuration. The following table describes the common clients and their
respective protocols and the ports used.
Client type

Protocol and port

Microsoft Outlook
Web App

HTTPS; TCP port 443

Microsoft Exchange
ActiveSync

HTTPS; TCP port 443

POP

POP3; TCP port 110 (or port 995 for Secure Sockets Layer (SSL))

IMAP

IMAP4; TCP port 143 (or port 993 for SSL)

Outlook Anywhere

HTTPS; TCP port 443

Certificates. Because of the importance of using SSL secure network traffic between Client Access
servers and messaging clients, you must ensure that you deploy the appropriate certificates on the
Client Access servers. You can secure all client connections to the Client Access server using SSL.
Note By default, the Client Access server is configured with a self-signed certificate that is
not trusted by clients. You should remove this certificate, and install a certificate from a
trusted certification authority (CA).
An important consideration when planning the use of certificates is identifying the source of the
certificates. Exchange Server 2010 can use self-signed certificates, or certificates issued by either a
public or private CA. Each type of certificate has benefits and disadvantages. In Exchange Server 2010,
although you can use the self-signed certificates for internal communicationsuch as for securing
SMTP connections between Hub Transport serverswe do not recommend this. Similarly, you also
can use these self-signed certificates to secure client connections to Client Access servers, but because
none of the client computers trust this certificate, we do not recommend this solution either. Rather,
you should consider obtaining a certificate from a public CA or internal CA for all Client Access
servers.
For clients to connect to the Client Access server using SSL without receiving an error message, the
names on the certificate must match the names that the clients use to connect to the server. For
example, if your users connect to the Outlook Web App site using a URL such as
https://mail.contoso.com, and they connect to the IMAP4 server using a name such as
IMAP.contoso.com, you need to ensure that the certificates you use support both server names.
Additionally, if you enable Autodiscover access from the Internet, your certificate also must support a
name such as Autodiscover.contoso.com.
You can implement this configuration by using the following options:

Obtain a separate certificate for each client protocol that requires a unique name. This may
require multiple certificates for all Client Access servers. This may also require multiple websites in
Internet Information Services (IIS). This is the most complicated option to configure.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-9

Configure all clients to use the same server name. For example, you could configure all clients to
use the server name mail.contoso.com, and obtain a certificate for just that one name.

Obtain a certificate with multiple subject alternative names. Most public CAs support the use of
multiple names in the certificates subject alternative name extension. When you use one of these
certificates, clients can connect to the Client Access server using any of the names listed in the
subject alternative name.

Use a certificate with a wildcard name. Most public CAs also support the use of wildcards in the
certificate request. For example, you could request a certificate using the subject of
*.contoso.com, and use that certificate for client connections.

Note Not all clients support wildcard certificates. Microsoft Office Outlook, Windows
Internet Explorer, and Window Mobile 6 or newer clients support wildcard certificates, but
you need to verify this functionality for all messaging clients that are used in your
organization before deploying these certificates.

Public computer access. It is possible that users will use public computers to access their messaging
data. For example, a user might use a computer located in an Internet caf to read their email.
Because public computers are unmanaged, they are unmanageable. You must plan carefully for what
type of access you will allow from public computers. For example, if users are using Outlook Web
Access to access their email and any attachments, you can impose limitations on how message
attachments are handled.

Mobile device security. Mobile devicesespecially mobile phonesare prone to becoming lost or
stolen. If these devices contain sensitive corporate or private information and data, there is a
corresponding security risk posed by these devices. You must configure client access to mitigate the
security risks.

High availability. Your users rely on your messaging environments so that they can perform critical
business tasks, and it is extremely important for your messaging solution to be available when
required. High availability is a commonly used term that refers to a specific technology or
configuration that helps to ensure service availability. In Exchange Server 2010, all client access to the
Mailbox role is handled by the Client Access roleeven Messaging Application Programming
Interface (MAPI)-based client communication. Consequently, it is more important than ever that the
Client Access server role is highly available to your Internet-based clients. Exchange Server 2010 uses
client access arrays to provide for this high availability. A client access array is a load-balanced
collection of Client Access servers that are contained in a single site.
To create a client access array, you first must deploy multiple Client Access servers. Next, you need to
use either hardware or software-based network load balancing (NLB) to create a cluster. Then, add
the name for the network load-balanced cluster into DNS. After adding the DNS record, you can
create the client access array and assign it to an AD DS site using the New-ClientAccessArray
cmdlet. Finally, you must assign the client access array to each of the mailbox databases in the site
using the Set-MailboxDatabase cmdlet with the RpcClientAccess parameter to specify the name
of the client access array.
A client access array can exist only in a single AD DS site. Therefore, you would need to create a client
access array in each AD DS site that needs to load balance Client Access servers.

2-10

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Load balancing. It is important that client access requests are serviced in a timely manner. The
provision of multiple Client Access servers in a client access array not only improves high availability
of the client access role, but also distributes the workload amongst the Client Access servers in the
array.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-11

Identifying the Network Considerations for Client Access

Many of the considerations of providing Internet-based client access apply equally to the local network
environment. Firewall configuration, certificates, load-balancing, and high availability all remain factors in
your design, whether the client is local or remote. However, it is important to understand how the Client
Access role fits within the context of your existing network infrastructure, and to consider any changes
that you might need to make to that infrastructure to better support the role.
Note Implementing Exchange Online may introduce additional Client Access Server
configuration changes. It is important that you consider your Exchange Online
implementation when designing your Client Access Server network configuration. For
further information about the changes that may be introduced by Exchange Online
deployments, refer to Module 12.

AD DS
The Client Access server role uses AD DS, and specifically the global catalog service, to locate the site that
contains a users mailbox. Consequently, you must ensure that each Client Access server has local access
to a global catalog server.

Perimeter Network Configuration

Because the server running the Client Access server role must be a member server in an AD DS domain,
you cannot deploy the Client Access server role in a perimeter network. Instead, use an application layer
firewall, such as Microsoft Forefront Threat Management Gateway, to publish the Client Access server
services to the Internet.

Site Design
In Exchange Server 2010, all messaging clients accessing an Exchange Server 2010 mailbox connect to a
Client Access server. For users to access their mailbox, you must deploy a Client Access server in the same
site as the Mailbox server.

2-12

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Note Client access to public folder content is handled by the Mailbox server rather than
the Client Access server role.
Note In Exchange Server 2007 or earlier Exchange Server versions, MAPI clients such as
Office Outlook connect directly to Mailbox servers. In Exchange Server 2010, with the
introduction of the Remote Procedure Call (RPC) Client Access service, MAPI clients no
longer connect directly to the Mailbox servers for mailbox access.
Deploying Client Access servers in an environment with multiple AD DS sites adds complexity to
deployment planning, particularly when you consider the options for providing Internet access to those
Client Access servers.
In a single-site scenario, the Client Access server communicates directly with Mailbox servers. In a
multiple-site scenario, clients are directed to a Client Access server located in the same site as the Mailbox
server, or a Client Access server in a remote site might proxy a request to a Client Access server in the
same site as the Mailbox server. The option you select for a multiple-site scenario depends on whether
clients can connect directly to a Client Access server in the same site as their mailbox.
If you have multiple AD DS sites, you can provide Internet access to each sites Client Access server. To
enable this option, you must configure an external URL for each Client Access server. You also must
ensure that clients can resolve the URL name in DNS, and can connect to the Client Access server using
the appropriate protocol.

Public Key Infrastructure

Certificates, and the authorities that issue and maintain them, form part of your Public Key Infrastructure
(PKI).
Generally, you should deploy a certificate issued by a public CA if users access the Client Access server
from the Internet. In this scenario, it is important that the clients trust the certificate.
However, you could consider using an internal or private CA, only if computers that are members of the
internal domain access the Client Access server. In this scenario, by deploying an Enterprise CA, you can
automate the process of distributing and managing certificates and certificate revocation lists.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-13

Identifying the Network Considerations for Message Routing

When you begin to plan your message routing infrastructure, there are a number of important factors
regarding the existing network infrastructure that you must consider.

Routing Topology
By default, Hub Transport servers use direct relay to other Hub Transport servers for messages that must
be routed to other AD DS sites. That is, they establish a direct connection using SMTP over Transmission
Control Protocol (TCP) port 25 to the target Hub Transport server. To facilitate this, it is important that an
efficient Transmission Control Protocol/Internet Protocol (TCP/IP) routed infrastructure exists between
geographic locations represented by site objects in AD DS.

Site Design
The Hub Transport server uses the site-link cost assignment to determine a routing; the originating Hub
Transport server uses IP site-link costs to determine the lowest cost path to the destination site. It is
therefore important that the AD DS site configurationincluding the site-link costsare configured
appropriately to support efficient message routing. If they are not, and you are unable to reconfigure
them due to other AD DS-aware applications having different needs than Exchange Server 2010, you can
do one of the following:

Configure one or more AD DS sites in your organization as Exchange Server 2010 hub sites. When a
hub site exists along the least-cost routing path between two Hub Transport servers, the messages
are routed to a Hub Transport server in the hub site for processing before they are relayed to the
destination server. The Hub Transport server routes a message through a hub site only if it exists
along the least-cost routing path. The originating Hub Transport server always calculates the lowestcost route first, and then checks if any of the sites on the route are hub sites. If the lowest-cost route
does not include a hub site, the Hub Transport server will attempt a direct connection.

2-14

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Note Use the Set-ADSite Identity sitename HubSiteEnabled $true cmdlet to configure a
site as hub site.

Configure Exchange-specific routing costs. You also can modify the default message routing topology
by configuring an Exchange-specific cost to an AD DS IP site link. If you assign an Exchange serverspecific cost to the site link, the Hub Transport server uses this attribute instead of the AD DSassigned cost to determine the least-cost routing path.
Note Use the Set-AdSiteLink Identity ADsitelinkname ExchangeCost value cmdlet to
assign Exchange specific routing costs. You also can use the Set-AdSiteLink Identity
ADsitelinkname MaxMessageSize value cmdlet to assign a maximum message size limit
for messages sent between AD DS sites.

Edge Configuration
In Exchange Server 2010, internal message routing is handled by the Hub Transport server role. In typical
deployments, we recommend that you deploy one or more Edge Transport servers in your perimeter
network to handle external message routing to and from the Internet. If you are not deploying an Edge
Transport server, you will need to configure the Hub Transport server to enable inbound and outbound
mail flow.
Note To enable inbound mail flow, configure an SMTP Receive connector to accept
anonymous connections on port 25 using a network interface that is accessible from the
Internet. To enable outbound email flow, configure an SMTP Send connector with an
address space of *that can use DNS or a smart host to send messages to the Internet.
If you are using the Hub Transport server to send and receive email from the Internet, you should
configure antivirus and anti-spam agents on the Hub Transport server.
We strongly recommend that you use an Edge Transport server role or some other SMTP relay server to
send and receive messages from the Internet. If you are using an SMTP gateway server other than an
Exchange Server 2010 Edge Transport server role, you still will need to configure the SMTP Send
connector and SMTP Receive connector. The only difference is that you should configure the SMTP
gateway server as the smart host on the SMTP Send connector, and accept only connections from the
SMTP gateway server on the SMTP Receive connector. As an alternative to managing your own Edge
Transport server role, you should also consider Exchange Hosted Services.
Once you have established the precise mechanism that you will use to handle external message routing,
you must consider the firewall settings between the corporate network, the perimeter network, and the
Internet. Server-to-server communications between the internal and perimeter network is over
Transmission Control Protocol (TCP) port 25. Likewise, communication between SMTP hosts on the
Internet is over TCP port 25. If you intend supporting remote clients that use POP or IMAP for mail
retrieval, you must consider providing SMTP connectivity to enable those clients to send email. It is
convention to use TCP port 587 to support client SMTP relaying; this port must be open on the external
firewall.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-15

Global Catalog
Routing decisions made by the Hub Transport server are based on information stored in AD DS.
Consequently, you must ensure that each Hub Transport server has local access to a global catalog server
to ensure that it can perform the necessary routing queries.
Note Routing decisions made by Edge Transport servers are based on information stored
in AD DS Lightweight Directory Services (AD LDS).

Exchange Online
If you rely solely on an Exchange Online messaging solution within your organization, then there is no
message routing within your organization. However, in hybrid deployment, in which both an on-premises
and an Online Exchange environment will coexist, messages flow from the Internet to your on-premises
Exchange servers. Where applicable, messages then flow from your on-premises Exchange servers to the
recipients mailboxes in the cloud. Consequently, implementing Exchange Online may introduce
additional message routing considerations. For example, you must deploy at least one Exchange Server
2010 SP1 Hub transport in your organization.
Note For further information about the changes that may be introduced by Exchange
Online deployments, refer to Module 12.

2-16

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Lesson 2

Designing the AD DS Infrastructure

Exchange Server 2010 depends on AD DS to store the Exchange Server 2010 specific configuration and
recipient information. This means that the AD DS design can have a significant impact on the Exchange
Server 2010 design, and on the performance of the Exchange Servers and messaging clients. This lesson
describes the AD DS requirements for Exchange Server 2010, and the implications that the AD DS design
has on the Exchange Server 2010 design.
After completing this lesson, you will be able to:

Identify the AD DS design owners.

Design the AD DS forest.

Design the AD DS domain.

Design the AD DS sites for Exchange Server 2010.

List the considerations for deploying Exchange Server 2010 servers in AD DS sites.

Design a domain controller placement strategy.

List the considerations for modifying the current AD DS design.

Plan the preparation of AD DS to support the Exchange Server 2010 deployment.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-17

Identifying the AD DS Design Owners

In most small or medium-sized organizations, the same administrator or administrator group is likely
responsible for the AD DS and Exchange Server 2010 infrastructure. Larger organizations often split these
roles between two different teams, who must work together because of the inter-relationship between the
AD DS and Exchange Server 2010 designs.
Note Exchange Server 2010 uses a split permissions model, which distinguishes between
AD DS permissions and Exchange Server 2010 permissions. This makes it easier to separate
the administrative tasks between the two services. However, during the design phase, the
AD DS and Exchange Server 2010 design teams must work together to ensure an optimal
AD DS and Exchange Server 2010 design.

Who Are the AD DS Design Owners?

AD DS design owners may be an individual administrator, or group of administrators, who are responsible
for the overall AD DS 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 AD DS administration.
The AD DS design owners are responsible for any changes to the AD DS environment that may impact the
entire forest. For example, in most organizations, the design owners must approve all schema changes,
including 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 AD DS design owners. However, these
groups should be used only to implement decisions that the actual design owners make.

2-18

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Some organizations may have multiple teams of AD DS design owners. These organizations typically have
multiple AD DS 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 AD DS design owners, you may need to negotiate with all teams
during the Exchange Server 2010 design.

Importance of Working with the AD DS Design Owners

You must review the AD DS design as part of the Exchange Server 2010 design process, during which you
identify issues where the AD DS design is not optimized for Exchange Server 2010. When you identify
these issues, you then must work with the AD DS design owners to understand the current designs
rationale, and to explore options for changing it.
If you identify issues with the AD DS design that may impact the Exchange Server 2010 design, you might
convince the AD DS design owners to modify the AD DS design. In other cases, the AD DS design owners
may have good reasons for why they cannot change the design, and you may need to modify the
Exchange Server 2010 design.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-19

Designing the AD DS Forest

The AD DS forest design can impact the Exchange Server 2010 design significantly. The Exchange Server
2010 organization boundary is always the same as the AD DS forest boundary. Although you can deploy
Exchange Server 2010 in a multiple forest environment, it is complicated to design this type of Exchange
Server 2010 deployment.

AD DS Forest Options
Exchange Server 2010 supports a variety of AD DS forest options, including:

No forest. If you do not deploy AD DS, you still can deploy an Exchange Server 2010 computer
running the Edge Transport server role. The Edge Transport server role stores server configuration
information in Active Directory Lightweight Directory Services (AD LDS), rather than AD DS.

Single forest. In this topology, you install Exchange Server in a single AD DS forest that spans the
entire organization. The same forest contains all user and group accounts, and all of the Exchange
Server 2010 configuration information.

Resource forest. In this topology, you install Exchange Server 2010 in an AD DS forest that does not
contain the user and group accounts. Organizations that require a secure boundary between the
administration of AD DS and Exchange Server 2010 use this design. In a resource forest, you
designate one forest for accounts and authentication, and another for Exchange Server.

Cross-forest. In this topology, you install Exchange Server 2010 into multiple, different AD DS 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 Server 2010 deployment, and a unique Exchange Server organization object.

2-20

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Exchange Server 2010 Design in a Single Forest Environment

The Exchange Server 2010 organization boundary must correlate to the AD DS forest boundary. This
means that the single forest deployment is the easiest Exchange Server 2010 deployment to configure
and manage. The single forest option offers the following advantages:

Provides the richest set of email system features with the simplest deployment. 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 Server 2010 administrative groups.

Takes advantage of an existing AD DS structure. If you have already deployed AD DS, you can use the
existing structure, domain controllers, and the Global Catalog servers. Thus, you do not have to
deploy new servers.

A single forest has one disadvantageadministrators must determine how to share or divide
management responsibilities for AD DS and Exchange Server 2010 objects.
Best Practice A single forest means that the Exchange Server 2010 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 2010 Design in a Resource Forest Environment

If your organization has multiple forests, the preferred method for implementing Exchange Server is to
create an Exchange resource forest. In this scenario, you set up a separate AD DS forest that you dedicate
to running Exchange Server 2010 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 Server 2010
servers.
In a resource forest environment, the GAL is created in the Exchange Server 2010 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 Exchange 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 Exchange Server 2010 resource forests accounts and mailboxes.

Exchange Server 2010 Design in a Cross-Forest Environment

An organization with a cross-forest topology has multiple AD DS forests, each containing an Exchange
organization. Unlike an Exchange Server 2010 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, informationincluding mailbox rules and delegate permissionsdoes not
move when you move users between the Exchange organizations.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-21

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 groups 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.

Exchange Online
Implementing Exchange Online may introduce a number of design changes, depending upon your
intended messaging configuration. If you plan to implement an Exchange hybrid deployment, consider
the following factors:

Exchange hybrid deployments currently support single sign-on with only a single AD DS forest in
your on-premises AD DS. If you intend to implement a hybrid deployment, plan to implement a
single AD DS forest.

Single label SMTP domain names are not supported. For example, although Contoso.com is
acceptable, Contoso is not. When planning your AD DS forest name, ensure that you avoid using
single label SMTP domain names.

The Exchange Server 2010 SP1 (or higher) AD DS schema must be implemented to support hybrid
deployments.

To implement Active Directory Federation Services (AD FS) and single sign-on within your hybrid
deployment, the user principal name (UPN) of the forest root must be Internet-routable.
Consequently, you must give careful consideration to the internal AD DS forest domain name. For
example, Contoso.local or Contoso.Priv are not Internet-routable, while Contoso.com is. If your
current AD DS forest root UPN is not Internet-routable, it might be sufficient to change the UPN
suffix of all your existing users to a valid, registered, and routable domain suffix; this is a minor
change.

2-22

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Designing the AD DS Domain

You can deploy Exchange Server 2010 in several different domain configurations. Although deploying
Exchange Server 2010 in a single domain environment may be the simplest design, there is very little
difference between deploying Exchange Server 2010 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 AD DS tree. In this configuration, there is a single, top-level parent
domain, and all of the domains share a contiguous DNS namespace with that parent domain.

Multiple domains in multiple AD DS trees. In this configuration, 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. Exchange Server uses the forest root as a location for its security
groups.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-23

Domain Design Implications for Exchange Server 2010

Provided that all domains are in the same AD DS forest, there are few design implications for the
Exchange Server 2010 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 2010 services, and to Exchange recipients.
Note The functional level for all AD DS forest domains in which you deploy Exchange
Server 2010 must be Microsoft Windows 2000 Server native mode or higher. One reason
is that Exchange Server 2010 allows only universal security groups or universal distribution
groups to be mail-enabled. Additionally, when you prepare the AD DS forest for the
Exchange Server 2010 installation, several Exchange universal security groups are created
that set permissions on Exchange configuration objects. You can create universal security
groups only in a domain that is in Windows 2000 Server native mode or higher.
There are two domain options that may impact the Exchange Server 2010 design in a multiple domain
environment:

Create a dedicated domain for the Exchange Server 2010 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 Server administrators also can be the dedicated domain
administrators. This means that the administrators can perform all administrative tasks on the
Exchange Server 2010 servers without requiring any administrative rights in other AD DS 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 2010 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 2010 domain, and this configuration may require additional
domain controllers for the domain in other locations.
Instead of deploying a dedicated domain for the Exchange Server 2010 servers, consider using the
Exchange Server 2010 Administrator role to delegate Exchange Server 2010 permissions. Users or
groups that you assign to this role receive full administrative permissions to the specific Exchange
Server 2010 computer.

Deploy Exchange Server 2010 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 SMTP addresses for the different business units users. By default, Exchange
Server 2010 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 email address policies to assign the required email addresses to the
different business units users.

2-24

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Designing the AD DS Sites for Exchange Server 2010

In an organization with multiple locations, the AD DS site design has a significant impact on the Exchange
Server 2010 design. Exchange Server 2010 and messaging clients use AD DS sites to locate domain
controllers, and to define message routing.

How Exchange Server 2010 Uses AD DS Sites

Exchange Server 2010 is a site-aware application, which means that Exchange Server 2010 servers
are aware of which site they are in, and use this information while providing messaging services. The
Microsoft Exchange AD DS Topology service determines and updates the site attribute of the Exchange
Server 2010 object. Exchange Server 2010 servers also can retrieve and use the site information for other
Exchange Server 2010 servers.
The Exchange Server 2010 server roles use AD DS site membership information as follows:

The Mailbox server role uses AD DS site membership information to determine which Hub Transport
servers are located in the same AD DS site as the Mailbox server. 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 AD DS site information to provide efficient access to user mailboxes. When the
Client Access server role receives a user connection request, it queries AD DS to determine which
Mailbox server is hosting both the users mailbox and the servers site membership. If the Client
Access server that received the initial user connection is not in the same site as the users Mailbox
server, then the connection is redirected or proxied to a Client Access server in the same site as the
Mailbox server.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-25

The Hub Transport server role retrieves information from AD DS to determine the organizations
internal and external mail routing. When a message is submitted to the Exchange Transport service,
the categorizer queries AD DS for information about where the message must be delivered. If
the recipients mailbox is on a Mailbox server in the same AD DS site as the Hub Transport server, it
delivers the message directly to that mailbox. If the recipients mailbox is on a Mailbox server in a
different AD DS site, then the message is relayed to a Hub Transport server in that site, which then
delivers it to the Mailbox server.The Unified Messaging server role uses AD DS site membership
information to determine which Hub Transport servers are located in the same AD DS site as the
Unified Messaging server. The Unified Messaging 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 AD DS to match a telephone numberor other UM property such as the users Mailbox
serverto a recipient account. The Hub Transport server delivers the message to a Mailbox server
within its same AD DS site, or relays the message to another Hub Transport server, which then delivers
it to a Mailbox server that is outside the AD DS site.

Considerations for Designing Exchange Server 2010 Sites

When designing the AD DS site configuration, consider the following factors:

Understand the rationale for the current AD DS site design. Organizations that have deployed AD DS
will already have implemented a site design that likely is based on AD DS design best practices. AD
DS 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 2010 deployment. You do not have to deploy Exchange
Server 2010 servers in each AD DS site. If high bandwidth and reliable network connections link all of
your organizations locationsregardless of the distance between officesyou should consider
implementing a centralized messaging system in which all Exchange Server 2010 servers are in one
central location. Because all Exchange Server 2010 serversand other required services such as
domain controllers and DNS serversare on the same fast network, this design will produce the best
Exchange Server 2010 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 AD DS site for Exchange Server 2010 servers. If you use a centralized
design for Exchange Server 2010 servers, or if you deploy several Exchange Server 2010 servers in a
data center, you should consider creating a dedicated AD DS site that contains all of the Exchange
Server 2010 servers in the location. You should also consider including domain controllers and Global
Catalog servers that are dedicated to providing directory services for the Exchange Server 2010
servers in that dedicated AD DS site. This design enables more predictable Exchange Server 2010
performance, because other clients are not using the domain controllers for authentication.Consider
modifying the AD DS site design. If the AD DS site configuration results in an inefficient Exchange
Server 2010 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 Server 2010 servers in both locations, you
should consider configuring separate sites to optimize domain controller access for Exchange Server
2010 servers and messaging clients.

2-26

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Deploying Exchange Server 2010 Servers in AD DS Sites

Exchange Server 2010 has a much stronger reliance on AD DS sites than previous Exchange Server
versions. Therefore, you must consider the AD DS site configuration when you design the Exchange Server
2010 deployment.

Considerations for Deploying Exchange Server 2010 Servers in AD DS Sites

Consider the following information when deciding whether to deploy Exchange Server 2010 servers in an
AD DS site.

The first decision you must make when designing the Exchange Server 2010 deployment is whether
to place a server running the Mailbox server role in the AD DS 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 sites Mailbox server. You also must deploy a Client Access server in the site to enable
users to access Office Outlook 2007 or Office Outlook 2010 client features, including Autodiscover
and Availability services, or to access their mailboxes via Outlook Web App 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 2010 server rolesexcept the Edge Transport
server and clustered mailbox serverson the same server. This means that in a small site, a
single computer can hold all of the required server roles.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-27

Designing a Domain Controller Placement Strategy

As part of the AD DS 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 2010 and
messaging client performance significantly.

How Exchange Servers Locate Domain Controllers

Like other AD DS clients, Exchange Server 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 service (SRV) resource 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 2010 to find domain controllers and global catalog servers in the
local AD DS site.
Each Exchange Server 2010 server is configured dynamically with its site each time it authenticates to AD
DS. As part of the authentication process, the site name is stored in the registry. If the computer running
Exchange Server 2010 is a domain controller, the server determines its site by comparing its IP address to
the site configuration information that the AD DS 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 2010 server. To ensure a positive user experience, all Exchange Server servers and
Office Outlook users must have fast access to a global catalog server.

2-28

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Note The Windows Server 2008 operating system provides a new type of domain
controllera read-only domain controller (RODC). Exchange Server 2010 does not use
RODCs, or RODCs that you configure as read-only global catalog (ROGC) servers. This
means that you should not deploy an Exchange 2010 server in any site that contains only
RODCs or ROGC servers.

For security and performance reasons, you should not run Exchange Server 2010 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 2010 to become a
domain controller. Once you install Exchange Server 2010, changing its role from a member
server to a domain controller, or vice versa, is not supported.

As a general guideline, you should implement Exchange processors to global catalog server
processors in an 8:1 ratio in each site, assuming that the processors are similar models and speeds. In
some situations, however, if AD DS includes a large number of users or you have large distribution
lists, you may need more global catalog servers.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-29

Discussion: Considerations for Modifying the Current AD DS Design

The Exchange design may require some AD DS changes. However, it can be difficult to modify the AD DS
design in a large, complex organization.

Discussion Questions
Based on your experience, consider the following questions:
Question: What impact might result from changing the AD DS design in a large, complex
company?

Question: How can you balance the complications of modifying the current AD DS design
with the optimal Exchange Server-based design?

Question: How can you help an organization determine whether to modify the AD DS
design?

2-30

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Planning for AD DS Preparation to Support the Exchange Server 2010

Deployment

To install Exchange Server 2010, you must run the Exchange Server 2010 setup command to prepare the
AD DS forest for the installation. In smaller organizations, it is quite probable that a single individual will
prepare AD DS to support Exchange Server when deploying the first Exchange Server. In larger
organizations, different teams of support staff may be involved in the various stages of the preparation
process.
You can use the setup command with the following switches:
Setup switch

Explanation

/PrepareAD
/OrganizationName:
organizationname

Prepares the global Exchange objects in AD DS, creates the Exchange

Universal Security Groups in the root domain, and prepares the current
domain.
Must be run by a member of the Enterprise Admins group.

/PrepareLegacy
ExchangePermissions

Is necessary if the organization contains Exchange Server 2003 servers.

Modifies the permissions assigned to the Enterprise Exchange Servers
group to allow the Recipient Update Service to run.
Must be run by a member of the Enterprise Admins group.

/PrepareSchema

Prepares the schema for the Exchange Server 2010 installation.

Must be run by a member of the Enterprise Admins and Schema Admins
groups.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-31

(continued)
Setup switch
/PrepareDomain
/PrepareDomain
domainname
/PrepareAllDomains

Explanation
Prepares the domain for Exchange Server 2010 by creating a new global
group in the Microsoft Exchange System Objects container called
Exchange Install Domain Servers.
Is not required in the domain where /PrepareAD is run.
Can prepare specific domains by adding the domains FQDN, or prepare
all domains in the forest.
Must be run by a member of the Enterprise Admins and Domain Admins
groups.

Note You must prepare the AD DS forest in the same domain and the same site as the
domain controller that hosts the Schema Master role.

Options for Preparing AD DS

You have the following options when you prepare AD DS for Exchange Server 2010:

In an organization that is not running an earlier Exchange Server version, and which has a single
domain in the AD DS forest, you do not need to prepare AD DS before installing the first Exchange
Server. In this scenario, you can just install Exchange Server 2010, and all of the AD DS schema
changes are implemented during the installation.

If the user account that you are using to update the schema is a member of the Schema Admins and
the Enterprise Admins group, you do not need to run /PrepareLegacyExchangePermissions and
/PrepareSchema before running /PrepareAD. If your account has the necessary permissions, the
/PrepareAD process also configures the legacy permissions and makes the required schema changes.

Running setup with the /PrepareAD parameter performs the following actions:

Prepares the schema if /PrepareSchema has not been run, and the command is run by a Schema
Admins group member.

Prepares the permissions if /PrepareLegacyExchangePermissions has not been run, and the command
is run by an Enterprise Admins group member.

Creates the Microsoft Exchange container in the Configuration partition in AD DS, and populates the
container with all the child containers required to install Exchange Server 2010 computers.

Creates a new organizational unit (OU) in the AD DS domain named Microsoft Exchange Security
Groups, and then creates the security groups that are used to assign permissions in the Exchange
organization.
Note The security groups that are created in the Microsoft Exchange Security Groups OU
are management role groups that use role-based access control (RBAC) to assign
permissions in the Exchange organization.

2-32

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Lesson 3

Designing the DNS Infrastructure

Name resolution is an important foundation network service. Without it, many applications would be
unable to function correctly. This is true of Exchange Server 2010, which uses DNS in many ways. This
lesson explores the considerations surrounding DNS when you are planning to implement Exchange
Server 2010.
After completing this lesson, you will be able to:

List the considerations for DNS.

Describe split DNS.

Design a DNS infrastructure for Exchange Server.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-33

Considerations for DNS

Without a correctly configured DNS infrastructure, Exchange Server cannot function correctly.

Correctly Configured DNS

Consider carefully the following points that relate to DNS when planning Exchange Server deployments:

Ensure that all host records are correctly registered. Use of a dynamic name servicesuch as
Windows DNSensures this is achieved. If Exchange Server 2010 servers do not correctly register
their names and the services that they are running, they will not be contactable. By default, Exchange
Server 2010 registers with and performs queries against the DNS server configured on the TCP/IP
properties of the installed network adapter. You can change this default behavior by modifying the
Internal DNS Lookups and External DNS Lookups settings on the Exchange Server 2010 property
sheet by using the Exchange Management Console.

Configure the DNS suffix for each Exchange Server. Exchange servers supporting the Mailbox, Hub
Transport, Client Access, or Unified Messaging roles must be members of an AD DS domain; their
FQDN is automatically derived from the local hostname appended with the AD DS domain name.
However, it is important to remember you must manually configure the primary DNS suffix of the
Edge Transport servers in your perimeter network to match your currently configured default
authoritative accepted domain.

Configure Edge Transport server DNS resolver settings. The Edge Transport server sits in the
perimeter network and may be installed with two network interface cards (NICs), one of which is
Internet-facing, the other of which is internally connected. You must configure the network interface
that is connected to the external network to use a public DNS server for name resolution. This enables
the Edge server to resolve SMTP domain names to mail exchanger (MX) resource records, and route
mail to the Internet. You must configure the internal NIC to use a DNS server in the perimeter
network.

2-34

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

If your Edge Transport server has a single NIC, use the Internal DNS Lookups tab and the External
DNS Lookups tab to configure the appropriate DNS settings to enable appropriate name resolution.
You can access the DNS settings for your Edge Transport server by using the Exchange Management
Console, and then viewing the properties of your Edge Transport server.

Ensure that the Edge Transport servers and the Hub Transport servers are able to use DNS host
resolution to locate each other. You must manually create host records for the Hub Transport servers
in a forward lookup zone on the DNS server in the perimeter network. Additionally, you must create
host records for Edge Transport servers in a forward lookup zone on the internal DNS servers.

Avoid using single label domains. As discussed previously, this has long been a recommendation from
Microsoft, but with Exchange hybrid deployments, single label domain names are not supported.
Note In earlier Exchange Server versions, the Windows Internet Name Service (WINS) was
required in order to support multi-domain environments. This is no longer a requirement in
Exchange Server 2010.

Disjoint Namespace
In addition to ensuring the preceding steps have been performed, you must also consider the impact of a
disjoint DNS namespace on the Exchange organization. Typically, the primary DNS suffix of the computers
in an AD DS domain is the same as the DNS domain name. For example, in the domain Adatum.com,
computers will typically have a primary DNS suffix of Adatum.com. However, you may require the domain
name and the primary DNS suffix to be different from one another; this is called a disjointed namespace.
For instance, following a merger or acquisition, you may have a topology with a disjointed namespace.
In Exchange Server, there are two supported disjointed namespace scenarios:

The domain controller is disjointed. Computers that are members of this domain can be either
disjointed, or not disjointed. In this scenario, the primary DNS suffix of the domain controller is not
the same as the DNS domain name, but computers in the domainincluding Exchange servers and
Office Outlook client computerscan have a primary DNS suffix that either matches the primary DNS
suffix of the domain controller, or matches the DNS domain name.

A member computer in an AD DS domain is disjointed, even though the domain controller is not. In
this scenario, the primary DNS suffix of a computer on which Exchange Server 2010 is installed does
not match the DNS domain name; thus the member computer is disjointed. Member computers that
are running Office Outlook can have a primary DNS suffix that either matches the primary DNS suffix
of the disjointed Exchange server, or matches the DNS domain name.
Note To support either of these scenarios, you must modify the msDSAllowedDNSSuffixes AD DS attribute on the domain object container. You must add all of
the DNS suffixes to the attribute. In addition, to make sure that the DNS suffix search list
contains all DNS namespaces that are deployed within the organization, you must configure
the search list for each computer in the domain that is disjointed.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-35

DNS Required Records

In order to support messaging with third parties on the Internet, it is necessary for you to create and
configure two DNS namespaces:

The internal namespace supports internal name resolution, and resolution to and from the perimeter
network.

The external namespace is used by third parties on the Internet to locate your servers so that they
may route messages to your organization.

To enable Internet messaging functionality, you must make a number of configuration changes to your
external DNS zone. These changes include:

Adding appropriate MX and host (A or AAAA) resource records to your external DNS zone for your
SMTP hosts.

Adding a Sender Policy Framework (SPF) resource record in the external DNS zone that defines which
of your SMTP hosts is allowed to send email on behalf of your organization.

2-36

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

What Is Split DNS?

If you want to have a matching internal and external DNS namespace, that can pose certain problems;
however, split DNS can provide a solution to these problems. For example, in a non-split DNS
configuration for the domain Adatum.com, you might have a DNS zone that looks like the following
example:
Host

Record type

IP address

www

131.107.1.200

Relay

131.107.1.201

Webserver1

192.168.1.200

Exchange1

192.168.0.201

When a client computer on the Internet wants to access the SMTP relay using the published name of
relay.adatum.com, it queries the DNS server that returns the result 131.107.1.201. The client then
establishes a connection over SMTP to that IP address.
However, the client computers on the corporate intranet also use the published name of
relay.adatum.com. The DNS server returns the same resulta public IP address of 131.107.1.201. The
client now attempts to establish a connection to the returned IP address by using the external interface of
the publishing computer. Depending upon the client configuration, this may or may not be successful.
By configuring two zones for the same domain nameone on each of two DNS serversyou can avoid
this problem.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-37

The internal zone for adatum.com would now look like the following table:
Host

Record type

IP address

www

CNAME

Webserver1.adatum.com

Relay

CNAME

Exchange1.adatum.com

Webserver1

192.168.1.200

Exchange1

192.168.0.201

While the external zone for adatum.com would look like the following table:
Host

Record type

IP address

www

131.107.1.200

Relay

131.107.1.201

MX

Relay.adatum.com

Now client computers in the internal and external networks can resolve the name relay.adatum.com to
the appropriate internal or external IP address.

2-38

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Designing a DNS Infrastructure for Exchange Server

Your DNS infrastructure must be capable of meeting your Exchange Server organizations needs. These
needs include:

Server-to-server resolution. When any Exchange Server needs to communicate with any other
Exchange Server, they must be able to determine the appropriate IP address for a specific host name.
For example, if a Hub Transport server wishes to route mail to another Hub Transport server in
another site, it must first determine which computer is providing the Hub Transport server role in the
remote site. Then, it must resolve the returned name into the appropriate IP address.

Client-to-server resolution. When client computerseither attached to the internal network or

connected to the Internetwant to connect to a server, they must be able to resolve the designated
name to the appropriate IP address. For example, a client computer using Outlook Web Access and
provided with the external URL of a Client Access server in the users site, must resolve that name to
the external IP address of the publishing host in the perimeter network.

Outbound delivery from the Hub Transport server to the Edge Transport server. To ensure proper
routing of messages from the internal network to the Edge Transport server in the perimeter network,
the Hub Transport servers must be able to resolve the FQDNs of the Edge Transport servers as
defined in the Edge Subscription, to the appropriate IP address in the perimeter network. You must
add these records to the internal DNS zone.

Outbound delivery from the Edge Transport Server to the Internet. To ensure delivery of email from
the Edge Transport Server to the Internet, you must configure name resolution on the Edge Transport
servers. Configure the use of either a public DNS server, or configure an internal DNS server with
appropriately configured forwarding.

Inbound delivery to the Edge Transport Server from the Internet. To ensure successful delivery of
email from the Internet to the Edge Transport servers, you must configure appropriate MX and host
(A or AAAA) resource records in a publicly accessible DNS server. This enables third-party
organizations to locate your Edge Transport servers.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-39

Inbound delivery from the Edge Transport Server to the Hub transport server. In order to ensure
successful delivery of email from the Edge Transport servers to the Hub Transport servers, you must
configure the Edge Transport servers internal NIC to use a DNS server on the perimeter network that
hosts a zone to which you have added the necessary Hub Transport server host records.
Note By default, in Exchange hybrid deployments, messages are routed to the onpremises Exchange servers and then, where necessary, routed onwards to the Exchange
Online environment for those users whose mailboxes are hosted online. However, if you
wish to have email routed primarily to the Exchange Online environment, perhaps to take
advantage of the message hygiene services provided by Forefront Online Protection for
Exchange (FOPE), you can configure this behavior in the Online Portal, or in your DNS MX
records, or within FOPE.

2-40

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Lesson 4

Planning Exchange Server Administration

To ensure that your Exchange organization functions optimally, you must secure the organization
properly. Part of the process of securing the Exchange organization involves planning and implementing
an appropriate administrative model. This enables you to determine which users can perform specific
administrative tasks.
After completing this lesson, you will be able to:

Describe Exchange Server 2010 permissions.

Describe the split permissions model.

Describe the default Role Based Access Control configuration.

Design a custom management delegation strategy.

Design a management tool strategy.

Manage Exchange Server 2010.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-41

Exchange Server 2010 Permissions

Exchange Server 2010 implements a permissions model known as Role Based Access Control (RBAC). The
RBAC permissions model defines which administrative tasks specific users can perform. With RBAC, you no
longer have to modify and manage access control lists (ACLs) on Exchange Server or AD DS objects. In
Exchange Server 2010, RBAC controls the administrative tasks that users can perform, and the extent to
which they can administer their own mailbox and distribution groups.
RBAC assigns permissions to users in two primary ways, depending on whether the user is an
administrator or end user:

Management role groups. RBAC uses management role groups to assign permissions to
administrators. These administrators may require permissions to manage the Exchange Server
organization or some part of it. Some administrators may require limited permissions to manage
specific Exchange Server features, such as compliance or specific recipients. To use management role
groups, add users to the appropriate built-in role group, or to a custom role group. RBAC assigns
each role group one or more management roles that define the precise permissions that RBAC grants
to the group. Management role groups use several underlying components to define how RBAC
assigns permissions:

Role holder. A role holder is a user that you can add to a role group. When a mailbox becomes a
role-group member, RBAC grants it all of the permissions that the management roles provide. To
add mailboxes to a role group, you can either add the user account to the group in AD DS, or use
the Add-RoleGroupMember cmdlet.

Management role group. The management role group is a universal security group that contains
mailboxes that are role group members. Management role groups are assigned to management
roles. The combination of all the roles assigned to a role group defines everything that users
added to that role group can manage in the Exchange Server organization.

2-42

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Management role. A management role is a container for a group of management role entries.
These entries define the tasks that users can perform if RBAC assigns them the role using
management role assignments.

Management role entries. A management role entry is a cmdletincluding its parametersthat

you add to a management role. By adding cmdlets to a role as management role entries, you are
granting rights to manage or view the objects associated to that cmdlet.

Management role assignment. A management role assignment assigns a management role to a

role group. Once you create a management role, you must assign it to a role group so that the
role holders can use it. Assigning a management role to a role group grants the role holders the
ability to use the cmdlets that the management role defines.

Management role scope. A management role scope is the scope of influence or impact that the
role holder has once RBAC assigns a management role. When assigning a management role, use
management scopes to target which objects that role controls. Scopes can include servers, OUs,
recipient objects, databases, and more.

Note Database scopes were introduced in Exchange Server 2010 SP1 enabling you to
target specific databases based on database lists or filterable database properties.

Management role assignment policies. Management role assignment policies are used to assign enduser management roles. Role assignment policies consist of roles that control what users can do with
their mailboxes or distribution groups. These roles do not allow management of features with which
users are not associated directly. When you create a role assignment policy, you define everything
users can do with their mailboxes. For example, a role assignment policy may allow users to set
display names, set up voice mail, and configure Inbox rules. Another role assignment policy might
allow users to change their company information, such as addresses or phone numbers, use text
messaging, and set up distribution groups. Every user with an Exchange Server 2010 mailbox
including administratorsreceives a role assignment policy by default.

Direct User Role Assignment. You also can use Direct User Role Assignment to assign permissions.
Direct User Role Assignment is an advanced method for assigning management roles directly to a
user or Universal Security Group, without the need to use a role group or role assignment policy.
Direct User Role Assignment is useful when you need to provide a granular set of permissions to a
specific user only. However, we recommend that you avoid using Direct User Role Assignment, as it is
significantly more complicated to configure and manage.
Question: What requirements does your organization have for assigning Exchange Server
permissions? Does your organization use a centralized or decentralized administration
model? What special permissions will you need to configure?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-43

What Are Split Permissions?

In small organizations, it is often the case that the same group of people is responsible for administering
AD DS and Exchange Server. In larger organizations, it is usual to separate the management of AD DS
from other applications, including Exchange Server.
To help address this need for administrative separation, Exchange Server 2010 introduced split
permissions, enabling a degree of separation for the administration of these two facets of your messaging
infrastructure.

Role Based Access Control (RBAC) split permissions. Permissions to create security principals in the
AD DS domain partition are controlled by RBAC. Only those administrators who are members of the
appropriate role groups can create security principals.

Active Directory split permissions. Permissions to create security principals in the AD DS domain
partition are completely removed from any Exchange Server user, service, or server. No option is
provided in RBAC to create security principals. Creation of security principals in AD DS must be
performed using AD DS management tools. You can choose to implement Active Directory split
permissions during Setup.
Note Active Directory split permissions was introduced in Exchange Server 2010 SP1. You
must run setup to enable Active Directory split permissions.

If your organization requires a split permissions model, use the RBAC split permissions model; this model
provides more flexibility while providing almost the same administrative separation as Active Directory
split permissions.
Note Exchange servers and services can create security principals in the RBAC split
permissions model; this is not true with Active Directory split permissions.

2-44

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Active Directory split permissions are appropriate if the following are true:

Your organization requires that security principals, such as users and groups, be created using only
the AD DS management tools or only by users who are granted specific permissions in AD DS.

You want to completely separate the ability to create security principals from those who manage the
Exchange organization.

You want to perform all distribution group management, including creation of distribution groups
and adding and removing members of those groups, using AD DS management tools.

You don't want Exchange servers, or third-party programs that use Exchange on their behalf, to
create security principals.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-45

What Is the Default Role Based Access Control Configuration?

Exchange Server 2010 includes several built-in role groups that you can use to provide varying levels of
administrative permissions to user groups.

Built-in Role Groups

You can add users to, or remove them from any built-in role group. You also can add or remove role
assignments to or from most role groups.
Role group

Description

Organization
Management

Role holders have access to the entire Exchange Server 2010 organization,
and can perform almost any task against any Exchange Server object.

View-Only Organization
Management

Role holders can view the properties of any object in the organization.

Recipient Management

Role holders have access to create or modify Exchange 2010 recipients

within the Exchange Server organization.

UM Management

Role holders can manage the Unified Messaging features within the
organization, such as Unified Messaging server configuration, mailbox
properties, prompts, and auto-attendant configuration.

Discovery Management

Role holders can perform searches of mailboxes in the Exchange

organization for data that meets specific criteria.

Records Management

Role holders can configure compliance features, such as retention policy

tags, message classifications, and transport rules.

Server Management

Role holders have access to Exchange server configuration. They do not have
access to administer recipient configuration.

2-46

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

(continued)
Role group

Description

Help Desk

Role holders can perform limited recipient management.

Public Folder
Management

Role holders can manage public folders and databases on Exchange servers.

Delegated Setup

Role holders can deploy previously provisioned Exchange servers.

Note All of these role groups are located in the Microsoft Exchange Security Groups OU in
AD DS. This OU contains several other universal security groups that grant permissions to
the Exchange Server computer accounts.

Management Role Assignment Policies

Management role assignment policies associate end-user management roles with users. You do not
configure administrative permissions with management role assignment policies. Rather, you use
management role assignment policies to configure what changes users can make to their mailbox settings
and to distribution groups that they own. Every user with an Exchange Server 2010 mailbox receives a role
assignment policy, by default. You can:

Decide which role assignment policy to assign by default.

Choose what to include in the Default Role Assignment Policy.

Override the default policy for certain mailboxes.

Choose not to assign role assignment policies by default.

Role Assignment Components

Role assignment policies consist of the following components that define what users can do with their
mailboxes:

Mailbox. Mailboxes are assigned a single role assignment policy. When a mailbox is assigned a role
assignment policy, the policy is applied to the mailbox. This grants the mailbox all of the permissions
that the management roles provide.

Management role assignment policy. The management role assignment policy is an object in
Exchange Server 2010. Users are associated with a role assignment policy when you create their
mailboxes or change the role assignment policy on their mailboxes. The combination of all the roles
included in a role assignment policy defines everything that associated users can manage on their
mailboxes or distribution groups.

Management role assignment. Management role assignments link management roles and role
assignment policies. Assigning a management role to a role assignment policy grants users the ability
to use the cmdlets in the management role. When you create a role assignment, you cannot specify a
scope. The scope that the assignment applies is based on the management role, and is either Self or
MyGAL.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-47

Management role. A management role is a container for a group of management role entries. Roles
define the specific tasks that users can do with their mailboxes or distribution groups.

Management role entry. A management role entry is a cmdlet, script, or special permission that
enables users to perform a specific task. Each role entry consists of a single cmdlet, and the
parameters that the management role can access.

2-48

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Designing a Custom Management Delegation Strategy

Exchange Server 2010 includes a Default Role Assignment Policy that provides end users with the most
commonly used permissions. For most organizations, you do not need to modify the configuration.
However, you can change the management role assignment policy if your organization has specific
requirements regarding how users can interact with their mailboxes or groups.

Working with Assignment Policies

You can modify the default role assignment configuration in several ways:

Change the default permissions on the Default Role Assignment Policy by adding or removing
management roles. For example, if you want to enable users to perform additional tasks on their
mailboxes, you can identify the management role that grants them the necessary permissions, and
add the role to the Default Role Assignment Policy.

Define a new role assignment, and then configure that role assignment to be the default for all
mailboxes. Use the Set-RoleAssignmentPolicy cmdlet to replace the built-in Default Role Assignment
Policy with your own. When you do this, RBAC assigns the role assignment policy that you specify to
new mailboxes, by default.
Note When you change the Default Role Assignment Policy, RBAC does not assign the
new Default Role Assignment Policy automatically. You will need to use the Set-Mailbox
cmdlet to update previously created mailboxes to the new Default Role Assignment Policy.

Configure additional role assignment policies, and assign the policies to a mailbox manually. Use the
RoleAssignmentPolicy parameter on the New-Mailbox, Set-Mailbox, or Enablemailbox cmdlets. When
you assign an explicit role assignment policy, the new policy takes effect immediately and replaces
the previously assigned explicit role assignment policy. If you have many different user groups with
special needs, you can create role assignment policies for each group.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-49

Configuring a Custom Role Group

In addition to the built-in role groups, you also can create custom role groups to delegate specific
permissions within the Exchange Server organization. Use this option when your ability to limit
permissions is beyond the scope of the built-in role groups.
RBAC enables complete flexibility in how you assign permissions in an Exchange Server 2010 environment.
For example, RBAC enables you to assign permissions to a group of administrators in a branch office who
only need to manage recipient tasks for branch-office users, and mailboxes on branch office Mailbox
servers. To implement this scenario, you would:
1.

Create a new role group, and then add the branch office administrators to the role group. You can
use the New-RoleGroup cmdlet to create the group. When you create the group, you must specify
the management roles. Additionally, you also can specify the management scope for the role.

2.

Assign management roles to the branch office administrators. To delegate permissions to a custom
role group, you can use one or more of the default built-in management roles, or you can create a
custom management role that is based on one of the built-in management roles. Exchange Server
2010 includes approximately 70 built-in management roles that provide granular levels of
permissions. To view a complete list of all the management roles, use the get-managementrole
cmdlet. To view detailed information about a management role, type get-managementrole rolename
| FL, and then press Enter.
Note You also can configure a new management role rather than use one of the existing
management roles. To do this, use the New-ManagementRole cmdlet to create a custom
management role based on one of the existing management roles. You can then add and
remove management role entries as needed. By default, the new management role inherits
all of the permissions assigned to the parent role. You can remove permissions from the role
as necessary, by using the Remove-managementroleentry cmdlet. However, it can be
complicated to create a new management role or remove unnecessary management role
entries, so we recommend that you use one of the existing roles whenever possible.

3.

Identify the management scope for the management role. For example, in the branch office scenario,
you could create a role assignment with an OU scope that is specific to the branch office OU.

4.

Create the management role group using the information that you collect. Use the New-RoleGroup
cmdlet to create the link between the role group, the management roles, and the management
scope. For example, consider the following cmdlet:

New-RoleGroup Name BranchOfficeAdmins roles Mail Recipients, Distribution Groups,

Move Mailboxes, Reset Password, Mail Recipient Creation User BranchOfficeAdmins
RecipientOrganizationalUnitRestriction Contoso.com/BranchOffice.

It does the following:

Creates a new role group named BranchOfficeAdmins.

Assigns the Mail Recipients, Distribution Groups, Move Mailboxes, Reset Password, and Mail
Recipient Creation management roles to the BranchOfficeAdmins role group.

Configures a management role scope limited to the BranchOffice OU in the Contoso.com

domain.

2-50

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Designing a Management Tool Strategy

All Exchange Server administration tools, including Exchange Management Console, Exchange
Management Shell, and Exchange Control Panel, use RBAC to determine user permissions. Therefore,
permissions are consistent regardless of which tool you use; this is because when you define RBAC
permissions, you can define precisely which Exchange Management Shell cmdlets a user can run, and
which objects the user can modify.

Exchange Management Console

The Exchange Management Console uses the Microsoft Management Console (MMC) 3.0 paradigm of a
four-pane environment. These four components are the console tree, the result pane, the work pane, and
the action pane. The Exchange Management Consoles unique feature is its console tree, which has four
main nodes: Organization Configuration, Server Configuration, Recipient Configuration, and Toolbox.
These four nodes have four distinct functions:

The Organization Configuration node contains all configuration options for each Exchange Server role
that affects the messaging systems functionality. This node allows you to configure database
management, ActiveSync policies, journal and transport rules, message-formatting options, and email
domain management.

The Server Configuration node contains the configuration options for each Exchange Server in the
organization. Settings that you can manipulate include: server diagnostic-logging settings, productkey management, and per-server Outlook Web App configuration.

The Recipient Configuration node contains the configuration and creation tasks for mailboxes,
distribution groups, and contacts. You also can use it to move or reconnect mailboxes.

The Toolbox node contains 12 utilities and tools that you can use to monitor, troubleshoot, and
manage Exchange Server. These tools include Exchange Best Practices Analyzer, Public Folder
Management Console, Messaging Tracking, and Database Recovery Management.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-51

You also can use the Exchange Management Console to manage both onsite and hosted Exchange Online
environments.
Note The root node of the console tree now also includes two tabs in the Content pane.
The Organizational Health tab displays a report on the overall status of the Exchange
organization with information on the number of databases, servers and Client Access
Licenses that have been deployed. The Customer Feedback tab is where both the Customer
Experience Improvement Program can be enabled, and links to Exchange documentation
can be found.

Exchange Management Shell

The Exchange Management Shell and the Exchange Management Console run on top of Windows
PowerShell version 2.0 command-line interface. They use cmdlets, which are commands that run within
Windows PowerShell. Each cmdlet completes a single administrative task, and you can combine cmdlets
to perform complex administrative tasks.
In Exchange Management Shell, there are approximately 700 cmdlets that perform Exchange Server
management tasks, and even more non-Exchange Server cmdlets that are in the basic Windows
PowerShell shell design.
Exchange Management Shell is more than just a command-line interface that you can use to manage
Exchange Server 2010. Exchange Management Shell is a complete management shell that offers a
complex and extensible scripting engine that has sophisticated looping functions, variables, and other
programmatic features so that you can create powerful administrative scripts quickly.

Windows Remote PowerShell

Exchange Server 2010 builds on the success of Exchange Server 2007 usage of Windows PowerShell 1.0,
by leveraging its remote Windows PowerShell functionality within Windows PowerShell 2.0. By using the
remote Windows PowerShell feature, Exchange Server 2010 includes many new features.

Exchange Control Panel

The Exchange Control Panel is a new feature in Exchange Server 2010. It enables end users and Exchange
Server specialists to manage many aspects of the messaging environment from a secure web page that
includes inbox rules, public groups, account information, call answering rules, and retention policies.
You can assign permissions to Exchange Control Panel users by assigning and customizing one of the
preconfigured RBAC groups.
The Exchange Control Panel runs on the Client Access servers, and you access it either from the Options
menu in Outlook Web App, or by visiting https://Server/ecp.
The Exchange Control panel supports the following user roles:

End users

Outlook Web App options

Email subscriptions

Group management

Mobile phone management

2-52

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Exchange administrators and specialists

Mailbox creation and management

Distribution group management

Legal discovery

Message tracking

Role assignment user interface

Note Exchange Server 2010 SP1 provides ECP improvements that enable you to create
and manage management role groups and management role assignment policies in the
ECP, including the ability to: add and remove management roles to role groups and role
assignment policies; add and remove members to and from role groups; and assign users to
role assignment policies.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-53

Demonstration: How to Manage Exchange Server 2010

In this demonstration, you will review how to navigate the Exchange Management Console, and use it to
manage Exchange Server. You will also review how to create a mailbox, and how to use Windows
PowerShell command-line interface scripting and pipelining to change the address on multiple mailboxes.
The instructor also will describe basic cmdlet aliases. Finally, your instructor will demonstrate the Exchange
Control Panel.

Use the Exchange Management Console

1.

Open the Exchange Management Console.

2.

Note the consoles layout: console tree on the left, content pane in the middle, and actions pane on
the right.

3.

Notice that the console tree has four nodes: Organization Configuration, Server Configuration,
Recipient Configuration, and Toolbox.

4.

Expand each console tree section to view the available nodes.

5.

In the console tree, expand Organization Configuration, click Mailbox, and then view the
information available in the Content pane.

6.

In the console tree, expand Server Configuration, click Mailbox, and then view the information in
the Content pane.

7.

In the console tree, expand Recipient Configuration, click Mailbox, and then view the information
in the Content pane.

2-54

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Use the Exchange Management Shell

The instructor will run the following cmdlets:

Get-Mailbox

Get-Mailbox | Format-List

Get-Mailbox | fl

Get-Mailbox | Format-Table

Get-Mailbox | ft Name, Database, IssueWarningQuota

Get-Help New-Mailbox

Get-Help New-Mailbox -detailed

Get-Help New-Mailbox -examples

$Temp = "Text"

$Temp

$password = Read-Host "Enter password" AsSecureString

New-Mailbox -UserPrincipalName [email protected] -Alias Chris -Database "Mailbox

Database 1" -Name ChrisAshton -OrganizationalUnit Users -Password $password -FirstName
Chris -LastName Ashton -DisplayName "Chris Ashton" -ResetPasswordOnNextLogon $true

Use the Exchange Control Panel

The instructor will perform the following steps:
1.

Open Exchange Control Panel as a standard user.

2.

Open Exchange Control Panel as an administrator, and review and compare the settings.
Question: Does the Exchange Management Console organization seem logical to you? Why
or why not?

Question: Does the Exchange Management Console have the same functionality as it did in
previous Exchange Server versions? What is different about this version?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-55

Lab: Designing Exchange Server Integration with the

Current Infrastructure

Lab Setup
For this lab, you will use the available virtual machine environment. Before beginning the lab, you must
complete the following steps:
1.

On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2.

Ensure that the 10233B-NYC-DC1 and 10233B-NYC-SVR1 virtual machines are running.

3.

If required, connect to the virtual machines. Log on to the virtual machines as

Contoso\Administrator using the password Pa$$w0rd.

Lab Scenario
Contoso, Ltd is planning to deploy Exchange Server 2010. You are a messaging consultant from A. Datum
Corporation, and have been tasked with verifying that the existing network infrastructure is suitable to
support Exchange Server 2010.
Once you have determined that the prerequisites are met, you will prepare the AD DS forest so that the
server deployment team can begin the Exchange Server 2010 deployment.
Note Your instructor may choose to perform this lab as a group discussion rather than an
individual activity.

2-56

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Exercise 1: Evaluating the Current Network Infrastructure at Contoso

Scenario
In this exercise, you will examine the current network infrastructure. You will determine whether it is
suitable to support Exchange Server 2010, and make recommendations about any necessary changes.
The main tasks for this exercise are as follows:
1.

Review the supplied documentation.

2.

Answer questions relating to the documentation.

3.

Complete a report that provides information about necessary changes required to the network and
AD DS infrastructure, to enable support for Exchange Server 2010.

Task 1: Review the supplied documentation

Review the diagram and read the supporting documentation.

Sites

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-57

Supporting Documentation
Email thread of correspondence with Ed Meadows:

Ed Meadows
From:
Jason Carlson [[email protected]]
Sent:
1 February 2010 14:00
To:
[email protected]
Subject: Re: Contoso Exchange Server 2010 project
Thanks; thats really helpful.
Yes, we can delegate tasks to specified individuals. Well discuss what you need when I get there. See you
next week.
Jason.
----- Original Message ----From:
Ed Meadows [[email protected]]
Sent:
31 January 2010 13:30
To:
[email protected]
Subject: Contoso Exchange Server 2010 project
Attachments:
Contoso.vsd
Jason,
Please find attached the Visio diagram of our three AD DS sites. All three sites are connected, logically,
with the DefaultIPSiteLink site link, and with default values.
The New York City office is our head office, and supports around 500 users. Branch Office 1 has 100 users,
while the other branch has only 30 users hence the RODC. Our only Internet connection is from the NYC
offices. We have a couple of DCs there.
Our namespace is pretty straightforward; Contoso.com is the only domain.
Wed like to be able to delegate administration of specified Exchange administration tasks to couple of
individuals out at Branch Office 1. Is that easy to do? I hope all this helps, and see you here in New York
next week.
Ed

2-58

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Task 2: Answer questions relating to the documentation

Question: Based on the supplied information, is there anything you might need to
reconfigure before deploying Exchange Server?

Question: What else do you need to know before you can begin deploying Exchange Server
2010?

Task 3: Complete a report that provides information about necessary changes required
to the network and AD DS infrastructure to enable support for Exchange Server 2010

Complete the following proposal document by answering the questions.

Contoso Exchange Server network infrastructure
Document Reference Number: JC110210/1
Document Author
Date

Jason Carlson
11th February 2010

Requirement Overview
To determine what changes, if any, are required to the existing network and AD DS infrastructure to
support Exchange Server 2010.
Proposals
Question: The internal and external DNS zone names are the same for Contosoi.e. Contoso.com.
What issue does this raise for clients connecting to their mailboxes using Outlook Web App from
their home computers?
Question: What DNS records must you configure in the external Contoso.com DNS zone?
Question: How do you propose to support the messaging needs of users in Branch Office 2?
Question: What messaging client will you deploy to Branch Office 2?
Question: What server role must you consider deploying in the head office to facilitate inbound
and outbound messaging to and from the Internet?
Question: How many Client Access servers do you envisage needing?
Question: How many Hub Transport servers are required?
Question: Ed Meadows has explained that the administrators at the Branch Office 1 site needs to
be able to perform limited recipient management tasks. To which built-in role group should you
assign these branch administrators?

Note

Be prepared to discuss your proposed design with the class.

Results: After this exercise, you should have completed the Contoso Exchange Server network
infrastructure report.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-59

Exercise 2: Determining Suitability for Exchange Server 2010

You must verify that the AD DS environment and the server meet all prerequisites for installing Exchange
Server 2010. Use the following checklist to verify that the prerequisites are met.
Prerequisite

Achieved?

AD DS domain controllers: Windows Server 2003 SP1 or later

Yes or No

AD DS domain and forest functional level: Windows Server

2003 or higher

Yes or No

DNS requirements

Yes or No

Exchange Server 2010 schema changes

Yes or No

AD DS management tools

Yes or No

Microsoft .NET Framework 3.5 or later

Yes or No

Windows Remote Management

Yes or No

Windows PowerShell 2.0

Yes or No

2010 Office System Converter: Microsoft Filter Pack

Yes or No

Web Server Internet Information Services (IIS) server role along

with the following role services:
ISAPI Extensions
IIS 6 Metabase Compatibility
IIS 6 Management Console
Basic Authentication
Windows Authentication
Digest Authentication
Dynamic Content Compression
.NET Framework Extensibility

Yes or No

Windows Server 2008 features:

WCF Hypertext Transfer Protocol (HTTP) Activation
RPC over HTTP Proxy

Yes or No

The main tasks for this exercise are as follows:

1.

Evaluate the AD DS requirements.

2.

Evaluate the DNS requirements.

3.

Evaluate the server requirements.

Task 1: Evaluate the AD DS requirements

1.

On NYC-DC1, evaluate whether the domain controller requirements are met.

2.

Evaluate whether the domain and forest functional level requirements are met.

3.

Use Adsiedit.msc to evaluate whether the Exchange schema changes are applied.

2-60

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Task 2: Evaluate the DNS requirements

On NYC-SVR1, use Ipconfig, Ping, and NSLookup to evaluate DNS name resolution functionality.

Task 3: Evaluate the server requirements

1.

On NYC-SVR1, evaluate whether the required Windows Server 2008 featuresincluding the required
AD DS administration toolsare installed.

2.

Evaluate whether the IIS components are installed.

3.

Evaluate whether the prerequisite software is installed.

Results: After this exercise, you should have evaluated whether your organization meets the AD DS, DNS,
and server requirements for installing Exchange Server 2010. You should have identified the additional
components that need to be installed or configured to meet the requirements.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-61

Exercise 3: Preparing the AD DS Forest for Exchange Server 2010

Scenario
Now that you have identified which prerequisites are not met in the current AD DS and server
configuration, you need to update the environment to meet them.
The main tasks for this exercise are as follows:
1.

Install the Windows Server 2008 server roles and features.

2.

Prepare AD DS for the Exchange Server 2010 installation.

Task 1: Install the Windows Server 2008 server roles and features
1.

2.

On NYC-SVR1, in Server Manager, install the prerequisite server roles and features for Exchange
Server 2010:

AD DS Snap-Ins and Command-Line Tools

.NET Framework 3.5.1

RPC over HTTP Proxy

For IIS:

Digest Authentication

Dynamic Content Compression

IIS 6 Management Console

Configure the Net.Tcp Port Sharing Service to start Automatically.

Task 2: Prepare AD DS for the Exchange Server 2010 installation

1.

In the 10233B-NYC-SVR1 on localhost Virtual Machine Connection window, on the File menu,
click Settings.

2.

Click DVD Drive, and then click Image File.

3.

Click Browse, and browse to C:\Program Files\Microsoft Learning\10233\Drives.

4.

Click EXCH2010SP2.iso, click Open, and then click OK.

5.

On NYC-SVR1, from a command prompt, run the Exchange Server setup program with the
setup /PrepareAD parameter. Configure an Exchange organization name of Contoso.

Results: After this exercise, you should have prepared the AD DS and server configuration for the
Exchange Server 2010 installation.

2-62

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Exercise 4: Configuring Exchange Server Delegation

Scenario
You must help Ed Meadows achieve his objective of delegating various management tasks to branch
administrators. To meet the management requirements, you need to ensure that Adam Carter is added to
the Help Desk group.
The main task for this exercise is as follows:

Configure permissions for Adam Carter, the branch administrator.

Task: Configure permissions for Adam Carter, the branch administrator

1.

2.

Create a new user in the Users folder in Active Directory Users and Computers:

Full name: Adam Carter

User logon name: Adam

Password: Pa$$w0rd

On NYC-SVR1, in AD DS Users and Computers, add Adam Carter to the Help Desk group.

Results: After this exercise, you should have delegated administration.

To prepare for the next module

When you finish the lab, revert the virtual machines to their initial state. To do this, complete the
following steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-NYC-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for virtual machines 10233B-NYC-SVR1.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then in the Actions pane, click Start.
Note Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully started
before starting the other virtual machines.

6.

Wait for 10233B-VAN-DC1 to start, and then start 10233B-VAN-EX1. Connect to the virtual machine.

7.

Wait for 10233B-VAN-EX1 to start, and then start 10233B-VAN-EX2. Connect to the virtual machine.

8.

Wait for 10233B-VAN-EX2 to start, and then start 10233B-VAN-CL1. Connect to the virtual machine.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 2-63

Module Review and Takeaways

Review Questions
1.

If you determine that your current site configuration does not support your Exchange Server routing
requirements, what options do you have?

2.

What command might you use to configure a site as a Hub site?

3.

What is the main reason for deploying Exchange Server in a multi-tree forest?

4.

What issue does configuring a split DNS solution resolve?

Best Practices
Supplement or modify the following best practices for your own work situations:

Avoid using IP addresses to define servers on clients. If the server providing an email client service
changes, you must update the configuration of all affected client computers to match the new IP
address. Additionally, digital certificates that are provided to enable authentication and encryption
between clients and servers are configured with a subject name that matches the designated servers
published FQDN. If an IP address is used, this will at best raise an error on the client, and at worst,
prevent email retrieval.

Only open required ports on your firewalls. Aim to minimize the open ports by being selective about
what client types you will support.

2-64

Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure

Use a self-signed certificate only for small deployments, or for testing purposes. Replace the selfsigned certificate as soon as possible after deployment.

A single forest means that the Exchange Server 2010 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.

3-1

Module 3
Planning and Deploying Mailbox Services
Contents:
Lesson 1: Overview of Mailbox Services in Exchange Server 2010

3-3

Lesson 2: Designing Mailbox Servers

3-8

Lesson 3: Designing Recipient Management

3-21

Lesson 4: Designing Public Folder Architecture

3-37

Lab: Planning and Deploying Mailbox Services

3-51

3-2 Planning and Deploying Mailbox Services

Module Overview

Microsoft Exchange Server 2010 includes some major improvements to mailbox services when
compared to previous versions of Exchange Server. For example, the disk input/output (I/O) requirement
for Exchange Server 2010 is approximately 70 percent less than what is required for Exchange Server 2007.
To optimize your mailbox services performance in Exchange Server 2010, you must consider these
improvements when designing your mailbox services.
The mailbox services design includes the physical design of the Mailbox servers, including the storage
system. It also includes the design of recipient management and public folder architecture.
After completing this module, you will be able to:

Describe mailbox services in Exchange Server 2010.

Design Mailbox servers.

Design recipient management.

Design public folder architecture.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-3

Lesson 1

Overview of Mailbox Services in Exchange Server 2010

The improvements in mailbox services in Exchange Server 2010 include improved resource scheduling,
user-managed distribution groups, and the ability to move mailboxes between databases while users are
logged on. One particularly important area of improvement is disk performance, which is enabled by
changes in the database structure.
After completing this lesson, you will be able to:

Describe the new mailbox services in Exchange Server 2010.

Describe the storage changes in Exchange Server 2010.

Identify considerations for designing Exchange Server 2010 storage for large mailboxes.

Identify the information that is required to design Mailbox servers.

3-4 Planning and Deploying Mailbox Services

New Mailbox Services Features in Exchange Server 2010

Key Points
Exchange Server 2010 includes many new features for mailbox services. You need to be aware of these
features when designing the implementation of mailbox services, because they may have special
requirements that increase the resource load on Mailbox servers.
Some new mailbox services features in Exchange Server 2010 are:

Personal archives. You can enable personal archives for each user with a mailbox on an Exchange
Server 2010 Mailbox server. The personal archives are an alternative to personal folders (PST) files,
which are stored locally.

Calendar repair. Each Exchange Server 2010 Mailbox server runs the Calendar Repair Assistant on a
configurable schedule. The Calendar Repair Assistant corrects calendar inconsistencies.

Resource configuration in the Exchange Management Console. Resource mailboxes were introduced
in Exchange Server 2007, but you could manage them only in the Exchange Management Shell. In
Exchange Server 2010, you can use the Exchange Management Console to manage the most
common settings for resource mailboxes.

Live mailbox moves. In Exchange Server 2010, you can move mailboxes from one database to another
while users are logged on and using their mailbox. Previous versions of Exchange Server required
users to be logged out of their mailboxes during a move.

User-managed distribution groups. It is now possible for users to create their own distribution groups
by using Microsoft Office Outlook 2010 or Outlook Web App. This decreases the workload of
Exchange administrators.

Bulk management. You can perform more bulk management tasks from within the Exchange
Management Console than in previous versions of Exchange Server. Now, you can edit recipient
properties and send email to recipients.
Question: Do you expect that these new features will have an impact on your organization?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-5

Storage Changes in Exchange Server 2010

Key Points
Exchange Server 2010 includes many changes to the way storage is used. The improvements in storage
utilization in Exchange Server 2010 allow you to take advantage of new trends in storage, such as large
slower and inexpensive disks instead of small fast expensive disks..Some of the changes to storage include:

Removal of storage groups. Previous versions of Exchange Server allowed you to place multiple
databases that shared a single set of transaction logs, into a storage group. In Exchange Server 2010,
each database exists independently, and has its own set of transaction logs.

Removal of single instance storage. Previous versions of Exchange Server stored a message only once
in the database, if the message was addressed to multiple recipients in the same mailbox database.
Exchange Server 2010 stores a message copy in each users mailbox when the message is addressed
to multiple recipients in the same mailbox database. This makes disk access more sequential, and
improves read performance. The addition of database compression prevents the mailbox database
from increasing in size when compared to previous versions of Exchange Server.

Database is a peer to the server. Previous versions of Exchange Server managed a database as a
subcomponent of a server. In Exchange Server 2010, databases are managed at the organization level.
A database is linked to a server, but is not a subset of a server. This is an important concept for
Database Availability Groups (DAGs), where multiple copies of a database can exist on multiple
servers.

Disk I/O is optimized for commodity storage. Exchange Server 2010 reduces disk Input/Output
Operations Per Second (IOPS) by up to 70% over Exchange Server 2007. This is done primarily by
making as many disk operations as possible sequential rather than random. Mailbox databases have
been restructured in Exchange Server 2010 to support this. As a consequence, you can consider using
cheaper and larger disks for data storage, such as SATA disks. You can also consider using just a
bunch of disks (JBOD) rather than Redundant Array of Independents Disks (RAID).
Question: How will changes to storage in Exchange Server 2010 affect your organization?

3-6 Planning and Deploying Mailbox Services

Designing Storage for Large Mailboxes

For many users, access to email is critical for them to perform their jobs. Email is used for communication
internally with colleagues and externally with partners and customers. The amount of data kept in
mailboxes continues to grow, and all of this data must be searchable.
New generations of hard disks are getting larger, but spin rates and seek times are not improving.
Sequential read rates are increasing as a result of greater data density, but random access read rates are
the same. Exchange Server 2010 takes advantage of the increasing disk size, so that you can offer larger
mailboxes to users without increasing cost or decreasing performance. With the I/O improvements in
Exchange Server 2010, you can use larger and less expensive disks in many scenarios. Disk I/O relates to
the number of mailboxes stored on a disk rather than the volume of mailbox data stored on the disk.
Large mailboxes reduce the disk I/O requirements for a Mailbox server because they reduce the number
of mailboxes that are stored on a disk. Fewer mailboxes on a disk results in lower disk I/O.
As a result of lower disk I/O, you can consider using large 7200 RPM disks rather than smaller, faster
15000 RPM disks. A typical 7200 RPM disk stores between 1 and 3 terabytes. A typical 15000 RPM disk
stores less than 1 terabyte. The 7200 RPM disks are significantly less expensive per gigabyte (GB).
Many Exchange administrators initially assume that mailboxes should be kept on one set of fast disks and
personal archives should be kept on another set of slower disks. However, if personal archives are kept on
the same set of disks as the mailboxes, then fewer mailboxes and archives are kept on the same set of
disks. Reducing the number of active mailboxes on the disk behaves similarly to having large mailboxes
on the disk. Overall disk I/O is reduced for the disk, and slower disks can be used for all data.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-7

Information Required for Designing Mailbox Services

Key Points
To design mailbox services, you must identify the information required for both mailboxes and public
folders. Typically, the information you gather helps you to determine the size of databases that need to be
accommodated, and the processing load that those databases will place on the mailbox servers.
To design mailbox databases, you must consider the following factors related to mailboxes:

Number of users. A larger number of users typically increases disk utilization.

Frequency of usage. Higher frequency usage typically increases disk utilization.

Size of mailboxes. Larger mailboxes combined with a higher number of users increases overall
database size.

Service level agreements (SLAs). To meet the recovery requirements, you may need to keep databases
small so that restore times are reduced.

To design public folder databases, you must consider the following factors:

Frequency of usage. Higher frequency of usage typically increases disk utilization.

Size of public folders. Larger public folders combined with a greater number of public folders
increases overall database size.

Replication requirements. If you need to replicate public folders, at least two public folder databases
are required.

Type of client. Office Outlook 2003 requires public folders for performing free/busy searches, and
downloading offline address books.
Question: What other information would you want to gather before designing mailbox
servers?

3-8 Planning and Deploying Mailbox Services

Lesson 2

Designing Mailbox Servers

In Exchange Server 2010, a Mailbox server manages and maintains mailbox databases and public folder
databases. When you design a Mailbox server, a primary consideration is storage configuration. However,
you also need to consider processor and memory requirements. And you need to consider high
availability as an option for mailbox databases through the use of DAGs.
After completing this lesson, you will be able to:

Design mailbox sizing.

Design Mailbox server database configurations.

Design Mailbox server database disk storage.

Design Mailbox server processor and memory requirements.

Design Mailbox servers for high availability.

Describe the considerations for virtualizing Mailbox servers.

Design a test plan for evaluating disk storage options.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-9

Designing Mailbox Sizing

Key Points
To design mailbox size, you must first understand the business needs that drive mailbox size. The business
needs for mailbox storage vary depending on the type of users. For example, a sales person who is forced
to delete older messages may lose valuable information, which results in lost sales, while general office
staff may have no need to keep a larger volume of mail for a longer term.
To select an appropriate mailbox size, you should consider:

What types of messages do users need to keep for an extended period of time?

How long do messages need to be kept?

How does the volume of messages stored vary by job role?

What is the cost of increasing storage size versus the cost of not having content easily available?

Cached Exchange Mode

When you deploy Office Outlook 2003 or later, you can use Cached Exchange Mode. Cached Exchange
Mode places a copy of the mailbox on the client computer, and it synchronizes the changes with the
Exchange server. After the mailbox is synchronized on the client computer, all requests to view or modify
a message or calendar item are performed on the locally cached copy of the mailbox.
In previous versions of Exchange Server, using Cached Exchange Mode increases the Mailbox server
performance, because fewer requests are submitted to the Mailbox server. In Exchange Server 2010, using
Cached Exchange Mode does not increase Mailbox server performance, because of the changes in storage
architecture.
Users with a slow connection to the Exchange server typically experience a performance improvement
when using Cached Exchange Mode. However, as the size of the cached mailbox increases, performance
decreases. Increased random access memory (RAM) and faster disks in client computers can increase the
performance of locally cached mailboxes.

3-10

Planning and Deploying Mailbox Services

Personal Archives
Personal archives are a new feature in Exchange Server 2010. Personal archives address problems that you
might encounter if you archive data to PST files. PST files are problematic because they are difficult to
manage and because they might be stored in a location that is not backed up. This increases the risk of
losing messages.
The intent behind personal archives is to replace PST files. Messages are archived to the personal archive
rather than to a PST file. The personal archive can be located either in the same mailbox database as the
associated mailbox or in a different mailbox database. Therefore, a personal archive decreases the size of a
user mailbox, but not the size of Exchange data. In fact, if PST files are imported, the overall size of
Exchange data might increase.
When you use Cached Exchange Mode and personal archives simultaneously, you reduce the amount of
data that is cached on the client. Only the content in the user mailbox is cached locally on the client, and
the content in the personal archive is not cached. This can improve overall client performance, while still
providing access to archived data as needed.

Additional Considerations
Some additional considerations are:

Do not assume that the mailbox quota size is the amount of disk space that is used for each mailbox.
Many mailboxes might not be filled to capacity. Find out what the actual usage is for mailboxes, and
then be prepared for the possibility that mailboxes will grow to the maximum size of the quota.

Databases never shrink automatically. If you have a large mailbox database that you remove users
from, the mailbox database does not shrink automatically. Instead, empty white space remains inside
the database file. To physically shrink the database on the disk, you must perform an offline
defragmentation. Alternatively, you can create a new mailbox database, move mailboxes into the new
mailbox database, and the delete the old mailbox database.

Deleted item retention affects mailbox database size. If you increase the deleted item retention limit
from the default value of 14 days, you need to plan for larger mailbox databases. The affect of
deleted item retention on mailbox size varies depending on the volume and size of messages
received by your users. Deleted items in the dumpster are not included when quotas are calculated
for a users mailbox. The deleted items in the dumpster are also not included when viewing the size of
the mailbox in the Exchange Management Console.

A litigation hold increases mailbox size. When a litigation hold is enabled for a mailbox, no messages
are ever purged from the mailbox. In addition, all changes to mailbox items are tracked. If a litigation
hold is left on for an extended period of time, the mailbox increases in size significantly.

Deleted mailbox retention affects mailbox database size. If you increase the deleted mailbox retention
limit from the default of 30 days, the size of the mailbox database increases.

Clients running the Post Office Protocol (POP3) may remove messages immediately. Unlike clients
running Messaging Application Programming Interface (MAPI) and Outlook Web App, clients running
POP3 are sometimes configured to delete messages from the mailbox after the messages are
downloaded to the client. If you configure the POP3 clients in this way, mailboxes are much smaller
than those that the MAPI and Outlook Web App clients use.
Question: How many clients in your organization use Cached Exchange Mode?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-11

Designing Mailbox Server Database Configuration

Key Points
In previous versions of Exchange Server, it is recommended that you keep the log files and database on
separate disks. That way, if the disk fails and the database is lost, you still have the log files available after
a restore and you can replay them to recover messages received since the last backup. In Exchange
Server 2010, the same recommendation still applies in small environments that do not use DAGs.
However, if there are multiple replicated copies of a database, you do not need to keep the transaction
logs and database separate, because a different replica is used for recovery instead of recovering from a
backup.
In Exchange Server 2010, it is a best practice to locate multiple databases on a single logical unit number
(LUN), because the disk I/O is random. You can separate transaction logs onto different physical disks to
increase performance, but this is not typically necessary. In most cases, because Exchange Server 2010 has
lower I/O requirements, you can keep transaction log files and database files on the same volume without
impacting performance.
You can separate log files from database file for recoverability when using backups. By storing database
files on log files on separate volumes or disks, you can replay transaction logs after a database restore
when the database was lost due to a failed volume or disk.

Disk Space Considerations

When you calculate the disk space requirements for a database on a Mailbox server, you need to consider
more than just the mailbox databases. In most cases, you may want to enable indexing on databases to
speed up searches. Each index uses approximately 5 percent of the mailbox database disk space. This
index is placed in the same location as the database.
Single item recovery retains deleted messages in a database for a specified period of time. When you
enable single item recovery, the database size increases.

3-12

Planning and Deploying Mailbox Services

Previous versions of Exchange Server do not include personal archives. A personal archive is typically used
for longer term retention of mailbox content. If you enable personal archives, the database size may
increase.
You can use a recovery database in a variety of recovery scenarios to extract mailbox data. To use a
recovery database, you must have sufficient disk space available to restore the database and transaction
logs.

Exchange Server Editions

Exchange Server 2010 does not limit the of size of databases based on the edition of Exchange
Server 2010 that you select. The only database limitation based on the edition of Exchange Server 2010 is
the number of databases that are supported on each server. Exchange Server 2010 Standard Edition
supports up to 5 mounted databases on each server, and Exchange Server 2010 Enterprise Edition
supports up to 100 mounted databases on each server.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-13

Designing Mailbox Disk Storage

Key Points
Because of the storage improvements in Exchange Serve 2010, you can consider using less expensive and
slower types of disk storage, which you might not have been able to consider for previous versions of
Exchange Server. However, ultimately you need to test the storage configuration that you select to ensure
it meets your needs.
Consider the following:

Replicated database copies increase the amount of storage space required. If your organization uses
DAGs to replicate mailbox databases for high availability, consider the number of database copies
when you calculate how much disk space you need and what it costs.

Slower disks have a significantly lower cost per GB than faster disks. The reduced disk I/O
requirements of Exchange Server 2010 mean that large capacity 7200 RPM disks are suitable for many
organizations. You can obtain 7200 RPM disks of equal size with the SATA or SAS interface. SAS disks
cost slightly more than SATA disks, but, in testing at Microsoft, SAS disks had a 50 percent lower
failure rate than SATA disks.

Direct attached storage (DAS) is significantly cheaper than a storage area network (SAN). As a result,
DAS is preferable if you use DAGs to create multiple replicated copies of data. You can purchase
external drive arrays and use them to connect a large number of disks to a single server. The lower
reliability of DAS is mitigated by the multiple database copies in the DAG. If you have a SAN with
available space then you might prefer to use the SAN for the higher reliability it provides.

You can consider JBOD if you have three or more replicas of a database in a DAG. JBOD provides no
redundancy, but this is acceptable because the DAG has multiple database copies. JBOD is used with
DAS.

3-14

Planning and Deploying Mailbox Services

Some organizations have a significant investment in SANs for all server storage. If you use a SAN, the
increased reliability may mean that you choose to implement fewer database copies in a DAG. You
can also keep some database copies on a SAN and others on DAS. Even when a SAN is used, having
two database copies is recommended.

An Internet small computer system interface (iSCSI) SAN typically has lower performance than a Fibre
Channel SAN, but it is also significantly less expensive. If you use a SAN, the lower I/O requirements in
Exchange Server 2010 make iSCSI an option over Fibre Channel in a wide range of scenarios.

Use RAID to increase the redundancy of the disk system if there are less than three database copies in
a DAG. A variety of RAID types are available to increase the performance and redundancy of the disk
system. RAID 10 is the best-performing RAID option, because it has the speed of a striped set and the
redundancy of mirroring. However, it is fairly expensive, because 50 percent of the disk space is used
for redundant data. You can use the Exchange 2010 Mailbox Server Role Requirements Calculator to
help you plan the storage configuration of Mailbox servers. This spreadsheet contains many
calculations to help you accurately estimate the hardware requirements to support a specific number
of users with a specific storage configuration. You can download this tool from the Microsoft website,
and it is updated regularly.
Question: Which disk configuration do you use in most of your servers?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-15

Designing Mailbox Server Processor and Memory Requirements

Key Points
Exchange Server 2010 requires a 64-bit processor and operating system. Exchange Server 2010 supports
two specific processor architectures: AMD64 and Intel Extended Memory 64 Technology. It does not
support Itanium processors.
Exchange Server 2010 can take advantage of multicore processors. A multicore processor can process
multiple tasks at the same time. A typical server processor has four or more cores. If the processor
supports hyper-threading, Microsoft recommends that you disable hyper-threading. Hyper-threading
causes problems in capacity planning and offers little performance improvement.
The number of processor cores required for a Mailbox server varies, depending on the number of
mailboxes and how intensely they are used. For average usage, a single processor core can support
approximately 1,000 active mailboxes. Average usage is defined as a user who sends 10 messages a day
and receives 40 messages a day.
If the Mailbox server role is combined with other server roles, you must account for the processor
requirements of those other server roles. For average usage, a single server with the Mailbox, Client
Access, and Hub Transport server roles installed can support approximately 500 mailboxes.
Note The maximum recommended number of processor sockets is two per Mailbox
server. Up to four processor sockets are recommended for multi-role servers.

Memory Requirements
The memory requirements for Exchange Server 2010 vary depending on the number of mailboxes and
how intensely they are used. The minimum recommended RAM for a Mailbox server is 4 GB. A server that
combines multiple roles should have a minimum of 8 GB of RAM.

3-16

Planning and Deploying Mailbox Services

When calculating the memory required for your Mailbox server, take the minimum require and add
additional memory for each user based on their messaging volume. For each 50 messages per day sent or
received, you should allocate 3 megabytes (MB) per user. For example, if the average user in your
organization sends and receives 100 messages per day then you should allocate 6 MB per user in addition
to the minimum RAM for your Mailbox server configuration.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-17

Designing Mailbox Servers for High Availability

Key Points
To implement high availability of mailbox databases, you use a DAG. A DAG allows you to replicate
mailbox databases to multiple servers. If the server that is servicing clients fails, a replica on another server
in the DAG begins to service client requests.
Note The high availability methods available in previous versions of Exchange Server are
not available in Exchange Server 2010.
Some considerations for implementing DAGs are:

Mailbox database names must be unique in the Exchange Server organization. This may require you
to develop a naming convention. This naming convention should not include the server name,
because the database can move between DAG members.

The storage path must be identical for all copies of a database. This means that all members of a DAG
should have the same disk configuration with the same drive letters. For increased flexibility, you can
use mount points instead of various drive letters, but this is not required.

DAG implementation uses the Windows Server 2008 operating system failover clustering feature.
This is only available in the Windows Server 2008 Enterprise and Datacenter operating system
editions. However, DAGs are supported for both the Exchange Server 2010 Standard and Enterprise
editions.

DAGs can be managed completely from within Exchange Server 2010 management tools. This
simplifies the process of DAG configuration, and masks the complexity of failover clustering from
administrators.

3-18

Planning and Deploying Mailbox Services

A DAG cannot make public folder databases highly available. Public folders should use public folder
replication for high availability. However, public folder databases can exist on a server that is a
member of a DAG. Public folder replication can be used to make a public folder highly available.

A server that is a member of a DAG can have additional server roles installed. For example, a server
that is a member of a DAG can have the Client Access and Hub Transport server roles installed.
Question: Will you consider implementing a DAG for your organization?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-19

Virtualizing Mailbox Servers

All Exchange Server 2010 server roles can be virtualized. A virtualized implementation of Exchange
Server 2010 is supported when running on the Microsoft Hyper-V technology or on any other
hypervisor that is validated in the Windows Server Virtualization Validation Program.
Some considerations for hardware requirements are:

In general, when Exchange Server 2010 is running in a virtual machine, it has the same hardware
performance requirements as when it is not virtualized. The requirements for memory and processing
power are the same. For example, if your planning indicates that a server running Exchange
Server 2010 requires 16 GB of memory, a virtualized version of that server also requires 16 GB of
memory.

Memory should not be oversubscribed. Exchange Server 2010 uses caching in memory to improve
performance. If memory is oversubscribed, Exchange Server 2010 does not have full control over
memory allocation in the virtual machine, which can reduce performance.

Do not allocate virtual processors to virtual machines at a ratio higher than two virtual processors per
processor core. For example, if the physical host has two processors with six cores each, you should
not allocate more than 24 virtual processors.

Some considerations for storage are:

Dynamically expanding virtual disks are not supported. This is because of performance concerns as
the disks expand.

Differencing or delta mechanisms such as snapshots are not supported. This is because the snapshot
mechanisms are not application-aware and, as a consequence, recovery to the snapshot is
unpredictable.

Test virtual disk performance to be sure that it meets your needs. Virtual disk performance is typically
slightly lower than physical disk performance.

3-20

Planning and Deploying Mailbox Services

Pass-through storage and iSCSI storage are both supported. However, iSCSI storage has reduced
performance if the network stack of the virtualization environment does not support jumbo frames.
Jumbo frames are supporting in Hyper-V on Windows Server 2008 R2, but they must be enabled in
the parent partition and the virtual machine.

You can use the virtual machine high availability that is provided by your virtualization environment with
Exchange Server 2010. This is supported even for servers that are part of a DAG. Some considerations for
virtual machine high availability are:

The virtual machines must not save and then restore state when moved. All migration between hosts
must be an online migration, such as Hyper-V Live Migration, or else the virtual machines can be shut
down and restarted.

Online migration methods must be supported by the hypervisor vendor.

If a virtual machine or host fails, the virtual machine must be restarted on an alternate host with a full
boot process.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-21

Designing a Test Plan for Server Performance

Key Points
To design a test plan for Mailbox server performance, you need to accurately understand how the server
will be used. This includes factors such as the number of mailboxes, the number of messages users will
send, and the type of clients that will be accessing mailboxes. If you do not accurately understand the
load that will be placed on the server, it is impossible to ensure that server performance will meet your
needs.
When you create your test environment, you should ensure that it replicates the conditions in your
production environment as closely as possible. This means that you should be using identical hardware,
software, and drivers on the test system and production system.
To test server performance, it is impossible to completely replicate the users in a production environment.
However, Microsoft provides two tools that you can use to generate simulated loads on the server:

Exchange Load Generator (Loadgen). You can use this tool to create a simulated load of MAPI,
Outlook Web App, the Microsoft Exchange ActiveSync technology, Internet Message Access
Protocol (IMAP), POP3, and Simple Mail Transfer Protocol (SMTP) clients on Exchange servers. You
can configure this tool based on the usage data you have gathered to determine whether the
performance is acceptable.

Jetstress. You can use this tool to verify disk performance by simulating the Exchange Server database
and the log file loads that a specific number of users produce. It is also capable of simulating the load
generated by database replication in a DAG.
Note In many cases, you can use virtualization to test the functionality of proposed
configurations, including Exchange Server 2010. However, virtualization is not appropriate
for testing server performance unless the production Exchange server is also virtualized.
Question: Do you test server performance before implementation?

3-22

Planning and Deploying Mailbox Services

Lesson 3

Designing Recipient Management

In many ways, recipients are the focus of Exchange Server management, because they are the system
users. Exchange Server 2010 provides some new opportunities to improve recipient management over
previous versions of Exchange Server, such as more fine-grained control over recipient management for
administrators, and delegation of distribution group management. Other aspects of recipient
management include address lists, email address policies, system messages, resource mailboxes, and
mailbox moves.
After completing this lesson, you will be able to:

Design recipient management processes.

Design address lists.

Design address book policies.

Design email address policies.

Design system messages.

Design distribution groups.

Design resource mailboxes.

Design mailbox moves.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-23

Designing Recipient Management Processes

Key Points
Exchange Server 2010 provides a much greater level of flexibility in defining management permissions for
all aspects of Exchange Server 2010, including the management of recipients. By default, a number of
management role groups are created, which allow you to delegate management of specific tasks. For
example, the Recipient Management role group allows you to delegate recipient management tasks.
However, this management role group provides the ability to manage recipients for the entire
organization.
You can perform more customized delegation of management permissions by using management roles
and scopes. A management role defines the management tasks that can be performed, and the scope
defines the objects that the management role can be applied to. The scope can be defined based on
filters that use almost any recipient property or organizational unit (OU).
To delegate recipient management, you must:
1.

Define the users who will perform management tasks.

2.

Assign the appropriate management roles to users or groups.

Management Tools
When you design recipient management processes, you need to consider which management tool is the
most appropriate for different management users.

The Exchange Management Console is best suited for general management tasks, because it provides
a graphical interface that is easy to use. However some less commonly used optionssuch as creating
a recovery databaseare not available.

The Exchange Management Shell provides access to all management options. The scripting
capabilities make it well-suited for performing repetitive tasks. The Exchange Management Console
also has the ability to pipe output from one cmdlet as input to another cmdlet, which enables it to
support bulk operations such a creating many new user accounts simultaneously.

3-24

Planning and Deploying Mailbox Services

The Exchange Control Panel provides access to a limited set of recipient management tasks. It is wellsuited for users who only need to perform those limited tasks. Because it is a web-based
administrative tool, users do not need to install an administrative application on a client computer.
Therefore, you can use this tool for performing remote administration. Tasks performed in the
Exchange Control Panel include multi-mailbox search, some recipient management tasks,
configuration of role-based access control (RBAC), and mobile device management.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-25

Designing Address Lists

Key Points
Address lists are lists of recipients based on a Lightweight Directory Access Protocol (LDAP) query. The
purpose of an address list is to make it easier for users to select a recipient for a message or a meeting
request. Several address lists are created by default in Exchange Server 2010.
The default address lists are:

Global Address List (GAL). This list contains all recipients in the Exchange Server organization.

All Users. This list contains mailbox users, mail-enabled users, room mailboxes, and equipment
mailboxes.

All Groups. This list contains all distribution groups.

All Contacts. This list contains all mail-enabled contacts, but it does not contain mail-enabled users.

All Rooms. This list contains all room mailboxes.

Public Folders. This list contains all mail-enabled public folders.

In larger organizations, the default address lists may not entirely meet the needs of the organization. You
might want to create additional address lists that are specific to workgroups or regions. Creating
additional lists can make it easier to find appropriate recipients by providing smaller lists to look through.
You also can include the smaller lists in offline address books.
The default address lists are all automatically updated when new recipients are created. If you create
customized address lists, those address lists may not be automatically updated depending on the criteria
used to define them. Use the Update-AddressList cmdlet to force an address list to update when
required. Consider running a script as a scheduled task to automatically update customized address lists at
least once a day.

3-26

Planning and Deploying Mailbox Services

Exchange Cached Mode

When you configure an Office Outlook client to use Exchange Cached Mode, the client uses the offline
address book when possible. The default offline address book includes only the GAL. In this default
configuration, you browse the GAL by using the offline address book while you query the other address
lists from a global catalog server.
When you add new recipients to an Exchange Server organization, the recipients are not immediately
available in the GAL of clients that use Exchange Cached Mode. The client needs to download a new copy
of the offline address book before the new recipients are listed in the GAL. The offline address book is
typically updated only once every 24 hours. To work around this, users can use the All Users list or other
appropriate address lists that are not cached.

Multiple Global Address Lists

You can create multiple GALs in an Exchange Server organization, although you would rarely use this
option. Each user still has only a single GAL address list, but the GAL that is available to a user varies. The
GAL that is available to a user is the GAL that has the smallest number of recipients and that the user is a
member of, unless address book policies (ABPs) are used. Multiple GALs are appropriate when a single
Exchange Server organization is used to provide email services for multiple organizations.

Hierarchical Address Book

An address book feature introduced in SP2 for Exchange Server 2010 is the hierarchical address book. You
can use this feature to organize the structure of the GAL to match your organization. To organize the
hierarchy, create distribution groups and set them as hierarchical groups. In many cases, distribution
groups already represent workgroups in your organization. The hierarchical address book feature allows
you to reuse those groups to create address books.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-27

Designing Address Book Policies

Many organizations need only a single set of address lists, which all users share. However, if an
organization needs multiple GALs or different address lists for different groups of users, ABPs simplify the
management of those address lists. Individual mailboxes are associated with an ABP and receive the lists
specified in the ABP. ABPs are introduced in SP2 for Exchange Server 2010.
Each ABP contains:

A GAL

An offline address list

A room list

One or more additional address lists

When you create the address lists for ABPs, consider which attributes should be used to identify the
address list and the GAL members. You should consider using custom attributes for this purpose, because
they can be configured on all recipient types. Some other attributes, such as Company, are not present for
all recipient types.

Scenarios for using ABPs

Some scenarios for using ABPs include:

Differing address lists for multiple related companies that share a single Exchange organization. Each
organization has a separate set of address lists, including separate GALs.

Differing address lists for departments in a single organization. A common GAL is used for all ABPs,
but each department can have different departmental address lists for internal use.

Differing address lists for user groups in a school. Students can be assigned a GAL that includes only
their teacher and other students in their class, while teachers are assigned a GAL that includes all
addresses in the school.

3-28

Planning and Deploying Mailbox Services

Considerations for using ABPs

When you design ABPs, first identify the various user groups that need differing address lists. Then, create
the appropriate address lists, create ABPs that the address lists are assigned to, and then assign the ABPs
to mailboxes.
When you use ABPs, consider the following:

Mailboxes associated with an ABP must be hosted on a Mailbox server running Exchange Server 2010
with SP2.

Hierarchical address books and ABPs cannot be used at the same time.

A GAL in an ABP must contain, at a minimum, the objects defined in the other address lists that are
part of the ABP. The GAL should also contain the user that the ABP is assigned to.

ABPs do not separate mailboxes in an Exchange organization. ABPs create separate address lists, but
they do not prevent users who have differing ABPs from sending messages to each other.

To use ABPs, users must connect through either Exchange Web Services (EWS) or the Address Book
Service on a Client Access server. Outlook 2011 for Mac and Entourage 2008 clients query global
catalog servers directly to obtain address lists and do not use ABPs. If Outlook 2011 for Mac connects
from the Internet, you can configure it to use EWS instead of querying directly.

Any address list except a GAL can be used as the room list in an ABP. This means that you can use an
empty address list in scenarios where users assigned an ABP do not need to book rooms.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-29

Designing Email Address Policies

Key Points
You can use email address policies to apply email addresses to recipients. A single email address policy
can include multiple email addresses. This allows you to have multiple variations in user name or domain
name for each recipient.
The Default Policy applies to all recipients. In many organizations, the Default Policy is the only one
required, because all users have the same email address format. Larger organizations may need multiple
email address policies to provide varying address formats or domain names for some users. For example, a
recently purchased subsidiary may need to retain older email addresses to ensure that they receive
messages from clients that have not updated their address books with the companys new email address.
When you create an email address policy with multiple email addresses, you must define one of the
addresses as the primary address. The recipient can receive messages at all defined email addresses, but
outgoing messages use the primary address as the Reply To address. When you change domain names or
email address formats for the organization, you should retain the old email addresses and add the new
email addresses as the primary address. Then as recipients outside your organization reply to messages,
they can add the new email addresses to their address books.
When you modify email address policies or create new ones, you can apply the changes immediately, or
schedule them to occur at a later time. By scheduling the policy application to occur outside of regular
business hours, you minimize the impact on the system.
Question: Do you see a need for multiple email address policies in your organization?

3-30

Planning and Deploying Mailbox Services

Designing System Messages

Key Points
Exchange Server 2010 allows you to customize system messages. You can use delivery status notifications
(DSNs) to notify internal and external senders about message delivery status. You can use quota messages
to inform users when their mailboxes are above the defined quota levels.
You can customize a DSN to add additional information, or to provide a better explanation of why the
error occurred. You could also modify a DSN to provide contact information for the person who can help
resolve the problem. You can format the custom DSN by using Hypertext Markup Language (HTML).
If you choose to customize DSN messages, you can customize them separately for internal and external
senders. When you provide contact information in a DSN, it may only be appropriate for internal senders.
You can customize quota messages to make the messages more user-friendly, or to provide contact
information. For example, in a warning message about a mailbox that is too large, you could provide
some information about how to request a larger mailbox quota.
Question: Will you customize quota messages for your organization?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-31

Designing Distribution Groups

Key Points
When you create a new distribution group in Exchange Server 2010, it is created as a universal group. This
ensures that there are no problems with groups containing members from multiple domains. Distribution
groups that are upgraded from previous versions of Exchange Server may be Global groups and function
properly with Exchange Server 2010.
When designing distribution groups, you can perform the following tasks:

Designate an expansion server for a group. The expansion server is responsible for expanding the
group membership list for delivery. This server is not required in Exchange Server 2010, but you can
use it to control processing load. If you do not specify an expansion server, then the first Hub
Transport server processing the message functions as the expansion server.

Designate a group manager. Use this for delegating group membership management to a user in a
department or workgroup that is responsible for the group. The group manager can then manage
the membership of the group, which reduces the workload for Exchange Server administrators. In
many cases, a group manager is more responsive to requests for group membership changes than
Exchange Server administrators.

Enable moderation. When you enable moderation, messages sent to the group must be approved by
a moderator before they are delivered to the group. This can be useful for ensuring that only
appropriate content is sent to a group. For example, a moderator could ensure that an All Users
group is not used by enthusiastic parents attempting to sell fund-raising chocolates for their children.

Reuse security groups as distribution groups. If a security group is already configured with the
members that you want to use for a distribution group, then you can mail-enable an existing security
group. This avoids the need to maintain two separate membership lists. However, you must consider
who will manage the group membership, as often the task of managing distribution groups is
separate from managing security group membership.

3-32

Planning and Deploying Mailbox Services

Allow users to join and leave distribution groups when appropriate. You can configure distribution
groups to allow users to join and leave distribution groups rather than requiring an Exchange Server
administrator to maintain the group membership. This allows users to join distribution groups that
receive information that is of interest to them. For example, in a research and development
department, there could distribution groups for various subject areas. You can also configure groups
to require manager approval for joining. Users cannot join and leave security groups. Security groups
have closed membership.

Dynamic Distribution Groups

The dynamic distribution group membership list is generated based on an LDAP query. The automatic
generation of the membership reduces the workload of Exchange Server administrators. However, to
successfully use dynamic distribution groups, you need to have sufficient recipient information in Active
Directory Domain Services (AD DS) to create effective queries. For example, you may need to configure
recipient information such as Department, Company, or City.
The use of dynamic distribution groups does increase the load on domain controllers. However, the
increase is minimal unless dynamic distribution groups are being used very often.
Question: Will you use moderated groups in your organization?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-33

Designing Resource Mailboxes

Key Points
You can use resource mailboxes for booking rooms and equipment. The main benefit of using resource
mailboxes is to provide a centrally accessible schedule for the resource so that users can see when it is
available. You have the option to automate the booking process, or designate a delegate to manage all
bookings.
When you configure a resource mailbox to automatically accept bookings, it reduces the delegates
management workload. It also makes it faster for users to confirm that the resource is booked. You can
define rules for when a resource mailbox will automatically accept a booking.

In-Policy and Out-of-Policy Requests

In-policy requests are those requests that meet the standard booking rules for the resource. You can
select which users will have in-policy requests automatically approved, and which still need to be
approved by a delegate. For example, you can configure a room resource for the marketing department
to automatically accept meeting request from users in the marketing department, but require meeting
requests from other users to be approved by a delegate.
The resource policy defines the rules that are in-policy. These rules include:

Allow conflicting meeting requests. When this option is enabled, multiple users can book a resource
at the same time. In most cases, this is not appropriate.

Allow repeating meetings. Some organizations choose not to allow this option, in order to prevent
users from booking resources unnecessarily.

Allow scheduling only during working hours. Use of this option is often appropriate inside a building
that will not generally be available outside of work hours. However, it would not be appropriate to
use this option for a resource such as projectors or laptops that are used outside the organization.

Reject repeating meetings that have an end date beyond the booking window. Use this option to
ensure that repeating meetings are not booked too far in the future.

3-34

Planning and Deploying Mailbox Services

Booking window. This option defines how far in the future meeting requests can be scheduled. If this
window is too large, then a resource may be booked far in the future, but the person that booked the
resource may not actually require the resource by the time the distant meeting date arrives.

Maximum duration. This option defines how long a given meeting can last.

Maximum conflict instances. When a repeating meeting is being scheduled, a certain number of
conflicts can be allowed so that the entire meeting request is not rejected.

Conflict percentage allowed. When a repeating meeting is scheduled, you can use this option to allow
a certain percentage of conflicts, so that the entire meeting request is not rejected.

Out-of-policy requests are those that do not meet the standard booking rules for the resource. Out-ofpolicy requests must always be approved by a delegate. However, you can specify the users that can
submit out-of-policy requests. If a user is not allowed to submit out-of-policy requests, any out-of-policy
requests submitted by that user will be rejected, rather than waiting for delegate approval.
You need to decide the appropriate policy settings for each resource, who can book in-policy requests,
and who can book out-of-policy requests.

Delegates
In addition to determining booking policies, you also need to decide which user or users should be the
delegate for a resource. The resource delegate is responsible for approving meeting requests that are not
automatically accepted, and for arbitrating conflicting requests. The delegate for a resource should be the
person responsible for managing that resource within the organization.
Question: Does your organization need to implement resource mailboxes?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-35

Designing Mailbox Moves

Key Points
You can move mailboxes between mailbox databases and mailbox servers. Some of the reasons you might
want to move mailboxes are:

Migration to a new server. When you purchase a new server, you will need to move mailboxes to the
new server before decommissioning the old server.

Load balancing between servers. If one server is performing poorly because it is overloaded, you may
want to move some mailboxes to another server with sufficient resources to handle additional
mailboxes.

Reduce database size. If a mailbox database becomes too large in size, it may be difficult to restore
during disaster recovery. You can create multiple smaller mailbox databases, and then move
mailboxes onto those databases.

User moves between locations or departments. Often a mailbox database or mailbox server is
dedicated to a department or location. When a user moves to a different location or department, you
should also move the user mailbox to the appropriate mailbox database.

Online Mailbox Moves

Previous versions of Exchange Server do not support moving mailboxes when users are logged on. This
limits the timeframe for mailbox moves, and in some cases it results in migration projects lasting for an
extended period of time.
In Exchange Server 2010, you can perform mailbox moves online with no user impact. This avoids the
need to schedule mailbox moves. However, to perform an online mailbox move to Exchange Server 2010,
the source server must be running Exchange Server 2007 with SP2 or Exchange Server 2010, and you must
initiate the move by using the New-MoveRequest cmdlet, rather than the Move-Mailbox cmdlet. When
you use the Exchange Management Console to move mailboxes, an online mailbox move is performed
when possible.

3-36

Planning and Deploying Mailbox Services

Question: Do you see a need for online mailbox moves in your organization?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-37

Lesson 4

Designing Public Folder Architecture

You can use public folders as a repository for data in collaboration scenarios. You can also use them as a
central mailbox for a group of users, and as centralized calendars. Although Exchange Server 2010 deemphasizes public folders, they are still fully supported, and some organizations use them extensively.
After completing this lesson, you will be able to:

Analyze business requirements for public folders.

Design Mailbox servers for storing public folders.

Design public folder replication.

Design client access to public folders.

Plan the public folder hierarchy.

Design public folder permissions.

Describe options for transitioning away from public folders.

3-38

Planning and Deploying Mailbox Services

Analyzing Business Requirements for Public Folders

Key Points
Some organizations make little use of public folders, while 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 organizations business
requirements for public folders.

Information Required for Planning Public Folders

To clarify and determine business requirements for public folders, you should consider the following
information:

What versions of Office Outlook does your organization use? If you use Office Outlook 2003 or earlier
versions, you still require public folders to store the offline address book and free/busy information.

How many public folders has your organization implemented, and how much data does each public
folder 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 helps you plan the location and
capacity of the public folder servers. 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 organizations 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
functionssuch as storing company datawhile other organizations use public folders for more
advanced functionssuch as creating customized applications.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-39

Do the public folders support strategic business applications? Analyze the organizations 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 that uses the Microsoft SharePoint
services or another kind of web server for sharing some types of company information?
Question: Does your organization use public folders, and if it does, what is the purpose?

3-40

Planning and Deploying Mailbox Services

Designing Mailbox Servers for Storing Public Folders

Key Points
Public folders are stored in public folder databases on Exchange Server 2010 Mailbox servers. By default, if
you specify that your organization includes Office Outlook 2003 or earlier clients when you install your
organizations first Mailbox server, a public folder database is created on this first Mailbox server. No other
public folder databases are installed; however, 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 can 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 how much space to dedicate to a
public folder database.
The processor and memory requirements for servers hosting a public folder database are the same as for
other Mailbox servers. If the server hosts 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. If public folder data changes frequently, then the disk I/O, memory, and processing
requirements increase.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-41

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 users 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 mailbox databases.

3-42

Planning and Deploying Mailbox Services

Designing Public Folder Replication

Key Points
Organizations that use public folders extensively also frequently use public folder replication to provide
fault tolerance and better access for users in different locations. When you enable public folder
replication, the data in a public folder is synchronized between two or more servers. If one server is
unavailable, users can access the data from one of the remaining replicas. A public folder database can
exist on a Mailbox server that is part of a DAG, but the public folder database cannot be replicated by the
DAG.

Default Configuration for Public Folder Replication and Referrals

Exchange Server 2010 supports a single public folder tree, also known as the public folder hierarchy. The
public folder hierarchy is replicated to each Exchange Server 2010 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, Office 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
2010. If a public folder replica is located in more than one other site, the Exchange server refers the client
to the replica site based on the lowest IP site link costs between the sites.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-43

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 organizations locations, and the impact that
replicating public folders and referrals has on the network. When designing a public folder replication and
referral strategy, consider the following factors:

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. Simply calculate how much new content is added to the public folder on
a daily basis, and that is the network traffic that 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. To optimize replication, you should:

Configure public folder replication only for public folders that do not change frequently and that
contain large messages.

Use public folder referrals for public folders that change frequently and to which users must
always have access to the latest content.

Schedule public folder replication during non-peak hours. In cases of limited bandwidth, and if
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 you 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, you should
enable public folder replication. This provides users with a more positive experience compared to
accessing public folders across a wide area network (WAN) connection. If you do not have a Mailbox
server capacity in the remote site, then use public folder referrals.

If you have Office Outlook 2003 or earlier MAPI clients, you should enable replication 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 Office Outlook
clients in your organization require.
Question: Why would you replicate the content of public folder?

3-44

Planning and Deploying Mailbox Services

Designing Client Access to Public Folders

Key Points
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 2010, users can access public folders only using MAPI clients such as Office Outlook
2007, or earlier Office Outlook versions. In some earlier versions of Exchange Server, users could also
access the public folders by using an IMAP4 or network news transfer protocol (NNTP) client.
In most organizations, users on the internal network use Office Outlook to access email on the Exchange
server, so these users continue to have access to public folders. However, organizations rarely deploy
Office 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 remote procedure call (RPC) over Hypertext Transfer Protocol Secure (HTTPS)
to connect to the Client Access server.

You can provide access to the mailboxes and public folders through Outlook Web App. Earlier
versions of Outlook Web Access opened a new window to view public folders. Outlook Web App in
Exchange Server 2010 integrates public folders into the same interface as the mailbox.

To provide access to public folders for IMAP4 and NNTP clients, you must leave the public folders on
an earlier Exchange Server version. Next, you must configure the clients and the network
infrastructure to enable the clients to connect to the Exchange server that is hosting the public folder.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-45

If users use 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 email address to the public folder
that enables users to send messages to the folder using any email client.
Note If web access to public folders is important in your organization, consider moving
the public folder content to a server running SharePoint.

3-46

Planning and Deploying Mailbox Services

Planning the Public Folder Hierarchy

Key Points
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.
The following table lists the guidelines that you must consider when designing the public folder hierarchy.
Guideline

Reason

Create hierarchical structure Typically, a public folder hierarchy is organized according to a

into logical and consistent
companys business model, so that each top-level folder represents one
groupings that are easy for department within the company.
users to explore and access.
Use a consistent and logical
naming scheme for public
folders.

Users should be able to identify the contents of a public folder from the
public folder name.

Create a public folder

hierarchy that enables you
to delegate administrative
tasks.

By assigning the appropriate permissions at the top-level folders, you

can allow users to perform tasks such as adding permissions, or adding
and removing folders within their departments top level public folder.

Create a public folder

hierarchy that can simplify
administrative processes.

You can 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-47

Designing Public Folder Permissions

Key Points
To ensure the simplified management of public folder infrastructure 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

The following table lists the guidelines that you must consider when designing administrative permissions
for public folders.
Guideline

Reason

Identify a group of
administrators who will
administer public
folders.

Public folder administration includes managing folder creation permissions,

assigning permissions 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
permissions for lowerlevel folders.

In most cases, the public folder users understand the public folder
requirements better than the messaging administrators. This means you can
delegate the public folder administration taskssuch as creating new public
folders and assigning client permissionsto advanced users. In many
organizations, each department assigns a user or group of users the
responsibility of managing the departments 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 to
assign permissions to lower-level folders, but it does not allow them to modify other public
folder settings, such as replication or folder size.

3-48

Planning and Deploying Mailbox Services

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 Office Outlook, the Public
Folder Management Tool, or the Exchange Management Shell to assign public folder roles.
You can apply client permissions to a user based on the following rules:

If the user is explicitly granted permission to the public folder, only those clients that have been
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 users
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 users permissions are the least restrictive
of any distribution group or the default permissions for the public folder.

The following table lists the guidelines that you must consider when designing client permissions.
Guideline

Reason

Create mail-enabled
universal groups to
enable public folder
permissions.

You can grant access to public folders for individual users, but managing
groups is more efficient than managing individual users. 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

anonymous
permissions.

Default permissions are assigned to all authenticated users. In Exchange

Server 2010, the default group is assigned the Author permission role. This
means that all users can view the folder contents and can 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
Office Outlook clients must be authenticated in order to access a user
mailbox, you rarely allow anonymous access to public folders in Exchange
Server 2010.

Limit permissions at
higher levels of the
hierarchy.

When you create a new public folder, it inherits the permissions from the
parent public folder. Limiting permissions in the parent folder ensures that
unnecessary permissions are not given to lower-level folders.

Note When permissions are modified on a parent folder, they are not inherited by the
child folders. However, you can propagate permissions from the parent folder to child
folders.
Question: Which users in your organization have permission to create new public folders?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-49

Alternatives to Public Folders

Key Points
Public folders are still supported by Microsoft, and will be supported at least as long as Exchange Server
2010 is supported. However, public folders are deprecated. This means that you should be exploring
alternatives to public folders before creating additional public folders.
One of the most commonly used alternatives to public folders is SharePoint Server 2010 and SharePoint
Foundation 2010. SharePoint Server 2010 and SharePoint Foundation 2010 share a common core set of
features, but SharePoint Server 2010 has additional advanced features. Both are web-based platforms for
collaboration.
Some of the commonly used features in SharePoint are:

Document libraries. Used to store documents that can be checked in and out, and tracked with
version control.

Discussion groups. Used to provide a forum for communication, similar to postings in a public folder.

Shared calendars. Can be used as a direct replacement for shared calendars in a public folder.

Contacts. Can be linked with Office Outlook to provide a shared location for creating contacts.

SharePoint can also be integrated with Exchange Server 2010 to provide meeting workspaces. Meeting
workspaces are created as a site to support a meeting and are created automatically as part of the
meeting request. You can use the meeting workspace to store documents related to the meeting and to
have preliminary discussions.

3-50

Planning and Deploying Mailbox Services

Other Alternatives
If you do not require the advanced functionality in SharePoint, you can also consider using:

Web-based discussion forums. If your only requirement is to provide discussion forums, there are a
wide variety of web-based discussion products available that you can use. Because the interface is
web-based, you do not need for special client software.

NNTP servers. If your only requirement is to provide discussion forums, you also can consider using
an NNTP server. However, many users might not understand what an NNTP client is, which may lead
to increased user support requirements.
Question: Does your organization use SharePoint?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-51

Lab: Planning and Deploying Mailbox Services

Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, do the
following:
1.

On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-CL1 virtual

machines are running.

3.

If required, connect to the virtual machines. Log on to the virtual machines as

Adatum\Administrator using the password Pa$$w0rd.

Lab Scenario
You are a messaging engineer for the A. Datum Corporation, an enterprise-level organization with
multiple locations. A. Datum Corporation is an international organization involved in technology research
and investment, and it is planning to upgrade from Exchange Server 2003 to Exchange Server 2010.
You have been tasked with reviewing the current messaging infrastructure and network topology, with a
goal of planning the deployment and configuration of mailbox services. You need to make proposals
about how best to address the needs of the various stakeholders in the organization.
Finally, you need to implement part of your proposed mailbox services design.
Note Your instructor may choose to perform this lab as a group discussion rather than as
an individual activity.

3-52

Planning and Deploying Mailbox Services

Exercise 1: Designing the Mailbox Server Deployment

Scenario
In this exercise, you will examine the current topology and messaging infrastructure. You will determine
the appropriate Mailbox server deployment based on the information supplied in the A. Datum Exchange
Server 2010 project documentation.
The main tasks for this exercise are as follows:
1.

Review the A. Datum Corporation documentation.

2.

Answer questions related to the documentation.

3.

Perform high level planning for Mailbox server storage in London.

4.

Use the Exchange 2010 Mailbox Server Role Requirements Calculator spreadsheet to determine the
configuration.

5.

Update the A. Datum Large Mailbox server design document.

Server Design Interviews

Marcel Truempy, 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 percent over the next three years. We will be buying more companies,
so prepare for that, as well.

Carole Poland, IT Manager

We have deployed a very good SAN at London, Tokyo, and Vancouver. 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 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.
Many of our organizations users are using Office Outlook 2003, but we have started a project to deploy
the Windows 7 operating system with the 2007 Microsoft Office system; however, it will take at least 18
months to complete. Additionally, we will be deploying new client computers in our future London and
Chennai offices.

Andreas Herbinger, Messaging Specialist

I understand that Carole wants to use the SAN for mailbox storage, but I think she is underestimating the
amount of storage space we require for Exchange Server servers. The SANs that we have in place right
now have only about 10 terabytes of free disk. Unless we keep our mailboxes very small, it simply wont
be sufficient.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-53

Her plan to use the SAN will also not result in high availability for Mailbox servers. The server itself will be
a single point of failure. Exchange Server 2010 does not support the use of single copy clusters like
Exchange Server 2007. A DAG will be required for high availability, and each server in the DAG maintains
a copy of the database. It would be incredibly inefficient to store multiple copies of the same data on the
same SAN.
For initial planning purposes, we need to assume that well use a DAG with at least three database copies.
Two copies will be located in the location with users, and one copy will be offsite for disaster recovery.
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 200 MB or
more. During a meeting last week, the CIO mentioned that when we get to Exchange Server 2010, we
would set up a mailbox size limit of 500 MB for all users and a 1 GB limit for executives or other
exceptional cases. About 25 percent of the users will fall into the exceptional category. In addition, we
want to create personal archives for the users that are double the size of the mailbox to eliminate the use
of PST files.
I have some concerns with increasing the mailbox size to this limit. The back-up system in all of our offices
doesnt have as much capacity as we would like. In some offices, we are still backing up to tape. Some of
the tape backup systems can restore at only 50 GB per hour. According to the SLA that we have in place,
we are supposed to restore any failed database within an hour of failure.

Server Design Statistics

This is a standard profile that can be used for all mailbox servers. Based on the number of users in each
location, we can vary the amount of RAM and the size of the storage.

Server Hardware Characteristics

Processor: 2 x six core processor, total SPECint Rate of 400

Disks: 2000 GB, 7.2K revolutions per minute (RPM) SAS 3.5

Tier 1: User Messaging Statistics

Number of mailboxes: 25 percent of total on each Mailbox server

Messages sent/received per day: 20 sent/80 received

Average message size: 50 KB

Tier 2: User Messaging Statistics

Number of mailboxes: 75 percent of total on each Mailbox server

Messages sent/received per day: 10 sent/40 received

Average message size: 25 KB

Task 1: Review the A. Datum Corporation documentation

Review the following information:

Server Design Interviews

Server Design Statistics

3-54

Planning and Deploying Mailbox Services

Task 2: Answer questions related to the documentation

Question: In the Server Design Interviews, what points are raised that impact your Mailbox server
deployment plan, and how do they impact it?

Question: In the Server Design Statistics, what information is relevant to determining server
design, and why?

Task 3: Perform high level planning for Mailbox server storage in London

Complete the following proposal document by answering the questions.

A. Datum high level planning for mailbox servers in London
Document Reference Number: JC040400/1
Document Author
Date

Jason Carlson
2nd April 2010

Requirement Overview
Create a high level plan for Mailbox server storage in London.
Additional Information
N/A
Question: Assuming that there are 12,000 users in London, how much disk space is required for
mailbox databases?

Question: Should the disk space for Mailbox servers be SAN or DAS?

Question: If DAS is used, will the disk space use RAID or JBOD?

Question: What size and speed of disk do you think is appropriate?

Question: Should transaction logs be stored on a separate LUN from database files?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-55

Task 4: Use the Exchange 2010 Mailbox Server Role Requirements Calculator
spreadsheet to determine the configuration
1.

On VAN-CL1, open the \\VAN-EX1\E$\Labfiles\LabResources\E2010Calc18.2.xlsm spreadsheet.

Click Enable Content and then click Yes.

2.

Enter the following data on the Input tab:

Exchange Environment Configuration

Global Catalog Architecture: 64-bit

Server Multi-Role Configuration: No

Server Role Virtualization: No

High Availability Deployment: YES

Number of Mailbox Servers Hosting Active Mailboxes/DAG (Primary Datacenter): 2

Number of Database Availability Groups: 1

Mailbox Database Copy Configuration

Total Number of HA Database Copy Instances (Includes Active Copy) within DAG: 3

Total Number of Lagged Database Copy Instances within DAG: 0

Number of HA Database Copy Instances Deployed in Secondary Datacenter: 1

Exchange Data Configuration

Data Overhead Factor: 20%

Mailbox Moves / Week Percentage: 1%

Dedicated Maintenance / Restore LUN: Yes

LUN Free Space Percentage: 20%

Exchange I/O Configuration

I/O Overhead Factor: 20%

Additional I/O Requirement / Server: 0

Site Resilience Configuration

Site Resilient Deployment: Yes

Site Resilience User Distribution Model: Active/Passive

Site Resilience Recovery Point Objective (Hours): 24

Activation Block Secondary Datacenter Mailbox Servers: Yes

Database Configuration

Maximum Database Size Configuration: Default

Automatically Calculate Number of Unique Databases / DAG: Yes

Calculate Number of Unique Databases / DAG for Symmetrical Distribution: No

3-56

Planning and Deploying Mailbox Services

Tier 1 User Mailbox Configuration

Total Number of Tier 1 User Mailboxes: Use the data from Task 2

Projected Mailbox Number Growth Percentage: Use the data from Task 2

Total Send/Receive Capability / Mailbox / Day: Use the data from Task 2

Average Message Size (KB): Use the data from Task 2

Mailbox Size Limit (MB): Use the data from Task 2

Personal Archive Mailbox Size Limit (MB): Use the data from Task 2

Deleted Item Recovery Window (Days): 14

Single Item Recovery: Enabled

Calendar Version Storage: Enabled

IOPS Multiplication Factor: 1.00

Megacycles Multiplication Factor: 1.00

Desktop Search Engines Enabled (for Online Mode Clients): No

Predict IOPS Value: Yes

Tier 2 User Mailbox Configuration

Total Number of Tier 2 User Mailboxes: Use the data from Task 2

Projected Mailbox Number Growth Percentage: Use the data from Task 2

Total Send/Receive Capability / Mailbox / Day: Use the data from Task 2

Average Message Size (KB): Use the data from Task 2

Mailbox Size Limit (MB): Use the data from Task 2

Personal Archive Mailbox Size Limit (MB): Use the data from Task 2

Deleted Item Recovery Window (Days): 14

Single Item Recovery: Enabled

Calendar Version Storage: Enabled

IOPS Multiplication Factor: 1.00

Megacycles Multiplication Factor: 1.00

Desktop Search Engines Enabled (for Online Mode Clients): No

Predict IOPS Value: Yes

Backup Configuration

Backup Methodology: Exchange Native Data Protection

Database and Log Isolation Configured: No

Backup/Truncation Failure Tolerance: 3

Network Failure Tolerance (Days): 0

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

Storage Options

3.

Consider Storage Designs Utilizing JBOD (if applicable): Yes

Primary Datacenter Disk Configuration

Database + Log: Use the data from Task 2

Restore LUN: Use the data from Task 2

Secondary Datacenter Disk Configuration

Database + Log: Use the data from Task 2

Restore LUN: Use the data from Task 2

Server Configuration

Primary Datacenter Mailbox Servers: Use the data from Task 2

Primary Datacenter Mailbox Servers: Use the data from Task 2

Log Replication Configuration

For Hours 1-5,20-24: 1%

For Hours: 6-7,18-19: 5%

For Hours 8-17, 7%

Network Configuration:

Network Link Type: Fast Ethernet

Network Link Latency: 50.00

Log off of VAN-CL1.

Task 5: Update the A. Datum Large Mailbox server design document

Complete the following proposal document by answering the questions.

A. Datum Large Mailbox server design
Document Reference Number: JC040400/2
Document Author
Date

Jason Carlson
2nd April 2010

Requirement Overview
Determine the hardware configuration for large Mailbox servers that use DAS.
Additional Information
N/A
Proposals
Question: What is the processor configuration for each server?

Question: What type of disks are being used?

3-57

3-58

Planning and Deploying Mailbox Services

(continued)
A. Datum Large Mailbox server design
Question: How many databases are recommended?

Question: How many mailboxes are recommended for each database?

Question: What is the recommended RAM for this server?

Question: What is the expected CPU utilization for this server?

Question: What is the recommended number of LUNs on the server?

Question: How many databases are recommended per LUN?

Question: What is the total disk space required per server?

Question: What type of RAID is recommended?

Question: How many database disks are recommended for the primary datacenter servers?

Question: How many database disks are recommended for the secondary datacenter server?

Results: After this exercise, you should have determined the configuration for London mailbox servers.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-59

Exercise 2: Designing Recipient Management

Scenario
In this exercise, you will determine the appropriate recipient management design based on the
information supplied in the A. Datum Exchange Server 2010 project documentation.
The main tasks for this exercise are as follows:
1.

Review the A. Datum Corporation documentation.

2.

Answer questions related to the documentation.

3.

Document the required configuration

Recipient Management Interviews

Conor Cunningham, Messaging Services Manager
We have two distinct business units right now. A. Datum is using the adatum.com domain, and Trey
Research is using the TreyResearch.net domain. All users in each business unit should be using their
assigned email address. However, sometimes, external users send messages to the wrong domain. All
incoming messages should correctly resolve for both domains.
Ive been also been asked whether it is possible for Trey Research to have a separate GAL and other
address books from A. Datum. Since most communication is with a business unit wed like to simplify the
address books for them.

Lori Penor, IT Client Services Manager

Client Services is the first point of contact when users in our organization have computer problems. They
also create and manage the user accounts. In our existing system, they are also responsible for creating
mailboxes. Id like this to continue.
The Client Services staff at each location should be able to create and manage users and mailboxes only in
that physical location. The exceptions to that are Client Services team leaders in each location.
Occasionally, there is a need for Client Services staff to manage users in another location, but that should
be restricted to only the team leaders.

Sidney Higa, IT Client Services Team Lead in Toronto

Were quite excited about the implementation of Exchange Server 2010. We have some ongoing concerns
that were hoping the new implementation can help us out with.
Our first concern is booking meeting rooms. The current system is working, but is difficult to configure.
Wed like to have an automated system where most bookings are automatically accepted and only
conflicts or other problems need to be manually approved.
Our second concern is group management. Right now, we are responsible for managing the membership
of distribution groups. If there is some way we can easily delegate that down to department
representatives, it would significantly reduce our workload.

Task 1: Review the A. Datum Corporation documentation

Review the following information:

Recipient Management Interviews

3-60

Planning and Deploying Mailbox Services

Task 2: Answer questions related to the documentation

Question: In the Recipient Management Interviews, what points are raised that impact your
Mailbox server deployment plan, and how do they impact it?

Task 3: Document the required configuration

Complete the following proposal document by answering the questions.

A. Datum recipient management configuration
Document Reference Number: JC040400/3
Document Author
Date

Jason Carlson
2nd April 2010

Requirement Overview
Determine the configuration required to meet recipient management needs.
A. Datum recipient management configuration
Proposals
Question: How will you ensure that recipients are assigned the correct email addresses?
Question: How will you enable the IT Client Services staff to perform recipient management?
Question: How will you meet the needs for meeting room bookings?
Question: How will you address the needs for distribution group management?
Question: How will you address the need for separating the address books for A. Datum and Trey
Research?

Results: After this exercise, you should have designed the appropriate configuration for recipient
management.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-61

Exercise 3: Designing a Public Folder Deployment

Scenario
In this exercise, you will determine the appropriate recipient management design based on the
information supplied in the A. Datum Exchange Server 2010 project documentation.
The main tasks for this exercise are as follows:
1.

Review the A. Datum Corporation documentation.

2.

Answer questions related to the documentation.

3.

Document the required configuration

Public Folder Interviews

Scott MacDonald, Vice President North America
The executives have a wide variety of information that wed like to share. We were thinking that a
discussion forum would be useful. Ive been talking with Sabine and he has been recommending Windows
SharePoint Services for this type of collaboration. Hes told me that there are several SharePoint sites
being successfully used by other groups in the organization. However, we are very comfortable using
Outlook for this and dont want to use learn yet another tool.
It is important that we can access this data quickly from any location. I also want to make sure that a
single server failure will not cause data to be lost.

Conor Cunningham, Messaging Services Manager

There are a number of groups using SharePoint sites collaboratively and very successfully. We are actively
encouraging anyone that is looking to use public folders to consider SharePoint instead. SharePoint is
capable of a much wider variety of functionality that public folders just cannot do. It has features like
document libraries, shared calendars, blogs, and discussion groups.
That said, I dont see eliminating public folders anytime soon. So many users are just comfortable with
them.

Lori Penor, IT Client Services Manager

We are looking for a way to share information within the IT Client Services team. I was thinking that a
public folder might be the best way to do this. That way we can have a shared calendar for department
events and discussions.

Task 1: Review the A. Datum Corporation documentation

Review the following information:

Public Folder Interviews

Server Design Interview

Task 2: Answer questions related to the documentation

Question: In the Public Folder Interviews, what points are raised that impact your public folder
deployment plan, and how do they impact it?

Question: In the Server Design Interview, what points are raised that impact your public folder
deployment plan, and how do they impact it?

3-62

Planning and Deploying Mailbox Services

Task 3: Document the required configuration

Complete the following proposal document by answering the questions.

A. Datum public folder configuration
Document Reference Number: JC040400/4
Document Author
Date

Jason Carlson
2nd April 2010

Requirement Overview
Determine the configuration required to meet public folder needs.
Proposals
Question: How will you address the executives desire for public folders?
Question: How will you address the IT Client Services request for a public folder?
Question: Other than the public folder for executives, which other public folders are required?

Results: After this exercise, you should have designed the appropriate configuration for public folders.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-63

Exercise 4: Implementing Mailbox Services

Scenario
The main tasks for this exercise are as follows:
1.

Replicate and configure the Executives public folder.

2.

Create and configure a resource mailbox.

3.

Test the delegation of a resource mailbox.

4.

Configure a distribution group for delegated management and moderation.

5.

Test moderation of a distribution group.

Task 1: Configure an address book policy for Trey Research.

1.

On VAN-EX1, use the Active Directory Users and Computers administrative tool to create a new
organizational unit in the root of adatum.com.

Name: Trey

2.

Open the Exchange Management Console and browse to the Mailbox node under Organization.

3.

Create a new address list for Trey Research users:

4.

Name: Trey Users

Display Name: Trey Users

Container: \

Recipient container: Adatum.com/Trey

Recipient types: Users with Exchange mailboxes

Conditions: None

Schedule: Immediately

Create a new address list for Trey Research rooms:

Name: Trey Rooms

Display Name: Trey Rooms

Container: \

Recipient container: Adatum.com/Trey

Recipient types: Resource mailboxes

Conditions: None

Schedule: Immediately

5.

Open the Exchange Management Shell.

6.

Create a new GAL for Trey Research by using the following command:
New-GlobalAddressList TreyGAL RecipientContainer ou=Trey,dc=adatum,dc=com

3-64

Planning and Deploying Mailbox Services

7.

Create a new OAB for Trey Research by using the following command:
New-OfflineAddressBook TreyOAB AddressLists TreyGAL

8.

9.

In the Exchange Management Console, create a new address book policy with the following settings:

Name: TreyABP

Global address list: TreyGAL

Offline address list: TreyOAB

Room list: Trey Rooms

Address lists: Trey Users

In the Exchange Management Shell, assign TreyABP to all users in the Trey organizational unit by
using the following command:
Get-Mailbox OrganizationalUnit Trey | Set-Mailbox AddressBookPolicy TreyABP

10. On VAN-CL1, log on as Adatum\Wei with the password Pa$$w0rd.

11. Open Outlook 2010, configure an Outlook profile as needed and then view the list of address books.
12. Verify that the Global Address List is empty because the OAB containing TreyGAL has not been
generated yet.
13. Verify that Wei is the only user listed in the Trey Users address book.
14. Log off of VAN-CL1.

Task 2: Create and configure a resource mailbox

1.

2.

On VAN-EX1, open the Exchange Management Console and create a new resource mailbox with the
following options:

First name: Room 100

User logon name: Room100

Alias: Room100

In the properties of Room 100, perform the following:

Enable the Resource Booking Attendant.

Specify Andreas Herbinger as a delegate.

Allow Luca Dellamore to submit out-of-policy requests.

Task 3: Test the delegation of a resource mailbox

1.

On VAN-CL1, log on as Adatum\Luca using the password Pa$$w0rd.

2.

Open Microsoft Outlook 2010.

3.

Create and send a new meeting request with the following settings:

To: Luca; Conor

Subject: Exchange Planning

Start time: Tomorrow 1pm

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

End Time: Tomorrow 2pm

Room: Room 100

4.

Notice that an automatic response is received indicating that the booking was accepted by Room
100, because the request is in-policy. The response may take a minute or so to appear.

5.

Create and send a new meeting request with the following settings:

To: Luca; Conor

Subject: Exchange Project Review

Start time: 9 months from today at 1pm

End Time: 9 months from today at 2pm

Room: Room 100

6.

Open the Microsoft Internet Explorer browser, and then connect to https://vanex1.adatum.com/owa.

7.

Log on to Outlook Web App as Adatum\Andreas using the password Pa$$w0rd.

8.

Read and approve the meeting request from Luca.

9.

In Outlook, verify that Room 100 has accepted the meeting request.

3-65

Task 4: Configure a distribution group for delegated management and moderation

1.

On VAN-EX1, use the Exchange Management Console to open the Properties of the Executives
distribution group.

2.

On the Group Information tab, add Conor Cunningham as group manager.

3.

On the Membership approval tab, verify that group membership is Closed.

4.

On the Mailflow Settings tab:

Enable moderation.

Add Luca Dellamore as the moderator.

Add the Executives distribution group as a sender that does not require approval.

Task 5: Test moderation of a distribution group

1.

On VAN-CL1, send a message in Outlook Web App from Andreas with the following settings:

To: Executives

Subject: New Public Folder

Body: The Executives public folder has been created for you.

2.

View the delivery report for the New Public Folder sent item.

3.

In Office Outlook, approve the message for the Executives group.

4.

In Outlook Web App, view the delivery report for the New Public Folder sent item, and then verify its
delivery.

Results: After this exercise, you should have created and tested a public folder, a resource mailbox, and a
distribution group.

3-66

Planning and Deploying Mailbox Services

To prepare for the next module

When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the
following steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-CL1. Close the virtual
machine connection windows

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then in the Actions pane, click Start.

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then in the
Actions pane, click Connect.
Important: Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully
started before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10233B-VAN-EX1. Connect to the virtual machine.

8.

Wait for 10233B-VAN-EX1 to start, and then start 10233B-VAN-EX2. Connect to the virtual machine.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3-67

Module Review and Takeaways

Review Questions
1.

Why might you choose to use SATA drives instead of a SAN or SCSI drives for your Mailbox servers?

2.

When deciding between editions of Exchange Server, you need to consider the number of databases
you require. How many databases does the Standard edition of Exchange Server 2010 support?

3.

Which administrative tool should be used by a user that has been configured as a group manager?

4.

Which clients require the presence of public folders?

Best Practices Related to Designing Mailboxes

Supplement or modify the following best practices for your own work situations:

Use Cached Exchange Mode to increase client performance over slow connections.

Do not use Cached Exchange Mode to increase Mailbox server performance. In Exchange Server 2010,
the use of Cached Exchange Mode by clients does not affect Mailbox server performance.

Use personal archives to reduce the size of the cached mailbox when using Cached Exchange Mode.

Use personal archives instead of PST files.

Use quotas to enforce size limits on mailboxes.

3-68

Planning and Deploying Mailbox Services

4-1

Module 4
Planning and Deploying Client Access Services in Microsoft
Exchange Server 2010
Contents
Lesson 1: Overview of the Client Access Server Role

4-3

Lesson 2: Designing Client Access Server Deployment

4-14

Lesson 3: Designing Client Access

4-34

Lesson 4: Designing Client Access Policies

4-48

Lab: Planning and Deploying Client Access Services in

Exchange Server 2010

4-57

4-2 Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Module Overview

Microsoft Exchange Server 2010 provides access to user mailboxes for most types of messaging clients
that can connect from almost anywhere. The messaging clients access the Exchange Server mailboxes
through the Client Access server role. Because of the importance of this server role, you must understand
how it works, and how to design the Client Access server deployment. This module describes how to
design the Client Access server role deployment in Exchange Server 2010.
After completing this module, you will be able to:

Describe how the Client Access server role works.

Design the Client Access server deployment.

Design access for messaging clients.

Design policies for managing client access.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-3

Lesson 1

Overview of the Client Access Server Role

1
The Client Access server role provides access to Exchange Server 2010 mailboxes for all messaging clients.
Because all users connect to Client Access servers, you need to ensure that you design and deploy these
servers correctly. To do this, you must understand the services provided by the Client Access server role,
and how this role interacts with other Exchange Server 2010 server roles. This lesson provides a summary
of how the Client Access server role works in an Exchange Server 2010 deployment.
After completing this lesson, you will be able to:

Describe the client access business requirements that might impact your Client Access server design.

Describe the services provided by the Client Access server role.

Describe how the remote procedure call (RPC) Client Access service works.

Describe how client access works with multiple sites.

Describe the requirements for accessing Client Access servers from the Internet.

4-4 Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Client Access Business Requirements

The Client Access servers design can have a significant impact on how satisfied users are with the
messaging system. All clientsincluding Messaging Application Programming Interface (MAPI) clients
such as Microsoft Office Outlook 2010connect to a Client Access server to access a mailbox on an
Exchange Server 2010 Mailbox server. Office Outlook 2010 or newer clients also connect to Client Access
servers to download offline address books (OABs), to access the Availability services, and to use the
Autodiscover feature. This means that substandard Client Access server performance directly affects users.

Information Required to Design Client Access Servers

When designing the Client Access server configuration, you will need to collect the following data:

Total number and type of client connections. The total number of clients affects the Client Access
server design. Although the Client Access server can handle thousands of client connections
simultaneously, the number of connections is still an important consideration when you are planning
the server hardware and the number of servers to deploy. Additionally, the types of clients you deploy
are important, because each client access type may have unique requirements.

Client usage profiles. Along with the total number of clients, you also need to consider how the
clients use the messaging system. This information should include a typical client profile that lists the
number of messages read and sent, and the average size of messages and attachments.

Client locations. Consider the client locations when designing the Client Access server deployment.
Collect information that includes whether all clients are located on an internal network only, whether
clients are also connecting from the Internet, and whether clients will be connecting from branch
offices.

Security requirements. All organizations should be using a Secure Sockets Layer (SSL) to secure client
connections to the Client Access servers. SSL encryption and decryption requires additional resources
on the Client Access server, so you may need to increase the server hardware resources if most clients
are connecting using Outlook Anywhere or Outlook Web App.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-5

Availability requirements. In addition to planning the Client Access server deployment from a capacity
perspective, also consider the availability requirements for the organization. If your organization
requires that all services continue to be available during a single-server failure, then you need to
deploy at least two Client Access servers in a Client Access server array.

Performance requirements. Performance requirements may be harder to define objectively than some
of the other requirements, but most users will have minimum levels of performance expectations
when they access their mailboxes. Understanding the performance expectations will help you to
design an appropriately sized Client Access server deployment.

4-6 Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Client Access Server Services

The Client Access server role in Exchange Server 2010 provides support for multiple types of messaging
clients, and provides several additional services for these clients. As you design your Client Access server
deployment, consider these clients and services.

Client Access Server Clients

Exchange Server 2010 supports the clients listed in the following table.
Client

Description

Office Outlook (MAPI)

Office Outlook 2003 SP1 and newer clients can connect to Exchange Server
2010 mailboxes through the Client Access server role. MAPI clients require
RPC connectivity to the Client Access server.

Outlook Anywhere

Outlook Anywhere enables Office Outlook 2003 or newer clients to access

user mailboxes by using RPCs encapsulated in a Hypertext Transfer Protocol
(HTTP) or Hypertext Transfer Protocol/Secure (HTTPS) packet. This enables
secure access to user mailboxes from clients located on the Internet.

Outlook Web App

Outlook Web App in Exchange Server 2010 lets you access your email from
any web browser. Exchange Server 2010 provides a complete set of features
for the following browsers on a computer running Windows XP, Windows
Server 2003, Windows Vista, or Linux:
Windows Internet Explorer 7 and later versions.
Firefox 3.0.1 and later versions.
Chrome and later versions.
On a computer running Max OS X, you can use:
Safari 3.1 and later versions.
Firefox 3.0.1 and later versions.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-7

(continued)
Client

Description

Microsoft Exchange
ActiveSync

Exchange ActiveSync lets you synchronize data between your mobile phone
and Exchange Server 2010. You can synchronize email, Contacts, Calendar
information, and Tasks. Devices that run Windows Mobileincluding
Windows Mobile 5.0 and Windows Mobile 6 or newerare all supported.
Devices running Windows Mobile 6.1 or newer support Autodiscover.
Exchange ActiveSync is licensed to other mobile device manufacturers, and is
available on a large variety of mobile devices.

POP3 and IMAP4

Besides supporting MAPI and HTTP clients, Exchange Server 2010 supports
Post Office Protocol version 3 (POP3) and Internet message access protocol
version 4 (IMAP4) clients. By default, POP3 and IMAP4 install at the same time
you install the Client Access server role. However, the services needed to
support POP3 and IMAP4 require a manual start. To use POP3 and IMAP4,
you must first start the POP3 and IMAP4 services.

Entourage 2008, Web

Services Edition

Entourage 2008, Web Services Edition, uses Exchange Web Services instead of
Web Distributed Authoring and Versioning (WebDAV) to provide access to
the user mailboxes, which provides support for Autodiscover. You can use
Autodiscover to automatically configure the client profile.
Note: Office Outlook 2011 for Mac also uses EWS to connect to
Exchange Server.

Note Previous versions of Entourage used WebDAV to connect to the Exchange

mailboxes. WebDAV is not available in Exchange 2010, so you must use the Web Services
edition of Entourage to connect to Exchange 2010 mailboxes.

Client Access Server Services

In Exchange Server 2010, the Client Access server role provides critical services for all messaging clients.
The following table lists the services provided.
Service

Description

RPC Client Access

Service

Enables MAPI clients such as Office Outlook 2010 to connect to user

mailboxes. The client connects to the Client Access server using a MAPI
connection.

Autodiscover

The Autodiscover service configures client computers that are running Office
Outlook 2007 or newer, or supported mobile devices. The Autodiscover
process configures the Office Outlook client profile, including the Mailbox
server, Availability service, and OAB download locations.

Availability

The Availability service makes free/busy information available for Office

Outlook 2007 and Outlook 2010 and Outlook Web App clients. The
Availability service retrieves free/busy information from Mailbox servers or
Public folders, and presents the information to the clients.

Address Book

The Client Access server makes OABs available through a web service. Only
Office Outlook 2007 or later clients are capable of retrieving OABs from a web
service.

4-8 Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

(continued)
Service

Description

Exchange Web
Services

Exchange Web Services enables client applications to communicate with the

Exchange server. You can also access Exchange Web Services
programmatically, and it provides access to much of the same data that is
available through Office Outlook. Exchange Web Services clients can integrate
Office Outlook data into lineofbusiness (LOB) applications.

MailTips

The MailTips feature provides notifications for users regarding potential issues
with sending messages, before they send the messages.

Exchange Control
Panel

The Exchange Control Panel is a webbased management interface that

enables selfservice for mailbox users, and enables users to perform specific
management tasks without having access to the entire Exchange
Management interface.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-9

How RPC Client Access Service Works

The introduction of the RPC Client Access service is one of the most significant architectural changes in
Exchange Server 2010. In previous Exchange Server versions, Office Outlook configured as a MAPI client
always connected to the Mailbox server directly, rather than connecting to a front-end or Client Access
server. In Exchange Server 2010, all clients connect to the Client Access server role, regardless of the client
protocol used.

How RPC Client Access Services Work

The architectural changes modify client communication with the Mailbox server in the following ways:

When a MAPI client starts, it connects to a Client Access server. The client protocol has not changed,
and it is still backwards-compatible with older Office Outlook versions.

When the client connects to the Client Access server, the Client Access server uses a MAPI RPC
connection to communicate with the Mailbox server.

When a client such as Office Outlook 2010 or Outlook Web App requests the global address list
(GAL), the Client Access server role provides a Name Service Provider Interface (NSPI) service, and it
queries the GAL on behalf of the client. This means that all client connections for address book
lookups are now sent to the Client Access server rather than a global catalog server.

RPC Client Access Service Benefits

RPC Client Access services provide a number of benefits:

All clients now use the same mailbox access architecture.

Organizations that deploy highly available Mailbox servers experience fewer client outages due to
mailbox databases that fail over to other servers. When a mailbox fails over to another server,
Exchange Server notifies the Client Access server, and redirects the client connections to a new server
within seconds. In a failover scenario, Exchange Server 2007 clients are disconnected for between 1
and 15 minutes. In Exchange Server 2010, if one Client Access server in a Client Access server array

4-10

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

fails, the client immediately reconnects to another Client Access server in the array. If a Mailbox server
fails, the client disconnects for 30 seconds.

You can move mailboxes from one Mailbox server to another, even while the user is online and
connected to the mailbox.

The new architecture supports more concurrent client connections to the Mailbox server. In Exchange
Server 2007, each Mailbox server handles up to 64,000 connections. In Exchange Server 2010, that
number increases to 250,000 connections.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-11

How Client Access Service Works with Multiple Sites

In Exchange Server 2010, all messaging clients connect to a Client Access server when they access their
Exchange Server mailboxes. You must deploy a Client Access server in the same site as the Mailbox server
so users can access their mailboxes.

How Clients Access Mailboxes in a Single Site

The following steps describe what happens when a messaging client connects to the Client Access server:
1.

If the client connects from the Internet using a non-MAPI connection, then the client connects to the
Client Access server using the client protocol. Only the client connection protocol ports must be
available on the external firewall.

2.

If the client connects from the internal network using Office Outlook configured as a MAPI client,
then the client connects to the Client Access server using MAPI RPC connections.

3.

The Client Access server connects to an Active Directory Domain Services (AD DS) domain controller
using Kerberos to authenticate the user. Internet Information Services (IIS) or the RPC Client Access
service on the Client Access server performs the authentication. The Client Access server also provides
a directory lookup service for all clients. When the client requests the GAL, or searches the GAL for a
specific recipient, the Client Access server performs the AD DS lookup for the client.

4.

The Client Access server connects to the Mailbox server using a MAPI RPC to submit messages to the
mailbox database, or to read messages.

How Client Access Works with Multiple AD DS Sites

Deploying Client Access servers in an environment with multiple AD DS sites adds complexity to
deployment planning, particularly when you consider the options for providing Internet access to those
Client Access servers.

4-12

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

How Client Access Works with Multiple Internet Access Points

If you have multiple AD DS sites, you can provide Internet access to each sites Client Access servers. When
an Internet client connects to the Client Access server from the Internet, the Client Access server
authenticates the user, and then queries a global catalog server for the user mailbox location. At this
point, the Client Access server has two options:

If the users mailbox is located in the same site as the Client Access server, then the Client Access
server connects to the Mailbox server to fulfill the client request.

If the users mailbox is located in a different site from the Client Access server, the Client Access server
contacts a domain controller to locate the Client Access server in the site where the user mailbox is
located. If the Client Access server uses an external URL, then the Client Access server redirects the
client request to the Client Access server in the site that contains the user mailbox by presenting the
user with a page that provides the correct URL for the Client Access server, so the user can connect to
the appropriate Client Access server within the home site.
Note With Exchange Server 2010 SP2, you can configure cross-site silent redirection to
enable this redirection process to happen without presenting the user with a webpage
containing the correct URL. When you enable this feature, a user with a mailbox in AD DS
site A who accesses the Outlook Web App URL in AD DS site B will be silently redirected to
the Outlook Web App URL for AD DS site A. To enable cross-site silent redirection, you must
use the new CrossSiteRedirectType parameter from the Set-OWAVirtualDirectory
cmdlet. The parameter has two possible settings, Silent and Manual. The default setting is
Manual.
If you do not configure an external URL for the Client Access server in the site that contains the user
mailbox, then the Client Access server receiving the request proxies the client request to the Client
Access server in the appropriate site.
Note Exchange Server 2010 can redirect only Outlook Web App and Outlook Anywhere
clients to another Client Access server in a different site. All other Client Access server client
requests are proxied to a Client Access server in the same site as the user mailbox. To
optimize access for non-Outlook Web App clients, you must configure the clients to
connect directly to a Client Access server in the users home site.

How Client Access Works with a Single Internet Access Point

The Client Access server in the site containing the user mailbox might not be accessible from the Internet,
or it might not have an external URL. In this case, when the user connects to a Client Access server in a site
that does not contain the user mailbox, the Client Access server proxies the client request to the Client
Access server in the site where the users mailbox is located. This proxy process uses the same protocol as
the client. In the destination site, the Client Access server then uses RPC to connect to the Mailbox server
managing the user mailbox.
For the Client Access server to proxy the client request, you must configure the Client Access servers that
are not accessible from the Internet to use Integrated Windows authentication. Exchange Server supports
proxying for clients that use Outlook Web App, Outlook Anywhere, Exchange ActiveSync, and Exchange
Web Services.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-13

Requirements for Accessing the Client Access Server from the Internet

To enable access to the Client Access server from the Internet, complete the following steps:
1.

Enable access from the Internet to the Client Access servers using the client access protocols. To
connect to the Client Access server, clients must be able to access the server using HTTPS, POP3 or
IMAP4. Configure the Internet firewalls or reverse proxy to enable this access.

2.

Configure the external URLs for each of the required client options. You can configure all of the Client
Access server web server-based features with an external URL. By default, the external URL is blank.

3.

Configure an external Domain Name System (DNS) name resolution. For each Client Access server
that you expose to the Internet, verify that the servers host name can be resolved on the Internet. To
do this, add a host record for the Client Access server to the DNS zone on the DNS server that is
hosting the Internet DNS zone for your organization. If you are using different host names for each
Client Access server, then configure a host record for each host. If you are using the same domain
name internally and externally, then configure the host records on both the internal and external DNS
servers.

4.

Implement SSL certificates with multiple subject alternative names. If you are using multiple host
names for the Client Access services, or if you are publishing Autodiscover to the Internet, then ensure
that the SSL certificates that you deploy on each Client Access server have the required server names
listed in the subject alternative name extension.

5.

Configure Autodiscover for the Outlook Anywhere and Exchange ActiveSync clients. To enable access
to Autodiscover, you must enable access through the firewall to the Autodiscover virtual directory on
the Client Access server. Additionally, you must configure an external URL on the virtual directory,
and configure the required DNS records for clients to locate the Autodiscover service from the
Internet.
Note You have numerous design decisions to make when configuring Internet access to
the Client Access servers. Later lessons in this module address these design decisions in
depth.

4-14

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Lesson 2

Designing Client Access Server Deployment

The first step in designing client access to Exchange Server mailboxes is designing the Client Access server
deployment and configuration. You must consider several factors when designing deployment, including
the hardware configuration, and how you will provide access to the services enabled on the Client Access
server. This lesson describes how to design Client Access server deployment.
After completing this lesson, you will be able to:

Design the hardware requirements for the Client Access server.

Design Client Access server security.

Design SSL certificates for Client Access servers.

Design the Autodiscover configuration.

Design the configuration for the Availability service.

Design the MailTips deployment.

Design client throttling.

Design Client Access server deployments for organizations with multiple namespaces.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-15

Designing Client Access Server Hardware Requirements

The Client Access server in Exchange Server 2010 provides significantly more services than the front-end
server provides in Exchange Server 2003, or that the Client Access server provides in Exchange Server
2007. In particular, the RPC Client Access service requires significantly more resources on the Client Access
server than was required in previous versions of Exchange Server.

Designing Hardware Configurations for Client Access Servers

Consider the following guidelines when designing the Client Access server configuration:

There is currently no specific recommended processor configuration for Client Access servers.
However, we recommend that you use a minimum of 2 processor cores, and a maximum of 12
processor cores.

The recommended memory configuration is dependent on the number of client connections and the
transaction rate for a Client Access server. The recommended random access memory (RAM) for
Client Access servers is 2 gigabytes (GB) of RAM per processor core, with a minimum of 8 GB of RAM.

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 input/output (I/O).
Activity
Protocol logging

Descriptions and recommendations

Protocol logging is a sequential write process that, if enabled, causes a
performance issue and requires disk space to store the log files. On a server
that handles a large number of messages, consider moving these log files to a
dedicated disk.

4-16

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

(continued)
Activity

Descriptions and recommendations

Content
conversion

Content conversion for all Exchange Server 2010 protocols occurs on the
Client 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 Multipurpose Internet Mail Extensions (MIMEs)
before sending it to the client. This conversion occurs on the Client Access
server, and if the message is larger than 64 kilobyte (KB), 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 Client Access server requires a fast network connection to Mailbox servers and global catalog
servers. If you have a large number of internal MAPI clients, the network connection may become a
bottleneck. To reduce the network bottleneck, configure the Client Access server with multiple 1
gigabits per second (Gbps) network cards.

As a general guideline, you should deploy three Client Access server processor cores in an AD DS site
for every four Mailbox server processor cores. This is a significant change from previous Exchange
Server versions, primarily due to the increased processor load required for the RPC Client Access
service.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-17

Client Access Server Security

In many organizations, the Client Access server is accessible from the Internet for Outlook Anywhere,
Outlook Web App, and Exchange ActiveSync clients. Therefore, always ensure that the Client Access server
that faces the Internet is as secure as possible.
Important In previous Exchange Server versions, we recommended that you run the
Security Configuration Wizard (SCW) to disable services and configure the Windows Firewall
settings on Client Access servers. To enable this option, you needed to register Exchange
Server-specific SCW configuration files before running the SCW. Exchange Server 2010,
however, is designed to be secure by default, and during installation, only configures
required services and firewall settings. Exchange Server 2010 does not provide the SCW
configuration files. Running the SCW on an Exchange 2010 server is not recommended.

Securing Communications Between Clients and Client Access Servers

To encrypt the network traffic between messaging clients and the Client Access server, you must secure
the network traffic using SSL. To configure the Client Access server to use SSL, complete the following
steps:
1.

Obtain and install a server certificate on the Client Access server. Ensure that the certificate name
matches exactly the server name that users will use to access the Client Access server. Additionally,
ensure that all the client computers and mobile devices that will access the server trust the certificate
issued by a certification authority (CA).

2.

Configure the Client Access server virtual directories in IIS to require SSL. Secure the following virtual
directories:

Autodiscover

ecp

EWS

4-18

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Microsoft-Server-ActiveSync

OAB

owa

RPC

RPCWithCert

Configuring Secure Authentication

Exchange Server 2010 provides several authentication options for clients communicating with the Client
Access server. If the server has multiple authentication options enabled, then it negotiates with the client
to determine the most secure authentication method that the options support.

Standard Authentication Options

The following standard authentication options are available on the Client Access server:

Integrated Windows authentication. Integrated Windows authentication is the most secure standard
authentication option. When users log on with a domain account, they are not prompted for a user
name or password. Instead, the server negotiates with the Windows security packages installed on the
client computer to obtain the user name and password of the logged-on user. Unencrypted
authentication information is not transferred across the network.
Important When using a single Internet-accessible Client Access server for all sites, you
must enable Integrated Windows authentication on all of the Client Access servers that are
not Internet accessible. For example, the outward-facing Outlook Web App server can use
forms-based authentication, but the internal Client Access servers must be configured to
allow Integrated Windows authentication. This is changed from Exchange Server 2007.

Digest authentication. Digest authentication secures the password by transmitting it as a hash value
over the network. To use Digest authentication, users must have an account stored in AD DS.

Basic authentication. Basic authentication transmits passwords in clear text over the network.
Therefore, you should always secure basic authentication with SSL encryption. Basic authentication is
the authentication option that is most widely supported by clients. Single sign-on is not supported, so
workstation credentials are never automatically passed over basic authentication.

Forms-Based Authentication
Forms-based authentication is available only for Outlook Web App and Exchange Control Panel, and
when you use this option, it replaces the other authentication methods. This is the preferred
authentication option for Outlook Web App, because it provides enhanced security. With forms-based
authentication, Exchange Server uses cookies to encrypt the user logon credentials in the client
computer's web browser. Tracking the use of this cookie allows Exchange Server to time-out inactive
sessions.
The amount of time required before an inactive session times out varies depending on the computer type
selected during logon. If you choose a public or shared computer, the session times out after 15 minutes
of inactivity. If you choose a private computer, the session times out after 12 hours of inactivity.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-19

Note You can configure the time-out values for public and private computers by
modifying the Client Access server registry. Use the Regedit utility, or the Set-ItemProperty
cmdlet. For more information about how to configure these settings, see the "Set the
Forms-Based Authentication Private Computer Cookie Time-Out Value" topic in Exchange
Server 2010 Help.
Forms-based authentication is enabled by default for Outlook Web App and Exchange Control Panel.
Note In Exchange Server 2010 SP2, if you have enabled cross-site silent redirection, and if
the authentication method for the Outlook Web App virtual directory on both the initial
and redirected Client Access servers is set to forms-based authentication, the user must
enter their credentials only once. However, if the authentication methods differ, the users
may be required to enter their credentials a second time.

Protecting the Client Access Server with an Application Layer Firewall

To provide an additional layer of security for network traffic and to protect the Client Access server,
deploy an application layer firewall or reverse proxysuch as Microsoft Forefront Threat Management
Gateway or Forefront Unified Access Gatewaybetween the Internet and the Client Access server.
Application layer firewalls provide the following benefits:

You can configure the firewall as the endpoint for the client SSL connection. The firewall can decrypt
the client traffic, apply application layer filtering, and then re-encrypt the traffic before sending it to
the Client Access server.

You can offload SSL decryption to the firewall. If you do not require all connections on your internal
network to be secure, you can configure the firewall to decrypt the SSL traffic, but not re-encrypt it
before sending the traffic to the Client Access server. This means that Client Access server resources
are not used to perform SSL decryption and encryption.

If you use Forefront Threat Management Gateway or Forefront Unified Access Gateway as the
application layer firewall, you can configure the firewall to pre-authenticate all client connections
using forms-based authentication. This means that only authenticated connections are allowed into
the internal network.
Note If you are using certificate-based authentication for Exchange ActiveSync, you must
configure a server-publishing rule that forwards the client traffic to the Exchange Server
computer without decrypting the packets on the Microsoft Internet Security and
Acceleration (ISA) Server.

4-20

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Designing Client Access Server Certificates

Because of the importance of using SSL secure network traffic between Client Access servers and
messaging clients, you must ensure that you deploy the appropriate certificates on the Client Access
servers. You can secure all client connections to the Client Access server using SSL.
Note By default, the Client Access server is configured with a self-signed certificate that is
not trusted by clients. You should remove this certificate and install a certificate from a
trusted CA. Exchange Server 2010 provides a certificate wizard that enables you to install
and manage certificates without having to use the Exchange Management Shell, as was the
case in Exchange Server 2007.

Choosing a Certification Authority

One of the most important considerations when planning to use certificates is identifying the certificate
source. Exchange Server 2010 supports self-signed certificates, certificates issued by a public CA, and
certificates issued by a private CA. Each certificate type has advantages and disadvantages, which are
identified in the following table.
Certificate
type
Public CA

Explanation
Advantages:
Client computers already trust the root CA, so you can chain certificates to the
root without further configuration.
The public CA provides full certificate and certificate revocation management
services.
Disadvantage:
The certificates issued by public CAs are more expensive than self-signed
certificates, or certificates issued by internal CAs.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-21

(continued)
Certificate
type

Explanation

Internal CA

Advantages:
Revocation is managed internally, so you can centrally revoke certificates if a
private key is compromised.
By managing your own CA, you have more flexibility in how you manage
certificate distribution.
Disadvantages:
Implementing an internal CA can be complicated, and the complexity may cause
security problems if incorrectly managed.
While the certificates issued by internal CAs are free, the cost of implementing
and managing a CA implementation can be higher than buying certificates from
a public CA.
Client computers that are not members of an internal AD DS domain do not
automatically trust the root CA, so you must add certificates for the trusted rootto-client machines, where necessary.

Self-signed
certificates

Advantage:
You can deploy self-signed certificates without a Public Key Infrastructure (PKI).
When you install Exchange Server 2010, it automatically creates a self-signed
certificate for each computer.
Disadvantages:
No centralized revocation lists. If the certificates private key is compromised,
each associated party must be notified manually to change to a new certificate
and stop relying on the existing one.
Client computers do not automatically trust the self-signed certificate, so you
must add certificates for the trusted root-to-client machines where necessary.

You can use self-signed certificates for internal communication, such as for securing Simple Mail Transfer
Protocol (SMTP) connections between Hub Transport servers. You also can use them to secure client
connections to Client Access servers, but because none of the client computers trust these certificates, we
do not recommend this solution. Rather, you should consider obtaining a certificate from a public CA or
internal CA for all Client Access servers.
In most cases, you should deploy a certificate issued by a public CA if users access the Client Access server
from the Internet, to ensure that the clients trust the certificate, and that they have access to certificate
revocation lists from any location.
If only computers that are members of the internal domain access the Client Access server, consider using
an internal, or private CA. By deploying an enterprise CA, you can automate the process of distributing
and managing certificates and certificate revocation lists.

Federation Certificates
The Microsoft Federation Gateway is a free cloud-based service offered by Microsoft and acts as a trust
broker between your on-premises Exchange Server 2010 organization and other federated Exchange 2010
organizations.
If you want to configure federation in your Exchange organization, you must establish a one-time
federation trust with the Microsoft Federation Gateway, so that it can become a federation partner with
your organization.

4-22

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

With this trust in place, users authenticated by AD DS are issued Security Assertion Markup Language
(SAML) delegation tokens by the Microsoft Federation Gateway. These tokens enable users from one
federated organization to be trusted by another federated organization.
If you intend to implement a federation trust with the Microsoft Federation Gateway, with Exchange
Server 2010 SP1, you automatically use a self-signed certificate to create this trust. The self-signed
certificate for this purpose is created automatically and installed on Exchange servers in your organization
when you use the New Federation Trust wizard in the Exchange Management Console.

Identifying the Required Client Protocols

While planning the certificate deployment, determine the client protocols that are used to connect to the
Client Access server, and ensure that your certificate is configured for each certificate type.

Planning the Certificate Names

To prevent error messages during client connection to the Client Access server using SSL, the names on
the certificate must match the names that the clients use to connect to the server. For example, suppose
your users connect to the Outlook Web App site with https://mail.contoso.com, and they connect to the
IMAP4 server with IMAP.contoso.com. In this case, the certificates you use must support both
mail.contoso.com and IMAP.contoso.com. Additionally, if you enable Autodiscover access from the
Internet, your certificate also must support a name such as Autodiscover.contoso.com.Use the following
options to implement this configuration:

Obtain a separate certificate for each client protocol that requires a unique name. This may require
multiple certificates for all Client Access servers. This may also require multiple websites in IIS. This is
the most complicated option to configure.

Configure all clients to use the same server name. For example, you could configure all clients to use
the server name mail.contoso.com, and obtain a certificate for just that one name.

Obtain a certificate with multiple subject alternative names. Most public CAs support multiple names
in the certificates subject alternative name extension. When you use one of these certificates, clients
can connect to the Client Access server using any of the names listed in the subject alternative name.

Use a certificate with a wildcard name. Most public CAs also support the use of wildcards in the
certificate request. For example, you could request a certificate using the subject of *.contoso.com,
and use that certificate for client connections.
Note Not all clients support wildcard certificates. Office Outlook, Internet Explorer, and
Windows Mobile 6 or newer clients support wildcard certificates, but you need to verify this
functionality for all messaging clients that are used in your organization before deploying
these certificates. Deploying wildcard certificates is also considered a security risk in many
organizations, because the certificate applies to any server name in the domain. If this
certificate is compromised, all host names for the organization are also compromised.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-23

Designing Autodiscover

The Autodiscover service in Exchange Server 2010 simplifies configuration of Office Outlook 2007 or
newer clients and Windows Mobile. Autodiscover provides configuration information that Office Outlook
requires to create a profile for the client. Office Outlook clients use the Autodiscover service to repair
Exchange Server connection settings for corrupted profiles, and for user mailboxes that are moved to
different servers. The Autodiscover service uses email addresses and passwords to provide profile settings
to Office Outlook 2007 or newer clients, and supported mobile devices.
When creating a profile, Autodiscover provides information so that the client can locate various web
services, such as the Availability service, Unified Messaging settings, and OABs.

Consider Modifying the Internal URL

By default, the Autodiscover URL matches the server name where you installed the Client Access server
rolefor example, https://cas1.adatum.com/autodiscover/autodiscover.xml.
The Client Access server deployment process registers this name in AD DS by creating a server connection
point that matches the fully qualified domain name (FQDN) of the server with the installed Client Access
server role. Domain-joined computers use this server connection point to locate the Autodiscover service.
Each deployed Client Access server in an organization has its own Autodiscover server connection point
record. The domain-joined Office Outlook 2010 client authenticates to the AD DS site, and searches for
the Autodiscover server connection point objects.
The Office Outlook client obtains and enumerates the Autodiscover service instances, and then connects
to the first Client Access server in the list, obtaining the required profile informationin the form of XML
datathat is needed to connect to the user's mailbox.

4-24

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

When you start Office Outlook 2010 on a client that is not connected to the domain, it tries to locate the
Autodiscover service by using DNS. Office Outlook determines the email address suffix of the userfor
example, adatum.comand checks DNS for two predefined URLs. For example, if your SMTP domain is
adatum.com, Office Outlook attempts to connect to the Autodiscover service with the following two URLs:

https://adatum.com/autodiscover/autodiscover.xml

https://autodiscover.adatum.com/autodiscover/autodiscover.xml

Because the behavior for internal and external clients differs, you may decide that you want to use a
single URL for both your internal and external clients.
To modify the internal Autodiscover URL, use the Exchange Management Shell. Type the following
command, and then press Enter:
Set-ClientAccessServer -Identity ServerName -AutodiscoverServiceInternalURI
https://mail.adatum.com/autodiscover/autodiscover.xml

Consider Site Affinity

If your organization has a large distributed wide area network (WAN) supporting AD DS sites that are
connected by slow network links, consider configuring site affinity for the Autodiscover service.
When you configure site affinity on the Client Access server, you enable clients using Office Outlook 2010
and Office Outlook 2010 to retrieve Autodiscover information from the closest AD DS site. This provides
Autodiscover information to the Office Outlook clients more quickly than if site affinity was not set.
To use site affinity, specify which AD DS sites the clients prefer to use to connect to particular
Autodiscover service instances.
To configure site affinity, use a cmdlet similar to the following example:
Set-ClientAccessServer -Identity "ServerName"
-AutodiscoverServiceInternalURI "https://VAN-EX1/autodiscover/autodiscover.xml"
AutodiscoverSiteScope "HeadOffice"

This cmdlet configures the Autodiscover service URL in the HeadOffice site to use the VAN-EX1 server.

Configure DNS
You must configure DNS with the correct information so that external clients can locate the appropriate
Client Access servers. When the Office Outlook client attempts to locate the Client Access server, it first
tries to locate the server connection point information in AD DS. If the client is outside the network, AD
DS is not available, so the client queries DNS for a server name based on the SMTP address that the user
provides. Office Outlook queries DNS for the following URLs:

https://autodiscover.<emaildomain>/autodiscover/autodiscover.xml

https://<emaildomain>/autodiscover/autodiscover.xml

To enable Autodiscover functionality for external clients, you must configure a DNS record on the DNS
server that the client uses to provide name resolution for that request. The DNS record should point to a
Client Access server that is accessible from the Internet.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-25

Configure External Host Names

To initiate communications with the Exchange Server messaging system, Office Outlook 2010 requests
certain information from the Autodiscover serviceincluding connection settings and URLs for the
required Exchange services. Exchange Server creates and stores these settings and URLs in AD DS during
setup, and updates them when you configure Exchange Server by using the Exchange Management Shell
or the Exchange Management Console.
Configure the necessary URLs for the Exchange services that you want to provide to external clients. These
services are:

Outlook Anywhere

Offline address book

Unified Messaging

Exchange Web Services

If you do not configure the external URL values, the Autodiscover service information that is provided to
the Office Outlook 2010 client may be incorrect for clients that are connecting from outside your network.
Note Users may be able to connect to their Exchange Server mailboxes; however, they will
be unable to use Exchange Server features such as Out of Office functionality, the
Availability service, Unified Messaging, and OAB downloads.
Additionally, certificates used to provide security when accessing these services must be correctly
configured with the appropriate hostnames. If multiple URLs are required, the certificate must support
multiple names.

Ensure Autodiscover Virtual Directory Is Accessible

After deploying and configuring Autodiscover, you must test the service. You can use the Test Email
AutoConfiguration feature in Office Outlook 2010 to test whether or not Autodiscover is working
correctly. To use this feature, complete the following steps:
1.

Open Office Outlook 2010 using a profile that can connect to a Mailbox server.

2.

Press and hold the Ctrl key, click the Office Outlook icon in the notification area of the Windows task
bar, and then click Test E-mail AutoConfiguration.

3.

Enter your email address and password in the respective text boxes.

4.

Clear the Use Guessmart and Secure Guessmart Authentication check boxes. Guessmart automates
the process of configuring Outlook 2010 as an IMAP4 or POP3 client.

5.

Click AutoConfigure, and then click the Log tab to view detailed information on how the client
attempts to complete the autoconfiguration.

4-26

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Designing the Availability Service

The Availability service enables Outlook Web App and MAPI clients to access free/busy information. These
clients use Autodiscover to obtain the URL for the Availability service. By default, the Availability service
uses the URL http://servername/EWS.
By default, the Availability service deploys on all Client Access servers, and you do not usually need to
configure it except in scenarios in which you are integrating the free/busy information from multiple
forests.

Design Considerations for the Availability Service

Consider the following when designing the Availability service:

Legacy clients. Office Outlook 2003 and earlier clients do not use the Availability service for accessing
free/busy information. These clients must use system public folders to determine availability.
Exchange Server 2003 uses a public folder called SCHEDULE+FREE BUSY to disseminate availability
information. If you have only Office Outlook 2007 or newer clients, then you do not need to use this
public folder-based mechanism for sharing and determining availability information.

Cross-forest configurations. In Exchange Server 2003, sharing availability information between forests
is complex, and requires directory synchronization and additional tools such as the Inter-organization
Replication (IORepl) tool. Exchange Server 2010 supports cross-forest availability features without
these requirements.
You can select the granularity of free/busy information between forests when you configure crossforest availability. Choose between per-user and organization-wide granularity.
Per-user free/busy information is only supported in a trusted cross-forest topology. It enables the
Availability service to make cross-forest requests on behalf of a particular user, and it also enables
users in a remote forest to grant detailed free/busy information to other cross-forest users.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-27

With organization-wide free/busy data, the Availability service makes cross-forest requests only on
behalf of particular organizations. It returns users default free/busy information, and you cannot
control the level of free/busy information that it returns to users in other forests.
To ensure proper cross-forest availability, you must:

Synchronize the GAL between forests. You can use the GAL Synchronization (GALSync) tool for
this requirement.

Ensure that the Autodiscover service is working between forests. In cross-forest scenarios, the
Autodiscover service provides information to the Availability service by locating and providing
the external and internal URLs for the Office Outlook client and the Client Access server, for
cross-forest availability. Consequently, Client Access servers must be able to connect to the
Autodiscover service on the target forest to determine the target forests Availability URL.
When configuring your Autodiscover service to support cross-forest availability scenarios, select
from between two options:

If the forests trust each other, then export the server connection point from the target to the
source forest.

Otherwise, use DNS to resolve the autodiscover.targetforest.com website address.

Ensure that all Client Access servers can validate the certificate on the target forest. We recommend
that you use a third-party certificate from an authority that both parties trust.
Note Because the Availability service is the only method for sharing cross-forest
availability information, and because Office Outlook 2003 clients do not use the Availability
service, legacy clients cannot access free/busy information from a remote forest unless you
replicate the content of the SCHEDULE+FREE BUSY public folder between forests. Use
IORepl to synchronize free/busy data across multiple forests.

4-28

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Designing MailTips

MailTips inform users about issues or limitations with their outgoing messages. Exchange Server 2010
analyzes the messagesincluding the list of recipients to which they are addressedand if it detects
potential problems, notifies users with MailTips. Senders can use the MailTips feedback to adjust their
message, and thus avoid undesirable situations or non-delivery reports (NDRs).

How MailTips Work

MailTips is a web service provided by Exchange Server 2010. When a sender composes a message, the
client software performs an Exchange Web Services service call to the Exchange Server 2010 server with
the installed Client Access server role. The Exchange Server 2010 server responds with the list of MailTips
that apply to that message, and the client software displays the MailTips to the sender.
The Client Access server uses the following sources to compile MailTips for a specific message:

AD DS

Recipient mailboxes

Local group metrics data

To ensure MailTips is optimized, you should understand how the Client Access server role interacts with
these services.

Group Metrics Data

Group metrics provide the following information:

Number of members

Number of members who are external to your organization

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-29

The Client Access server role uses group metrics data when deciding whether to display the following
MailTips:

Large Audience. Displays when a sender adds a distribution group with a large membership count as
defined by your organization.
Note By default, any message addressed to more than 25 recipients is considered a large
audience.

External Recipients. Displays when a sender adds a distribution group that contains members who are
external to your organization.

Exchange Server evaluates MailTips each time senders add recipients to their messages, but it does not
calculate group metrics data as users compose their messages, because this could have an adverse impact
on performance. Instead, Exchange Server calculates group metrics data as a background process that you
can schedule to run during non-business hours.
Note By default, the Mailbox server that generates the OAB also generates the group
metrics data.
The Microsoft Exchange File Distribution Service distributes group metrics data. The service queries AD DS
for a list of Mailbox servers that are enabled for group metrics generation, and then copies the group
metrics data from the closest Mailbox server every eight hours.

AD DS and the Mailbox Server

When the mail client queries Client Access server, the Client Access server compiles the list of applicable
MailTips and returns all of them so the user can view them at the same time.
The Client Access server uses the following process to compile MailTips for a specific message:
1.

The mail client queries the web service on the Client Access server for MailTips that apply to the
recipients in the message.

2.

The Client Access server gathers MailTips data:

3.

The Client Access server queries AD DS, and reads group metrics data.

The Client Access server queries the Mailbox server to gather the Recipient Out-of-Office and
Mailbox Full MailTips. If the recipient's mailbox is on another site, then the Client Access server
requests MailTips information from the Client Access server in the remote site.

The Client Access server returns MailTips data back to the client.

For best performance, the Client Access server must have high-speed and reliable connectivity to both the
AD DS site and the Mailbox servers.
Note You can enable MailTips over an organization relationship between your Exchange
Server environment and Exchange Online, or another organization. With Exchange Server
2010 SP1, you have granular control over which MailTip types are returned over the
organization relationship in addition to just allowing or preventing returning MailTips.

4-30

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Designing Client Throttling

Client throttling is a technology designed to ensure that users do not overload the Exchange Server
messaging system. It also helps to ensure that users connected to Exchange Server from a variety of
client-types, share system resources equitably.
Exchange Server provides a default client throttling policy that may be sufficient for most organizations.
However, you can create additional client throttling policies or modify the default policy as your
organizational needs dictate.
Client throttling tracks resource consumption on a per-user basis, which enables you to createif
necessarya per-user throttling policy. Additionally, if you are hosting multiple tenants within your
Exchange Server organization, you can configure a per-tenant client throttling policy.
You can configure the following components to adhere to a client throttling policy:

Exchange ActiveSync

Exchange Web Services

IMAP4

POP3

Outlook Web App

Windows PowerShell

For each of these components, you can configure the following client throttling policy parameters:

MaxConcurrency. Indicates how many concurrent connections a user can have against an Exchange
server. If a user tries to make more connections than allowed by the policy, the new connection
attempts fail. Use a value between 0 and 100. To unthrottle this component, specify the value $NULL.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-31

PercentTimeInCAS, PercentTimeInAD, PercentTimeInMailboxRPC. For each of these parameters,

define a percentile value. For example, if you use the value 100, then in each minute, a client can
consume 60 seconds of resource time. To unthrottle these components, specify the value $NULL.
Note PercentTimeInCAS is an overlapping superset of both PercentTimeInAD and
PercentTimeInMailboxRPC. This is because for the Exchange Server component to make an
AD DS or RPC call, it must already be running Client Access server code. Additionally, the
expenditure in processing time for PercentTimeInCAS does not stop while Lightweight
Directory Access Protocol (LDAP) or RPC calls are being made. Consequently, you must set
the PercentTimeInCAS value higher than both the PercentTimeInAD and
PercentTimeInMailboxRPC values for a given component.

PowerShellMaxConcurrency. Defines the maximum number of remote shell sessions that a user can
have open at one time.

PowerShellMaxCmdlets. Defines the maximum number of cmdlets that a user can run over the time
period.

PowerShellMaxCmdletsTimePeriod. Defines the time period, in seconds, that the user can run the
maximum number of cmdlets as defined by the PowerShellMaxCmdlets parameter.

PowerShellMaxCmdletQueueDepth. Defines the number of operations that a user can run at the same
time.
Note The PowerShellMaxCmdletQueueDepth parameter directly affects the behavior of
the PowerShellMaxCmdlets and PowerShellMaxConcurrency parameters. For example, the
PowerShellMaxConcurrency parameter consumes at least two of the operations defined by
the PowerShellMaxCmdletQueueDepth parameter, but additional operations are also
counted against the throttling limit each time you run the cmdlet. The number of
operations that count toward the throttling limit depends on the cmdlets that you run.
Configure the PowerShellMaxCmdletQueueDepth parameter to at least three times larger
than the value of the PowerShellMaxConcurrency parameter.

You can use the performance monitor to examine how throttling governs the overall usage of system
resources.
Note Exchange Server 2010 SP1 introduced a number of client throttling behavioral
changes. For example, in Exchange Server 2010 SP1, all client throttling policies are enabled
by default. For further information about this and other client throttling changes introduced
by Exchange Server 2010 SP1, see the Microsoft TechNet website.

4-32

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Designing Client Access Services with Multiple Namespaces

Before deploying Exchange Server 2010, you must consider how you will implement your external
namespaces. A namespace is a logical structure represented by a DNS domain name, such as adatum.com.
The decisions you make about your DNS namespace impact:

DNS configurations

Digital certificates

Client configurations

Selecting a Namespace Model

Align your namespaces with your site configuration. In particular, consider implementing a separate
namespace for each site that contains an Internet-facing Client Access server. You can configure Exchange
Server 2010 according to one of the following organizational models:

Centralized data center. All servers are located within one physical site with a single namespace, such
as mail.adatum.com. With this model, there are few DNS records to configure, fewer certificates to
manage, and only one URL for client computers. However, this model does not support multiple data
centers.

Single namespace with proxy sites. Only one site contains an Internet-facing Client Access server.
Consequently, this model uses only one namespace. With this model, you must configure fewer DNS
records, manage fewer certificates, and client computers use only one external URL. However,
because there are potentially many sites that do not contain an Internet-facing Client Access server,
many users will access their mailboxes using a proxy.

Single namespace and multiple sites. Each site may have an Internet-facing Client Access server, or
there may be only one site that contains Internet-facing Client Access servers. In this model, the sites
use one namespace. Again, because there is a single namespace, DNS and certificates are easier to
manage, and client computers use a single external URL. However, this model also suffers from the
same disadvantages as those of the single namespace with proxy sites.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-33

Regional namespaces. This model consists of multiple physical sites and multiple namespaces. For
example, a site located in Seattle might have the namespace mail.usa.adatum.com, while a Vancouver
site might have the namespace mail.canada.adatum.com. This model reduces proxying, but there are
more DNS records and certificates to manage. Additionally, client computers must be configured with
the appropriate external URL.

Multiple forests. This model consists of multiple forests that have multiple namespaces. An
organization that uses this model could be made up of two partner companies. Namespaces might
include mail.usa.adatum.com, and mail.europe.contoso.com.

Proxying and Redirection

Proxying occurs between two Client Access servers when you designate one Client Access server as an
Internet-facing server, in an organization with multiple sites. The Internet-facing Client Access server
proxies requests to Client Access servers in sites that have no Internet presence. For example, when a user
uses Outlook Web App to request mailbox access, the Internet-facing Client Access server proxies the
request to the Client Access server closest to the user's mailbox.
Exchange Server supports proxying for clients that use Outlook Web App, Exchange ActiveSync, Exchange
Web Services, POP3, and IMAP4 clients.
As an alternative to proxying, you can configure the Internet-facing Client Access server to redirect clients.
For example, when an Outlook Web App user connects to a Client Access server outside the AD DS site
that hosts the Mailbox server, the user sees a webpage that contains a link to the correct Client Access
server for the users mailbox.
Note To enable redirection, if your Client Access server is Internet-facing, configure the
ExternalURL property on the Outlook Web App virtual directories using the Exchange
Management Console or the Exchange Management Shell. You must also configure the
authentication method on these virtual directories to be Integrated Windows
authentication. If your organization has multiple Internet-facing AD DS sites and the
Internet connection to one of those sites is disabled, you can temporarily disable
redirection, and then configure Outlook Web App to use proxying instead. After the
Internet connection in the site that has the problem is restored, you can reinstate
redirection. You can enable and disable redirection using the Set-OWAVirtualDirectory
cmdlet.
Only Outlook Web App clients support redirection.

4-34

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Lesson 3

Designing Client Access

The type and version of client that you implement affects the deployment and configuration choices that
you make. This lesson explores the particular considerations for each client-type.
After completing this lesson, you will be able to:

Design MAPI client access.

Design Outlook Anywhere access.

Design Outlook Web App and Exchange Control Panel.

Design Exchange ActiveSync access.

Design POP3 and IMAP4 access.

Design firewalls and reverse proxies for client access.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-35

Designing MAPI Client Access

The Client Access server role supports connections from RPC and MAPI clients such as Office Outlook
2007 and Office Outlook 2010; this was not the case with Exchange Server 2007, where MAPI clients
connected directly to the Mailbox server role. The MAPI client access change in Exchange Server 2010
provides consistency and improved failover scenarios for MAPI clients.

Benefits of MAPI Client Access

MAPI client access benefits your organization as follows:

Consistency. All clients now use the Client Access server to access their mailbox.

Availability. If you deploy highly available Mailbox servers, clients can fail over more quickly to an
alternate Mailbox server. When the failover occurs, the Mailbox server notifies the Client Access
server, and the clients are redirected to the alternate Mailbox server within seconds.

Performance. The new architecture supports more concurrent client connections.

Convenience. You can move user mailboxes between Mailbox servers even when the client is online
and connected.

You do not need to change your configuration if your users run Office Outlook 2007 or Office Outlook
2010. However, if your users use Office Outlook 2003 SP1 or earlier, you must adjust the Office Outlook
client configuration changes to support MAPI client access. Specifically, you must enable RPC encryption
on the client by either changing the Exchange Server account settings in Office Outlook, or by using a
Group Policy object to deploy the configuration change.

Disabling MAPI Access

To disable all or some MAPI client types from connecting to Exchange Server, create the following registry
value on the Mailbox server:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\
ParametersSystem\Disable MAPI Clients

4-36

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

You can disable a specific MAPI client version by entering its version number. You can also specify a range
of version numbers.

To disable a specific MAPI client version, type: 12.1234.01

To disable a range of MAPI client versions, type: 11.1234.01-12.1234.01

Note To determine the MAPI client version for Office Outlook clients, view the file version
for the Emsmdb32.dll file. The Emsmdb32.dll file version is listed as X.Y.Z, and you must
enter this version value as X.Y.Z in the registry. For example, if the version is 12.0.4407.1004,
then enter 12.4407.1004 in the Disable MAPI Clients registry. Server-side Exchange Server
components also use MAPI to log on. Some components report their client version as an
Exchange build number; consequently, ensure that you do not restrict 6.x.x on an Exchange
server.

You can disable MAPI access for a specific user, mailbox, or for all mailboxes on a specific server. Use the
Exchange Management Console or the Exchange Management Shell to perform this task.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-37

Designing Outlook Anywhere Access

You may decide to implement a single Office Outlook client within your organization so that users
whether they are internal or externaluse a single interface to access their email and related content.
Outlook Anywhere uses RPC over HTTPS to enable users connected to the Internet to access Exchange
Server with Office Outlook 2007 or Office Outlook 2010. To support Outlook Anywhere within your
organization, note the following:

Configure Autodiscover. Autodiscover provides the necessary URLs for Outlook Anywhere clients. If
you do not configure Autodiscover settings correctly, Outlook Anywhere clients may fail to connect
to users mailboxes, or else may connect but provide limited or reduced functionality.

Remember that Client Access redirection is not supported. In a multi-site environment, you may need
to configure an Internet-facing Client Access server in each site that supports Outlook Anywhere
clients. Alternatively, configure Client Access proxying.

Enable Outlook Anywhere on at least one Client Access server per site. Users connect to the Client
Access server that is in the site that also hosts the Mailbox server containing their mailboxes.

Plan certificates carefully. You can use the same SSL server certificate that you use for both Outlook
Web App and Exchange ActiveSync to secure Outlook Anywhere. During installation, Exchange Server
2010 creates a default virtual directory named Rpc on the default IIS website on the Client Access
server. The Rpc virtual directory uses SSL to manage security for Outlook Anywhere and external
client access.
Note Bear in mind that if you use multiple Client Access serverseach in a different site
and each with different namesyou should obtain a certificate that can support multiple
names. You may use a single certificate if you add all the possible DNS name values to the
certificate Subject Alternative Name property on the certificate request. Some CAs support
wildcard names for a particular domain suffixfor example, *.adatum.com.

4-38

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Configure firewall. Outlook Anywhere uses TCP port 443 for communication. To ensure proper
functionality, this port must be open on all firewalls through which Outlook Anywhere traffic passes.
This is the same Transmission Control Protocol (TCP) port used by Outlook Web App and many other
common web-based applications.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-39

Designing Outlook Web App and Exchange Control Panel

Exchange Server 2010 uses Outlook Web App to provide users with web browser access to their
mailboxes. The Outlook Web App feature set is similar to those available in Office Outlook 2010.
Note Exchange Server 2010 SP2 provides a mini version of Outlook Web App. The mini
version of Outlook Web App is a lightweight, browser-based client, similar to the Outlook
Mobile Access client in Exchange 2003. It is designed to be used on a mobile operating
system. The mini version of Outlook Web App provides users with basic messaging and
calendaring functionality.
Outlook Web App in Exchange Server 2010 includes features such as chat, text messaging, mobile phone
integration, and enhanced conversation view. You can access these features from an expanded set of web
browsers, including Internet Explorer 6.0 or later, Firefox, Safari, and Chrome.
Outlook Web App provides many important benefits for an organization, including:

Communication through HTTP. You can easily secure the connection using SSL. Additionally, you will
probably not need to reconfigure your firewalls, because HTTP is a widely implemented protocol.

No need to deploy client software. All client computersincluding computers that run Linux or
Macintoshprovide a web browser. Consequently, users can access their mailboxes from any client
that can access the Client Access servers URL.

Direct access to unique features. You can access features such as the archive mailbox or conversation
view through Outlook Web App, without deploying Office Outlook 2010.

Outlook Web App cannot provide offline access to mailboxes. If the Exchange server hosting Outlook
Web App is offline, users cannot read or send messages. If offline access to files is required, you must
select another remote access method to the Exchange server. Outlook clients using Outlook Anywhere,
ActiveSync, POP3, and IMAP4 clients can cache messages to provide offline access.

4-40

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

The Exchange Control Panel is a webbased management interface that you can use to enable selfservice
for mailbox users. Users can perform specific management tasks without having access to the entire
Exchange Management interface.

Design Considerations for Outlook Web App and Exchange Control Panel
When planning the deployment for Outlook Web App and Exchange Control Panel, consider the
following:

Authentication. Select a suitable authentication method. The Outlook Web App and Exchange
Control Panel virtual directories support the following authentication methods:

Integrated Windows authentication

Digest authentication

Basic authentication

Forms-based authentication

Virtual directory segmentation. Segmentation lets you enable and disable features that are available
to users in Outlook Web App. By default, all mail-enabled users in your Exchange organization can
access their mailboxes by using Outlook Web App. Depending on the needs of your organization, you
can use segmentation to configure the following restrictions for user access:

Control access to certain Outlook Web App features for specific users.

Disable an Outlook Web App feature completely.

Advanced security options. Aside from the standard security measures that you must implement
such as configuring SSL on both the Outlook Web App and Exchange Control Panel virtual
directoriesalso consider configuring Outlook Web App to support secure MIME (S/MIME).
S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who
have a digital identifier (ID) can read them. With S/MIME, users can digitally sign a message, which
allows recipients to verify both the senders identity, and that no one has tampered with the message.
S/MIME requires users to sign in to Outlook Web App using either Internet Explorer 7 or Internet
Explorer 8. Users must have a digital ID, and must install the S/MIME control for Outlook Web App
before they can send encrypted and digitally-signed messages through Outlook Web App. They must
also have both a digital ID and the S/MIME control to read encrypted messages in Outlook Web App.
The S/MIME control is necessary for signature verification on a digitally signed message. Use the
SMIME tab in the Options menu to install the S/MIME control for Outlook Web App on a users
computer.

Outlook Web App virtual directory options. When deploying Outlook Web App and Exchange
Control Panel, consider the following virtual directory options:

Simplify the Outlook Web App URL. You can use the IIS Manager to simplify the Outlook Web
App URL that users use to access their mailboxes.

Configure the default website to redirect clients to the Outlook Web App virtual directory.
For example, when a user types https://servername/, IIS redirects them to
https://servername/owa.

Alternatively, redirect users that use the form http:/servername/ to use SSL, and connect to
the Outlook Web App virtual directory. For example, when a user types http://servername/,
IIS redirects them to https://servername/owa.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-41

Redirect requests. If you have multiple AD DS sites that have Internet-facing Client Access servers,
use redirection to route users to the Client Access server that gives them the best Outlook Web
App experience. If you have multiple Client Access servers in different AD DS sites in an
organization, but only one Internet-facing server, use Client Access server-to-Client Access server
proxying to direct users to the Client Access server that will give them the best Outlook Web App
experience.

Create new Outlook Web App virtual directories. For most organizations, the default Outlook
Web App virtual directory that Exchange Server creates during Client Access server role
installation is sufficient. Businesses that provide hosting services may choose to create new
Outlook Web App virtual directories.

4-42

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Designing Exchange ActiveSync Access

Exchange Server 2010 supports mobile devices used as messaging clients. You can synchronize mailbox
content and perform most of the same tasks with mobile devices as you can with other messaging clients.
Note Exchange Server 2010 SP1 enables mobile device users to synchronize their text
messages with their Exchange Server mailbox. The Short Message Service (SMS) Sync
feature works with Windows Mobile 6.1 with the Outlook Mobile Update and with Windows
Mobile 6.5. When synchronizing text messages, users are able to send and receive text
messages from their Inbox; this feature is dependent on the user's mobile phones or devices
supporting this feature.
Consider the following factors when designing access to Exchange ActiveSync.

Configure Autodiscover. Exchange ActiveSync clients use Autodiscover to retrieve configuration

information. It is important to properly configure Autodiscover to provide the correct information.

Verify that SSL is enabled for mobile device connections. To ensure that the communication between
the mobile device and the Client Access server is secure, ensure that you configure the MicrosoftServer-ActiveSync virtual directory to require SSL.

Install certificates on mobile devices. Just like desktop computers, mobile devices are configured to
trust the root certificates for most public CAs. If you use an SSL certificate from a trusted commercial
CA, you might not have to install the certificate on your device; most devices have certificates from
several trusted commercial CAs preinstalled in the devices root store. However, if you choose to use
an internal CA to provide certificates for your Client Access servers, you must configure the mobile
devices to trust the root CAs by installing the root certificates on the device.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-43

Implement Exchange ActiveSync policies. Exchange ActiveSync policies provide one option for
securing mobile devices. When you apply the policy to a user, the mobile device automatically
downloads the policy the next time the device connects to the Client Access server. To ensure that
mobile devices are as secure as possible, configure Exchange ActiveSync policies that require device
passwords, and encrypt the data stored on the mobile device.
Note All users are initially assigned to the default ActiveSync policy.

Configure your firewall to support Direct Push. Direct Push provides notification to the mobile phone
when new content is ready to be synchronized to the device. For Direct Push to work through your
firewall, you must open TCP port 443 between the Internet and the Client Access server. In addition to
opening ports on your firewall, for optimal Direct Push performance, increase the time-out value on
your firewall from the default to 15 to 30 minutes.
Note It is possible to disable Direct Push for users that are roaming.

Consider data plans when configuring client settings. Select an appropriate data plan for your mobile
devices that provides sufficient bandwidth for the desired services. Alternatively, tailor the services
that you provide to mobile device users based on the characteristics of their device data plan.

4-44

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Designing POP3 and IMAP4 Access

Previous email solutions often used POP3, and later IMAP4, for email retrieval. Various Microsoft products,
including Office Outlook Express and Windows Mail, still support these mail retrieval protocols.
Be sure to consider whether support for these protocols is relevant for your organization. Exchange server
does support many client types, and perhaps these other client types might be more relevant to your
users.
By default, Exchange Server 2010 supports POP3 and IMAP4 client connections, but you must start the
services manually. To enable user access for these protocols, start the services, and then configure them to
start automatically.

Configuration Options
You can configure the following settings for POP3 and IMAP4.
Option

Description

Bindings

Configures the local server addresses that will be used for unencrypted Transport
Layer Security (TLS) or SSL connections.

Authentication

Configures the supported authentication options, such as basic authentication,

Integrated Windows authentication, and secure logon requiring TLS. The default
setting is secure logon.

Connection
settings

Configures server settings, such as time-out settings, connection limits, and the
command relay or proxy target port (used for connections to an Exchange Server
2003 back-end server).

Retrieval settings

Configures the message formats used for the protocols, and configures how clients
will retrieve calendar requests.

User access

Enables or disables access for the POP3 and IMAP4 protocols for each user account.
By default, all users are access-enabled.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-45

In addition to configuring the POP3 and IMAP4 services to automatically start, you must open the
required ports on your firewall. These ports are:

POP3: 110 and 995 (SSL)

IMAP4: 143 and 993 (SSL)

Consider using a reverse proxy to publish these protocols.

Remember that although the clients retrieve messages by using either POP3 or IMAP4, they must send
messages using SMTP. You must provide a SMTP connector for POP3/IMAP4 client use, or else confirm
that users with these clients have access to a third-party SMTP relay, such as one provided by their
Internet service provider.
If you decide to provide SMTP within your organization, you may wish to use an Edge Transport server to
fulfill this role. However, you cannot configure the Edge Transport server to support authenticated
connections using internal AD DS accounts.
Consequently, you may choose to configure a Hub Transport server to provide this functionality. By
default, all Hub Transport servers implement a Client servername SMTP connector called Client
servername that supports authenticated connections over TCP port 587. You must open this port on your
firewall. Consider using a reverse proxy to publish this protocol.

Securing SMTP Connections

To secure the SMTP connections to the Hub Transport server, complete the following steps:
1.

Enable TLS for SMTP client connections. Configure the SMTP Receive connector on the Hub Transport
server to either require TLS security, or to enable basic authentication, but only after you initiate a TLS
session. If your SMTP service has a trusted certificate, you should enable these options, and then
configure all clients to use TLS.

2.

Use the Client Receive connector (port 587), and configure the Hub Transport servers with two
Receive connectors. The default Receive connector uses port 25, while the Client Receive connector
uses port 587. By default, both connectors require TLS security, and allow users to connect to the
connector. However, by using the Client Receive connector, you can avoid using the default SMTP
port for client connections. As described in RFC 2476, port 587 was proposed only for message
submission use from email clients that require message relay.

3.

Ensure that anonymous relay is disabled. Both of the default Receive connectors block anonymous
relays. Do not modify this option on any Receive connector that is accessible from the Internet. If you
enable anonymous relay, anyone can use your server to relay spam.

4.

Enable POP3 and IMAP4 selectively. If only some users in your organization require POP3 and IMAP4
access, then disable this option on all other mailboxes.

4-46

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Designing Firewalls and Reverse Proxies for Client Access

Most organizations have firewalls that protect their internal networks from unwanted Internet access. You
can configure these firewalls to enable users to connect to the required virtual directories and services on
the Client Access server, and to provide access to an SMTP server for IMAP4 and POP3 clients.
Implementing a firewall solution means that you need to configure the messaging clients to use a server
name that resolves to an external IP address on the firewall. Users that are connected to the Exchange
servers from both inside and outside the organization can complicate the messaging client configuration.
For example, users may connect to the Exchange servers from the internal network using the actual server
name, but may need to use a more generic namesuch as mail.contoso.comwhen connecting to the
server from the Internet. You may need to instruct users to use the two server names, or you may need to
configure the internal DNS zone to provide name resolution to the more generic name.
Configuring firewalls to provide access to the Exchange servers is fairly easy, but does raise potential
security issues. Standard firewalls filter network traffic based on source and destination IP addresses and
ports, but cannot analyze the contents of network packets. A standard firewall may use reverse Network
Address Translation (NAT), but still forward the packets directly to the Client Access server. This means
that the traffic that the firewall forwards to the internal Exchange servers may contain malicious code that
it did not detect.
As an alternative to the standard firewall, you can use a reverse proxy or an application layer firewall to
enable access to the internal Exchange servers. Reverse proxies provide an additional layer of security for
network traffic, and protect the Client Access servers. They terminate all client connections, and scan all
network packets for malicious code. The reverse proxy then initiates a new connection to the Client Access
server, and forwards the traffic to the internal network.
To use a reverse proxy, you must configure messaging clients to use a server name that resolves to an
external IP address on the firewall.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-47

Reverse proxiessuch as Microsoft Internet Security and Acceleration (ISA) Server 2006 or Forefront
Threat Management Gatewayprovide the following benefits:

You can configure the firewall as the endpoint for the client SSL connection. The firewall decrypts the
client traffic, applies application-layer filtering, and then re-encrypts the traffic before sending it to
the Client Access server.

You can offload SSL decryption to the firewall. If you do not require all connections on your internal
network to be secure, you can configure the firewall to decrypt the SSL traffic, but not re-encrypt it
before sending the traffic to the Client Access server. This means that the Client Access server
resources are not used to perform SSL decryption and encryption.

You can use ISA Server or Forefront TMG forms-based authentication. If you use ISA Server 2006 or
Forefront TMG as the application layer firewall, you can configure the firewall to pre-authenticate all
client connections using forms-based authentication. This means that only authenticated connections
are allowed into the internal network.
Note If you use certificate-based authentication for Exchange ActiveSync, you must
configure a server-publishing rule that forwards the client traffic to the Exchange Server
computer without decrypting the packets on the ISA Server computer.

In addition to using ISA Server or Forefront TMG to configure forms-based authentication, you also can
use these tools to publish Outlook Web App servers by using mail-server publishing rules, and to control
email attachment availability to protect your organizations resources when users access them through
Outlook Web App. Configuring authentication on the reverse proxy ensures that network traffic enters
your internal network only after user authentication.

4-48

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Lesson 4

Designing Client Access Policies

Many organizations provide employees with the option to access their Exchange Server mailboxes with
mobile devices. However, this can raise security concerns, because mobile devices may contain a large
amount of confidential information, and they are easily lost or stolen. Therefore, it is essential to define
security policies for mobile device management.
After completing this lesson, you will be able to:

Design Outlook Web App mailbox policies.

Describe the options for managing mobile devices.

Design security policies for mobile devices.

Design policies for device management.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-49

Designing Outlook Web App Mailbox Policies

After analyzing your organizations business needs, modify the Outlook Web App virtual directory settings
to address most users requirements. These settings include:

Authentication

Segmentation

Public computer file access

Private computer file access

Remote file servers

Once you have configured most users settings, consider modifying the properties of the default Outlook
Web App Mailbox policy. Outlook Web App mailbox policies enable you to configure the following
settings:

Segmentation

Public computer file access

Private computer file access

Finally, after modifying the default Outlook Web App Mailbox policy, create additional policies to address
the needs of specific users or groups of users. You can assign the policy through the Exchange
Management Console using the Exchange Management Shell. For example, if you wish to configure users
in the Executives organizational unit (OU) with the Executive Policy Outlook Web App Mailbox Policy, use
the following command:
Get-Mailbox -OrganizationalUnit Executives | Set-CASMailbox -owamailboxpolicy "Executive
Policy"

4-50

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Considerations for Designing Outlook Web App Mailbox Policies

Exchange Server 2010 provides several configuration options for managing access for Outlook Web App
users. These configuration options include:

Configuring SSL for secure communication. By default, the Outlook Web App virtual directory
requires SSL for all connections. The default certificate installed on the Client Access server is a selfsigned certificate. Remove the default certificate and install a certificate from a trusted 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 FQDN for the certificate that matches the
FQDN that users will connect to when accessing Outlook Web App.

Configuring authentication. The Client Access server supports several types of authentication for
Outlook Web App. The most secure option is forms-based authentication, which uses a cookie-based
authentication system. This cookie is configured to time out 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 App at any point, which removes the cookie from the computer memory.

Configuring access to attachments. You can configure the types of attachments that users can
download with Outlook Web App. You also can block access to attachments based on file extension
or 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, consider configuring WebReady
Document Viewing as a requirement. This feature converts attachments with supported file
extensions or MIME types to HTML, and displays them so that users 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.
Note To prevent users from directly accessing files, in addition to enabling the Force
WebReady Document Viewing option, you also must clear the Enable direct file access
option.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-51

Options for Managing Mobile Devices

One of the most common ways users access their mailboxes is with mobile devices, such as cell phones
and personal digital assistants (PDAs). However, these mobile devices present a serious security risk.
Exchange Server 2010 provides several options for managing these devices.

Requirements for Mobile Device Policies

Mobile clientssuch as Exchange ActiveSync clientshave unique security requirements. Mobile clients
are susceptible to loss and theft, because the devices are small and portable. Additionally, these devices
may contain highly confidential information, because company executives often carry them. The storage
cards that fit into mobile device expansion slots store increasingly large amounts of data. While this datastorage 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 2010 provides Exchange ActiveSync policies as one option for securing mobile devices.
You can set security restrictions on devices by configuring the applicable policies, and applying them to
user mailboxes. These security restrictions include configuring requirements for password length and
complexity, and permissions for downloading attachments to 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.

4-52

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Managing Mobile Devices

You also can manage mobile devices with either the Exchange Management Console or the Exchange
Management Shell. You generally use these tools when users report lost or stolen devices. The console
and the shell enable you to:

View a list of all mobile devices for each user.

Send a remote wipe command to the mobile device, which removes all data on the mobile device
and sets 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 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 can connect to the Client Access server using Exchange
ActiveSync.
You can manage which device types can connect to the Client Access server. To support features such as
Exchange ActiveSync mailbox policies, the mobile client must be running Windows Mobile 5.0 with the
Messaging and Security Feature Pack, or a newer version of Windows Mobile. To ensure that the policies
apply 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.
Note From Exchange Server 2010 SP1, you can manage Exchange ActiveSync devices
using the Exchange Control Panel (ECP).

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-53

Designing Exchange ActiveSync Policies

Exchange ActiveSync policies are one of the most important ways to implement mobile device security in
Exchange Server 2010. You can configure password policies for mobile devices by configuring Exchange
ActiveSync policies.

Exchange ActiveSync Policy Options

Exchange ActiveSync policies include settings such as:

Password complexity requirements, password length, password expiration, and the time-out value
before users must re-enter their password.

Restrictions on downloading attachments to mobile devices.

Requirements for data encryption on mobile devices.

The number of times users can enter the wrong passwords before their devices are locked or wiped.

Storage of the devices recovery password on an Exchange server. If you select this option, you can
view the password from either Outlook Web App 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 high security level by requiring long, complex passwords that users need
to change frequently. Also, you can configure a 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.
Higher password security tend to increase device lockout incidences, and Exchange administrators are
likely to spend more time recovering or resetting passwords, causing increased user dissatisfaction. Lower
security levels tend to increase user satisfaction, but also increase the chances of serious security breaches.
As part of the design process, you need to negotiate a security level that is acceptable to the organization.

4-54

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Consider configuring different policies for different users. For example, consider configuring a policy with
higher security settings for user groups that carry highly confidential information on their mobile devices,
or have access to highly confidential email. Create as many policies as required, and use the Exchange
Management Shell to assign the policies to multiple users simultaneously.
Also consider enabling remote file access through Exchange ActiveSync, rather than allowing users to
download attachments. Users with compatible mobile devices can view files from an internal file share
rather than downloading the files to their mobile devices.
In addition to setting Exchange ActiveSync policies, you also may need to define other policies regarding
the data that users can store on mobile devices. For example, you can block users from receiving email
attachments, but allow them to transfer data to the devices through a cradle or a USB connection. As part
of managing mobile devices, you should define corporate policies that determine the data that users can
store on their devices.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-55

Designing Mobile Device Remote Wipe Policies

Exchange Server 2010 provides the option to wipe a mobile device remotely if it appears to be a security
issue. For example, for lost or stolen devices, 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

Wiping a mobile device remotely returns the device to its factory default condition the next time the
device synchronizes to the Exchange server. This can protect the devices data, and ensure that no one can
use the device to access the users mailbox.
However, remotely wiping a device that was only temporarily lost can cause user dissatisfaction.
Therefore, you should design policies that allow administrators to wipe users mobile devices, and that
allow users to wipe their own devices.
Note The remote wipe does not delete data stored on a memory card in the computer. To
protect this data, you should require encryption for all data stored on the mobile device.
When defining policies for performing remote wipes, you must:

Define a policy so that Exchange administrators can wipe devices 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 with lost or stolen devices, so they know how to report missing devices.

Develop policies and procedures for rebuilding wiped devices or rebuilding new devices. It is easy to
wipe a mobile device, but more difficult to rebuild the device and restore lost data. To improve
efficiency, create procedures so that users can back up and restore their data and configuration
information. Also provide training to Help Desk personnel to support users during this process.

4-56

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Develop policies for allowing users to wipe their own devices. Exchange Server 2010 also allows users
to wipe their own devices, or to remove the partnership between a device and their Exchange
mailbox. This option is available on the Outlook Web App Options page. Allowing users to wipe
their own devices can decrease the time required for administrators 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, remove this option in the
Outlook Web App segmentation settings.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-57

Lab: Planning and Deploying Client Access Services in

Exchange Server 2010

Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, you must:
1.

On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, and 10233B-VAN-EX2 virtual machines are
running.

3.

If required, connect to the virtual machines. Log on to the virtual machines as

Adatum\Administrator using the password Pa$$w0rd.

Lab Scenario
You are a messaging engineer for the A. Datum Corporation, an enterprise-level organization with
multiple locations. A. Datum Corporation is an international corporation involved in technology research
and investment, and is planning to upgrade from Exchange Server 2003 to Exchange Server 2010.
You have been tasked with reviewing the current messaging infrastructure and network topology, and
planning the deployment and configuration of Client Access servers. You are required to make proposals
about how best to address the needs of the various stakeholders in the organization.
Finally, you are required to implement part of your proposed Client Access design.
Note Your instructor may choose to perform parts of this lab as a group discussion, rather
than an individual activity.

4-58

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Server Design Interview Notes.doc

Marcel Truempy, 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 percent over the next three years. We will be buying more companies,
so prepare for that, as well.

Carole Poland, IT Manager

We have deployed a very good storage area network (SAN) at London, Tokyo, and Vancouver. 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. 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.
Many of our organizations users are using Microsoft Office Outlook 2003, but we have started a project
to deploy the Windows 7 operating system with the 2007 Microsoft Office system; however, it will take at
least 18 months to complete. Additionally, we will be deploying new client computers in our future
London and Chennai offices.

Andreas Herbinger, Messaging Specialist

I understand that Carole wants to use the SAN for mailbox storage, but I think she is underestimating the
amount of storage space we require for Exchange servers. The SANs that we have in place right now have
only about 10 terabytes of free disk. Unless we keep our mailboxes very small, that simply will not be
sufficient.
Her plan to use the SAN will also not result in high availability for Mailbox servers. The server itself will be
a single point of failure. Exchange Server 2010 does not support the use of single copy clusters like
Exchange Server 2007. A DAG will be required for high availability, and each server in the DAG maintains
a copy of the database. It would be incredibly inefficient to store multiple copies of the same data on the
same SAN.
We currently have a mailbox size limit of 50 megabyte (MB) for all users. However, this limit is 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 200 MB
or more. During a meeting last week, the CIO mentioned that when we get to Exchange Server 2010, we
would set up a mailbox size limit of 250 MB for all users, with a 500 MB limit for executives or other
exceptional cases. About 25 percent of the users will fall into the exceptional category. In addition, we
want to create archive mailboxes for the users that are double the size of the mailbox to eliminate the use
of .pst files.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-59

I have some concerns with increasing the mailbox size to this limit. The back-up system in all of our offices
does not have as much capacity as we would like. In some offices, we are still backing up to tape. Some of
the tape backup systems can restore at only 50 GB per hour. According to the service level agreement
that we have in place, we are supposed to restore any failed database within an hour of failure.

Requirements Interview Notes.doc

Madeleine Kelly, CEO
The Board of Directors has just initiated a three-year plan that will result in A. Datum 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 anywhere in the world, and negotiating partnerships or takeovers.
Whatever messaging solution you create has to be very flexible and easily expanded.

Karen Toh, Vice President Europe

My biggest complaint with the current email 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
tell me 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 email from anywhere in
the world at any time.

Marcel Truempy, CIO

In the last five years since I became CIO, our email system has changed from being a useful tool for
business to being a critical part of our business processes, and everybody notices when email is not
available. To give you an example, a couple of months ago all of the email servers in London were
unavailable for six hours due to a virus outbreak. A couple of months before, one of the servers in
Vancouver failed, and we could not send email to and from Vancouver for eight hours while the hardware
vendors came in to fix the hardware. This happened right in the middle of some 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 email system is availability. This system must always be available.

Scott MacDonald, Vice President North America

Our Security and Compliance Department is based in Vancouver, so it reports 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

A. Datum is establishing an important partner relationship with Contoso, Ltd. Contoso, Ltd is a high-tech
research organization, and we are working on some confidential projects with them. We need to ensure
that all of the email that we are sending between our company and Contoso, Ltd cannot be viewed by
anyone else on the Internet.

4-60

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Carole Poland, IT Manager

My biggest concern with this project is the budget. This company has a history of setting 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 conscious of the budget.

Shane DeSeranno, Network Operations Manager

The Network Operations department is responsible for managing all of the WAN links, the local area
networks (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.

Jason Carlson, Network Specialist

I can provide you with a Microsoft Office Visio diagram that has all of our WAN connections and our
connections to the Internet. Our network right now is quiet reliable, but we do not have much available
bandwidth between company locations.

Tzipi Butnaru, Directory Services Manager

The company just finished upgrading all of the AD DS domain controllers to Windows Server 2008,
Service Pack 1 (SP1). As part of the upgrade, we did a thorough review of our whole AD DS design. We do
not anticipate making any more changes to the AD DS configuration for a while.

Conor Cunnigham, 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 App. Many of our users work at home, and most of them use
POP3 clients. I also have security concerns with these clients, but a bigger problem for them is
functionality. Users complain that they cannot easily access their calendar information or send meeting
requests. And we have more and more people asking for access to their email through cell phone devices.

Andreas Herbinger, 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 convinced their managers to approve size increases 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.

Luca Dellamore, Messaging Specialist

We currently have four administrative groups in our Exchange Server organization. We have an
administrative group for North America, one for Europe, and one for Asia (LondonAG, VancouverAG, and
TokyoAG). The extra administrative group contains all of the routing groups (RoutingGroupAG). In each
location, we have a group of Exchange Server administrators that have full administrative permissions for
their administrative group, but do not have any permission in the other administrative groups
(LondonExAdmins, VancouverExAdmins, and TokyoExAdmins). In London, we have a group of senior
messaging specialists who have full control over all administrative groups (EnterpriseExAdmins). 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 Vancouver is
called VancouverRG, and then we have LondonRG and TokyoRG. I can send you the Office Visio with all of
the Exchange servers in each location. We have a routing group connector between VancouverRG and
LondonRG, and between LondonRG and TokyoRG.
We use two SMTP namespaces: adatum.com, and TreyResearch.net.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-61

AD DS and Routing Interview Notes.doc

Tzipi Butnaru, Directory Services Manager
The company just finished upgrading all of the AD DS domain controllers to Windows Server 2008 SP1.
The company has indicated that there is no budget for any further AD DS 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 projects budget is in jeopardy. Any input you could provide to this decision would be appreciated
greatly.

Andreas Herbinger, Messaging Specialist

We currently have 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, Vancouver, and Tokyo. The
problems appear 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 accept inbound
SMTP email for Trey Research. We need to ensure 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 Outlook Web Access. We would really like to
make sure that the experience for the Outlook Web App users is as positive as possible.

Shane DeSeranno, Network Operations Manager

We have been monitoring network traffic by protocol for the last year, and have noticed a significant
increase in the network bandwidth that SMTP traffic uses. In your design, you need to ensure that email
messages always are sent to the network connections with the highest bandwidth. Also, make sure that
you take advantage of any other way that you can save bandwidth that email uses.
We are just taking over managing the network in San Diego, 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.

Jason Carlson, Network Specialist

Our department is responsible for the companys 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, Vancouver, 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 email messages are being scanned for viruses and spam in all locations where we
allow SMTP traffic.

4-62

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Adatum_CurrentPerimeterDesign.vsd

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-63

Adatum_CurrentADSiteDesign.vsd

4-64

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Policy Requirements.doc
As part of the Exchange Server 2010 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 users in the organization is 5 MB.

The graphics department regularly sent messages with 10 MB attachments. The graphics personnel
are located in London, Vancouver, and Tokyo. These messages must be delivered within the
organization.

The current limit for sending and receiving email to the Internet is 2 MB. Many users in the
organization have concerns about this limit, and would like to at least 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 percent buffer when designing message size policies.

All users must have a maximum mailbox size of 250 MB. Executives and managers must have a
maximum mailbox size of 500 MB. Each user will also have an archive mailbox that is twice the size of
the mailbox.

All users should receive a warning when their mailbox reaches 80 percent of the maximum mailbox
size, and should be prevented from sending email when their mailbox reaches 90 percent of the
maximum size.

Users should be able to recover items in their mailboxes for 7 days after the message has been
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
email back saying that the meeting has been accepted. No duplicate meetings should be accepted by
a meeting room. 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 entire organization should be able to
book the meeting room, but the meeting requests much be accepted by a member of the Sales
Support team in London.

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 email 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 email system.

As access to email 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-65

The security officer is concerned about making mobile device access available for all users. He has
specified the following security requirements:

All users who will be accessing email on the Exchange server must be required to have an
alphanumeric password that is at least 6 characters long.

Users who want to download attachments to the device must have encryption enabled on the
device, and the device must be configured to lock after five failed logon attempts.

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 a user gets a new mobile
device, but they 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
email is sent between team members. Retaining this email 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 easily be 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.

4-66

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

A. Datum User Distribution Summary.doc

Location

Internal users

Mobile users

London
Corporate
Headquarters

12,000 currently
10,000 after the new
London office is ready

1,000 Outlook Web Access users

500 Outlook Anywhere and mobile client users
800 Office Outlook users connecting through a virtual
private network (VPN)

London (new
office)

4,000 (anticipated)

200 Outlook Web Access users

50 Outlook Anywhere and mobile client users

San Diego
Former head
office of
Trey Research

500

50 POP3 client users

Vancouver

6,000

800 Outlook Web Access users

100 Outlook Anywhere and mobile client users

Tokyo

5,000

1,000 Outlook Web Access users

200 Outlook Anywhere and mobile client users
200 Office Outlook users connecting through a VPN

Chennai (new
office)

800 (anticipated)

200 Outlook Web Access users

50 Office Outlook users connecting through a VPN

A. Datum has deployed a single AD DS forest with a dedicated root domain named Adatum.com, and
three child domains in the same tree. These domains are:

EU.Adatum.com

NA.Adatum.com

AS.Adatum.com

Additionally, the organization has deployed a domain named TreyResearch.net in the San Diego location.
This domain is configured as a separate tree in the Adatum.com forest.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-67

Exercise 1: Designing the Client Access Server Deployment

Scenario
In this exercise, you will examine the current topology and messaging infrastructure. You will determine
the appropriate Client Access server deployment based on the information supplied in the A. Datum
Exchange Server 2010 project documentation.
The main tasks for this exercise are as follows:
1.

Review the A. Datum documentation.

2.

Answer questions related to the documentation.

3.

Update the A. Datum Client Access server deployment plan document.

Task 1: Review the A. Datum documentation

Review the following information:

Server Design Interview Notes.doc

Requirements Interview Notes.doc

AD DS and Routing Interview Notes.doc

Adatum_CurrentPerimeterDesign.vsd

Adatum_CurrentADSiteDesign.vsd

Task 2: Answer questions related to the documentation

Question: In the Server Design Interview Notes document, what points are raised that impact
your Client Access server deployment plan, and why do they impact the plan?

Question: In the Requirements Interview Notes document, what points are raised that impact
your Client Access server deployment plan, and why do they impact the plan?

Question: In the AD DS and Routing Interview Notes document, what points are raised that
impact your Client Access server deployment plan, and why do they impact the plan?

Question: Is there anything in the Adatum_CurrentPerimeterDesign.vsd diagram that raises

Client Access server deployment issues? If so, what?

Question: Is there anything in the Adatum_CurrentADSiteDesign.vsd diagram that raises Client

Access server deployment issues? If so, what?

4-68

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Task 3: Update the A. Datum Client Access server deployment plan document

Complete the following proposal document by answering the questions.

A. Datum Client Access Server Deployment Plan
Document Reference Number: JC040410/1
Document Author
Date

Jason Carlson
4th April 2010

Requirement Overview
Determine the number and placement of Client Access servers within the existing network
infrastructure.
Additional Information
Identify infrastructure changes that may be required due to the proposed deployment.
Proposals
Question: With reference to the Adatum_CurrentADSiteDesign diagram, how many Client Access
servers do you propose to deploy in each site?
Question: Do you have sufficient information from the documents reviewed so far, to determine
whether some sites require additional Client Access servers?
Question: Based on the documentation you have reviewed, what client types must you support?
Question: Is it clear from the documentation that you have reviewed which sites support which
client types?
Question: While maintaining compliance with the requirements mentioned in the documentation,
can you propose changes to the client types that will simplify the configuration?
Question: Which Client Access servers do you propose to make Internet-facing?
Question: How will you configure Autodiscover to support your Client Access server model?

Note

Be prepared to discuss your proposed design with the class.

Results: After this exercise, you should have completed the A. Datum Client Access server deployment
plan document.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-69

Exercise 2: Designing Client Access

Scenario
In this exercise, you will determine which Client Access server features and services are required, and you
will plan how to configure them to support the defined requirements.
The main tasks for this exercise are as follows:
1.

Review the A. Datum documentation.

2.

Answer questions relating to the documentation.

3.

Update the A. Datum Client Access server configuration document.

Task 1: Review the A. Datum documentation

Review the contents of the following documents:

Policy Requirements.doc

A. Datum User Distribution Summary.doc

Task 2: Answer questions relating to the documentation

Question: In the Policy Requirements document, what points are raised that impact your Client
Access server deployment plan, and why?

Question: In the A. Datum User Distribution Summary document, what points are raised that
impact your Client Access server deployment plan and why?

Task 3: Update the A. Datum Client Access server configuration document

Complete the following proposal document by answering the questions.

A. Datum Client Access Server Configuration
Document Reference Number: JC040410/2
Document Author
Date

Jason Carlson
4th April 2010

Requirement Overview
Determine the feature configuration for Client Access servers in the A. Datum Exchange Server 2010
upgrade.
Proposals
Question: Based on the information in the A. Datum User Distribution Summary document, do you
envisage deploying additional Client Access servers in any sites?
Question: Which features must you enable on the Client Access servers to support the current
client-types?
Question: Which client protocols must you enable through the firewalls?

4-70

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

A. Datum Client Access Server Configuration

Question: What would you do to address the security concerns raised regarding mobile clients?
Question: To support the other client types, what other configuration changes must you make?
Question: While maintaining compliance with the requirements mentioned in the documentation,
can you propose changes to the client types that will simplify the configuration?

Note

Be prepared to discuss your proposed design with the class.

Results: After this exercise, you should have completed the A. Datum Client Access server configuration
document.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-71

Exercise 3: Implementing Client Access

Scenario
In this exercise, you will implement Exchange ActiveSync according to your proposals.
The main tasks for this exercise are as follows:
1.

Verify the Exchange ActiveSync virtual directory configuration.

2.

Create a new Exchange ActiveSync mailbox policy.

3.

Configure Exchange ActiveSync settings from the ECP.

Task 1: Verify the Exchange ActiveSync virtual directory configuration

In the Exchange Management Console, review the configuration for the Microsoft-Server-ActiveSync
virtual directory. The virtual directory configuration can be viewed for each Client Access server in the
Client Access node.

Task 2: Create a new Exchange ActiveSync mailbox policy

1.

On VAN-EX2, in the Exchange Management Console, create a new Exchange ActiveSync Mailbox
policy with the following configuration:

Name: Executive Policy

Enable non-provisionable devices

Enable attachments to be downloaded to the device

Require passwords

Disable simple passwords

Enable password recovery

Minimum password length: 6

Require encryption on device

Note

You must create and then modify the policy to configure the following two settings.

Configure the number of failed logon attempts at 5

Require encryption on storage card

2.

Review the other Exchange ActiveSync Mailbox policy settings.

3.

Apply the Exchange ActiveSync Mailbox policy to users in the Executives OU. Open Exchange
Management Shell, and then execute the following command:
Get-Mailbox -OrganizationalUnit Executives | Set-CASMailbox
-activesyncmailboxpolicy "Executive Policy"

Task 3: Configure Exchange ActiveSync settings from the ECP

1.

Open Internet Explorer and navigate to https://van-ex2.adatum.com/ecp.

2.

Logon as adatum\administrator using the password of Pa$$w0rd.

4-72

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

3.

From Phone & Voice, from within the ActiveSync Device Policy, review the Executive Policy.
Notice that text messages can be synchronized by default.

4.

From within ActiveSync Access, create a New Device Access Rule:

All families

Quarantine Let me decide to block or allow later.

You will not be able to save the settings as there are no devices currently in use within the
Adatum organization. Cancel the policy creation and close all open windows.

Results: After this exercise, you should have deployed and configured Exchange ActiveSync for members
of the Executives group.

To prepare for the next module

When you finish the lab, revert the machines back to their initial state. To do this, complete the following
steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2. Close the virtual machine connection
windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then in the Actions pane, click Start.

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then in the
Actions pane, click Connect.
Important Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully
started before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10223A-VAN-EX1. Connect to the virtual
machine.

8.

Wait for 10233B-VAN-EX1 to start, and then start 10223A-VAN-EX2. Connect to the virtual machine.

9.

Wait for 10233B-VAN-EX2 to start, and then start 10223A-VAN-EDG. Connect to the virtual
machine.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 4-73

Module Review and Takeaways

Review Questions
1.

When a user attempts to connect to an Internet-facing client access server, the petitioned server
determines that the users mailbox is located in another site. The Client Access server in the other site
is not configured with an external URL. What happens next?

2.

You have deployed a single Internet-facing Client Access server to support all sites in your
organization. Which authentication method must you configure on all other Client Access servers?

3.

Your users seem to be experiencing problems when trying to access their mailboxes using Outlook
Web App. You realize they are typing the incorrect URL, and are forgetting the https prefix. What can
you do to assist?

Best Practices
Supplement or modify the following best practices for your own work situations:

Never deploy a Client Access server in your perimeter network.

As a general guideline, deploy three Client Access server processor cores in an AD DS site for every
four Mailbox server processor cores.

4-74

Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Do not run the Security Configuration Wizard on servers that support Exchange Server 2010 server
roles.

If your organization has deployed Exchange servers in multiple AD DS sites, consider configuring site
affinity for the Autodiscover service.

If you have multiple Client Access serverseach in a different site and with different namesbe sure
to obtain a certificate that can support multiple names.

5-1

Module 5
Planning and Deploying Message Transport in Microsoft
Exchange Server 2010
Contents
Lesson 1: Designing Message Routing for Exchange Server 2010

5-3

Lesson 2: Designing Hub Transport Servers

5-13

Lesson 3: Designing the Message Routing Perimeter

5-29

Lab: Planning and Deploying Message Transport in Exchange Server 2010

5-44

5-2 Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Module Overview

After you have defined the business requirements of your organization and have a good understanding of
the current network environment, the next step is to design message routingboth within the
organization, and between your organization and other organizations that are connected to the Internet.

Objectives
After completing this module, you will be able to:

Design message routing for Microsoft Exchange Server 2010.

Design Hub Transport servers.

Design the message routing perimeter.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-3

Lesson 1

Designing Message Routing for Exchange Server 2010

One of the Exchange Server 2010 infrastructures 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 2010, the routing topology integrates tightly with the Active Directory Domain Services
(AD DS) site configuration.

Objectives
After completing this lesson, you will be able to:

Describe the message transport components in Exchange Server 2010.

Describe the default message routing configuration in Exchange Server 2010.

Explain how to modify the default message routing topology.

Explain how to design message routing to mitigate the effects of message routing failure.

5-4 Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Overview of Message Transport Components in Exchange Server 2010

The message transport pipeline in Exchange Server 2010 consists of several components that work
together to route messages. Messages from outside the organization enter this pipeline through a Simple
Mail Transfer Protocol (SMTP) Receive connector on an Edge Transport server, a Hub Transport server, or
another non-Exchange SMTP server. Messages inside the organization enter the transport pipeline
through the SMTP connector on a Hub Transport server, through agent submission, from the Pickup or
Replay directory, or by direct placement by the store driver in the Submission queue.

Submission Queue
When the Microsoft Exchange Transport service starts, the categorizer creates one Submission queue on
each Edge Transport server and Hub Transport server. The Submission queue stores all messages on a disk
until the categorizer processes them for further delivery. No message can be categorized without being
submitted to the Submission queue. While the categorizer processes a message, it remains in the
Submission queue. After the categorizer categorizes a message successfully, it removes it from the
Submission queue.
Messages can enter the Submission queue in several ways:

Messages received by an SMTP Receive connector. Use this for messages inbound from the Internet
or from a client using Post Office Protocol version 3 (POP3) or Internet Message Access Protocol
(IMAP).

Messages placed in the Pickup directory. Use this method for troubleshooting and for legacy
applications.

Messages submitted by the store driver. Use this method to retrieve messages from a senders
Outbox.

Messages resubmitted after failed delivery. The categorizer resubmits messages that were not
delivered on the first attempt. You also can resubmit messages manually.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-5

Store Driver
Messages sent by mailbox users enter the message-transport pipeline from the senders Outbox. The store
driver on the Hub Transport server retrieves messages from the senders Outbox, and submits them to a
Submission queue.
The store driver can place messages into the Submission queue on any Hub Transport server that is on the
same AD DS site as the Mailbox server from which it retrieves the message. After the store driver adds the
message successfully to the Submission queue, it moves the message from the senders Outbox to the
senders Sent Items folder.
Messages in the Outbox are stored in MAPI format, and the store driver must convert them to Summary
Transport Neutral Encoding Format (STNEF) before placing them in the Submission queue. If the store
driver is unable to convert the content, it generates a non-delivery report (NDR).

Microsoft Exchange Mail Submission Service

The Microsoft Exchange Mail Submission service is a notification service running on Mailbox servers. It
notifies a Hub Transport server role in the local AD DS site when a message is available for retrieval from a
senders Outbox. The store driver on the notified Hub Transport server role then picks up the message
from the senders Outbox.
If there are multiple Hub Transport servers in the AD DS site, the Microsoft Exchange Mail Submission
service attempts to distribute notifications evenly between the Hub Transport servers.

Categorizer
The categorizer retrieves one message at a time from the Submission queue, and always picks the oldest
message first. On an Edge Transport server, categorization of an inbound message is a short process in
which the categorizer verifies the recipient SMTP address, and places the message directly into the
delivery queue. From the delivery queue, it routes the message to a Hub Transport server.
On a Hub Transport server, the categorizer performs the following tasks:

Identifies and verifies recipients. All messages must have a valid SMTP address.

Bifurcates messages that have multiple recipients. The expansion of distribution lists enables
identification of individual recipients who belong to the distribution list. Additionally, the categorizer
processes the return path for distribution-list delivery status notifications (DSNs), and it determines
whether Out-of-Office messages or automatically generated replies are sent to the original messages
sender.

Determines routing paths. As part of determining the routing path, the categorizer identifies the
destination. The destination must be a users mailbox, a public folder, or an expansion server for
distribution groups. If it cannot determine a valid destination, an NDR is generated.

Converts content format. Various recipients require messages in different formats. The categorizer
converts the message to an appropriate format for the recipient. Inside the Exchange Server
organization, the recipient format is stored in AD DS. Messages routed to the Internet are sent in the
Multipurpose Internet Mail Extensions (MIME) or Secure/Multipurpose Internet Mail Extensions
(S/MIME) format.

Applies organizational message policies. You can use organizational policies to control messaging
aspects such as size, permission to send messages to specific users, the number of message recipients,
and other characteristics.

5-6 Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Pickup Directory
Most messages enter the message transport pipeline through SMTP Receive connectors, or by submission
through the store driver. However, messages also can enter the message transport pipeline by being
placed in the Pickup directory on either a Hub Transport server or an Edge Transport server.
The store driver submits messages that the categorizer places in the Pickup directory to the Submission
queue. The store driver deletes messages from the Pickup directory after it submits them to the
categorizer from the Submission queue. Messages that the categorizer places in the Pickup directory must
be in the appropriate format and have read/write permissions configured.
The Pickup directory allows you to take a properly formatted text file, and have the Hub Transport server
process and deliver it. This can be useful for validating mail flow in an organization, replaying specific
messages, or returning recovered email to the message transport pipeline. Additionally, some legacy
applications may place messages in the Pickup directory for delivery, rather than communicate directly
with Exchange Server SMTP Receive connectors.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-7

Default Message Routing Configuration in Exchange Server 2010

Many organizations create AD DS sites to control AD DS replication and client authentication network
traffic. Exchange Server 2010 uses AD DS sites and AD DS site links to define an organizations internal
and external message routing.

How Exchange Server 2010 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 message 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 AD DS sites, the following steps occur:
1.

The Mailbox server uses AD DS site membership information to determine which Hub Transport
servers are in the same AD DS 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 by using the round-robin algorithm.

2.

The Hub Transport server performs recipient resolution, and queries AD DS to match the recipient
email address to a recipient account. The recipient account information includes the fully qualified
domain name (FQDN) of the users Mailbox server. The FQDN determines the AD DS site of the users
Mailbox server.

3.

The Hub Transport server uses AD DS site link information to determine the lowest cost route to the
destination AD DS 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 AD DS site receives a message, the Hub Transport
server forwards the message to the appropriate Mailbox server in the destination AD DS site.

5-8 Planning and Deploying Message Transport in Microsoft Exchange Server 2010

5.

If the message has multiple recipients whose mailboxes are in different AD DS sites, Exchange Server
uses delayed fan-out (or bifurcation) 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 Site 1 to Site 3 and
Site 4 both pass through Site 2, then a single copy of a message intended for recipients in Site 3 and
Site 4 is sent to a Hub Transport server in Site 2. The Hub Transport server in Site 2 then sends two
copies of the message, one each to a Hub Transport server in Site 3 and Site 4.
Note If you deploy Exchange Server 2010 in an existing legacy Exchange Server
environment, the organizations message routing will vary if the messages are routed to, or
from, previous Exchange Server versions. For example, in Exchange Server 2003, you can use
routing groups to group Exchange Servers into location contexts. These routing groups
may, or may not, match up with the AD DS site configuration. All Exchange Server 2010
servers are grouped into a single routing group for backwards compatibility with Exchange
Server 2003.

How Exchange Server 2010 Selects a Message Route

In some cases, there may be more than one route available for delivering messages between AD DS sites.
If a recipient is in the remote AD DS site, and multiple paths exist to get to that site, the Exchange Servers
routing service uses the following criteria to choose a path on which to send the message:

The path with the lowest cost from source to destination site. The lowest-cost route is calculated by
aggregating all AD DS IP site link costs, or the Exchange Server 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.
Note 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 evaluates only the site link. Therefore, it is important that the site links
logically reflect the underlying network topology.

Alphanumerically lower preceding AD DS 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\V14\Transport\Logs\Routing folder. The Exchange
Transport server recalculates the routing tables when the transport services begin, or when
changes to the routing topology are made.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-9

Modifying the Default Message Routing Topology

In some cases, you may want modify the default message routing configuration by configuring specific
AD DS sites as hub sites, and by assigning Exchange-specific routing costs to AD DS site links.

Options for Modifying the Default Message Routing Topology

By default, Hub Transport servers in one site attempt message delivery to another sites recipient by
establishing a direct connection to a Hub Transport server in the remote AD DS site. However, you can
modify the default message routing topology in three ways:

Configure hub sites. You can configure one or more AD DS 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.

Configure Exchange Server-specific routing costs. You also can modify the default message routing
topology by configuring an Exchange Server-specific cost to an AD DS IP site link. If you assign an
Exchange Server-specific cost to the site link, the Hub Transport server uses this attribute rather than
the AD DS-assigned cost to determine the least-cost routing path.

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
a 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 then distributes the messages.

5-10

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Considerations for Modifying the Default Routing Topology

Most organizations do not need to modify the default Exchange Server 2010 routing topology. However,
consider the following factors 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 AD DS
sites prevent direct SMTP communications.
Note Configuring hub sites does not decrease the network traffic, as Exchange Server
2010 uses delayed fan out, regardless of whether you configure hub sites or not.

Consider configuring an Exchange Server-specific cost to an IP site link if the cost does not result in
an optimal Exchange Server message routing topology, and if you cannot modify the AD DS
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.
Note If you nest groupsthat is, some of your groups contain groups as members
consider configuring the second-tier groups with expansion servers. This is especially
relevant if these groups are representative of users distributed regionally. For example, if A.
Datum Corporation had a worldwide sales team, a regional sales team for each continent,
and a sales team in each country within each continent, you might consider configuring the
top-level World-Wide Sales group with no expansion server. However, it might prove
efficient to configure the Americas-Sales, Asia-Sales, and Europe-Sales groups with
expansion servers in the relevant region. For example, Europe-Sales might be configured
with an expansion server in Paris, France. You might decide to continue this approach with
the next group level. For example, the London-Sales group has an expansion server that is
located in Canary Wharf, the head offices for A. Datum Corporation in London.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-11

Designing Message Routing to Mitigate the Effects of Message Routing

Failure

When designing the message routing topology, you also should consider how Exchange Server 2010 deals
with situations where message routing between sites fails.

How Exchange Server 2010 Deals with Message Delivery Failure

If a Hub Transport server cannot deliver a message to another Hub Transport server in the destination site
or a hub site, then the Hub Transport server delivers the messages through 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 AD DS 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 2010 uses deterministic algorithms to choose available paths
between AD DS sites. The algorithms are deterministic because they always choose one
path provided contributing factors do not change. Exchange Server 2010 does not loadbalance message delivery across multiple connectors with the same cost, and it does not fail
over to an alternate path if a Hub Transport server in a site does not respond.

5-12

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Guidelines for Dealing with Message Routing Failure

You should consider how Exchange Server 2010 deals with message routing failure when designing the
message routing topology. Consider the following guidelines:

For each of your organizations 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 AD DS sites where messages will be queued for multiple
destination sites. For example, if your organization uses a hub and spoke topology for the AD DS site
links, messages are queued in the hub AD DS 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 AD
DS site. If one of the Hub Transport servers is not available in a site, the source Hub Transport server
attempts to connect to the sites 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. For example, when more than one Hub Transport
server exists in a remote AD DS site, round-robin load balancing determines the routing
path. Fault tolerance is achieved by connecting to the next available server in a prioritized
list of servers when the selected server is unavailable.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-13

Lesson 2

Designing Hub Transport Servers

Hub Transport servers provide the message-routing backbone in any Exchange Server organization.
Therefore, it is important for you to plan the configuration and placement of your Hub Transport servers
with care, as a poor routing design may lead to degraded performance.

Objectives
After completing this lesson, you will be able to:

Describe the hardware requirements for Hub Transport servers.

Describe the default Hub Transport server configuration.

Plan SMTP send and receive connectors.

Plan for internal SMTP relay.

Design accepted domains and remote domains.

Design message throttling, back pressure, and size limits.

Troubleshoot internal message delivery.

5-14

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Hardware Requirements for Hub Transport Servers

Optimizing a messaging system is a question of optimizing all the elements within the system. In
Exchange Server 2010, by ensuring that your Hub Transport servers meet the recommended hardware
requirements, you can ensure an optimal routing infrastructure.
Note The hardware requirements of an Edge Transport server do not differ greatly from
that of a Hub Transport server.

Processor Requirements
Exchange Server 2010 is a 64-bit application, and must therefore run on a 64-bit processor. You can select
processors from Intel that support Intel Extended Memory 64 Technology, or processors from AMD that
support AMD64.
Note For more information about these processor options, see the Intel 64 Architecture
website at http://www.intel.com/technology/intel64/, or the AMD Opteron Processor
Family website at http://www.amd.com/us/products/server/processors/Pages
/server-processors.aspx.
After you have selected a 64-bit processor-based server computer, you should configure your Hub
Transport server role with an appropriate number of processor cores. You will need more cores for
organizations where you deploy Hub Transport servers with several Mailbox servers and thousands of
mailboxes.
You can efficiently use eight processor core Hub Transport servers when you also configure the Hub
Transport to use antivirus and anti-spam. Consider either one or two core processors configurations if
your organization does not support many mailboxes, or you have insufficient message traffic to warrant
using more processor cores. A maximum of 12 processor cores is recommended.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-15

Note 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.

Memory Requirements
When planning memory for your Hub Transport server, consider:

Memory speed. To support greater amounts of installed memory, some servers require slower
memory. For example, using PC3200 memory may enable you to scale your server to only 16
gigabytes (GB) of memory, while using PC2700 memory enables support for 32 GB of memory.

Module size. Ensure that the maximum memory module size enables you to meet your target
memory.

Number of memory slots. Linked to the module size, the number of slots determines the maximum
installable memory.

Total memory. The Hub Transport server role does not require substantial quantities of memory to
perform well in typical conditions. Generally, 1 gigabyte (GB) of random access memory (RAM) per
processor core, with a minimum of 4 GB per server, is sufficient to handle all but the most demanding
loads.

Disk Configuration
The performance of disk resources is also important in the Hub Transport server role as it processes email
from memory into the queue database. For optimal performance, consider placing the mail queue
database on a different disk spindle than that which hosts the related transaction logs. Additionally, you
must ensure that sufficient free-space is available to avoid back pressurea system resource monitoring
feature of the Microsoft Exchange Server 2010 transport service.

Network Configuration
Much of the network interface subsystem is tuned automatically. Server-based network adapters are
capable of detecting the type and level of traffic passing through the network interface, and they selftune to reflect this information. You should have operational practices in place to ensure that the latest
device drivers are maintained on the server for installed network interface cards (NICs).

Server Ratios
You should plan to deploy seven mailbox servers to each Hub Transport server, if the Hub Transport
server does not provide antivirus scanning. If your Hub Transport servers perform antivirus scanning, then
the Mailbox server to Hub Transport server ratio should be 5:1.

5-16

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Default Hub Transport Server Configuration

The fundamental building block of Exchange Server 2010s transport architecture is the Hub Transport
server. This role is responsible for all internal message routing, relaying of messages to and from the
perimeter network, and optionally, routing of messages to and from the Internet, depending upon
configuration. To design an optimal routing infrastructure, you might need to consider reconfiguring your
Hub Transport servers. It is therefore important to understand the default configuration.

Accepted Domains
Accepted domains configured at the organization level define the SMTP namespaces for which your
organization receives email. By default, your Exchange Server organization accepts email for the AD DS
forest root domain.

Remote Domains
Remote Domains enable you to configure message settings between your organization and other external
organizations. For example, you can configure out-of-office messages, and message format settings. By
default, the remote domain * is configured. This wildcard setting affects all messages sent to all other
domains.

Receive Connectors
Receive connectors handle inbound emailthat is, inbound to a specific Hub Transport server. Each Hub
Transport server hosts two SMTP receive connectors:

The Default <server name> connector is configured to accept inbound connections from any IP
address over all locally configured IP addresses using Transmission Control Protocol (TCP) port 25.
This connector is used to support connections from other Hub Transport servers. By default, the
following authentication mechanisms are enabled: Transport Layer Security (TLS) Basic authentication
(offer Basic authentication only after starting TLS), Exchange Server authentication, and Integrated
Windows authentication. Exchange Server users, Exchange servers, and legacy Exchange servers are
permitted to use the connector by default.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-17

The Client <server name> connector is provided to support inbound connections from SMTP clients.
It supports inbound connections on all connected NICs, and from any IP address over TCP port 587.
By default, the following authentication mechanisms are enabled: TLS, Basic authentication (offer
Basic authentication only after starting TLS), and Integrated Windows authentication. Only Exchange
Server users are permitted to use the connector by default.

There are no default Send connectors configured on each Hub Transport server.

Transport Agents
Transport agents process email messages that pass through the transport pipeline on a Hub Transport
server or Edge Transport server. Custom transport agents provide additional functionality to Exchange
Server 2010, such as anti-spam or antivirus programs, or any transport function that your organization
may require.
Exchange Server 2010 includes several default transport agents that enable it to provide features such as
transport rules and journaling. By default, the following transport agents are installed on Hub Transport
servers.

Transport Rule agent. The Transport Rule agent processes transport rules on Hub Transport servers. It
fires on the OnRoutedMessage transport event. Transport rules configured on Hub Transport servers
are stored in AD DS, making them accessible to all Hub Transport servers in the Exchange
organization. This allows Exchange Server to apply consistently a single set of rules across the entire
organization.

Journaling agent. The Journaling agent is a compliance-focused transport agent that processes
messages on Hub Transport servers. It fires on the OnSubmittedMessage and OnRoutedMessage
transport events. When you enable standard journaling on a Mailbox database, this information is
saved in AD DS, and is read by the Journaling agent.

Active Directory Rights Management Services Prelicensing agent. You can use the Active Directory
Rights Management Services (AD RMS) Prelicensing agent to certify the Microsoft Office Outlook
recipient's authenticity, so that the recipient can open messages without receiving a credential
prompt on every attempt. It fires on the OnRoutedMessage transport event.
Note Transport agents have full access to all messages that they process; Exchange puts
no restrictions on a transport agent's behavior. Consequently, transport agents that are
unstable or contain security flaws may affect the stability and security of Exchange Server
2010.

5-18

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Planning SMTP Send and Receive Connectors

An SMTP connector is an Exchange Server component that supports one-way SMTP connections, which
route mail between Hub Transport and Edge Transport servers, or between the transport servers and the
Internet. Exchange Server 2010 provides two types of SMTP connectors: SMTP Receive connectors, and
SMTP Send connectors.
Note Exchange Server 2010 automatically creates the Send and Receive connectors that
are required by intra-organization mail flow. These are implicit connectors that are not
visible in the Exchange Server management tools, and you cannot modify them.
An SMTP Receive connector is required for an Exchange Server 2010 computer to accept any SMTP email.
An SMTP Receive connector enables an Exchange Hub Transport or Edge Transport server to receive mail
from any other SMTP sources, including: SMTP mail programs such as Office Outlook Express, and SMTP
servers on the Internet, Edge Transport servers, or other Exchange Server SMTP servers.
Two default SMTP Receive connectors are created on each server running the Hub Transport server role.
An Exchange Server 2010 computer requires an SMTP Send connector to send any SMTP email.
Additionally, SMTP Send connectors are required to send email to any SMTP server on the Internet, or to
any SMTP servers in the same Exchange Server organization.
Note By default, no SMTP Send connectors are configured on Hub Transport servers,
except for the implicit SMTP Send connectors that are created dynamically to communicate
with Hub Transport servers in other sites.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-19

When to Consider Additional SMTP Connectors

You must configure additional SMTP connectors if you want to connect your Exchange Server
organization to the Internet. You have a number of options that you can consider to support this
connectivity:

Configure an Edge Subscription. Perhaps the easiest option is to deploy an Edge Server in your
perimeter network, and then create an Edge subscription between your internal Exchange
organization and the Edge Server in the perimeter network. This option results in the automatic
creation of the required Send and Receive connectorsbetween the organization and the perimeter,
and at the perimeter, to and from the Internet.

Configure Internet connectivity to and from the Hub Transport servers. If you do not deploy an Edge
Transport server, you must configure the Hub Transport server to enable inbound and outbound mail
flow. To enable inbound mail flow, you must configure an SMTP Receive connector to accept
anonymous connections on port 25 using a network interface that is accessible from the Internet. To
enable outbound email flow, you must configure an SMTP Send connector with an address space of
*that uses Domain Name System (DNS) to send messages to the Internet.
Note If you use the Hub Transport server to send and receive email from the Internet, you
should configure antivirus and anti-spam agents on the Hub Transport server.

Configure external SMTP relay. Smaller organizations often configure an SMTP relay agent, perhaps
hosted by an Internet Service Provider (ISP), to handle their Internet mail flow. To support this
configuration, you must configure your Hub Transport server. To enable inbound mail flow, you must
configure an SMTP Receive connector to accept anonymous connections on port 25 using a network
interface that is accessible from the Internet. To enable outbound email flow, you must configure an
SMTP Send connector with an address space of *that can use a smart host to send messages to the
Internet. You must ensure that the authentication configuration of this connector matches the details
provided by your ISP.

Configure internal SMTP relay. If your Exchange organization is responsible for handling email for
another AD DS forest, you will need to configure internal SMTP relaying. This option is discussed in
more detail in the following topic.

Configure mail flow through Exchange Online or a third-party gateway. To establish Internet mail
flow through Exchange Online (or an external SMTP gateway), you must create a Send connector and
a Receive connector between the Hub Transport servers in your Exchange Server organization and the
external SMTP servers that process and route Internet email. The precise details of the configuration
of these connectors vary.
Note You can configure multiple SMTP Receive connectors with different parameters on a
single Exchange server. However, you must configure each SMTP Receive connector with
the following: a port on which the connector can receive connections; local IP addresses
that can be used for incoming connections; and a remote IP subnet that can send mail to
this SMTP Receive connector. The combination of these three properties must be unique
across every SMTP Receive connector in the organization. In large organizations, there can
be multiple SMTP Receive connectors on a single server, or on multiple servers. In small to
medium-sized organizations, as few as two connectors (a Send and a Receive connector)
could serve the entire organization.

5-20

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

SMTP Connector Improvements in Exchange Server 2010 SP1

Exchange Server 2010 SP1 introduces a number of improvements in the transport architecture. These
include changes in the behavior of SMTP connectors.

SMTP failover and load balancing improvements. Exchange Server 2010 SP1 improves the way
Transport servers detect unhealthy servers and use enhanced DNS.
When all servers are healthy, enhanced DNS helps to distribute the load evenly, but when one or
more servers have become unavailable, the load distribution among the remaining healthy servers
may not be evenly balanced.
To help to address this, all Exchange Server 2010 SP1 Transport servers maintain a list of unavailable
servers. When routing a message, servers use this list to filter out the unavailable servers from the set
of target servers. Consequently, Exchange Server 2010 SP1 Transport servers always distribute the
load evenly between healthy servers and avoid any servers that are unavailable for any reason.

Send connectors over reliable connections improvements. Exchange Server 2010 SP1 provides the
ability to downgrade connection failures in Send connectors.
Within your Exchange organization, you may implement dedicated Send connectors that are used for
routing messages over well-defined, reliable communication channels, for example, a send connector
dedicated to sending messages to Exchange Online.
Because these communication channels are expected to be reliable, you might not expect to see so
many of the typical errors that occur on ordinary destinations over the Internet; consequently, you
might want to treat any such communication errors as transient instead of immediately resulting in
the generation of a non-delivery report (NDR).
With Exchange Server 2010 SP1, you can configure a send connector to downgrade authentication
and name resolution errors that normally result in an NDR, to transient errors. In these instances,
Exchange Server attempts delivery again, instead of immediately issuing an NDR.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-21

Planning for Internal SMTP Relay

Internal SMTP relay occurs when you configure your Exchange Server organization to route email that is
addressed to recipients that do not exist within your AD DS forest, to another SMTP host. A possible
scenario might arise if your organization has two AD DS forestsperhaps following a merger or
acquisition. Each forest has its own Exchange Server organization, and you decide to configure one
organization to handle all inbound message routing for both organizations.
To demonstrate this point, consider two AD DS forests: A. Datum, and Contoso. A. Datum Corporation
recently acquired Contoso, Ltd. Both organizations have implemented Exchange Server 2010 in their AD
DS forests; however, following the acquisition, it is decided that the Exchange Server organization A.
Datum will route all inbound email for both organizations. To facilitate this, you must complete the
following steps:
1.

Configure external DNS records for both organizations to point to the A. Datum Edge Transport
servers.

2.

Configure the A. Datum organization with two accepted domains:

Adatum.com is configured automatically as an authoritative accepted domain, as it is the forest

root domain for the A. Datum forest.

Contoso.com must be configured as an accepted domain for internal relay.

3.

Create a Send connector at A. Datum to route messages to the Contoso organization.

4.

Create a Send connector at Contoso to route messages to the A. Datum organization.

5.

Configure the reciprocal Receive connectors with settings that match the Send connectors in terms of
authentication and IP configuration.

6.

Configure a mechanism to synchronize the address lists between the two organizations. For example,
consider deploying Identity Integration Feature Pack (IIFP) or Microsoft Identity Integration Server
(MIIS) to propagate the mailbox users from Contoso to A. Datum as contacts.

5-22

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Designing Accepted Domains and Remote Domains

As part of the Hub Transport server configuration process, you should configure the domains for which
the Hub Transport server will accept email, and configure users with alternate email addresses.

Accepted Domains
When you create a new accepted domain, you have three options for the domain type you want to
create:

Authoritative Domain. Select this option if the recipients using this domain name have mailboxes in
the Exchange Server organization.

Internal Relay Domain. Select this option if the Hub Transport or Edge Transport server should
accept the email, but relay it to another messaging organization in another AD DS forest. The
recipients in internal relay domain do not have mailboxes in this Exchange organization, but do have
contacts in the global address list (GAL). When messages are sent to the contacts, the Hub Transport
server or Edge Transport server forwards them to another SMTP server.

External Relay Domain. Select this option if the Hub Transport or Edge Transport server should
accept the email, but relay it to an alternate SMTP server. In this scenario, the transport server
receives the messages for recipients in the external relay domain, and then routes the messages to
the email system for the external relay domain. This requires a Send connector from the transport
server to the external relay domain.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-23

By default, only the forest root domain is established as an accepted domain. There are a number of
situations in which you may consider adding additional accepted domains. These include:

Additional namespaces. If you have additional domains within your forest, or more particularly,
additional treeswhich represent different namespacesyou may consider adding authoritative
domains for them. If you add an authoritative domain for an additional tree or domain within your
AD DS forest, you must also create an email address policy to support the domain.

Mergers and acquisitions. When your organization acquires another organization, you may decide to
configure an accepted domain to facilitate internal relay to the acquired organization.

External relay. You must configure an accepted domain to support external SMTP relay. Unlike
internal relay, where your Exchange Server organization routes messages to a Hub Transport server in
another AD DS forest, an external relay is to any SMTP host outside your organization. An ISP might
configure external relay for a customer.

Remote Domains
Remote domains define SMTP domains that are external to your Exchange Server organization. You can
create remote domain entries to define the settings for message transfer between the Exchange Server
2010 organization and domains outside your AD DS forest. When you create a remote domain entry, you
control the types of messages that are sent to that domain. You also can apply message format policies
and acceptable character sets for messages that are sent from your organizations users to the remote
domain. The settings for remote domains determine the Exchange Server organizations global
configuration settings.
You can create remote domain entries to define the mail transfer settings between the Exchange Server
2010 organization and a domain that is outside your AD DS forest. When you create a domain entry, you
provide a name to help the administrator identify the entrys purpose when they view configuration
settings.
The domain name is limited to 64 characters. You also provide the domain name to which this entry and
the associated settings will apply. You can use a wildcard character in the domain name to include all subdomains. The wildcard character must appear at the start of the domain name entry. The SMTP domain
name is limited to 256 characters.
The default settings may be suitable for most situations, but when you work with a partner organization,
you may choose to create a remote domain for their SMTP namespace, and configure specific settings
accordingly.

5-24

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Designing Message Throttling, Back Pressure, and Size Limits

Under certain situations, it might be beneficial to configure a number of Exchange Server features that
enable you to more accurately control message flow within your organization. These features are:

Message throttling. Message throttling is a group of limits that you can impose on the number of
messages and connections that a Hub Transport server or Edge Transport server can process. This
helps to prevent the accidental inundation of the system resources on the transport server.

Back pressure. Back pressure is a system resource monitoring feature of the transport service that
exists on Hub Transport and Edge Transport servers. Transport servers detect when vital resources
such as available disk spaceare under pressure, and take configured action to help to avoid service
unavailability.

Message size limits. Message size limits enable you to restrict the total size of a message, or the size of
the individual components of a messagesuch as the message header or message attachmentsand
the number of recipients. You can apply limits globally for the whole Exchange Server 2010
organization, or specifically for a particular connector or user object.

Message Throttling
Message throttling involves a variety of limits on message processing rates, SMTP connection rates, and
SMTP session time-outs. These limits combine to prevent the Hub Transport server or Edge Transport
server from being overwhelmed by accepting and delivering messages. Although a large backlog of
messages and connections may be waiting to be processed, the message throttling limits enable the
transport server to process the messages and connections in an orderly manner.
You can set the message throttling options on:

The transport server. Configuring message throttling options on the transport server affects only
those messages transiting that particular transport server.

A Send connector. This enables you to control message throttling for a specific Send connectorfor
example, to control message throttling to an internal relay domain.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-25

A Receive connector. This enables you to control message throttling for a specific Receive
connectorfor example, to control message flow from a partner organization.
Note In Exchange Server 2010 SP1, a running average delivery cost of messages sent by
specific users is maintained by transport servers. The delivery cost of a message is
determined by factors including to how many recipients it is addressed, and whether it has
large attachments. If a user often sends costly messages, Transport servers can give priority
to other messages with lower costs before processing messages from that user.
Transport servers also track the Remote Procedure Call (RPC) utilization of mailbox servers.
RPC sessions are established with mailbox servers when transport servers deliver messages
and when interactive client sessions occur. Excessive RPC utilization can result in a
downgraded client experience. If a Hub Transport server determines that a mailbox server is
under RPC resource pressure, it can reduce the RPC sessions that it opens to that mailbox
server. This can help to improve interactive client sessions on the mailbox server.

Back Pressure
In Exchange Server 2010, when a transport server is in back pressure, incoming connections are accepted;
however, the incoming messages over those connections are either accepted at a slower rate, or are
rejected. This differs from Exchange Server 2007. When an Exchange Server 2007 Hub or Edge Transport
server is under resource pressure, it rejects incoming connections.
For each monitored system resource on a Hub Transport server or Edge Transport server, the following
three levels of resource utilization are applied:

Normal. The resource is not being overused.

Medium. The resource is slightly overused, and back pressure is applied to the server in a limited
manner. Mail from senders in the authoritative domain can flow. However, depending on the specific
resource under pressure, the server uses tar-pitting to delay server response, or rejects incoming MAIL
FROM commands from other sources.

High. The resource is severely overused, and full back-pressure is applied. All message flow stops, and
the server rejects all new incoming MAIL FROM commands.

Back pressure monitors the following resources:

Free space on the message queue database hard disk drive. The high level of hard disk space
utilization is calculated by using the following formula:
100 * (hard disk size fixed constant) / hard disk size
In this formula, the fixed constant defaults to 500 megabytes (MB).

Free space on the message queue database transaction logs hard disk drive. By default, the high level
of hard disk utilization is calculated by using the following formula:
100 * (hard disk size - Max(5 GB, 3*DatabaseCheckPointDepthMax) / hard disk size
In this formula, DatabaseCheckPointDepthMax defaults to 512 MB.

The number of uncommitted message queue database transactions.

5-26

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

The memory that is used by the EdgeTransport.exe process. By default, the high level of memory
utilization by the EdgeTransport.exe process is calculated by using the following formula:
75 percent of the total physical memory or 1 terabyte, whichever is less

The memory that is used by all processes. By default, the high level of memory utilization by all
processes is 94 percent of total physical memory.

Message Size Limits

You can configure the scope of message size limits as follows:

Organizational limits. These limits apply to all Exchange Server 2010 and Exchange Server 2007
servers that exist in your organization.

Global limits. These limits apply to all Exchange Server 2010, Exchange Server 2007, and Exchange
Server 2003 servers that exist in your organization.

Connector limits. These limits apply to any messages that use the specified Send, Receive, or Foreign
connector for message delivery.

AD DS site links. Any messages that exceed the maximum message size limit on any AD DS site link
included in the least cost routing path are not delivered, and generate a delivery status notification
(DSN) that has the value 5.3.4.

Routing group connectors. Any messages that exceed the maximum message size limit on any routing
group connector in the least cost routing path will not be delivered; they will generate a DSN that has
the value 5.3.4.

Server limits. These limits apply to a specific 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-27

Troubleshooting Internal Message Delivery

Exchange Server 2010 provides several tools for troubleshooting SMTP message delivery.

Using the Exchange Server Best Practices Analyzer

The Exchange Server Best Practices Analyzer is a tool that you can use to check the Exchange server
configuration and health of your Exchange server topology. This tool automatically examines an Exchange
server deployment, and determines whether the configuration is in line with Microsoft best practices. You
should run the Best Practices Analyzer after you install a new Exchange server, upgrade an existing
Exchange server, or make configuration changes.

Using the Exchange Mail Flow Troubleshooter

The Exchange Mail Flow Troubleshooter tool assists Exchange Server administrators in troubleshooting
common mail-flow problems.
When you launch the Mail Flow Troubleshooter, you are prompted to select from the symptoms that
describe the message-flow issue. Based on the symptoms, the tool suggests a troubleshooting path. The
tool also shows an analysis of possible root causes, and provides suggestions for corrective actions.

Using the Queue Viewer

Like previous Exchange Server versions, messages waiting to be processed or delivered reside in message
queues on the Hub Transport servers. However, unlike Exchange Server versions before 2007, all message
queues reside in a local Exchange Server database on the server.The message queues provide a very useful
diagnostic tool to locate and identify messages that have not been delivered.
Exchange Server 2010 provides simplified queues. Hub Transport servers maintain five queues:

Submission queue. This queue contains messages that the Categorizer is processing.

Remote delivery queue. There is one queue for each outbound SMTP domain to which mail is routed.

Poison message queue. This queue contains messages that might have caused the server to crash.

5-28

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Mailbox delivery queue. There is one queue for each Mailbox server to which the Hub Transport server
can deliver messages.

Unreachable queue. This queue contains messages that cannot be routed to their destinations.

Using Message Tracking

You also can use message tracking to troubleshoot message flow. By default, message tracking is enabled
on Hub Transport servers, and all message-tracking logs are stored in the C:\Program
Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking folder. The message-tracking
logs are retained for 30 days, with a maximum size for all log files of 250 MB.
Exchange Server 2010 SP1 introduced a number of message tracking improvements:

Improved error messages for delivery reports. If a user attempts to access delivery reports for a
message immediately after sending it, it is possible that the tracking information for that message has
not yet been inserted into the logs with the result that the user cannot view the report. In this type of
situation, Exchange Server 2010 SP1 improves the message displayed to the user, providing specific
explanations as to why the requested information is not available.

Message tracking, monitoring, and troubleshooting. Exchange Server 2010 SP1 adds several new
monitoring capabilities for message tracking, including new event log entries, alerts, and performance
monitor counters.

Message tracking trace levels. You can now request complete logs of every operation that was
executed by a Client Access server processing a delivery report request. The additional logging detail
may be beneficial when troubleshooting message flow.

Using the Routing Log Viewer

You can use the routing log viewer to open a routing log file that contains information about how the
routing topology appears to the Exchange server. You can use this information when you troubleshoot
message routing within the organization or to the Internet. To use the Routing Log Viewer, start the
viewer from the Tools folder in Exchange Management Console, and then open the routing log files on a
specific server. You can open the current log file or previous ones.

Using Protocol Logging

You also can configure protocol logging to provide detailed information for troubleshooting message
flow. Protocol logging is enabled on the SMTP Send connector or SMTP Receive connector properties,
and the log files are stored in the C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs
\ProtocolLog folder.

Using Telnet
You can use Telnet to check if the SMTP port responds, or to directly send an SMTP mail to a connector to
see if the connector accepts it. Telnet is a Windows Server 2008 feature, and you use it from the
command line using the following syntax: telnet <servername> SMTP or Port #.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-29

Lesson 3

Designing the Message Routing Perimeter

Another important component in designing an Exchange Server 2010 organizations 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. As you plan the
message routing perimeter, you must consider all possible ways that messages may be sent outside the
Exchange Server organization.

Objectives
After completing this lesson, you will be able to:

Describe the default Edge Transport server configuration.

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.

Plan address rewriting.

5-30

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Default Edge Transport Server Configuration

It is important that you are familiar with the default configuration of Edge Transport servers. This enables
you to make an informed choice about whether you must reconfigure the Edge Transport server to
support the needs of your organization.

Transport Agents
The Edge Transport server supports the following transport agents:

Connection Filtering agent. This is an anti-spam agent that is enabled on Edge Transport servers.

Address Rewriting Inbound agent. This agent rewrites inbound email addresses.

Edge Rule agent. This agent provides compliance at the Edge Transport server.

Content Filter agent. This agent evaluates inbound email messages, and assesses the probability that
an inbound message is legitimate or spam.

Sender ID agent. This is an anti-spam agent that is enabled on Edge Transport servers. Sender ID helps
to combat the impersonation of a sender and a domain, a practice that is known as spoofing; a
spoofed mail is an email message that has a sending address that is modified to appear as if it
originates from a sender other than the actual sender of the message.

Sender Filter agent. This is an anti-spam agent that is enabled on Edge Transport servers. The Sender
Filter agent acts on messages from specific senders outside the organization. You can maintain a list
of senders that are blocked from sending messages to your organization. You can block single
senders ([email protected]), whole domains (*@.adatum.com), or domains and all subdomains
*@*.adatum.com).

Recipient Filter agent. This is an anti-spam agent that is enabled on Edge Transport servers. The
Recipient Filter agent blocks messages according to the characteristics of the intended recipient in the
organization.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-31

Protocol Analysis agent. Protocol logging records the SMTP conversations that occur between email
servers as part of message delivery.

Attachment Filtering agent. This agent lets you apply filters at the Edge Transport server to control the
attachments that users receive.

Address Rewriting Outbound agent. This agent rewrites addresses for outbound email.

Connectors
By default, until you establish an Edge subscription, there are no Send or Receive connectors on the Edge
Transport server. If you decide to create an Edge subscription, the necessary Send and Receive connectors
are created. This is discussed in more detail in the following topic.

Accepted Domains
There are no accepted domains configured by default. After you have established an Edge subscription,
you must configure accepted domains for your organization. These settings are synchronized with the
Edge Transport servers through the Edge subscription process. This is discussed in more detail in the
following topic.

5-32

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Designing Edge Subscriptions

You can subscribe an Edge Transport server to an AD DS site. This associates the Edge Transport server
with the Exchange Server organization. A subscribed Edge Transport server is stamped with an AD DS site
attribute, which means that you can configure the Edge subscription as a source server for Send
connectors that you create in the Exchange Server organization.
When you configure an Edge subscription, the configuration between the Exchange Server organization
and the Edge Transport server occurs automatically, and enables Internet message flow. After you
configure the Edge Subscription, the Edge synchronization process replicates the following data from AD
DS to Active Directory Lightweight Directory Service (AD LDS):

Accepted and remote domains

Recipients (Hashed)

Safe senders (Hashed)

Send connectors

Hub Transport server list (for dynamic connector generation)

Note A one-way hash is used on the recipients and safe senders information so that a
malicious user cannot retrieve it from the Edge Transport server.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-33

Considerations for Designing Edge Subscriptions

When designing Edge subscription, consider the following factors:

You can subscribe an Edge Transport server only to a single AD DS site. If you have multiple AD DS
sites through which you want to route Internet email, 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 servers 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 AD DS 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 then 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 a mail exchanger (MX) resource record for
each Edge Transport server in the DNS zone that is accessible from the Internet. Internet SMTP hosts
use DNS round-robin to distribute the load for incoming email. Additionally, the internal Hub
Transport servers distribute message flow between all available Edge Transport servers to loadbalance outbound message delivery. If one of the Edge Transport servers is not available, both
inbound and outbound email is sent through the available servers.

5-34

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

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 organizations requirements, you can deploy multiple Edge Transport servers with multiple SMTP
Send connectors to send Internet email.

Considerations for Designing Outbound Message Flow

When designing outbound message flow, consider the following issues:

Using a single location for routing all messages to the Internet, or enabling 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 choose one of the following options:

Install an Edge Transport server in each location, and configure Edge subscriptions between the
Edge Transport servers and the local AD DS 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.
Note Exchange Server 2010 does not fail over automatically to use an alternate connector
if one connector is unavailable. Each server running Exchange Server 2010 chooses a single
route for delivering messages to a specified recipient. If a connector is 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 Server organization, wait for AD DS
replication to update all organizational domain controllers, and restart the Microsoft
Exchange Transport service to force the Hub Transport servers to recalculate routing.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-35

Configuring the SMTP Send connectors. To enable outbound message flow, you must configure at
least one SMTP Send connector to send email 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 AD DS 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 might have additional requirements for Send
connectors. For example, you might need to configure unique message routing or message
security for a partner organization. You can configure an additional Send connector using the
organizations SMTP domain as the address space, and then configure the other Send connectors
properties.

Manually configure Send connectors for Internet email. If you do not use an Edge Transport
server, or if you do not want to use Edge synchronization, you must manually configure the Send
connectors. You can configure Send connectors in the Hub Transport servers to route email
directly to the Internet, to an SMTP gateway server, or to other smart hosts.

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 nameresolution services for the Edge Transport servers, rather than using internal DNS servers.

5-36

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Designing Inbound Message Flow

To enable message flow from the Internet, you must configure the Exchange Server organization with at
least one SMTP Receive connector that will accept anonymous SMTP connections from Internet SMTP
servers. Depending on your organizations requirements, you can deploy multiple Edge Transport servers
with multiple SMTP Receive connectors to receive Internet email.

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 then configure Edge subscriptions
between the Edge Transport servers and the local AD DS 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 with 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 servers 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 email. All Hub Transport servers also are configured
with a Receive connector. However, this connector only accepts authentication connections.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-37

If you configure 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.

5-38

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Designing Message Routing to the Perimeter

In addition to planning a message routing topology inside the Exchange Server organization, you also
need to plan a message routing topology for messages sent to recipients outside the Exchange Server
organization. To do this, you must understand how Exchange Server 2010 selects a route for outbound
messages, and how to optimize this configuration.

How Exchange Server 2010 Routes Messages to the Network Perimeter

For Exchange Server 2010 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 AD DS 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 AD DS
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 namespace that meets the routing requirements
for an external recipient, Exchange Server 2010 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 3 MB size limit, it will not be considered for sending a message with a 4 MB
attachment. A disabled connector is not selected for sending messages.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-39

From the remaining connectors, select the connectors with the most specific address space match. For
example, if you configure one Send connector with the address space *.contoso.com, and a second
connector 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 connectors
cost is determined by adding the cost of the IP site links between the source site and the AD DS 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 AD DS site, while a server in the local AD DS
site is chosen over a source server in a remote AD DS 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
2010 uses deterministic routing for messages sent outside the organization. Exchange
Server 2010 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 AD DS site. When a scope is applied to a
Send connector, it is visible to only the Hub Transport servers in the AD DS 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
connectors scope to an AD DS site, you run the following command: Set-SendConnector identity Connectorname -AddressSpaces local:*.

Considerations for Designing Message Routing to the Network Perimeter

For all organizationsincluding those with a single AD DS siteif 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.

Whether to configure Edge subscriptions between the Edge Transport server and the AD DS site.

Both of these options are highly recommended to provide maximum security and administrative ease.
If your organization has multiple AD DS sites, you also should consider the following factors:

Consider whether you want to implement a single path for routing messages to the Internet, or
whether you want to implement multiple paths. The greatest advantage of a single route is security.
You need to 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.

5-40

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

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 2010 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 AD DS site that can route
messages to the Internet, use the same considerations that you used for planning internal message
routing between AD DS sites.

Use the connector scope to control whether messages sent to recipients outside the organization are
sent between AD DS sites. For example, if you have two company locations that have Internet
connections, but are connected by a wide area network (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 WAN link.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-41

Planning Address Rewriting

Address rewriting enables you to modify the addresses of originators or recipients in your Exchange
Server organization. Generally, you use address rewriting to present a consistent interface to
correspondents that are external to your organization.
There are a number of specific reasons why you might consider address rewriting.

Group consolidation. If your organization segments its internal business into separate domainsfor
technical or business reasonsthis would typically cause email to appear to originate from separate
organizations. For example, in the domains Asia.Adatum.com, Europe.Adatum.com, and
Americas.Adatum.com, address rewriting could be used to ensure that email appears to come from a
single domainAdatum.com.

Mergers and acquisitions. If you recently acquired a new company, it will have a different namespace
from your current organization. If you want email that originates in the acquired organization to
appear to come from your own organization, you could implement address rewriting.

Partners. If you use partner organizations to provide services or to manage projects, you can use
address rewriting. For example, if you outsource the launch of a new product to a marketing
company, it may be useful to implement address rewriting so that messages originating in the partner
organization have addresses from your own organization.

Considerations for Address Rewriting

It is important to note that there are a number of considerations for address rewriting.

Outbound-only address rewriting. When an email message is outbound from your Exchange
organization, outbound-only address rewriting involves modification of only the sender SMTP
address. You can configure the Address Rewriting agent only on the Send connector on the Edge
Transport server. The following list shows the conditions that are required to configure an outboundonly Address Rewriting agent:

5-42

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

The resulting addresses must be unique across the organization. For example, if you include the
unique email addresses [email protected] [email protected] in a rule to rewrite all
addresses to adatum.com, the Address Rewriting agent rewrites both addresses to
[email protected], and causes a conflict. When such a conflict occurs, you must change the email
address of one of the recipient mailboxes to an address that does not conflict with the email
address in any other subdomain.

You must configure a proxy address on each mailbox that matches the rewritten email address.
This enables those mailboxes to receive replies to email messages in which headers are rewritten.

When you use wildcard characters, there must be a period between the wildcard character and
the domain name.

You can use wildcard characters only in the internal domain.

No characters can be in front of the wildcard character.

Outbound-only address rewriting cannot affect the part of the address with the user name or
display name.

Only literal strings are supported.

Bidirectional address rewriting. Bidirectional address rewriting modifies both the sender SMTP address
on email messages that leave your Exchange Server organization, and the recipient SMTP address on
email messages that enter your Exchange Server organization. To do this, you configure the Address
Rewriting agent on both the Send connector and Receive connector on the Edge Transport server.
The following list shows the conditions that are required when you create a bidirectional Address
Rewriting agent:

You cannot use wildcard characters.

You must use full SMTP addresses when you configure a bidirectional address rewriting rule. For
example, the internal address is [email protected], and the external address is
[email protected].

Only literal strings are supported.

The address must be unique across the organization. For example, if an

email address such as [email protected] already exists, mapping [email protected] to
[email protected] will cause replies to messages from [email protected] to be delivered to the
wrong person.

Priority of address rewriting entries. The rule that best matches the internal and external domain pair is
applied. The following prioritization is the exact order of address rewriting entries from highest
priority to lowest priority:

Individual email addresses. For example, mapping [email protected] to [email protected].

Specific domain or sub-domain mapping. For example, mapping Adatum.com to Contoso.com or

Sales.Adatum.com to Adatum.com.

Domain flattening. For example, flattening *.adatum.com into Adatum.com.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-43

Digitally signed, encrypted, or rights-protected email. Address rewriting should not affect most signed,
encrypted, or rights-protected messages. If address rewriting were to invalidate a signature, make an
encrypted or rights-protected message unreadable, or otherwise change the security status of such
messages in any way, address rewriting is not applied. Addresses and information in the following
message sections can be rewritten, because information in these sections is not part of message
signing, encryption, or rights protection:

SMTP envelope fields

Top-level message body headers

Addresses and information in the following message sections is not rewritten, because information in
these sections is part of message signing, encryption, or rights protection:

Headers located inside MIME body parts that may be signed

The boundary string parameter of the MIME content type

5-44

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Lab: Planning and Deploying Message Transport in

Exchange Server 2010

Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, you must:
1.

On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, 10233B-VAN-EX2, and the 10233B-VAN-EDG

virtual machines are running.

3.

If required, connect to the virtual machines. Log on to the virtual machines as

Adatum\Administrator using the password Pa$$w0rd.

4.

Log on to 10233B-VAN-EDG as Administrator using the password Pa$$w0rd

Lab Scenario
You are a messaging engineer for A. Datum Corporation, an enterprise-level organization with multiple
locations.
You have been tasked with designing the new routing infrastructure for your organization. You must
examine the documentation that details the existing infrastructure, and then make proposals regarding
any changes you might need to make to address the organizations needs. You must also document your
proposals.
Finally, use various Exchange Server management tools to investigate the current routing topology, and
make some changes.
Note Your instructor may choose to perform this lab as a group discussion rather than an
individual activity.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-45

AD DS and Routing Interview Notes.doc

Tzipi Butnaru, Directory Services Manager
The company just finished upgrading all of the AD DS domain controllers to Windows Server 2008,
Service Pack 1 (SP1). The company has indicated that there is not enough budget for any further AD DS
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 projects budget is in jeopardy. Any input you could provide to this decision would be appreciated
greatly.

Andreas Herbinger, 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 (GAL), 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, Vancouver, 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 email for Trey Research. 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 Office Outlook Web Access. We would really
like to make sure that the experience for the Outlook Web App users is as positive as possible.

Shane DeSeranno, 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 SMTP traffic uses. In your design, you need to make sure that
email messages always are sent through the network connections that have the highest bandwidth. Also,
make sure that you take advantage of any other way that you can save bandwidth that email uses.
We are just taking over managing the network in San Diego, 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.

Jason Carlson, Network Specialist

Our department is responsible for the companys firewall configurations. With every company location
having its own Internet connection, this can be a real challenge. Right now, we are allowing Hypertext
Transfer Protocol Secure (HTTPS) access to some Exchange Servers in London, Vancouver, and Tokyo. This
configuration is working okay, but we do not want to open up any more messaging ports in any location.
Additionally, we are currently 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 we would need to know that the email messages are being scanned for viruses
and spam in all locations where we allow SMTP traffic.

5-46

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Adatum_Info.vsd (WAN Links)

Adatum_CurrentADSiteDesign.vsd

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-47

Adatum_CurrentPerimeterDesign.vsd

5-48

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Exercise 1: Designing a Message Routing Topology

Scenario
In this exercise, you will design a message routing topology for the A. Datum Exchange organization.
To complete this exercise, review the existing A. Datum Corporation documentation:

Interview notes from meetings with various A. Datum Corporation personnel.

Microsoft Office Visio diagrams describing the A. Datum Corporation site topology.

The main tasks for this exercise are as follows:

1.

Review the A. Datum Corporation documentation.

2.

Modify the A. Datum Current AD DS Site Design diagram with proposed changes to the site design.

Task 1: Review the A. Datum Corporation documentation

Review the contents of the following files:

AD DS and Routing Interview Notes.doc

Adatum_CurrentADSiteDesign.vsd

Adatum_Info.vsd

Task 2: Modify the A. Datum current AD DS site design diagram with proposed
changes to the site design
1.

Use callouts in the following diagram to document proposed changes to the site design. For each
proposed change, provide:

The proposed change.

A rationale for the proposed change.

2.

Indicate which server roles need to be deployed in each AD DS site.

3.

Document message flow within the organization. Document the changes that you will need to make
to the AD DS configuration to enable optimal message flow.
Note

Be prepared to discuss your proposed design with the class.

Results: After this exercise, you should have successfully modified the A. Datum AD DS site design.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-49

Exercise 2: Designing a Messaging Perimeter

Scenario
In this exercise, you will design a message perimeter for the A. Datum Exchange organization.
To complete this exercise, review the following A. Datum Corporation documentation:

Interview notes from meetings with various A. Datum personnel

Office Visio diagrams describing the A. Datum network perimeter configuration

The main tasks for this exercise are as follows:

1.

Review the A. Datum Corporation documentation.

2.

Modify the A. Datum Current Perimeter Design diagram with proposed changes to the site design.

Task 1: Review the A. Datum Corporation documentation

Review the contents of the following files:

AD DS and Routing Interview Notes.doc

Adatum_CurrentPerimeterDesign.vsd

Adatum_Info.vsd

Task 2: Modify the A. Datum current perimeter design diagram with proposed
changes to the site design
1.

Use callouts in the following diagram to document proposed changes to the perimeter design. For
each proposed change, provide:

The proposed change.

A rationale for the proposed change.

2.

Indicate whether you need to deploy any additional server roles in each AD DS site.

3.

Indicate the required firewall changes to meet your design requirements.

4.

Indicate any other infrastructure changes that you must implement to meet your design
requirements.

5.

For each company location, document how messages are delivered to the Internet, and how inbound
messages are delivered to internal recipients.
Note

Be prepared to discuss your proposed design with the class.

Results: After this exercise, you should have successfully designed the A. Datum messaging perimeter.

5-50

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Exercise 3: Discussion: Improving an AD DS and Message Routing Design

Scenario
In this exercise, you will present your design decisions from the previous two exercises, and discuss your
recommendations.

Task: Discuss as a class, and then answer the following questions

Question: What changes did you make to the AD DS site configuration and the
organizations message routing?

Question: If your recommended changes are implemented, how will messages flow between
the AD DS sites? Where will messages be queued in the event of a server or network
connection failure?

Question: How did you design message routing to the Internet?

Question: What conflicting requirements were presented in the scenario? How did you
resolve conflicting requirements?

Question: What additional information should you consider when designing message
routing in this scenario?

Results: After this exercise, you should have successfully improved the A. Datum AD DS and message
routing design.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-51

Exercise 4: Modifying the Routing Topology

Scenario
A. Datum Corporation has a partner organization, Contoso, Ltd based in New York. You must make some
configuration changes to the routing infrastructure to support messaging to the partner organization. In
this exercise, you will investigate the current routing topology, and then make some configuration
changes.
The main tasks for this exercise are as follows:
1.

Determine the current organizational settings.

2.

Examine the current routing topology.

3.

Add a new accepted domain.

4.

Configure a send connector to support the new accepted domain.

5.

Update the default site configuration with Exchange Server-specific values.

6.

Add an Edge Subscription.

7.

Review the updated topology.

Task 1: Determine the current organizational settings

1.

On VAN-EX1, open the Exchange Management Console.

2.

Browse to the Organization Configuration, and view the Send Connectors tab in the Hub
Transport node.
Question: Have any connectors been configured?

Question: Has an Edge Subscription been defined?

Task 2: Examine the current routing topology

1.

From the Toolbox, open Routing Log Viewer.

2.

Use the File menu to open the most recent routing table file.

3.

Use the various tabs to answer the following questions:

Question: Is Default-First-Site-Name a hub site?

Question: What is the AD DS cost of the link to VAN-EX1.Adatum.com?

Question: What Send Connectors are listed?

Question: What Address Spaces are listed?

4.

Close Routing Log Viewer.

5-52

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Task 3: Add a new accepted domain

From Organization Configuration, in the Hub Transport node, create a new Accepted Domain with
the following properties:

Name: Contoso

Domain name: Contoso.com

Type: External Relay Domain

Task 4: Configure a Send connector to support the new accepted domain

From Organization Configuration, in the Hub Transport node, create a new Send Connector with the
following properties:

Name: Contoso Connector

Intended use: Partner

Address: Contoso.com

Include all subdomains: Yes

Cost: 10

All other settings: default values

Task 5: Update the default site configuration with Exchange Server-specific values
1.

Open the Exchange Management Shell.

2.

At the Shell, type the following command, and then press Enter.
set-AdSite id Default-First-Site-Name HubSiteEnabled $true

3.

At the Shell, type the following command, and then press Enter.
set-AdSiteLink id DEFAULTIPSITELINK ExchangeCost 25

4.

Close the shell.

Task 6: Add an Edge subscription

1.

Switch to VAN-EDG.

2.

Open the Exchange Management Shell.

3.

At the Exchange Management Shell, type the following command, and then press Enter
new-edgesubscription filename C:\EdgeSubscriptionExport.xml.

4.

When prompted, type Y, and then press Enter.

5.

At the Exchange Management Shell, type the following command, and then press Enter.
copy c:\EdgeSubscriptionExport.xml \\VAN-EX1\c$

6.

Switch to VAN-EX1.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-53

7.

Create a new Edge Subscription with the following properties:

Site: Default-First-Site-Name

Subscription file: C:\EdgeSubscriptionExport.xml

Other settings: default values

Note

You may receive a warning. This is expected.

Task 7: Review the updated topology

1.

Open Routing Log Viewer from the Toolbox.

2.

Use the File menu to open the most recent routing table file.

3.

Use the various tabs to answer the following questions:

Question: Is Default-First-Site-Name a hub site?

Question: What SMTP Send Connectors are listed?

Question: What SMTP Address Spaces are listed?

Question: What is the connector cost for the Contoso Connector?

4.

Close the Routing Log Viewer.

Results: After this exercise, you should have modified the message routing topology.

To prepare for the next module

When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the
following steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EDG. Close the virtual
machine connection windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then in the Actions pane, click Start.

5-54

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then in the
Actions pane, click Connect.
Important Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully
started before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10233B-VAN-EX1. Connect to the virtual machine.

8.

Wait for 10233B-VAN-EX1 to start, and then start 10233B-VAN-CL1. Connect to the virtual machine.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 5-55

Module Review and Takeaways

Review Questions
1.

In which folder are the routing table logs stored?

2.

When would you consider implementing Exchange Server-specific routing costs?

3.

When you add an accepted domain for other than your forest root domain, what else must you
configure in order for recipients within your organization to receive email using the new accepted
domain?

5-56

Planning and Deploying Message Transport in Microsoft Exchange Server 2010

6-1

Module 6
Planning and Deploying Messaging Security
Contents
Lesson 1: Designing Message Security

6-3

Lesson 2: Designing Antivirus and Anti-Spam Solutions

6-16

Lab: Planning and Deploying Messaging Security

6-32

6-2

Planning and Deploying Messaging Security

Module Overview

A critical consideration when designing a Microsoft Exchange Server 2010 messaging solution is
ensuring that the messaging system is as secure as possible. This includes planning for message security,
which ensures that messages sent within the organization, and to and from the Internet, meet the
organizations compliance and security requirements. A second consideration for planning the security is
implementing an antivirus and anti-spam solution that prevents malicious emails from entering the
Exchange Server organization.

Objectives
After completing this module, you will be able to:

Design message security.

Design antivirus and anti-spam solutions.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-3

Lesson 1

Designing Message Security

Designing message security is an essential part of designing security for your Exchange Server 2010
organization. Exchange Server 2010 provides several features, such as transport rules, Simple Mail Transfer
Protocol (SMTP) connector security, and Domain Security to provide message-level security.

Objectives
After completing this lesson, you will be able to:

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.

6-4

Planning and Deploying Messaging Security

Defining Message Security Requirements

In most organizations, email is a primary tool for exchanging business information, and many business
processes depend upon it. However, SMTP email is not secure because SMTP message contents are not
encrypted or validated. This means that your confidential information potentially may be exposed
through email.
To plan for your organizations messaging security, you first need to understand what types of data your
organization is sending through email, and how you are currently securing those messages.

Analyze Email Message Contents

To collect information about email message contents, you should ask the following questions:

Is confidential business information sent via email? This information may include confidential
corporate documentation such as sales projections, salary information, trade secrets, or intellectual
property.

Is private customer information sent by email? If your organization uses email to exchange
information with customers, you need to analyze the type of information that you are exchanging.
Some informationsuch as customer queries or ordersmay be confidential. If this information
becomes public, the organizations reputation may suffer. Additionally, if the customer information
includes private information such as social security numbers or transactional information, your
organization may be legally liable.
Note It might also be important that recipients of messages can ensure that messages
were not tampered with during transit.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-5

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 email sent externally? In most
cases, confidential corporate information is sent to other internal users. However, those users may be
forwarding the information to external email addresses. In some organizations where users do not
have external email access, they may send email to an external email addresssuch as to personal
accountto enable them to work outside the office. Customer information is almost always sent
outside the organization.

Are confidential emails sent primarily to a limited number of external organizations, or to a variety of
recipients? If confidential emails are sent to external recipients, you need to understand where those
messages are going. In some cases, confidential email may be sent primarily to one or two partner
organizations. For example, a law firm may exchange confidential emails with large corporate clients.
In other cases, the confidential emails may be sent to thousands of recipients in many different
locations.

Analyze Current Security Mechanisms

Most organizations have some level of Internet email security. In some cases, organizations use corporate
policies to try to restrict what messages are sent to the Internet. For example, an organization might
implement a policy that prohibits email that is sent to customers, from including the customers social
security number, credit card number, or other personal information. Some organizations incorporate
technical solutions to enable email securitysuch as Secure/Multipurpose Internet Mail Extensions
(S/MIME), Pretty Good Privacy (PGP), or secure network connections.
Organizations that secure email by using policies or technical solutions should analyze the effectiveness
and satisfaction with their current solution by asking the following questions:

Are users complying with email usage policies?

If the organization policy requires that all customer emails with confidential information be secured
using Secure/Multipurpose Internet Mail Extensions (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
organizations needs.

6-6

Planning and Deploying Messaging Security

Designing Restrictions to Message Flow

One of the options for providing message security is to implement restrictions on what messages users
can receive and send out of the organization. Exchange Server 2010 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 Domain Services (AD DS) stores, and which are applied
on all Hub Transport servers in the Exchange Server 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 organizations 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, you might be required to 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-7

Implementing Edge Transport rules. Edge Transport rules are similar to Hub Transport rules except
that the Edge Rules agentwhich runs on the Edge Transport serverenforces 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 Lightweight Directory Services (AD LDS) 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 a feature that enables users to set a classification on a message.
Message classifications can be found in Exchange Server 2010, Microsoft Office Outlook 2007, Microsoft
Office Outlook 2010, and Outlook Web App. The message classification contains specific metadata that
describes the messages 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 Outlook 2007, Office Outlook 2010, and Outlook Web
App. 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 of the message classification options is the Attorney-Client Privileged (A/C Privileged) message
classification. The A/C Privileged message classification is one of two default message classifications that
Exchange Server 2010 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 can then 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.

6-8

Planning and Deploying Messaging Security

Exchange Server 2010 includes two default message classifications, but you can configure additional ones.
Before Office Outlook users can set and view message classifications, you must deploy the message
classification configuration files and create an Office Outlook registry key on the end users computers.
The Office Outlook message classification templates are XML files that you must generate after you create
and configure the message classifications.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-9

Designing SMTP Connector Security

Another option for securing email 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 email accept anonymous connections, and do not require
message encryption.

Options for Providing SMTP Connector Security

To provide additional security for SMTP email, you can use the following options:

Configure authentication for SMTP receive connectors. If you enable authentication for Receive
connectors, you can restrict the users or other SMTP servers that can establish an SMTP connection to
the Receive connectors for sending email.
Note Bear in-mind that enabling authentication on a receive connector could disrupt
normal SMTP email communications if that connector is used to accept email from the
Internet.

Configure authentication for SMTP send connectors. When you configure authentication on a Send
connector, you configure your SMTP server to use authentication when sending messages to another
server. If the authentication fails, the message is not delivered.
When configuring SMTP Send connectors that use a smart host, you must configure authentication to
match the method used by the smart host. You can select between the following authentication
mechanisms:

None. Select this option if you want an anonymous connection. This is quite common for
connectors used to support mail flow to and from the Internet.

6-10

Planning and Deploying Messaging Security

Basic Authentication. Basic authentication requires that you provide a user name and password.
We strongly recommend that you use an encrypted connection if you use basic authentication,
because the user name and password are sent in clear text. Select the Basic Authentication over
TLS check box to enable encryption on the connection.

Exchange Server Authentication. Select this option to authenticate by using an Exchange

Server authentication mechanism, such as Transport Layer Security (TLS) direct trust or
TLS\Kerberos.

Externally Secured. Select this option if the connection is secured by external means, such as
being physically secured over a private network, or secured using Internet Protocol security
(IPsec).

When configuring SMTP Receive connectors, you can select between the following authentication
mechanisms:

TLS. When you select this option, the STARTTLS keyword is advertised in the EHLO response to
connecting SMTP servers, and TLS authentication is accepted.

Domain Security. There are additional configuration steps required before you can enable
mutual TLS, which is required for Domain Security.

Basic Authentication. When you select Basic Authentication, the AUTH keyword is advertised in
the EHLO response to connecting SMTP servers, and Basic authentication is accepted. Because
the user name and password are sent in clear text when Basic authentication is used, you should
not use Basic authentication without encryption.

Offer Basic Authentication only after starting TLS. When you select this option, the connector
starts TLS first, and then after TLS encryption completes, the connector offers Basic
authentication.

Exchange Server authentication. Select this option to authenticate by using an Exchange Server
authentication mechanism, such as TLS direct trust or Kerberos through TLS.

Integrated Windows authentication. Select this option to use Integrated Windows

authentication, which represents NTLM, Kerberos, and Negotiate authentication mechanisms.

Externally Secured. Use this option if the incoming connections to this Receive connector are
secured by external means. When you select this option, you make an assertion of external
security that cannot be programmatically verified by Exchange Server. Before you select this
authentication method, you must first select the Exchange Server permissions group on the
Permission Groups tab.

Use the Permission Groups tab to select the permission groups assigned to the Receive connector. A
permission group is a predefined set of permissions granted to well-known groups of users,
computers, or security groups. Members of the selected permission groups on this tab are allowed to
submit messages to this Receive connector.
The following options are available on the Permission Groups tab:

Anonymous users

Exchange users

Exchange

Legacy Exchange servers

Partners

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-11

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 email 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
organizations SMTP server, and require authentication. If you use basic or Integrated Windows
authentication, you must 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 is encrypted.

You might need to configure authentication on a Send connector to meet another organizations
security requirements. If the other organization requires authentication, configure the Send connector
to use the other organizations SMTP server as a smart host, and then use the user credentials
provided by the other organization or TLS to authenticate the SMTP session.

TLS encryption ensures that authentication credentials and email 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 sends email to your organization. Normally, this requires 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. For example,
you could use a virtual private network (VPN) or a dedicated network connection between two
companies, or you could use IPsec to secure the message transfer. This option treats all email
messages sent through this connection as authenticated, rather than anonymous.

In most cases, you need to configure new SMTP connectors to support authentication and encryption.
To send and receive email 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 email 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.

6-12

Planning and Deploying Messaging Security

Designing Secure Message Routing Between Partner Organizations

In addition to configuring the SMTP connectors to enhance message security between partner
organizations, you can use the Domain Security feature in Exchange Server 2010 to provide extra security
and functionality.

How Domain Security Works

You can use Domain Security to manage secured message paths over the Internet for use with business
partners. After you configure these secured message paths, messages sent over the paths from an
authenticated sender display to users in the Office Outlook and Outlook Web App interfaces as Domain
Secured.
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 servers 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 CA that your organization owns and manages, or from a commercial CA.
Regardless of the CA you choose, the SMTP servers in the partner organization that you exchange
messages with 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-13

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 email 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
host 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 email.

3.

Configure outbound Domain Security. To configure outbound Domain Security, use Exchange
Management Shell commands to specify the domains to which you send domain-secured email, and
then configure the SMTP Send connector to use domain-secured email.

4.

Configure inbound Domain Security. To configure inbound Domain Security, use Exchange
Management Shell commands to specify the domains from which you receive domain-secured email,
and then configure the SMTP Receive connector to use domain-secured email.

5.

Test domain-secured mail flow. After you configure domain-secured email, 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.

6-14

Planning and Deploying Messaging Security

Designing Client-Based Messaging Security

Exchange Server 2010 supports client-based solutions for providing messaging security. Exchange Server
2010 supports both S/MIME and Rights Management Service (RMS).

Using S/MIME to Secure Email Messages

One of the client-based solutions for providing message security is S/MIME. S/MIME uses digital
signatures and message encryption to provide message-level authentication, non-repudiation, data
integrity, and message encryption.
Although S/MIME provides a very high level of security for SMTP messages, there are several issues that
can complicate an S/MIME implementation:

You must install a certificate on each client computer to enable email security. You need to plan for
certificates due to the following factors:

Certificate distribution. Because each client computer that sends or receives email by using
S/MIME must have a certificate, you must develop a plan for distributing certificates.

Certificate trust. You typically use S/MIME to secure email 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 recipients public key. This means that the message recipient must have a digital certificate,
and must provide the certificate with the senders public key. One method of distributing the
public key is to send a digitally signed email. This manual process of distributing public keys
makes the entire process cumbersome.

Note Consider that it is possible to use AD DS for distributing public keys.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-15

Certificate and private key backups. If a user ever loses the private key associated with their
computers certificate, the user will not be able to decrypt messages that were encrypted with the
public key that is 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 2008, and integrating the CA with AD DS. 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, it is not
possible to scan the messages for policy compliance, viruses, or spam.

Despite the limitations, S/MIME is the best option for securing email 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.

Using AD RMS to Secure Email

Active Directory Rights Management Services (AD RMS) for Windows Server 2008 is a technology that
works with RMS-aware applications such as Office Outlook to protect documents and email 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 AD RMS role on a server computer
running Windows Server 2008. All RMS clients must use RMS-aware applications, such as Office Outlook
2003 or a newer version.
RMS is a useful solution for implementing message security for internal users who use Office Outlook
2003 or a newer version to read email. However, implementing RMS for external users and customers is
more difficult, because the client computers must be able to connect to the AD RMS server to obtain
a certificate that enables reading RMS-protected content. Therefore, Outlook Anywhere users will not be
able to access RMS-protected email while offline, and Outlook Web App and external users will be able to
access these messages only if you make an RMS server Internet-accessible.

6-16

Planning and Deploying Messaging Security

Lesson 2

Designing Antivirus and Anti-Spam Solutions

Viruses and spam can inflict significant damage on an organization. Therefore, the spam and virus filtering
solution you design is a critical component to consider when you are designing message security for an
Exchange organization.

Objectives
After completing this lesson, you will be able to:

Describe the requirements for an antivirus and anti-spam solution.

Identify the options for implementing antivirus and anti-spam solutions in Exchange Server 2010.

Design an anti-spam solution.

Describe the recommendations for monitoring an anti-spam solution.

Design antivirus solutions.

Manage antivirus solutions.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-17

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 Server administrator, you must be constantly aware of attempts to have
malicious email enter your organization. To design an effective anti-spam and antivirus solution, you
should be familiar with the new techniques that spammers and malicious virus writers use.

Requirements for Spam and Virus Filtering Solutions

Many organizations have standard requirements for spam and virus filtering solutions. When evaluating
these solutions, you should consider the following critical factors:

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 you update your antivirus software before the
virus enters your organization. If you discover a new phishing scheme, it is important that you update
your anti-spam filters to block the phishing emails.

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 chances 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 email 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.

6-18

Planning and Deploying Messaging Security

What options does the solution provide for quarantining potentially malicious messages? This is
particularly important for anti-spam solutions, because this is the 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 2010 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 organizations individual recipients without
necessitating management of two separate directories? Does the solution integrate with your
administrative model so that you can assign permissions easily using existing administrative groups to
manage and monitor the system?

You also should document any unique requirements that your organization may have. For example, if
users are using S/MIME frequently to send encrypted email that spam or virus filters cannot scan, you may
need to explore other options for scanning 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 and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-19

Options for Implementing Antivirus and Anti-Spam Solutions in

Exchange Server 2010

Malicious senders or spammers may use a variety of methods to attempt to send malicious email or spam
into your organization. Therefore, no single tool or process can eliminate all malicious email or spam.
Exchange Server 2010 includes a variety of anti-spam and antivirus features that are designed to work
cumulatively to reduce the spam that enters your organization.
You can reduce the number of virus outbreaks and attacks by malicious software in your organization if
you are able to preventor at least reduce the quantity ofspam messages entering your organization.
By implementing antivirus and anti-spam tools at the perimeter network on the server configured with
the Edge Transport role, you can ensure a healthy message stream from the Internet.
Exchange Server 2010s transport architecture provides a number of antivirus and anti-spam solutions that
are implemented as a series of layers. The anti-spam and antivirus filters are applied in the following
order:

Connection filtering. The Connection filter inspects the IP address of the remote server that is trying
to send the message, to determine what action to take on an inbound message. Connection filtering
uses a variety of IP Block lists, IP Allow lists, and IP Block Providers services or IP Allow Provider
services to determine whether the connection from the specific IP should be blocked or allowed in
the organization.

Sender filtering. The Sender filter compares the sender on the MAIL FROM: SMTP command to an
administrator-defined list of senders or sender domains that are prohibited from sending messages to
the organization, to determine what action to take on an inbound message.

Recipient filtering. The Recipient filter compares the message recipients on the RCPT TO: SMTP
command to an administrator-defined Recipient Block list. If a match is found, the message is
not permitted to enter the organization. The recipient filter also compares recipients on inbound
messages to the local recipient directory to determine whether the message is addressed to valid

6-20

Planning and Deploying Messaging Security

recipients. When a message is not addressed to valid recipients, the message can be rejected at the
organization's network perimeter.

Sender ID. Sender ID is intended to combat the impersonation of a sender and a domain, a practice
that's frequently called spoofing. A spoofed mail is an email message with a sending address that was
modified to appear as if it originates from a sender other than the actual sender of the message.
Spoofed mails typically contain a From: address that appears to be from a certain organization. In the
past, it was relatively easy to spoof the From: address, in both the SMTP session, such as the MAIL
FROM: header, and in the RFC 822 message data, such as From: "Jo Berry" [email protected], because
the headers were not validated.
In Exchange Server 2010, Sender ID makes spoofing more difficult. When you enable Sender ID, each
message contains a Sender ID status in the metadata of the message. When an email message is
received, the Edge Transport server queries the sender's DNS server to verify that the IP address from
which the message was received is authorized to send messages for the domain that is specified in
the message headers. The IP address of the authorized sending server is referred to as the purported
responsible address (PRA).
Domain administrators publish sender policy framework (SPF) records on their DNS servers. SPF
records identify authorized outbound email servers. If an SPF record is configured on the sender's
DNS server, the Edge Transport server parses the SPF record and determines whether the IP address
from which the message was received is authorized to send email on behalf of the domain that is
specified in the message.
The Edge Transport server updates the message metadata with the Sender ID status based on the SPF
record. After the Edge Transport server updates the message metadata, the Edge Transport server
delivers the message as it ordinarily would. PRA is calculated based on the following message
headers:

Resent-Sender:

Resent-From:

Sender:

From:

Content filtering. The Content filter uses Microsoft SmartScreen technology to assess the contents
of a message. Based on the characteristics of millions of messages, Intelligent Message Filterthe
underlying technology in content filteringrecognizes indicators of both legitimate messages and
spam messages. Intelligent Message Filter can accurately assess the probability that an inbound email
message is either a legitimate message or spam.
Note Content filtering also acts on the safelist aggregation feature. Safelist aggregation
collects data from the anti-spam safe lists that Office Outlook and Outlook Web App users
configure, and makes this data available to the Content Filter agent on the computer that
has the Exchange Server 2010 Edge Transport server role installed. When an Exchange
Server 2010 administrator enables and correctly configures safelist aggregation, the Content
Filter agent passes safe email messages to the enterprise mailbox without additional
processing. Email messages that Office Outlook users receive from contacts, or contacts
added to their Outlook Safe Senders List, or have trusted, are identified by the Content
Filter agent as safe. The result is that messages that are identified as safe are not classified as
spam and unintentionally filtered out of the messaging system.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-21

Sender reputation. The Sender Reputation filter relies on persisted data about the IP address of the
sending server to determine what actionif anyto take on an inbound message. The Protocol
Analysis agent is the underlying agent that implements the sender reputation functionality. A sender
reputation level (SRL) is calculated from several sender characteristics that are derived from message
analysis and external tests. Senders whose SRL exceeds a configurable threshold are temporarily
blocked, and all their future connections are rejected for up to 48 hours.
In addition to the locally calculated IP reputation, Exchange Server 2010 also takes advantage of the
IP Reputation Service anti-spam updates, which are available through Microsoft Update. These
updates provide sender reputation information about IP addresses that are known to send spam.

Attachment filtering. The Attachment filter filters messages based on the attachment file name, file
name extension, or file Multipurpose Internet Mail Extension (MIME) content type. You can configure
attachment filtering to block a message and its attachment, to strip the attachment and allow the
message to pass through, or to delete the message and its attachment without notifying the
recipient.

Forefront Protection 2010 for Exchange Server. Microsoft Forefront Protection for Exchange Server
is an antivirus software package that is tightly integrated with Exchange Server 2010, and offers
antivirus protection for the Exchange Server environment.

Outlook Junk Email filtering. The Outlook Junk Email filter uses state-of-the-art technology to
evaluate whether a message should be treated as a junk email message based on several factors.
These factors include: time that the message was sent; content and structure of the message; and
metadata collected by the Exchange Server anti-spam filters. Messages caught by the filter are moved
to a special Junk Email folder where the recipient can access them later.
The messages that can reach a users Outlook Junk Email folder is determined by the spam
confidence level (SCL) threshold configured at the Exchange organizational level. By adjusting the SCL
threshold configuration, you can minimize:

Number of legitimate email messages that reach the Microsoft Outlook user's Junk Email folder.

Number of offensive spam email messages that reach the Outlook user's Inbox or Junk Email
folder.

Number of spam email messages that reach the Outlook user's Inbox.

You can escalate the content filtering action taken on messages that have a greater risk of being
spam. To understand this functionality, it is important to understand the different SCL threshold
actions, and how you can configure them:

SCL delete threshold. When the SCL value for a specific message is equal to or higher than the
SCL delete threshold, the Content Filter agent deletes the message. If the SCL value for a message
is lower than the SCL delete threshold value, instead of deleting the message, the Content Filter
agent compares the SCL value to the SCL reject threshold.

SCL reject threshold. When the SCL value for a specific message is equal to or higher than the SCL
reject threshold, the Content Filter agent deletes the message. If the SCL value for a message is
lower than the SCL delete and SCL reject threshold values, instead of deleting or rejecting the
message, the Content Filter agent compares the SCL value to the SCL quarantine threshold.

6-22

Planning and Deploying Messaging Security

SCL quarantine threshold. When the SCL value for a specific message is equal to or higher than
the SCL quarantine threshold, the Content Filter agent sends the message to a quarantine
mailbox. You must periodically review the quarantine mailbox. If the SCL value for a message is
lower than the SCL delete, reject, and quarantine threshold values, the Content Filter agent sends
the message to the appropriate Mailbox server, where the per-recipient SCL Junk Email folder
threshold value of the message is evaluated.

SCL Junk Email folder threshold. If the SCL value for a specific message exceeds the SCL Junk
Email folder threshold, the Mailbox server puts the message in the Outlook user's Junk Email
folder. If the SCL value for a message is lower than the SCL delete, reject, quarantine, and Junk
Email folder threshold values, the Mailbox server puts the message in the user's Inbox.

For example, if you set the SCL delete threshold to 8, the SCL reject threshold to 7, the SCL quarantine
threshold to 6, and the SCL Junk Email folder threshold to 5, all email with an SCL of 5 or lower will be
delivered to the user's Inbox.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-23

Designing Anti-Spam Solutions

Designing an anti-spam solution is difficult because if you set all anti-spam feature 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 SCL threshold appropriately for your organization, you
probably will not notice a reduction in spam.

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 suspected spam messages, 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 for spam on the hub transport server. In addition to scanning at the edge where messages enter
the organization, to help reduce the propagation of spam, also scan at the hub transport servers.

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 run a virus scan on messages that filters might later identify as spam, because filters
will block those messages eventually anyway. Moreover, spam filtering is less resource-intensive for
messaging servers compared to virus filtering.

6-24

Planning and Deploying Messaging Security

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 metadatasuch
as anti-spam stampsto 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 email 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 Server 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 AD LDS 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 Office Outlook users configure. Safelist aggregation can reduce the instances of
false-positives in anti-spam filtering. When an Exchange Server administrator enables and configures
safelist aggregation, the Content Filter agent passes email messages from the Safe Senders, Safe
Recipients, or Contacts Lists to the user mailbox without additional processing.
Note Safelist aggregation data contains both the users Safe Senders List and the users
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 2010 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.
To enable updates, you must access the Microsoft Update website 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-25

Recommendations for Monitoring the Anti-Spam Solution

It is almost impossible to configure an anti-spam solution so that as soon as it is placed into production, it
functions optimally. When you first implement the solution, you are likely to either have too many false
positives, or too many spam messages getting 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 monitoring requirements. As part
of the monitoring process, you should:

Monitor for false positives. This is probably the most important monitoring task, 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 emails 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 filters 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.

6-26

Planning and Deploying Messaging Security

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 2010 provides several scripts in the
%programfiles%\Microsoft\Exchange Server\Scripts folder that enable collecting agent log
information. These scripts provide information such as the IP addresses or domain names with the
most blocked spam messages, or the recipients who receive 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 2010 supports 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:

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 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 messages anti-spam stamp by opening the message in Office Outlook, and viewing the
Internet headers section in the Message Options page.
Question: Will you be deploying anti-spam filtering using an Edge Transport server in
Exchange Server 2010? What is the reasoning behind your decision?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-27

Designing Antivirus Solutions

One of the most common ways in which viruses spread from one organization to another is through
email. Thus, one of the primary means of protecting your Exchange Server organization is to ensure that
you stop all messages containing viruses at the messaging environments perimeter.

Guidelines for Designing an Antivirus Solution

When designing your organizations 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 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 Office
Outlook 2010, Outlook 2007, and Office Outlook 2003, and the anti-phishing features in
Windows 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. 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 application programming interface (VSAPI)
to scan mailbox databases. However, it is generally preferable to install antivirus software at the
entry point to your messaging infrastructure. Deploying antivirus components to the Edge and/or
Hub Transport servers enables you to reduce the risk of infection of a mailbox database.

Internet edge-based solutions. You also should deploy antivirus and anti-spam software on the
SMTP server, or the 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.

6-28

Planning and Deploying Messaging Security

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 malicious software that
email attachments transmit, and for which signature files are not yet available or deployed. A best
practice is to implement attachment stripping at the email gateway layer, and to match the gatewaylayer attachment stripping policy with the attachment blocking policy that the client enforces.

Scan both incoming and outgoing email for viruses. Although scanning incoming email is the primary
method for keeping a messaging environment free of viruses, you must also ensure that internal users
do not send viruses in outgoing email.

Implement an antivirus solution that can take advantage of specific transport-related Exchange Server
2010 features, including those that antivirus vendors can use to optimize antivirus solutions:

Transport agents for antivirus scanning. In an Exchange Server 2010 environment, all messages
must pass through a Hub Transport server, and inbound and outbound messages pass through
an Edge Transport serverif 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
scans 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 Protection 2010 for Exchange Server

Forefront Protection 2010 for Exchange Server is a Microsoft antivirus and anti-spam solution that
integrates with Exchange Server 2010. It provides advanced protection, optimized performance,
centralized management, and other features, including:

Support for multiple antivirus engines. Forefront Protection 2010 for Exchange Server includes
industry-leading, antivirus 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 Protection 2010 for Exchange Server automatically downloads the latest
signatures, and selects the optimal combination of engines that ensure a high protection level and
reduce exposure to any given threat.

Layered protection. Forefront Protection 2010 for Exchange Server provides protection at multiple
checkpoints in the messaging infrastructure, including Exchange Server 2010 Edge Transport servers,
Hub Transport servers, and Mailbox servers.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-29

Forefront Protection 2010 for Exchange Server utilizes the Exchange Server 2010 transport agents and
Microsoft VSAPI technologies.

Centralized management of remote installation, engine, and signature updating, reporting, and alerts
through the Microsoft Forefront Server Security Management Console.
Question: How will you modify your antivirus solution when you deploy Exchange Server
2010?

6-30

Planning and Deploying Messaging Security

Managing Antivirus Solutions

Managing an antivirus solution is a priority for messaging administrators. Virus writers are constantly
developing new viruses that exploit new vulnerabilities, or that use new techniques to bypass antivirus
solutions. Therefore, it is critical that you conduct daily monitoring and management of your antivirus
solution.

Guidelines for Managing Antivirus Solutions

To manage your organizations 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 antivirus systems to update
daily, and configure all critical systemssuch as the Internet Edge SMTP serversto update several
times daily.

Regularly monitor antivirus software sites for information on new viruses and virus outbreaks.

Monitor daily statistics for the volume of processed email, 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-31

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 users about
viruses, and how to deal with suspicious email. 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 can help prevent a virus from
spreading if it infects their system.

Consider using a solution such as Exchange Online, which offers anti-spam and antivirus solution
management from outside your organization. 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.

6-32

Planning and Deploying Messaging Security

Lab: Planning and Deploying Messaging Security

Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, you must:
1.

On the host computer, click Start, point to Administrative Tools, and then click Hyper-V
Manager.

2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, and the 10233B-VAN-CL1 virtual machines are
running.

3.

If required, connect to the virtual machines. Log on to the virtual machines as

Adatum\Administrator using the password Pa$$w0rd.

Lab Scenario
You are a messaging engineer for the A. Datum Corporation, an enterprise-level organization with
multiple locations. You have been tasked with undertaking an analysis of the organizations message
security requirements. After you complete the analysis, you must update the necessary documentation.
After you have completed the message security analysis, you will investigate the organizations antivirus
and anti-spam requirements, and update the necessary documentation with your planned changes.
Finally, you will implement some of your proposals.
Note Your instructor may choose to perform this lab as a group discussion rather than an
individual activity.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-33

Security Requirements.doc
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 that 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.

A. Datum has formed a strategic partnership with Contoso, Ltd. The central office for Contoso, Ltd is
located in New York. Because much of the email send between A. Datum and Contoso contains
confidential email, all messages sent between the organizations must be as secure as possible. When
viewing an email sent between the companies, users should be able to determine that the message
has been secured while in transit.

A. Datum 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 VPN. A. Datum 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 A. Datum organization should have the option of sending secure email to any
recipients on the Internet. However, the network administrators at A. Datum do not want to manually
deploy the certificates required to enable and manage secure email. At the same time, it is important
that the users can implement and use secure email with as few problems as possible.

Virus and Spam Filtering Requirements

All messages that are sent to A. Datum must be scanned for viruses and filtered for spam before the
messages enter the network.

The messaging administrators at A. Datum have identified two third-party organizations on the
Internet that provide lists of SMTP servers on the Internet that are known to send spam messages.
The messaging administrators have also 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
provided by these organizations 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.

A. Datum has several distribution lists that include over 200 recipients. Users from the Internet should
not be able to send email to any of these distribution lists.

The messaging administrators at A. Datum are concerned about the number of messages coming into
the organization with spoofed SMTP domain names. They want to reduce the quantity of these sorts
of messages.

6-34

Planning and Deploying Messaging Security

Many users are using the Safe Senders list in Office 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
website, the virus should be detected as soon as possible in order to avoid infecting other systems.

At a minimum, antivirus files on all systems should be updated daily, and the antivirus files on all
systems that receive email 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-35

Exercise 1: Designing Message Security

Scenario
In this exercise, you will design a messaging security implementation for the A. Datum Corporation.
To complete this exercise, review the existing A. Datum documentation:

Security Requirements.doc

The main tasks for this exercise are as follows:

1.

Review the A. Datum documentation.

2.

Modify the A. Datum Proposed Security Policies document with a proposed message security plan.

3.

Answer questions relating to the documentation.

Task 1: Review the A. Datum documentation

Review the contents of the following files:

Message Security Requirements section in the Security Requirements.doc

Task 2: Modify the A. Datum Proposed Security Policies document with a proposed
message security plan

Complete the relevant sections of the following document. In the document, provide:

The type of component you will need to configure.

The configuration details for each component.

A. Datum Proposed Security Policies

Document Reference Number: JC120310/1
Document Author
Date

Jason Carlson
12th March 2010

Message Security Components

Component
type

Configuration details

6-36

Planning and Deploying Messaging Security

(continued)
A. Datum Proposed Security Policies
Component
type

Configuration details

Additional notes

Note

Be prepared to discuss your proposed design with the class.

Task 3: Answer questions relating to the documentation

Note

Your instructor may perform this task as a discussion.

Question: How did you address the need to exchange secure email between the A. Datum
Corporation and Contoso, Ltd?

Question: Does your organization have a requirement for the Domain Security solution?
What barriers will there be to adopting this solution?

Results: After this exercise, you should have successfully designed message security for A Datum.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-37

Exercise 2: Designing Antivirus and Anti-Spam Solutions

Scenario
In this exercise, you will design an antivirus and anti-spam implementation for A. Datum Corporation.
To complete this exercise, review the existing A. Datum documentation:

Security Requirements.doc

The main tasks for this exercise are as follows:

1.

Review the A. Datum Corporation documentation.

2.

Modify the A Datum security Proposed Policies Document with a proposed antivirus and anti-spam
solution.

3.

Answer questions relating to the documentation.

Task 1: Review the A. Datum Corporation documentation

Review the contents of the following files:

Virus and Spam Filtering Requirements in the Security Requirements.doc

Task 2: Modify the A. Datum Proposed Security Policies document with a proposed
antivirus and anti-spam solution

Complete both the Anti-Spam and Antivirus Solution Components sections of the following
document. In the document, provide:

The type of component you will need to configure.

The configuration details for each component.

A. Datum Proposed Security Policies

Document Reference Number: JC120310/2
Document Author
Date

Jason Carlson
12th March 2010

Anti-Spam Solution Components

Component type Configuration details
Anti-spam
software
IP Allow List
provider
IP Block List
provider
SMTP connectors
Content filter and
quarantine
mailbox

6-38

Planning and Deploying Messaging Security

(continued)
A. Datum Proposed Security Policies
Anti-Spam Solution Components
Component type Configuration details
Sender ID
filtering
Safelist
aggregation
Blocked recipient
lists
Antivirus Solution Components
Component type Configuration details
Antivirus software
Antivirus software
Antivirus
stamping
Antivirus update

Additional notes

Note

Be prepared to discuss your proposed design with the class.

Task 3: Answer questions relating to the documentation

Note

Your instructor may perform this task as a discussion.

Question: How did you design the antivirus and anti-spam solution for A. Datum
Corporation? How does this compare to the solution you would implement for your
organization?

Results: After this exercise, you should have successfully designed an antivirus and anti-spam strategy for
A Datum.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-39

Exercise 3: Implementing Message Security

Scenario
In this exercise, you will implement some of your proposed changes. You must implement S/MIME within
the A. Datum Corporation organization.
The main tasks for this exercise are as follows:
1.

Create a new certificate template.

2.

Import the certificate template.

3.

Configure user certificate auto-enrollment.

4.

Update the group policy on VAN-CL1.

5.

Verify the presence of the certificate for Scott.

6.

Configure Outlook for Scott.

7.

Verify the presence of the certificate for Marcel.

8.

Configure Outlook for Marcel.

9.

Send a signed and sealed message to Scott.

10. Verify receipt of the secured message.

Task 1: Create a new certificate template

1.

On VAN-DC1, open a new MMC, and add the Certificate Templates snap-in.

2.

Duplicate the User template.

3.

Configure the following properties for the duplicate template, and then close the Exchange
Management Console:
a.

Template display name: S/MIME Certificate

b.

Domain Users granted the allow Enroll and Autoenroll permissions.

Task 2: Import the certificate template

1.

Open Certification Authority.

2.

Import the S/MIME certificate.

3.

Close Certification Authority.

Task 3: Configure user certificate auto-enrollment

1.

Open the Group Policy Management console.

2.

Locate and open the Default Domain Policy for editing.

3.

In Group Policy Management Editor, expand User Configuration, expand Policies, expand Windows
Settings, expand Security Settings, and then click Public Key Policies.

4.

Configure the Certificate Services Client Auto-Enrollment with the following options:
a.

Configuration Model: Enabled

b.

Renew expired certificates, update pending certificates, and remove revoked certificates:
Selected

6-40

Planning and Deploying Messaging Security

c.
5.

Update certificates that use certificate templates: Selected

Close the Group Policy Management Editor, and then close the Group Policy Management console.

Task 4: Update the group policy on VAN-CL1

1.

Switch to VAN-CL1.

2.

Open a command prompt, and at the command prompt, type gpupdate /force, and then press
Enter.

3.

Log off VAN-CL1.

Task 5: Verify the presence of the certificate for Scott

1.

Log on to VAN-CL1 using the following credentials:

User name: Scott

Password: Pa$$w0rd

Domain: Adatum

2.

Open a new MMC, and add the Certificates snap-in.

3.

Verify the presence of a certificate based on the S/MIME Certificate template in the Current
User\Personal certificate store.

4.

Close Console1 without saving changes.

Task 6: Configure Outlook for Scott

1.

Open Microsoft Outlook 2010.

2.

Accept all defaultsEXCEPT in the Welcome to the Microsoft Office 2010 wizard, click Dont make
changes and then click OK.

3.

Close Microsoft Outlook and log off.

Task 7: Verify the presence of the certificate for Marcel

1.

Log on to VAN-CL1 using the following credentials:

User name: Marcel

Password: Pa$$w0rd

Domain: Adatum

2.

Open a new MMC and add the Certificates snap-in.

3.

Verify the presence of a certificate based on the S/MIME Certificate template in the Current
User\Personal certificate store.

4.

Close Console1 without saving changes.

Task 8: Configure Outlook for Marcel

1.

Open Office Outlook 2010.

2.

Accept all defaultsEXCEPT in the Welcome to the Microsoft Office 2010 wizard, click Dont make
changes and then click OK.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-41

Task 9: Send a signed and sealed message to Scott

1.

Create a new message entitled S/MIME Test.

2.

Click the Options tab.

3.

On the Office Outlook ribbon, expand More Options.

4.

In the Properties dialog box, click Security Settings.

5.

In the Security Properties dialog box, select the following check boxes, and then click OK:

Encrypt message contents and attachments

Add a digital signature to this message

Request S/MIME receipt for this message

6.

In the Properties dialog box, click Close, and then click Send.

7.

Close Microsoft Outlook, and log off.

Task 10: Verify receipt of the secured message

1.

Log on to VAN-CL1 using the following credentials:

User name: Scott

Password: Pa$$w0rd

Domain: Adatum

2.

Open Microsoft Outlook 2010.

3.

Open the new message entitled S/MIME Test.

4.

In the message, click the padlock symbol. Read the information, and then click Close.

5.

In the message, click the symbol next to the padlock symbol. Read the information, and then click
Close.

Results: After this exercise, you should have successfully implemented some aspects of the messaging
security design for A Datum.

To prepare for the next module

When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the
following steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1 and 10233B-VAN-CL1. Close the virtual machine connection
windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then in the Actions pane, click Start.

6-42

Planning and Deploying Messaging Security

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then in the
Actions pane, click Connect.
Note Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully started
before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10233B-VAN-EX1. Connect to the virtual machine.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 6-43

Module Review and Takeaways

Review Questions
1.

On the Edge Transport server, which service holds the Edge Transport rules?

2.

You have established the required Edge Transport rules on one of the Edge Transport servers in your
perimeter network. Now you wish to duplicate the configuration. What is one way to easily duplicate
the Edge Transport rules?

3.

When selecting Basic authentication on a receive connector, what additional option should you
select?

4.

What is the purpose of the permissions groups on a Receive connector?

6-44

Planning and Deploying Messaging Security

Best Practices
Supplement or modify the following best practices for your own work situations:

Always consider implementing TLS when configuring Basic authentication on Send or Receive
connectors.

Deploy an Edge Server in your perimeter network to more easily secure your organization against the
threats posed by viruses and malicious software contained in email messages.

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.

Implement attachment stripping at the email gateway layer, and match the gateway-layer attachment
stripping policy with the attachment blocking policy that the client enforces.

7-1

Module 7
Planning and Deploying Messaging Compliance
Contents:
Lesson 1: Designing Transport Compliance

7-3

Lesson 2: Designing AD RMS Integration with Exchange Server 2010

7-12

Lesson 3: Designing Message Journaling and Archiving

7-20

Lesson 4: Designing Messaging Records Management

7-30

Lab: Planning and Deploying Messaging Compliance

7-37

7-2

Planning and Deploying Messaging Compliance

Module Overview

Microsoft Exchange Server 2010 provides a wide range of messaging compliance features that you can
use for more than just simple messaging and calendaring. You can use messaging compliance features to
control message transport, apply Rights Management Services (RMS), implement journaling and archiving,
and manage messages.
After completing this module, you will be able to:

Design transport compliance.

Design Active Directory Rights Management Services (AD RMS) integration with Exchange Server
2010.

Design message journaling and archiving.

Design messaging records management (MRM).

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

Lesson 1

Designing Transport Compliance

Transport compliance allows you to control messages as they are transported through the Exchange
Server organization. To implement transport compliance, you can use transport rules, message
classifications, and message moderation. These features can be used to control which users can send
messages, which users receive messages, and whether messages are modified.
After completing this lesson, you will be able to:

Identify the requirements and options for implementing transport compliance.

Design transport rules.

Design message classifications.

Design message moderation.

7-3

7-4

Planning and Deploying Messaging Compliance

Identifying Transport Compliance Requirements and Options

Key Points
Many organizations enforce transport compliance by controlling the senders and recipients of messages.
Exchange Server 2010 contains features that you can use to implement transport compliance, including:

Transport rules. Transport rules help you manage messages while messages are in transport. Each Hub
Transport server is responsible for applying transport rules to the messages that pass through it, and
each transport rule defines conditions that must be met for a transport rule to apply. If the conditions
are met, then the Hub Transport server performs the actions specified in the rule, such as modifying
the message, adding or removing recipients, and even deleting the message.

Moderated recipients. Moderated recipients control which recipients receive messages from other
recipients. When you send a message to a moderated recipient, a designated moderator must
approve that message before the message is delivered. In most cases, the moderated recipient is a
distribution group.

Message classifications. Message classifications add metadata to a message. Metadata typically

describes how the message should be used, and who should have access to the message. After you
classify a message, you can use transport rules to manage it in a specific way.

AD RMS integration. AD RMS integration controls what recipients can do with email messages. For
example, you can prevent users from printing or forwarding messages, and prevent unauthorized
users from reading messages.

Common transport compliance requirements include:

Add disclaimers to messages. Many organizations may require Exchange Server to add specific, prewritten text to all messages sent from the organizations to external recipients. Instead of relying on
individual users to add the disclaimer, you can centrally implement and enforce the use of disclaimers
by using transport rules.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-5

Restrict users from sending messages to other recipients. Use transport rules and moderated
recipients to control which users can send messages to other recipients. For example, a transport rule
could prevent a user from sending messages outside the organization. Or, you can restrict the
messages sent to a distribution group by implementing moderated recipients.

Block or retain messages with specific content. Use transport rules to block or retain messages with
specific content. For example, you can create a transport rule that deletes all messages with the text
string guaranteed return. Or, you could forward all messages with the text string guaranteed
return to a mailbox so that they can be reviewed.

Restrict what recipients can do with a message. Use AD RMS to limit what recipients can do with a
message. For example, you could create a message intended for the company lawyer, and prevent
that message from being forwarded to other recipients.

Block messages to a specific email domain. Use transport rules to block messages addressed to a
specific email domain. For example, you could use a transport rule to delete all messages addressed
to the contoso.com domain. Or, if there are multiple recipients, you could remove all recipients in the
contoso.com domain.

7-6

Planning and Deploying Messaging Compliance

Planning Transport Rules

Key Points
Transport rules provide you with an almost limitless ability to control messaging in your Exchange Server
organization. Always carefully plan your transport rules to ensure that they behave as intended.
Otherwise, you could accidentally delete messages, or deliver messages to unintended recipients.
When planning transport rules, do the following:

Plan conditions and exceptions carefully. Transport rule conditions and exceptions define which
messages are affected by the transport rule. If you implement the rules incorrectly, you may
unintentionally modify or delete messages.

Use regular expressions to check message contents. Use regular expressions to simplify the list of
terms when you are including a text string in a condition. You can use one regular expression, rather
than a list of variations on the same word. For example, when searching for a phone-number pattern,
you can use the expression \d\d\d(-|.)\d\d\d\d, which denotes a pattern of 3 digits, then a dot or
dash, and then four digits.

Test application of transport rules. Test new transport rules to ensure they behave as intended. This is
important because a new transport rule could conflict with existing transport rules.

Plan for transport rule limitations on encrypted and digitally signed messages. AD RMS integration
with Exchange Server 2010 enables you to implement transport rules and messaging policies when
you are using AD RMS Information Rights Management encryption to protect messages. Encryption
through other mechanisms may prevent the application of transport rules or records management.
For example, Exchange Server may not be able to scan encrypted messages for the text string
specified in a transport rule. Additionally, antivirus scanners cannot scan messages with encrypted
attachments.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-7

Use transport rules on Edge Transport servers to apply outbound message policies for delivery to
external recipients. Hub Transport servers apply transport rules, which results in unnecessary
processing for outbound messages. You can offload this processing to Edge Transport servers instead.
Additionally, in some cases, messages from external organizations may be relayed through Edge
Transport servers directly to another messaging organization, and not be processed by Hub Transport
servers at all.

Consider transport rule recovery. Deleted transport rules are not easily recoverable. Transport rules
are stored in Active Directory Domain Services (AD DS), and restoring rules from AD DS is a complex
process. Alternatively, documented transport rules are easy to recreate, and you can export transport
rules to backup files by using the Export-TransportRuleCollection cmdlet. However, when you
import transport rules onto a Hub Transport server, the server replaces all of the existing transport
rules for the organization.

7-8

Planning and Deploying Messaging Compliance

Planning Message Classifications

Key Points
Message classifications organize messages and provide additional information about those messages.
They also can trigger transport rules. Both users and transport rules can apply message classifications.
Message classifications are visible in Microsoft Office Outlook 2007 or later, and Outlook Web App.
These tools display classification information when users view classified messages.
The default message classifications are:

Attachment Removed

Originator Requested Alternate Recipient

Partner Mail
Note Exchange Server 2010 retains message classifications when upgraded from
Exchange Server 2007.

When planning message classifications, do the following:

Develop custom message classifications. In most cases, you need to create your own custom message
classifications to meet organizational needs. To do this, determine which classifications are required
to meet organizational needs, and define the sender and recipient descriptions that appear when the
message is classified.

Plan for localized versions of message classifications. Each message classification can include alternate
sender and recipient descriptions associated with different locales. For multilingual organizations,
create localized versions of message classification descriptions so that recipients can read the
message classification in their preferred languages.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-9

Configure client file distribution for Office Outlook 2007 and Office Outlook 2010. These clients do
not use message classifications by default, and must be configured to do so. To configure Office
Outlook 2007 and Office Outlook 2010, distribute an XML file that contains the message
classifications. This XML file needs to be redistributed each time you modify message classifications.
You also need to configure registry entries. Outlook Web App supports message classifications by
default.

Configure transport rules. You can use transport rules to control how Exchange Server transports
classified messages based on company polices. For example, you can create a transport rule that
prevents messages with the Company Internal classification from being delivered outside the
organization. Additionally, you can use transport rules to apply message classifications based on
message content, senders, or recipients. For example, you can automatically assign the Legal
classification to any message that arrives from an external lawyer.

7-10

Planning and Deploying Messaging Compliance

Planning Message Moderation

Key Points
Use message moderation to control which messages are delivered to specific recipients. In previous
Exchange Server versions, you could prevent recipients from sending messages to specific recipients, but
could not approve individual messages.
When planning message moderation, do the following:

Consider using moderation for large or confidential distribution groups. Many users within an
organization use large distribution groups for unauthorized messages of a personal nature, such as
fundraising activities. Enabling moderation allows you to control which messages are delivered to
groups that can include an entire physical location or organization.

Select an appropriate moderator. Ideally, a moderator is someone with authority to determine which
messages to allow, and which messages to block. In general, Exchange Server administrators should
not be moderators, because they are not closely linked to business decisions related to moderating
messages. For example, the moderator for a departmental distribution group also should be a
messaging user within that department. Remember that a busy group may generate many messageapproval requests. The moderator must have sufficient time to evaluate the moderated messages.

Configure appropriate moderation exceptions for groups. To reduce the load on a group moderator,
configure moderation exceptions. These exceptions should include senders that can be trusted to
determine appropriate content for the group.

Consider the role of group owners. A group owner can modify the membership list of a distribution
group, or approve membership requests. However, a group owner is not a moderator, and cannot
automatically approve messages sent to a moderated group. If the group owner also needs to
approve messages sent to a moderated group, then you must configure the owner as moderator of
the group.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-11

Plan for message moderation during upgrades. Previous Exchange Server versions do not support
message moderation. This can lead to unexpected results for message moderation. To ensure proper
moderation, you must route messages that are moderated by transport rules through an Exchange
Server 2010 Hub Transport server. Additionally, you must expand distribution groups with an
Exchange Server 2010 Hub Transport server to ensure that Exchange Server moderates messages
addressed to the groups.

Consider using moderated groups and transport rules. In addition to moderated groups, you also can
use transport rules to moderate message transport. This allows you to moderate messages based on
senders, recipients, text patterns, and many other useful scenarios. For example, you could moderate
all messages sent to the email domain of a competitor.

7-12

Planning and Deploying Messaging Compliance

Lesson 2

Designing AD RMS Integration with Exchange Server 2010

You can integrate Exchange Server 2010 with AD RMS to provide additional protection for messages. As
part of planning AD RMS integration, consider how to best protect messages, and how external recipients
can access AD RMS to decrypt and view messages.
After completing this lesson, you will be able to:

Describe the options for integrating AD RMS with Exchange Server 2010.

Design AD RMS integration.

Design AD RMS integration with other organizations.

Implement and manage AD RMS integration.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-13

Options for Integrating AD RMS and Exchange Server 2010

Key Points
AD RMS is a role of the Windows Server 2008 operating system that allows integrated applications to
secure document content. By using AD RMS with Exchange Server 2010, you can limit the recipients who
can read certain messages, prevent messages from being forwarded, and even prevent messages from
being printed. For integration to work, the client application must support AD RMS. Office Outlook 2007
and Office Outlook 2010 both support AD RMS for message protection. Mobile clients running the
Windows Mobile 6 operating system also support AD RMS for message protection. However, extra
configuration is required to support mobile devicesboth in AD RMS, and on the mobile device.
The options for integrating AD RMS and Exchange Server 2010 are:

Transport protection rules. A transport protection rule is a transport rule that applies an AD RMS
template. The AD RMS template defines the restrictions that Exchange Server places on messages. Use
the conditions in the transport rule to determine which messages are protected.

Outlook protection rules. An Outlook protection rule is similar in structure to a transport protection
rule, except it is applied at the Outlook-client level. The only conditions you can base this rule on are
FromDepartment, SentTo, and SentToScope. Within the Outlook client, users receive notification
when Outlook protection rules are applied. You can allow users to override the rules, which can be
useful when there may be exceptions to the normal rule that applies AD RMS templates. Only
Outlook 2010 supports Outlook protection rules.

Transport decryption. The first Exchange Server 2010 Hub Transport server within an organization
that handles a protected message decrypts the message for inspection. This allows the Hub Transport
server to apply transport rules based on message content, and to perform anti-spam and antivirus
scanning. The message is encrypted again before delivery to the next Hub Transport server. You can
configure Exchange Server 2010 to reject messages that it cannot decrypt, decrypt messages
whenever possible, or disable transport decryption.

7-14

Planning and Deploying Messaging Compliance

Journal report decryption. To ensure that journaled content is accessible for compliance purposes,
you must enable journal report decryption. When enabled, Exchange Server decrypts the message
before attaching it to the journal report. Journal report decryption is enabled by default.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-15

Planning AD RMS Integration

Key Points
AD RMS server implementation is the most basic requirement for AD RMS integration. The AD RMS server
generates the certificates that protect message content and specify restrictions.
After you have configured AD RMS, do the following:

Train users to use AD RMS functionality. Users have the option to apply AD RMS templates to
messages. However, they will most likely not use this functionality unless you train them on how to
use the templates.

Consider adding additional templates. Exchange Server 2010 comes with one template, the Do Not
Forward template. This template is useful, but you may need additional templates that prevent
message modification, printing, saving, and copying.

Define the boundaries for AD RMS-protected messages. To decrypt and view protected messages,
clients must be able to access the AD RMS server. Within your organization, it is easy to provide
clients with access to the AD RMS server. However, if you allow AD RMS-protected messages outside
of the organization, you also need to provide external users with access to your AD RMS server.

Use transport protection rules to protect messages regardless of the client. Depending on the client
software, users may not be able to apply AD RMS templates. For example, Outlook protection rules
are only applicable to Outlook 2010 clients. To ensure that messages are protected regardless of the
client software, implement transport protection rules that protect messages at the Hub Transport
server level.

7-16

Planning and Deploying Messaging Compliance

Planning AD RMS Integration with External Organizations

Key Points
AD RMS integration with external organizations is more complex than simply restricting AD RMS
deployment to your own organization. Before selecting the option for AD RMS integration with external
organizations, consider the following:

Can you create external user accounts in your Active Directory forest?

Have the external organizations deployed AD RMS?

Do you need to enable AD RMS integration for all users in the external organizations?

Have the external organizations deployed Active Directory Federation Services (AD FS)?

The options for integrating AD RMS with external organizations are:

Deploy an AD RMS server that is accessible from the Internet. If your AD RMS server is accessible from
the Internet, then external users can communicate with the AD RMS server to obtain the necessary
license certificates. This does not require the external organization to implement AD RMS, but it does
require you to create external user accounts in your Active Directory forest, or create a separate forest
with an AD RMS trust.

Configure trusted user or publishing domains. You can use both trusted user and trusted publishing
domains when the external organization has enabled AD RMS. These two integration methods allow
users in one organization to access content protected by AD RMS in the other organization.

Configure AD RMS integration with the Windows Live ID network of Internet services. Configure a
trust with Windows Live ID to allow protected content to be sent to any user with a Windows Live ID.
However, this option is suitable only for a small number of users, and does not allow the external user
to create protected content.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-17

Configure a federated trust by using AD FS. With this option, external clients contact the AD RMS
server in your organization, but AD FS performs authentication. Configuring this option means that
you do not need to create external user accounts in your Active Directory forest.

7-18

Planning and Deploying Messaging Compliance

Considerations for Implementing and Managing AD RMS Integration

Key Points
Consider the following when implementing AD RMS integration:

Provide Outlook Web App for external users. Outlook Web App allows external users to use a web
browser to view protected messages. You still need to create user accounts for the external users, but
you do not need to provide external access to your AD RMS server. The Client Access server hosting
Outlook Web App communicates with the AD RMS server instead. By contrast, Outlook Anywhere
requires the client to communicate directly with the AD RMS server.

Support for clients running Windows Mobile is not enabled by default. Mobile clients running
Windows Mobile 6 support AD RMS for message protection. You must enable AD RMS on the
Windows Mobile device by connecting it to a computer that has the AD RMS client and either the
Microsoft Exchange ActiveSync technology or Windows Mobile Device Center installed. Also, you
must configure security on the AD RMS server to allow mobile devices.

Develop a plan for distributing AD RMS templates. AD RMS templates must be distributed to the
clients so that the clients can use them. You can use the Windows Vista operating system with
Service Pack 1 (SP1) or later, and Windows Server 2008 to automate template distribution to clients.
By default, these tools distribute templates every 30 days. You can also copy AD RMS templates to
clients as part of a Group Policy Object (GPO).

Ensure that only trusted users have access to the journal mailbox. Exchange Server stores all journaled
content in an unencrypted format, when journal report decryption is disabled. This means that
anyone with access to the journal mailbox can read the messages. If encrypted messages contain
confidential information, then increase security on the journal mailbox.

Develop a communication plan for users. AD RMS is a powerful tool for managing message usage.
However, you must teach users how to use AD RMS.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-19

Monitor the performance impact of encryption on Hub Transport servers. Transport protection rules,
transport decryption, and journal report decryption require a Hub Transport server to encrypt or
decrypt messages. Encryption and decryption are processor-intensive tasks that may cause
performance issues on the Hub Transport server. This is particularly true when the server processes
many messages.

7-20

Planning and Deploying Messaging Compliance

Lesson 3

Designing Message Journaling and Archiving

Exchange Server 2010 includes many features that can help you design message journaling and archiving.
Message journaling stores copies of specified messages in dedicated mailboxes. Personal archives provide
users with a more convenient alternative to using personal folders (PST) files. A litigation hold prevents
message deletion until a time specified by an administrator. Multi-Mailbox Search can search the entire
Exchange Server organization for relevant messages.
After completing this lesson, you will be able to:

Identify the requirements and options for message journaling and archiving.

Describe the message journaling options.

Design message journaling.

Describe the mailbox archival process.

Design a personal archives deployment.

Design a litigation hold strategy.

Design a Multi-Mailbox Search implementation.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-21

Identifying Message Journaling and Archiving Requirements and Options

Key Points
Exchange Server 2010 includes new and enhanced features to improve message journaling and archiving.
These features are:

Message journaling. When you implement message journaling, Exchange Server copies specified
messages to a dedicated mailbox where they are retained until an administrator reviews them.

Litigation hold. When you implement a litigation hold for a mailbox, Exchange Server never purges
the mailboxs deleted messages, so they remain searchable with Multi-Mailbox Search.

Multi-Mailbox Search. When implemented, Multi-Mailbox Search enables authorized users to search
all mailboxes in the organization. This includes content in litigation hold and single-item recovery.

Personal archives. When implemented, personal archives provide users with an alternative to using
PST files to store historical data. Exchange Server creates personal archives as additional mailboxes
that are linked to the original user mailbox. The personal archive can be in the same mailbox
database as the original user mailbox or in a different mailbox database.

Requirements for using these features include:

Messages sent to or by members of a distribution group must be retained. You can create a transport
rule that journals messages sent to the distribution group or sent by members of the distribution
group.

Messages sent or received by specific users must be retained. You can enable a litigation hold on any
user mailbox, in order to retain all messages sent or received by that user indefinitely.

Messages must be searchable for specific types of content. You can use Multi-Mailbox Search to
search any mailbox in the Exchange Server organization.

7-22

Planning and Deploying Messaging Compliance

Users must store all messages in an Exchange Server database. You can enable personal archives,
import PST contents into the archives, and then disable the ability to use PST files.

Messages sent by users in a specific mailbox database must be retained. You can enable message
journaling on a mailbox database to capture all of the messages sent or received by mailboxes in that
mailbox database.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-23

Options for Implementing Message Journaling

Key Points
You can implement message journaling at multiple levels to collect only the specific messages you
require. You can then copy these messages to a local mailbox or to any other valid Simple Mail Transfer
Protocol (SMTP) address.
You can configure message journaling as follows:

On a specific mailbox database. Exchange Server journals all messages that are sent to or from
mailboxes in the mailbox database. This is the only type of journaling that does not require a
Microsoft Enterprise client access license (CAL) for Exchange Server.

On a specific recipient. Exchange Server journals all messages that are sent to or from a specific
recipient, by using a journal rule.

As part of managed folder policies. You can use managed folder polices to journal messages before
they are removed from user mailboxes. However, managed folder policies cannot be combined with
retention policies. So, this option for journaling is not appropriate for many organizations. Retention
policies move expired messages to a personal archive instead of journaling them.

7-24

Planning and Deploying Messaging Compliance

Planning Message Journaling

Key Points
When planning message journaling, do the following:

Identify which messages you should journal. Journal only the specific messages that are required. This
limits the storage space used by the journal mailbox.

Identify the type of message journaling to implement. After determining which messages to journal,
identify the journaling method required to journal those messages.

Identify the journal mailbox. Journal mailboxes receive all of an organizations journaled messages. In
most cases, the journal mailbox is located in a separate mailbox database or Mailbox server from the
source of the journaled messages. This prevents journaled content from affecting user mailbox
performance. You can also host a journal mailbox in a separate email system for security purposes.

Plan for multiple sites in large organizations. Large organizations can generate high levels of message
traffic. You can increase wide area network (WAN)-link utilization if you locate journal mailboxes
across a WAN-link from where the journaled messages are generated.

Consider a litigation hold as an alternative to journaling. A litigation hold retains messages and makes
them searchable without requiring message copies to be stored in another mailbox.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-25

Considerations for Managing the Journal Mailbox

Key Points
The journal mailbox contains journaled messages. Securing the journal mailbox and managing its size are
very important. Consider the following for the journal mailbox:

Plan for the maximum size of the journal mailbox. Allocate an appropriate amount of space for the
journal mailbox. Base the allocated space on the expected number of journaled messages and their
expected size. Use quotas to identify when the journal mailbox grows too large.

Define a process for addressing over-quota journal mailboxes. Determine how to address a journal
mailbox that grows past its quota. In some cases, you may have sufficient disk space to increase the
quota. In other cases, you may decide to remove content from the journal mailbox.

Use MRM to automate message removal. You can remove messages from the journal mailbox after
backing them up and ensuring they are recoverable from offsite storage. To simplify the process, use
MRM to automatically remove journaled messages after a specific time determined by your backup
schedule.

Place the journal mailbox in a separate database to provide backup flexibility. Exchange Server 2010
backups are performed at the database level. If you place the journal mailbox in a separate database,
you can back up the journal mailbox on a different schedule than user mailboxes.

Control who can access journal mailboxes. Most likely, your journal mailboxes contain confidential
information that should not be available to most users. Ensure that only authorized users can access
the contents of the journal mailboxes.

Ensure legal compliance. To ensure that your plan meets legal requirements, obtain approval from
legal representatives.

7-26

Planning and Deploying Messaging Compliance

Planning Personal Archiving

Key Points
You can enable personal archives for individual mailboxes that are hosted on an Exchange Server 2010
Mailbox server. Personal archives are additional mailboxes that are linked to a users primary mailbox.
These mailboxes appear and are accessible when users open Outlook 2007, Outlook 2010, or Outlook
Web App.
When planning personal archiving, do the following:

Consider the impact of personal archives on Mailbox server storage. Personal archives reduce user
mailbox size. However, they do not reduce the total storage utilization because the archived
messages are still stored in a mailbox database, Importing PST files into the archive results in higher
storage utilization. To reduce the impact on storage utilization, you can implement cloud-based
personal archives.

Consider which mailbox database to use for storing personal archives. If you keep personal archives in
the same mailbox database as the users primary mailbox, you reduce overall I/O because fewer
mailboxes are kept on a single disk. However, if you place personal archives in a different mailbox
database than the users primary mailbox, you can specify a different backup schedule for personal
archives.

Selectively enable personal archives. Not all users require them. Enable personal archives only for
users who need additional space for archiving messages, as determined by your organizational
policies.

Consider disabling access to PST files. PST files are difficult to manage because users create them,
sometimes in locations that are not backed up. If you provide personal archives, consider disabling
access to PST files to simplify management and to help ensure that all message data is backed up.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-27

Ensure that you have the correct versions of Outlook to support viewing personal archive contents.
Not all versions of Outlook support personal archives. The version of Outlook that is included in the
following editions of Microsoft Office do not provide access to personal archives:

Microsoft Office Home and Business 2010 (retail)

Microsoft Office Professional 2010 (retail)

Microsoft Office 2010 Standard (volume license)

Microsoft Office 2007 (volume license)

Develop policies for managing personal archive contents and quotas. The personal archive is not
considered part of a user mailbox when quotas are calculated. However, you can define quotas that
are specific to the personal archive. As with primary mailboxes, the organization should establish
consistent company policies regarding what content should be stored in personal archives and
regarding personal archive quotas.

7-28

Planning and Deploying Messaging Compliance

Planning a Litigation Hold

Key Points
Use a litigation hold to help ensure that messages are not purged from specified mailboxes. You typically
use this feature to ensure that all messages can be found in the case of potential or ongoing legal actions.
To enable a litigation hold, use the Set-Mailbox mailboxname LitigationHoldEnabled $true cmdlet.
When enabled, the litigation hold retains all versions of messages that have been modified.
Consider the following when implementing a litigation hold:

Enable a litigation hold only if required. If you implement a litigation hold for a large number of
mailboxes, the mailbox database size can grow quickly because messages cannot be deleted.

Messages in recoverable items (removed from Deleted Items) do not count toward the mailbox
quota. You do not need to do any special planning for user quotas when a litigation hold is enabled
for a mailbox.

There are quotas for recoverable items that can be set on a per-mailbox basis. The
RecoverableItemsWarningQuota is set to 20 GB by default, and an event is generated in the
Application log of the Mailbox server when the quota is reached. The RecoverableItemsQuota is set to
30 GB by default, and users cannot delete items when the quota is reached.
Note The RecoverableItemsQuota default configuration is derived from a setting on the
mailbox database that holds the mailbox.

Use the Legal Hold role to delegate management of litigation holds. In many cases, the manager
responsible for designating which users are subject to a litigation hold may not want to share that
information with Exchange Server administrators. You can delegate the ability to enable a litigation
hold by using the Legal Hold role.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-29

Planning Multi-Mailbox Search

Key Points
In previous Exchange Server versions, you cannot easily search an organization to find messages with
specified content. Multi-Mailbox Search in Exchange Server 2010 provides efficient search capabilities
across entire Exchange Server organizations, because it uses the indexes already created for the feature,
Exchange Search. You can access items that are recoverable with single-item recovery, or with a litigation
hold, by using Multi-Mailbox Search.
Multi-mailbox searches are often referred to as discovery searches. Discovery search results are stored in a
discovery mailbox. By default, there is one discovery mailbox named Discovery Search Mailbox. You
should create additional discovery mailboxes for distinct users or groups that perform discovery searches.
This helps ensure that access to the results of the searches are limited to only those authorized to perform
the searches. For example, the team performing searches for legal purposes may have access to different
mailboxes than the help desk staff recovering deleted messages from mailboxes.
Members of the Discovery Management role group can perform discovery searches across the entire
Exchange Server organization. In many cases, you will want to limit the scope of discovery searches. You
can use the Mailbox Search role to configure limited scopes for users performing discovery searches.
Auditors are likely candidates for assignment to the Discovery Management role group or the Mailbox
Search role.
You can use the Advanced Query Syntax format to generate search queries that are more specific than the
options provided in the basic user interface. If you have users who perform many discovery searches,
provide them with information about Advanced Query Syntax to make their searching more efficient.
You can use mailbox audit logging to track the use of Multi-Mailbox Search. Mailbox audit logging was
introduced in SP1 for Exchange Server 2010, but it is not enabled by default. You must enable mailbox
audit logging on each mailbox.

7-30

Planning and Deploying Messaging Compliance

Lesson 4

Designing Messaging Records Management

Use messaging records management (MRM) to control the lifetime of messages in an Exchange Server
organization. With MRM, you can define when to archive or delete messages in compliance with your
organizations messaging policies.
After completing this lesson, you will be able to:

Identify the requirements and options for implementing MRM.

Design a retention policy deployment.

Design a managed folder deployment.

Design migration from managed folder policies to retention policies.

Describe communication plans for messaging compliance.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-31

Identifying Messaging Records Management Requirements and Options

Key Points
MRM automates messaging management. You can apply policies centrally at the server level, or users can
apply policies directly to messages and folders.
Exchange Server 2010 MRM options are:

Retention policies. You can combine multiple retention policy tags, multiple personal tags, and the
default policy tag into one retention policy. MRM applies the retention policy to mailboxes. The
retention tags in a retention policy can specify that messages are archived or deleted.

Retention policy tag. A method for applying retention settings to a specific folder and its
subfolders.

Personal tag. A method in which users manually apply retention settings to a folder or item. A
personal tag overrides a retention policy tag.

Default policy tag. The policy tag with retention settings that applies to any item that is not
tagged explicitly by the user and is not in a folder subject to a retention policy tag.

Managed folder policies. A managed folder policy combines the settings for both managed default
folders and managed custom folders into a single unit that MRM applies to user mailboxes. A
managed folder can contain content settings that move, delete, or journal messages in a specific
folder. Managed folders are provided primarily for compatibility with Exchange Server 2007.
Retention policies are the preferred method for implementing MRM.

MRM requirements can include:

Deleting messages in specified mailbox folders after a specified time. Apply retention settings to
managed default folders or to managed custom folders, if messages should be deleted from only a
few folders. Use a default policy tag if messages should be deleted from all folders without applying
another retention policy.

7-32

Planning and Deploying Messaging Compliance

Allowing users to mark specific messages for retention. Use personal tags to allow users to manage
retention of their own folders and items.

Automatically moving messages to the personal archive at specified times. Use a retention policy with
the necessary retention tags to archive messages at the appropriate times.

Retaining messages related to specific projects. Configure managed content settings for custom
folders into which users move messages. Users can apply personal tags to manage messages that are
not stored in a custom folder.

Journaling messages when they are automatically deleted from user mailboxes. Use managed content
settings for the entire mailbox-managed default folder to journal messages if they are automatically
deleted. This can be overridden by managed content settings applied to a specific folder.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-33

Planning a Retention Policy Deployment

Key Points
You can apply only one retention policy to a mailbox. This means that you need to carefully plan the
retention tags for that policy. You may create several retention policies with different combinations of
retention tags to meet the needs of different user categories.
Even after you create and apply retention policies, users still have control over the retention process. Users
can control the process by moving messages into a folder with appropriate retention settings, or by
assigning personal tags to individual messages or folders.
When planning retention policy deployment, do the following:

Plan retention policy tags for default folders such as Inbox. To manage default-folder content, create
retention policy tags, and then use them in retention policies that you apply to mailboxes.

Plan a default policy tag. To manage content in folders that are not assigned a retention policy tag,
create a default retention policy tag, and include it in the retention policy.

Minimize the number of personal tags. Limiting the number of personal tags simplifies the retention
system for users. Users are more likely to use a simple system and to make fewer mistakes in applying
personal tags.

Base retention policies on compliance requirements. To create retention policies that meet the needs
of the organization, understand the business and regulatory requirements for messaging compliance.

Provide training on how to use retention policies. In particular, show users how AutoTagging
simplifies message retention by learning from past tagging performed by the user. A minimum of 500
tagged messages are required to enable AutoTagging. AutoTagging is an Outlook 2010 feature.

Use a retention hold for users who are out of the office for extended periods of time. Retention holds
prevent retention policies from being applied to a mailbox. If a user is away for an extended period of
time, this prevents messages from being archived until the user returns and can read the messages.

7-34

Planning and Deploying Messaging Compliance

Planning a Managed Folder Deployment

Key Points
Managed folders provide interoperability with Exchange Server 2007, and are supported by Exchange
Server 2010. If you are implementing MRM and have completely upgraded to Exchange Server 2010, then
use retention policies rather than managed folders. If you have a mixed Exchange Server 2007 and
Exchange Server 2010 organization, you may want to use managed folders to provide a consistent way to
manage mailbox content.
When planning a managed folder deployment, do the following:

Plan managed folder policies based on departments or project groups. Create managed folder
policies for groups that have similar needs. In most cases, departments or project groups have similar
needs and use the same managed folder policy.

Use managed custom folders and journaling to assist with message retention. The managed content
settings that you apply to managed folders do not have an option for archiving messages. Instead,
you can journal messages when they expire.

Implement a default managed folder policy for all users, and also custom managed folder policies as
needed. You can create a managed folder policy that meets the needs of most users in your
organization, and apply that policy to all mailboxes as the default. Then, you can create custom
managed folder policies for groups with special needs.

Provide user training for default folders and custom folders. Train your users so that they understand
the actions that are performed on messages as they move them to different folders. This prevents
confusion when messages are automatically deleted from specific folders.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-35

Planning Migration from Managed Folder Policies to Retention Policies

Key Points
After you implement Exchange Server 2010 in your organization, you should migrate from using
managed folder policies to using retention policies. This way, you can take advantage of the new features
in retention policies, such as archiving messages to a personal archive.
Do the following when planning migration from managed folder policies to retention policies

Create retention policies based on the settings in your managed folder policies. If your organizational
needs remain the same for MRM, identify how you can get a similar effect from retention policies as
you did from managed folder policies. In some cases, you cannot replicate the same functionality. For
example, you cannot journal messages by using a retention policy.

Be aware that when you apply a retention policy to a mailbox, the managed folder policy is removed.
This ensures that there is no conflict between retention policies and managed folder policies.

Apply retention policies to mailboxes as you deploy Outlook 2010. Only users with Outlook 2010 or
Outlook Web App can apply personal tags to messages and folders. The mailboxes of users with
previous versions of Outlook are still affected by retention policy tags and default policy tags based
on folders.

Train users in the differences between retention policies and managed folder policies. Retention
policies do not require users to move messages to specific folders. Unlike managed folder policies,
retention policies do not require users to move messages to specific folders for the retention settings
to apply. Users can manually apply personal tags to individual messages or can use AutoTagging.

7-36

Planning and Deploying Messaging Compliance

Discussion: Designing a User Communication Plan for Messaging

Compliance

Key Points
Communicating with your users is an essential part of implementing messaging compliance. Users need to
understand which tasks Exchange Server 2010 performs automatically, and how they can customize the
process to meet their needs.
Question: How do you communicate IT environment changes to users?

Question: What information would you include in a communication plan?

Question: How do you pilot and implement significant changes to your environment?

Question: How will you ensure that users follow messaging policies?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-37

Lab: Planning and Deploying Messaging Compliance

Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, you must do
the following:
1.

On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2.

Ensure that the 10233B-VAN-DC1 and 10233B-VAN-EX1 virtual machines are running.

3.

If required, connect to the virtual machines. Log on to the virtual machines as

Adatum\Administrator using the password Pa$$w0rd.

Lab Scenario
You are a messaging engineer for A. Datum Corporation, an enterprise-level organization with multiple
locations. A. Datum is an international corporation involved in technology research and investment, and it
is planning to upgrade from Exchange Server 2003 to Exchange Server 2010.
You are aware of the new messaging compliance features in Exchange Server 2010, and need to
determine how you will implement them to meet the needs of your organization.

7-38

Planning and Deploying Messaging Compliance

Exercise 1: Planning a Message Transport Implementation

Scenario
As part of the project planning for the Exchange Server 2010 implementation, the business units have
been interviewed to find any requirements that may impact the planning process. You think that the
security requirements document is most likely to have content that relates to message transport.
After reviewing the security requirements document, you find the following points that relate to the
configuration of message transport:

Before Exchange Server 2010 sends messages to recipients on the Internet, it must add a disclaimer
that was approved by the Legal department.

Messages sent to Internet recipients from members of the Sales team must include a different
disclaimer with the messages.

Messages with a Company Internal classification must be blocked from being sent to the Internet.
When users try to send messages with this classification to the Internet, they should receive a
response stating that 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 never be sent to users who are not on this team.

The main tasks for this exercise are as follows:

1.

Review the A. Datum documentation.

2.

Document the required configuration for message transport.

Task 1: Review the A. Datum documentation

Review the points related to message transport in the Exercise 1 scenario.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

Task 2: Document the required configuration for message transport

Complete the following proposal document by answering the questions.

A. Datum Message Transport Plan
Document Reference Number: JC040417/1
Document Author
Date

Jason Carlson
15th Apr 2010

Requirement Overview
Determine how you will manage message transport.
Proposals
Question: Are transport rules required? If so, how should you configure them?

Question: Is message moderation required? If so, how should you configure it?

Question: Are message classifications required? If so, how should you configure them?

Note

Be prepared to discuss your proposed plan with the class.

Results: After this exercise, you should have created a message transport plan.

7-39

7-40

Planning and Deploying Messaging Compliance

Exercise 2: Planning a Message Journaling and Archiving Solution

Scenario
The next stage in implementation planning is creating a plan for message journaling and archiving. As you
search through the A. Datum documentation for the project, you find the Message Compliance Interviews
document, with content that looks relevant for this plan.
You need to determine the configuration for message journaling and archiving.

Message Compliance Interview

Conor Cunningham, Messaging Services Manager
As part of our Mailbox server planning, we decided that users would be assigned personal archives as a
replacement for PST files. The PST files were simply too difficult to manage. We can use the personal
archives as part of our retention strategy.
As we move mailboxes to Exchange Server 2010, Id like to implement our new archiving scheme. What Id
like to do is this:

Archive all messages after 1 year.

Remove deleted items after 30 days.

Allow users to mark individual items not to be archived.

I have also been speaking with our auditors. They need to be able to monitor and track some
communication in the organization. One item is that all messages sent to the Executives group need to be
monitored. Auditors will review these messages from time to time. In addition, auditors need to be able to
monitor communication for specific users when legal proceedings are initiated. The auditors need the
ability to initiate this process and review all messages. It is important that no messages are deleted for the
specified users.
The main tasks for this exercise are as follows:
1.

Review the A. Datum documentation.

2.

Answer questions related to the documentation.

3.

Document the required configuration for journaling and archiving.

Task 1: Review the A. Datum documentation

Review the following information:

Message Compliance Interview

Task 2: Answer questions related to the documentation

Note

Your instructor may perform this task as a discussion.

Question: In the Message Compliance Interview, what points are raised that impact your
journaling and archiving plan?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

Task 3: Document the required configuration for journaling and archiving

Complete the following proposal document by answering the questions.

A. Datum Journaling and Archiving Plan
Document Reference Number: JC040417/2
Document Author
Date

Jason Carlson
15th Apr 2010

Requirement Overview
Determine how you will configure journaling and archiving.
Proposals
Question: Are personal archives required?

Question: Should you remove PST files?

Question: How can users access personal archives? Does this affect which users will receive
personal archives usage?

Question: Is journaling required? If so, how should you configure it?

Question: How can you prevent users from deleting messages?

Question: Can auditors prevent users from deleting messages?

Note

Be prepared to discuss your proposed plan with the class.

Results: After this exercise, you should have created a journaling and archiving plan.

7-41

7-42

Planning and Deploying Messaging Compliance

Exercise 3: Planning a Messaging Records Management Implementation

Scenario
Finally, you need to determine what type of MRM you need to implement. You are familiar with both
managed folder policies and retention policies. You need to determine if either is required to meet your
business objectives.
The main tasks for this exercise are as follows:
1.

Review the A. Datum documentation.

2.

Answer questions related to the documentation.

3.

Document the required MRM configuration.

Task 1: Review the A. Datum documentation

Review the following information:

Message Compliance Interview

Task 2: Answer questions related to the documentation

Note

Your instructor may perform this task as a discussion.

Question: In the Message Compliance Interview, what points are raised that impact your MRM
plan?

Task 3: Document the required MRM configuration

Complete the following proposal document by answering the questions.

A. Datum Messaging Records Management Plan
Document Reference Number: JC040417/3
Document Author
Date

Jason Carlson
15th Apr 2010

Requirement Overview
Determine how you will implement MRM.
Proposals
Question: Will you use managed folder policies for MRM? If so, how should you configure them?
Question: Will you use retention policies for MRM? If so, how should you configure them?

Note

Be prepared to discuss your proposed plan with the class.

Results: After this exercise, you should have created an MRM plan.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

7-43

Exercise 4: Implementing a Message Compliance Plan

Scenario
In this exercise, you will implement a message compliance plan. These steps are part of the configuration
that you planned in the previous exercises.
The main tasks for this exercise are as follows:
1.

Prevent Company Internal classification messages from being sent to the Internet.

2.

Test the classification rules.

3.

Enable personal archives for all mailboxes in Mailbox Database 1.

4.

Review the default policy tags and retention policies.

5.

Create the Standard Mailbox Retention Policy.

6.

Apply the retention policy to the mailboxes in Mailbox Database 1.

Task 1: Prevent Company Internal classification messages from being sent to the
Internet
1.

On VAN-EX1, open the Exchange Management Shell.

2.

At the shell, type the following command, and then press ENTER:
New-MessageClassification -name Company Internal Displayname Company Internal
-DisplayPrecedence Highest -RetainClassificationEnabled $true
-senderdescription This message is for internal distribution only; it will not be
forwarded on to the Internet

3.

At the shell, type the following command, and then press ENTER:
new-systemmessage dsncode 5.7.999 text Internal recipients only
Internal $True language En

4.

In the Exchange Management Console, on the Hub Transport node under Organization
Configuration, create a new transport rule with the following properties:

Name: Company Internal Rule

Condition 1: sent to users that are inside or outside the organization, or partners = Outside
the organization

Condition 2: marked with classification = Company Internal

Action: send rejection message to sender with enhanced status code

Bounce message: Messages classified as Company Internal cannot be sent to the

Internet

enhanced status code: 5.7.999

Exceptions: None

Task 2: Test the classification rules

1.

On VAN-EX1, open the Microsoft Internet Explorer browser, and then navigate to
https://van-ex1.adatum.com/owa.

2.

Click This is a private computer.

3.

In the Domain\user name box, type adatum\paul.

7-44

Planning and Deploying Messaging Compliance

4.

In the Password box, type Pa$$w0rd, and then click Sign in.

5.

On the Language page, click OK.

6.

Send a new message with the following properties:

7.

To: [email protected]

Subject: Company financial results

Permission: Company Internal

Wait a moment, and then open the returned message.

Question: Was the delivery successful?
Question: What error do you see?

Task 3: Enable personal archives for all mailboxes in Mailbox Database 1

1.

On VAN-EX1, in the Exchange Management Console, filter the Mailboxes view to list only those in
Mailbox Database 1.

2.

Select all of the mailboxes, and then enable archives in Mailbox Database 1.

Task 4: Review the default policy tags and retention policies

1.

On VAN-EX1, in the Exchange Management Console, under Organization Configuration, on the

Retention Policy Tags tab, read the list of retention policy tags.

2.

On the Retention Policy tab, view the properties of the Default Archive and Retention Policy.

Task 5: Create the Standard Mailbox Retention Policy

1.

2.

On VAN-EX1, in the Exchange Management Console, create a new retention policy tag with the
following settings:

Tag Name: Default 1 year archive

Tag Type: All other folders in the mailbox

Age Limit for retention (days): 365

Action to take when the age limit is reached: Move To Archive

Comment: Archive messages after 1 year

Create another retention policy tag with the following settings:

Tag Name: Deleted Items 30 day removal

Tag Type: Deleted Items

Age Limit for retention (days): 30

Action to take when the age limit is reached: Delete and Allow Recovery

Comment: Remove deleted items after 30 days

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

3.

7-45

Create a new retention policy with the following settings:

Name: Standard Mailbox Retention Policy

Retention policy tags: Default 1 year archive, Deleted Items 30 day removal

Mailboxes: none

Task 6: Apply the retention policy to the mailboxes in Mailbox Database 1

1.

On VAN-EX1, in the Exchange Management Console, browse to the Mailbox node.

2.

Add a the following expression to the existing filter that prevents the Discovery Mailbox from being
displayed:

Recipient Details Does Not Equal Discovery Mailbox

3.

After applying the filter, select all of the mailboxes, and then open Properties.

4.

On the Mailbox Settings tab, apply the Standard Mailbox Retention Policy to all of the mailboxes.

5.

Verify that the Standard Mailbox Retention Policy is applied to Paul West by viewing the Messaging
Records Management properties for his mailbox.

Results: After this exercise, you should have prevented messages classified as Company Internal from
being sent to the Internet, created a retention policy, and applied it to all of the mailboxes in Mailbox
Database 1.

To prepare for the next module

When you finish the lab, revert the machines to their initial state. To do this, complete the following steps:
1.

On the host computer, start the Microsoft Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3. Close the virtual
machine connection windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then, in the Actions pane, click Start.

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then, in the
Actions pane, click Connect.
Important: Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully
started before starting the other virtual machines.

7.

Wait for 10223B-VAN-DC1 to start, and then start 10223B-VAN-EX1. Connect to the virtual machine.

8.

Wait for 10233B-VAN-EX1 to start, and then start 10223B-VAN-EX2. Connect to the virtual machine.

9.

Wait for 10233B-VAN-EX2 to start, and then start 10223B-VAN-EX3. Connect to the virtual machine.

7-46

Planning and Deploying Messaging Compliance

Module Review and Takeaways

Review Questions
1.

What is the relationship between retention policy tags and retention policies?

2.

Does a personal archive decrease the size of a mailbox database?

3.

Can you apply message moderation to recipients other than distribution groups?

4.

Can Exchange Server 2010 prevent messages that meet specific criteria from being forwarded to
other users?

Best Practices Related to Messaging Records Management

Supplement or modify the following best practices for your own work situations:

Replace managed folder policies with retention policies as you migrate mailboxes to Exchange Server
2010 and Outlook 2010.

Implement Outlook 2010 to allow users to apply personal tags.

Provide users with training on how to apply personal tags and use AutoTagging.

Minimize the number of personal tags to simplify the user experience.

Base retention policies on business needs.

8-1

Module 8
Planning and Deploying High Availability
Contents:
Lesson 1: Introduction to High Availability Planning in Exchange Server 2010

8-3

Lesson 2: Designing High Availability for Mailbox Databases

8-14

Lesson 3: Designing High Availability for Other Server Roles

8-25

Lesson 4: Designing Site Resilience

8-32

Lab: Planning and Deploying High Availability

8-45

8-2 Planning and Deploying High Availability

Module Overview

Messaging systems are considered a critical business tool in most organizations. Outages of even a few
hours reflect poorly upon the IT departments, and can result in lost sales or loss of business reputation.
High availability helps ensure that messaging systems built on Microsoft Exchange Server 2010 can
survive the failure of a single server, or even multiple servers. You can implement high availability for all
the server roles in Exchange Server 2010.
After completing this module, you will be able to:

Describe high availability in Exchange Server 2010.

Design high availability for mailbox databases.

Design high availability for non-Mailbox server roles.

Design site resilience.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-3

Lesson 1

Introduction to High Availability in Exchange Server 2010

Before you can begin planning a highly available Exchange Server 2010 organization, you need to
understand the options for providing high availability for each server role. Then, you can select the
options that are most appropriate for your organization. In this lesson, you will learn what high availability
is, and how you can implement high availability for Exchange Server 2010 roles.
After completing this lesson, you will be able to:

Describe high availability.

Describe the components that must be highly available to help ensure Exchange Server availability.

Describe how database availability groups (DAGs) work.

Describe the options for implementing database copies.

Describe how shadow redundancy works.

Describe how high availability works for Client Access servers.

8-4 Planning and Deploying High Availability

What Is High Availability?

Key Points
Availability refers to a level of service that applications, services, or systems provide, and is expressed as
the percentage of time that a service or system is available. Highly available systems have minimal
downtimewhether planned or unplannedand are available more than 99 percent of the time,
depending on the needs and the budget of the organization. For example, a system that is unavailable for
8.75 hours per year would have a 99.9 percent availability rating.
To improve availability, you must implement fault-tolerance mechanisms that mask or minimize how
failures of the services components and dependencies impact the system. You can achieve fault tolerance
by implementing redundancy for single points of failure.

Defining Availability Requirements

Service availability is a complex issue that spans many disciplines. You can take many different approaches
to deliver the required availability levels, and each approach has its own cost implications.
Availability requirements must be expressed so that there are no misunderstandings about the
implications. Miscommunication concerning service level expectations between the customer and the IT
organization can result in inappropriate business results, such as unsuitable investment levels and
customer dissatisfaction.

Different Availability Requirements

One organizations requirement for 99.5 percent availability can be different from another organizations
requirement for 99.5 percent availability. One requirement may state the availability of the hardware
platform alone, while another may state the availability of complete end-to-end service. Even the
definition of complete end-to-end service availability can vary. It is important to understand how you
must measure each availability requirement. Consider the following scenarios:

If all hardware and software on the primary server are functioning correctly, and the application is
ready to accept all user connections, then does the solution provide 100 percent availability?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-5

If there are 100 users, but 25 percent cannot connect because of a local network failure, does the
solution still provide 100 percent availability? In this situation, the solution meets the 100 percent
availability expectations of 75 percent of the users, but for the rest of the users, it does not. How do
we consider this as part of the availability, because not all of the users are affected?

If only one user out of 100 can connect and process work, is the solution only 1 percent available?

If all 100 users can connect, but the service is degraded with only two out of three customer
transactions being available, or performance is poor, how does this affect availability measurements?

The availability measurement period also can have a significant effect on the definition of availability.
For example, a requirement for 99.9 percent availability over a one-year period allows 8.75 hours of
downtime, whereas a requirement for 99.9 percent availability over a rolling four-week window allows
only 40 minutes of downtime per period.

Outages
It also is necessary to identify and negotiate downtime periods for planned maintenance activities, service
pack updates, and software updates. These are scheduled outages, and typically not included as
downtime when calculating the systems availability. You typically calculate availability based on
unplanned outages, such as a system crash. However, you have to negotiate exactly which outages you
consider to be downtime.
Question: How does your organization define high availability for services?

8-6 Planning and Deploying High Availability

Components of High Availability

Key Points
When an application requires high availability, you need to consider more than just the application
components. All of the infrastructure and services that the application relies on also must be highly
available. This also applies to Exchange Server 2010.
Some of the additional components that you must consider include the following:

Data center infrastructure. The room that stores the server must have sufficient power and cooling
capacity, which must also be highly available. You can make power highly available by ensuring that
an alternate power sourcesuch as a battery or a generatoris available when the electrical utility
experiences outages. You can make cooling capacity highly available by using multiple cooling units
with sufficient capacity to keep the data center cool when one unit fails. In cases of a catastrophic
failure, you can use an alternate data center location.

Server hardware. To make server hardware highly available, there must be redundant components in
the server. Redundant components can include power supplies, network adapters, processors, and
memory. Error-correction code (ECC) memory helps to resolve minor errors in memory.

Storage. To make storage highly available on a single server, you can use a version of Redundant
Array of Independent Disks (RAID). RAID uses parity information to ensure that a server can survive
the loss of at least one hard drive without losing any data. If multiple servers are available, you can
replicate data between servers. This allows the data to survive the loss of an entire server, rather than
just a hard drive.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-7

Network infrastructure. To make a local area network (LAN) highly available, you must introduce
redundant components. Within a LAN, this typically means redundant switches. Even moderately
priced switches include redundant configurations. To make the network connectivity for any
individual computer fault-tolerant, you must configure redundant network interface cards on the
computer. This is a standard feature in most mid-level and higher servers. High availability for a wide
area network (WAN) is typically the responsibility of the WAN service provider. However, if you are
using private links for your WAN, you can create redundant paths through the WAN.

Internet connectivity. For highly available Internet access, you must have redundant Internet
connectivity. Ideally, you would use two different Internet service providers (ISPs), and two different
physical connectivity methods. For example, one ISP could be land-based, and the other wireless. If
you use these methods, it is unlikely that a problem affecting one ISP would affect the other. Many
firewalls and routers are capable of using one connection for Internet connectivity and failing over to
another if the primary service fails. For incoming email, you must use multiple mail exchange (MX)
resource records, with one record pointing at the IP address allocated by each ISP.

Network services. Active Directory Domain Services (AD DS) and Domain Name System (DNS) are
the two services that must be highly available to support highly available Exchange Server 2010
organizations. To make AD DS highly available, you should have multiple domain controllers and
global catalog servers. Depending on the size of a location, there may be multiple domain controllers
and global catalog servers in a single location. To make internal DNS highly available, you must have
multiple DNS servers with DNS information synchronized between them. By default, the DNS zones
for AD DS are Active Directoryintegrated, and replicated between all DNS servers in the forest.
Question: Which infrastructure is highly available in your organization?

8-8 Planning and Deploying High Availability

How DAGs Work

Key Points
A Database Availability Group (DAG) is a logical grouping of servers that you can use to provide high
availability for mailbox databases. A DAG can contain up to 16 servers. A mailbox database has a single
active copy on one of the servers in the DAG. Client requests are serviced by the active database copy.
Each mailbox database in a DAG can have one or more passive copies. Continuous replication copies
transaction log data from the active database to the passive copies. The logs are played on passive copies
of the database to update them with the same information as the active copy of the database. Continuous
replication file mode, which copies full transaction log files, is used initially. When all transaction log files
are copied and up to date, continuous replication block mode is used. Continuous replication block
mode replicates each file write to the active transaction log. Continuous replication block mode reduces
synchronization latency between the active and passive copies of a database. It also removes the current
log file as a single point of failure during failover.
If passive database copies are using continuous replication file mode and a failover occurs, any missing
transaction logs are copied to a passive copy before activation. If the missing transaction logs cannot be
copied, nonreplicated messages are recovered from the transport dumpster on Hub Transport servers. The
transport dumpster keeps a copy of messages until they are replicated.
DAGs require the clustering feature in the Windows Server 2008 operating system. However, the Active
Manager component is responsible for directing Client Access servers to the active copy of the database.
The Active Manager runs on all Mailbox servers that are DAG members, and runs as either the primary
active manager or a standby active manager.
The primary active manager is the Active Manager in a DAG that decides which copies are active and
passive. It is also responsible for processing topology change notifications and for reacting to server
failures.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-9

The standby active manager provides information to other components of Exchange Server about which
server hosts the active copy of a mailbox database. For example, the RPC Client Access service on a Client
Access server communicates with the Active Manager to determine the location of a mailbox for a user.
The standby active manager also detects local database and local information store failures. It reacts to
failures by sending a request to the primary active manager to initiate a failover (if the database is
replicated).
Note As an administrator, you do not manage which servers are primary active manager
or passive active manager. The process is completely automatic.
A DAG protects against corruption of individual database pages. The most common type of database
corruption is caused by small physical errors on disks. This type of error can cause individual database
pages to be corrupted. When a request is made to an active database for a corrupted page in the
database, the corrupted page is retrieved from a passive database copy and the active database is
repaired.

8-10

Planning and Deploying High Availability

Options for Implementing Database Copies

Key Points
After you add a Mailbox server to a DAG, the mailbox database is not automatically replicated to other
nodes in the DAG. You control which servers in a DAG have a copy of a specific database. Not all
databases need to have the same number of copies. In a 16-node DAG, one database can have 16 copies,
while another database is not redundant and contains only the one active copy.
When you implement a database copy, you must configure the activation settings. The activation
preference number controls the order in which passive database copies are activated when all passive
copies are up to date. If not all database copies are up to date, an up-to-date database copy is preferred
regardless of the activation preference number.
You can disable activation for a specific database copy. If you are performing maintenance, you may want
to disable activation to prevent a database from failing over to an alternate server. You may also want to
disable activation for a database copy in a remote site that is used only for disaster recovery.
For each passive copy of a database, you have the option to set a replay lag. The replay lag controls how
far behind the transaction logs are in replaying compared to the original source. For example, the active
mailbox database plays the transaction logs immediately, to place the data into the database. The replay
of logs on a passive database copy is delayed by the time period that you specify. In cases where the
transaction logs contain data that causes a logical corruption of the database, you can prevent the bad
data from being replayed on the passive copy because of the replay lag.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-11

Truncation lag controls how long transaction logs are retained before they are deleted. In a DAG, with at
least three database copies, it is common to configure circular logging on the database because a
database restore will never be performed. If circular logging is enabled, the transaction logs are deleted
shortly after they are played into the database. If you configure a truncation lag on a database copy,
transaction logs are kept for recovery in case there are problems with the transaction logs on the active
database copy. If circular logging is not enabled, a transaction log file is not eligible for truncation until it
is backed up. A transaction log file is also not eligible for truncation until it is replicated to all database
copies and played on all database copies that are not lagged.
Question: Do you anticipate using replay lag in your organization?

8-12

Planning and Deploying High Availability

How Shadow Redundancy Works

Key Points
Exchange Server 2010 includes the shadow redundancy feature, which provides redundancy for messages
for the entire time they are in transit. This is in addition to the transport dumpster. With shadow
redundancy, the message deletion from the transport databases is delayed until the transport server
verifies that the next hop for that message has completed delivery. If the next hop fails before reporting
back successful delivery, the message is resubmitted for delivery to that next hop.
When messages are delivered externally, many SMTP servers on the Internet do not support discard
status. If discard status is not supported, the final transport server in the Exchange 2010 organization
marks the message as delivered after delivery to the external SMTP server. Shadow redundancy is not
used if the next hop does not support it.
Incoming messages from the Internet do use shadow redundancy. The first transport server in the
Exchange 2010 organization delays the acknowledgement of message receipt for up to 30 seconds while
it delivers the message to the next transport server. If the first transport server fails at this point, the SMTP
server on the Internet resends the message. If the first transport server cannot send the message to the
next transport server within 30 seconds, the acknowledgement is sent to the Internet SMTP server to
indicate successful message delivery, and the message remains queued for delivery on the first transport
server.
Shadow redundancy provides the following benefits:

Eliminates reliance on the state of any specific Hub Transport or Edge Transport server. As long as
redundant message paths exist in your routing topology, any transport server becomes disposable.

If a transport server fails, you can simply remove it from production without worrying about emptying
its queues or losing messages.

If you want to upgrade a Hub Transport or Edge Transport server, you can bring that server offline at
any time without the risk of losing messages.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-13

Eliminates the need for storage hardware redundancy for transport servers.

Consumes less bandwidth than duplicate copies of messages on multiple servers. The only additional
network traffic generated with shadow redundancy is the exchange of discard status between
transport servers. Discard status is the information each transport server maintains, indicating when
the transport database is ready to discard a message.

8-14

Planning and Deploying High Availability

How High Availability Works for Client Access Servers

Key Points
A client access array is a load-balanced collection of Client Access servers that is in a single site. Because
all client connectionsincluding Messaging Application Programming Interface (MAPI)rely on
connections to Client Access servers, it is important to provide a redundant server array to improve
availability. To create a client access array, first deploy multiple Client Access servers. Next, use either
hardware-based or software-based Network Load Balancing (NLB) to create a cluster. Then, add the name
for the network load-balanced cluster into DNS. For example, you could add a host (A) resource record for
caa1.contoso.com that points to 10.10.10.25. After adding the DNS record, you can create the client
access array and assign it to an Active Directory site using the New-ClientAccessArray cmdlet. Finally,
assign the client access array to each of the mailbox databases in the site by using the SetMailboxDatabase cmdlet with the RpcClientAccess parameter.
A client access array can exist only in a single Active Directory site. Therefore, you need to create a client
access array in each Active Directory site that needs to load balance client access servers.
As a best practice, you should create the client access array before you create mailbox databases. When
new mailbox databases are created, the RpcClientAccess parameter is automatically configured to use a
client access array if one exists for that site. This avoids the need to update mailbox databases later.
Question: Why is high availability important for Client Access servers?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-15

Lesson 2

Designing High Availability for Mailbox Databases

You can implement high availability for mailbox databases by using a DAG. When you implement a DAG,
there are unique considerations that you must take into account. Proper design for a DAG ensures
sufficient performance and redundancy. A poorly designed DAG may not provide any redundancy for
mailbox databases, or may experience performance issues when one or more Mailbox servers fail.
After completing this lesson, you will be able to:

Describe the requirements for implementing DAGs.

Design the network components for a DAG deployment.

Design the storage components for a DAG deployment.

Design database copies and continuous replication.

Design a plan for monitoring and managing DAGs.

8-16

Planning and Deploying High Availability

Requirements for DAGs

Key Points
When you implement a DAG, you must ensure that you meet a number of very specific requirements. You
need to consider the requirements related to general configuration, operating system version, network
configuration, and DAG configuration.

General Configuration
The general requirements for implementing a DAG are:

DNS must be implemented with a host record for each Exchange server. Dynamic updates for DNS
are preferred.

Each Mailbox server must be a member of the same domain. It is not possible to have Mailbox servers
in different Active Directory domains as members of the same DAG.

The Mailbox servers that are members of a DAG cannot also be domain controllers. This configuration
is not supported.

The computer name for the Mailbox server must be unique, and must be 15 characters or less.

Operating System Version

All members of a DAG must be running the same operating system version. All DAG members must be
running Windows Server 2008, or all DAG members must be running Windows Server 2008 R2. It is not
possible to mix the two operating system versions within the same DAG.
A DAG is based on the use of Failover Clustering in Windows Server 2008. Only the Enterprise or
Datacenter versions of Windows Server 2008 and Windows Server 2008 R2 include Failover Clustering.
Therefore, only these operating system versions can be used for DAG members.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-17

Network Configuration
The network configuration requirements include the following:

One network adapter is supported, but two network adapters are recommended. This allows you to
configure a MAPI network, and a separate replication network.

Latency between DAG members must be less than 250 milliseconds (ms). This is important when you
configure a DAG with members in multiple physical locations.

You can use Internet Protocol version 6 (IPv6) only if Internet Protocol version 4 (IPv4) is also
configured. IPv4 cannot be disabled.

Automatic Private Internet Protocol Addressing (APIPA) is not supported for DAG members.

DAG Configuration
In addition to the physical network and IP addressing requirements for the member servers of the DAG,
the DAG itself has certain other requirements:

The DAG must have at least one IP address on the MAPI network. This address can be static or
dynamic, although a static IP address is typically used in most environments.

If the DAG is expanded across multiple subnets, then the DAG must have an IP address on each
subnet.

The name of the DAGlike the name of each member of the DAGmust be 15 characters or less,
and must be unique.

Witness Server
Failover Clustering in Windows Server 2008 uses the concept of a quorum for decision making in the
cluster. In clusters with a shared disk, connectivity to the shared disk can be used to define which nodes
should potentially be active in the cluster. In a DAG, there is no central disk.
A DAG requires the use of a witness server for a node and file share majority quorum. The witness server
functions as an additional member of the DAG for determining the quorum, but is only used when there
is an even number of members in the DAG. The witness server is a file share located on a server that is not
a member of the DAG.
The quorum for a DAG is used to determine which members participate in replications, and which can
mount databases. For example, if one computer in a DAG loses network communication, it is not part of
the quorum, and cannot mount databases.
It is recommended that you configure the witness server on a Hub Transport server in the Exchange
Server organization. The additional load on the server is minimal, and it is already under the control of the
Exchange Server management group. The witness server does not need to run the same version of
Windows Server as the members of the DAG.
If the DAG witness server is not an Exchange server, then you need to add the Exchange Trusted
Subsystem group as a member of the local Administrators group on the witness server.
Note It is possible for a DAG member to host additional server roles.
Question: Can your organization meet all of the requirements for a DAG?

8-18

Planning and Deploying High Availability

Designing Network Components for a DAG

Key Points
The MAPI network is the network that other Exchange servers use to communicate with DAG members.
Additionally, you can configure replication networks that are used exclusively for log shipping between
the DAG members. If only a single network is available, it is used for all communication, including log
shipping. Although this is supported, it is not recommended. If you use only a single network, then you
should use gigabit Ethernet to ensure you have sufficient network capacity on the members.
By adding a replication network, you provide redundancy for log shipping. If the MAPI network fails for a
member with active databases, those databases fail over to another member. If the replication network
fails for a member, replication is performed over the MAPI network.
Each DAG member must have the same number of networks. If you determine that the DAG will have two
replication networks in addition to the MAPI network, all members in the DAG must have three network
adapters.
DAG networks cannot share the same subnet, or be routable between them. The MAPI network must be
separate from replication networks. Replication networks must be separate from each other.
A DAG network can span multiple subnets. This is typically used when a DAG spans multiple data centers
for geographic redundancy. When you use multiple subnets for a DAG network, you must configure
routing between the subnets. For example, the subnet used for the MAPI network in one location must be
routable from the MAPI network for another location.
Note If a DAG member hosts additional Mailbox server roles, those roles communicate by
using the MAPI network.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

MAPI Network Configuration

The network adapter used for the MAPI network should have the following configuration:

Client for Microsoft Networks Enabled

QoS Packet Scheduler Optional

File and Printer Sharing for Microsoft Networks Enabled

Link-Layer Topology Discovery Mapper I/O Driver Enabled

Link-Layer Discovery Responder Enabled

Register this connections address with DNS

Replication Network Configuration

The network adapter used for the replication network should have the following configuration:

Client for Microsoft Networks Disabled

QoS Packet Scheduler Optional

File and Printer Sharing for Microsoft Networks Disabled

Link-Layer Topology Discovery Mapper I/O Driver Enabled

Link-Layer Discovery Responder Enabled

Do not register this connections address with DNS

Because a computer with a Windows operating system supports only a single default gateway, you
should not configure the replication network adapter with a default gateway. Instead, you should
configure static routes if routing is required on a replication network.

8-19

8-20

Planning and Deploying High Availability

Designing the Storage Components for a DAG

Key Points
The storage performance requirements for a DAG member vary depending on your organization. In
general, the storage for a DAG member must be sufficient to support all active databases and all passive
databases placed on the DAG member. Both active and passive databases generate disk activity. However,
passive databases generate less disk activity because they are not affected by users reading messages.

Failover Considerations
When designing the storage components for a DAG, you need to consider the results of DAG member
failure. When one DAG member fails, the active databases on that DAG member fail over to other DAG
members. If all of the active databases on a DAG member fail over to only one other DAG member, it
could potentially overload the target of the failover. You can design your DAG as follows:

Active/active. An active/active DAG has active mailbox databases on all nodes. When a node fails in
an active/active DAG, the active mailbox databases from the failed node should fan out to unaffected
members. This spreads the input/output (I/O) among several servers, and it prevents remaining
servers from performing poorly.

Active/passive. An active/passive DAG has at least one node dedicated to passive mailbox database
copies. By maintaining a passive server with sufficient capacity to become active, other active servers
are not affected by a failover.

Control the failover of mailbox databases by using the activation preference number. However, be aware
that the activation preference number is used to control failover only if all database copies are up to date.

Storage Selection
A DAG provides redundancy. As part of your design, you might select storage that is not redundant in
your servers. When you create three or more database copies, you should use just a bunch of disks (JBOD)
rather than RAID. This allows you to reduce your storage costs.
Question: Are you willing to consider using JBOD instead of RAID for database copies?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-21

Designing Database Copies and Continuous Replication

Key Points
When designing database copies, you need to consider how many database copies are required. There
are no specific rules for the number of databases you should have. More databases increase redundancy,
but they also increase the processing and storage load on the DAG members. If you are concerned about
network failure, you should design your database copies with at least one copy on a second network.

Replay Lag
You can configure a replay lag from passive copies of a database. This prevents shipped transaction logs
from being replayed on passive database copies for a specific timeframe.
The main purpose of configuring a replay lag is to avoid logical corruption of the passive database, based
on the transaction log data that has corrupted the active database. You need to consider how long this
replay lag should be. It needs to be long enough for you to identify the error and prevent the bad data
from being replayed on the passive copy. The replay lag is set for each database copy.
Using three database copies can provide fast recovery from database failure, and it prevents logical
corruption of the database by using transaction log replay. One copy is active, and a second copy is
passive with no replay lag. In case of a disk failure or server failure, the second copy can be configured to
activate automatically. The third copy is passive with a replay lag, and it is used to prevent logical
corruption based on transaction log data. If logical corruption occurs, the first two copies are corrupted,
but the third copy is not corrupted due to the replay lag. Then, during recovery, you can specify which
transaction logs should be replayed on the third copy.
The logical corruption that replay lag helps to recover from is quite rare. It is different from most common
database corruption that is caused by disk errors. The data in the transaction logs is based on valid MAPI
commands. Therefore, the logical corruption is more accurately described as unexpected data
manipulation than corruption. This can be caused by third-party applications that interact with Exchange
Server, such as archiving software.

8-22

Planning and Deploying High Availability

Log Truncation
Typically, database logs are truncated when you perform a backup. Alternatively, when circular logging is
enabled, transaction logs are truncated after they are placed into the database. In a DAG, transaction logs
are never truncated until they are replicated to all passive database copies and played into the passive
databases. If a passive database is a lagged copy, transactions logs must be replicated to it, but the logs
do not need to be played before other database copies truncate the logs.
You can extend the time that transaction logs are retained by setting the log truncation time on a
database copy. The retained transaction logs can be used for recovery operations if there is a problem
with transaction logs on the active copy.

Site Resilience
A DAG can include members on multiple subnets and in multiple physical locations. This makes it possible
to provide site resiliency by placing DAG members in two separate data centers in two separate locations.
Note Site resiliency is discussed in Lesson 4: Designing Site Resilience.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-23

Designing Monitoring and Management for a DAG

Key Points
In larger organizations, the management of DAGs is likely to be restricted to a relatively small group of
administrators. This group understands all of the design parameters that need to be taken into account
when creating and managing DAGs and database copies. You can delegate these permissions using Role
Based Access Control (RBAC).
To create and manage DAGs, you must be part of the Organization Management role group or Database
Availability Groups role group. To create and manage database copies, you must be part of the
Organization Management role group or Database Copies role group.

Monitoring
One of the unique challenges when managing DAGs is that, in a well-designed system, you may not
notice the failover of a database from one DAG member to another. One way you can monitor DAG
members is by using the Exchange Server 2010 monitoring management pack for System Center
Operations Manager 2007. The Exchange Server 2010 monitoring management pack proactively monitors
servers, and it can notify administrators when errors and events occur.
Exchange Server 2010 has some options for monitoring DAG status:

Get-MailboxDatabaseCopyStatus. Use this cmdlet to view status information about a specific

mailbox database copy, all mailbox database copies of a database, or all mailbox database copies on
a server.

Test-ReplicationHealth. Use this cmdlet to perform a variety of tests, and to report back status for
various replication components.

Event logs. In addition to events in logs for the Windows operating system, there are also event logs
that are specific to Exchange Server. These logs are located in the Applications and Services node. The
two specific logs that are of interest for high availability are the High Availability and
MailboxDatabaseFailureItems logs.

8-24

Planning and Deploying High Availability

CollectOverMetrics.ps1. This script collects statistics and information about switchovers and failovers.
The data reported is based on past events.

CollectReplicationMetrics.ps1. This script collects real-time statistics about replication while it is

running.

CheckDatabaseRedundancy.ps1. This script is scheduled to run on Mailbox servers as a scheduled task

named Database One Copy Alert. The task runs every 60 minutes. Running this task places events in
the Application event log if only a single copy of a mailbox database is healthy in a DAG. You can also
use this script interactively to generate summary reports and to show error details.
Note For examples on how to use the monitoring tools included in Exchange Server 2010,
see Monitoring High Availability and Site Resilience
(http://go.microsoft.com/fwlink/?LinkID=185448).
Question: Which users in your organization do you want to have permission to manage
DAGs?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-25

Lesson 3

Designing High Availability for Other Server Roles

High availability for non-Mailbox servers varies depending on the server role. Each server role has a
unique method for providing high availability. Hub Transport servers require no configuration other than
the addition of a second Hub Transport server. Client Access servers require a client access array to be
created. Edge Transport servers require the proper configuration of MX records in DNS.
After completing this lesson, you will be able to:

Design a highly available Hub Transport server deployment.

Design a highly available Client Access server deployment.

Design a highly available Edge Transport server deployment.

Design a highly available deployment using multiple server roles per server.

8-26

Planning and Deploying High Availability

Designing High Availability for Hub Transport Servers

Key Points
Each Active Directory site with an Exchange Server 2010 Mailbox server requires at least one Hub
Transport server to process the delivery of messages. If there is no Hub Transport server available in an
Active Directory site, Exchange Server users with mailboxes in that site will not be able to send or receive
messages.
High availability for message transport is particularly important for Hub sites. When a Hub site exists on a
routing path, all messages are forced to go through a Hub Transport server in that site. If no Hub
Transport servers are available in a Hub site, then messages cannot be delivered on that routing path.
To implement high availability for message transport in a site, you need to install multiple Hub Transport
servers in the site. No additional configuration is required. If one Hub Transport server in a site is
unavailable, Exchange services will automatically use the other Hub Transport server for message
transport.
Applications that use a Hub Transport server for message relaying will not automatically fail over to
another Hub Transport server unless the application can be configured with multiple destinations. To
provide high availability for applications, you must configure a load-balancing cluster for the Hub
Transport servers.
When a Hub Transport server fails, it may have messages in a queue waiting to be delivered. These
messages would be lost, but shadow redundancy ensures that messages are not lost. With shadow
redundancy, messages remain in the transport dumpster of other Hub Transport servers until they are
notified that the message has been delivered.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-27

You need to determine how many Hub Transport servers are justified for high availability. In branch
offices with a single server performing multiple roles, high availability for message transport may not be
important. For a main site with a large data center hosting mailboxes for thousands of users, you might
decide that three Hub Transport servers are necessary to provide the necessary level of redundancy. The
Hub Transport server role is commonly combined with the Client Access server role.
Question: Is high availability for Hub Transport more important for some sites than others?

8-28

Planning and Deploying High Availability

Designing High Availability for Client Access Servers

Key Points
All clients use Client Access servers to access mailboxes. Even MAPI clients use a Client Access server to
access mailbox contents. If a Client Access server is not available in an Active Directory site, users cannot
access their mailbox contents.
Depending on the design of Internet access to Client Access servers, the failure of a Client Access server in
an Active Directory site can prevent users from multiple sites from accessing mailbox contents. If users on
the Internet connect to Client Access servers in a single main Active Directory site, and those requests are
proxied to other Active Directory sites, the failure of Client Access servers in the main sites prevents access
to those proxied sites. Consequently, high availability becomes critical for the main site that proxies the
requests.
To implement high availability for a Client Access server, you use load balancing between the Client
Access server and a client access array. You can use hardware-based load balancing or software-based
load balancing. Windows Server 2008 includes the NLB feature. Your organization can select the type of
load balancing that you are most comfortable with.
Load balancing spreads client requests between the Client Access servers. If one Client Access server
becomes unavailable, then requests are handled by the remaining Client Access servers. The client access
array directs clients to the host name used by the load-balanced cluster.
All Client Access servers in the array must be configured with the same Secure Sockets Layer (SSL)
certificate. This is because all Client Access servers use the name specified in the client access array.

Internet Users
For Internet users, you need to consider redundant Internet connections as part of your design. You can
have two separate ISPs, and allow access through both to the Client Access servers in your organization. If
one ISP experiences a failure, users can access their mailbox content by using the alternate ISP at a
different domain name.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-29

Alternatively, if you configure each Active Directory site to be available directly from the Internet, the
failure of a single Internet connection affects connectivity only to one Active Directory site. This mitigates
the damage caused by failure, but does not provide complete redundancy.
Question: Is high availability for Client Access servers more important for some sites than
others?

8-30

Planning and Deploying High Availability

Designing High Availability for Edge Transport Servers

Key Points
The failure of an Edge Transport server can prevent an organization from receiving new Internet
messages. It can also prevent Exchange Server 2010 users from sending messages to Internet recipients. In
many cases, an interruption in Internet mail is considered a critical business event.
To make the Edge Transport server role highly available, you can install a second Edge Transport server.
For external message delivery, no additional configuration is required. For message reception, you must
configure an additional MX record for the second Edge Transport server. If both MX records have the
same priority, then incoming messages are load-balanced between the two Edge Transport servers.
To provide network redundancy for message delivery to the Internet, you can use two ISPs. Many firewalls
are capable of failing over to a second Internet connection when the primary connection fails. To receive
messages on the second Internet connection, you must create additional MX records.
If your Exchange Server organization has multiple points of contact with the Internet and multiple
locations with Edge Transport servers, this does not provide redundancy for outgoing messages. Messages
are delivered only on the lowest cost path. If the Edge Transport servers on the lowest cost path are
unavailable, the messages are queued on a Hub Transport server for delivery to the Edge Transport server.
Routing paths are not recalculated based on availability.
Question: Is high availability for Edge Transport servers important for your organization?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-31

Designing High Availability for Servers with Multiple Roles

Key Points
Exchange Server 2010 allows you to combine multiple server roles on a single Exchange server. For
example, a branch office may have only a single Exchange server that performs the Mailbox, Client Access,
and Hub Transport server roles. Even in larger organizations, it is common to combine all three core server
roles on each Exchange server to simplify the overall design.
When combined on a single server, there is no conflict between the high availability methods used for the
different server roles. An Exchange server with multiple server roles can be a member of a DAG or of a
client access array. If you are using a DAG, the server that is a DAG member cannot also be a member of
an NLB cluster. However, you can use hardware-based load balancing instead.

Transport Modification
Message transport is modified when the Hub Transport and Mailbox server roles are installed on the same
server. The transport path is modified to force messages to be delivered through a second server. This
ensures that the message is in the transport dumpster and shadow queues of an alternate server in case of
a server failure.
When the Mailbox Submission Service contacts a Hub Transport server role, it gives preference to a Hub
Transport server role on a separate server. For example, VAN-EX1 and VAN-EX2 both have the Hub
Transport and Mailbox server roles installed. When a user with a mailbox on VAN-EX1 sends a message,
the Mailbox Submission Service on VAN-EX1 prefers to notify VAN-EX2 to pick up the message from the
outbox.
When a Hub Transport server role has a message for delivery to a mailbox on the same server, the
message is first delivered to a Hub Transport server role on another server for delivery back to the
mailbox. For example, VAN-EX1 and VAN-EX2 both have the Hub Transport and Mailbox server roles
installed. When the Hub Transport server role on VAN-EX2 has a message for delivery to a mailbox on
VAN-EX2, it delivers the message to the Hub Transport server role on VAN-EX1 for delivery to the mailbox
on VAN-EX2.

8-32

Planning and Deploying High Availability

Capacity Planning
When you are planning capacity and optimizing performance, you need to consider not only the roles
that are running on the server now, but the additional load that will be placed on the server if another
server fails. For example, a single server that is a member of a DAG and in a client access array experiences
a load increase if another server in the DAG or another server in the client access array fails. This makes
performance planning more complex.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-33

Lesson 4

Designing Site Resilience

Site resilience allows messaging services to survive the failure of a physical location. Exchange Server 2010
supports site resilience for mailbox databases protected in a DAG. However, you should be aware of the
several considerations that are specific to the design of site resilience.
After completing this lesson, you will be able to:

Describe the options for providing site resilience in Exchange Server 2010.

Describe how site resilience works.

Design DAGs for site resilience.

Design other server roles for site resilience.

Design site failover and failback.

8-34

Planning and Deploying High Availability

What Is Site Resilience?

Key Points
Site resilience is the ability of the messaging system to survive a site failure, and to continue functioning
through the use of an alternate data center. In some cases, the alternate data center is a site that is
dedicated only to disaster recovery. In other cases, the alternate data center could be another company
site that is in use, but has sufficient capacity to handle services for the failed location.
A DAG is capable of existing across multiple subnets. This means that a DAG can exist across multiple
Active Directory sites. This is a major improvement over previous versions of Exchange Server that require
you to extend a subnet across a WAN link.
Site resilience exists only for Mailbox servers. Any other server roles that are required must already exist in
the site; they do not fail over. For example, Hub Transport servers and Client Access servers should already
exist in the alternate data center. Other servicessuch as DNS, domain controllers, and global catalog
serversmust also be available in the alternate data center.
Question: Does your organization plan for site resilience as part of its disaster recovery
planning?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-35

How Site Resilience Works

Key Points
At the simplest level, site resilience allows for a database in a DAG to fail over to an alternate data center.
Clients can continue to access their mailbox contents and send messages. It is important to understand
how clients behave during this process, so that you can make appropriate design decisions.
When the primary data center fails, the database is activated in the alternate data center. Client
computers locate an appropriate Client Access server or array for a database by using the
RPCClientAccessServer property of the database. Unless a specific action is taken, the client computers
still use the client access array in the primary site. Clients continue to have access to mailboxes by using
the client access array in the primary site, if it is available. The client access array in the primary data
center communicates with the Mailbox server in the alternate data center.
It is more efficient from a network perspective to have clients access a client access array in the alternate
data center. In particular, when the WAN link has high latency, there is improved performance. The
simplest way to redirect clients to the client access array in the alternate datacenter is to modify the DNS
record of the local client access array to resolve as the IP address of the client access array in the alternate
datacenter. You may need to clear the DNS cache on client computers for the DNS change to take effect.
You also have the option to update the RPCClientAccessServer property of the database to direct clients
to a client access array in the alternate data center. The behavior of clients varies depending on the
version of the Microsoft Office Outlook messaging client. In all cases, clients first attempt to connect to
the client access array in the primary data center.
Note To update the RpcClientAccessServer property of a database, use the SetMailboxDatabase cmdlet.

8-36

Planning and Deploying High Availability

Each Outlook client behaves as follows:

Outlook 2010 clients perform an Autodiscover to get the updated Client Access server property,
update the local profile, and then begin communicating with the client access array in the alternate
data center. After a restart, Outlook 2010 clients can connect directly to the client access array in the
alternate data center. This behavior is the same whether the Client Access server in the primary data
center is available or not.

Outlook 2007 clients perform an Autodiscover to get the updated Client Access server property, and
then begin communicating with the client access array in the alternate data center. If the Client
Access server in the primary data center is available, the profile is not updated automatically, and the
client continues to connect to the client access array in the primary site before being redirected to the
alternate data center. If the Client Access server in the primary data center is not available, the profile
is updated, and the client must restart.

Outlook 2003 clients are never redirected to the new client access array. You must manually update
the profile to use the new client access array.
Question: Which version of Outlook does your organization use?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-37

Designing DAGs for Site Resilience

Key Points
To configure a DAG for site resilience, the DAG must have at least one member in an alternate data
center. Then databases can be replicated to the member in the alternate data center. No other specific
configuration is required on the Mailbox servers, or for databases.
A DAG supports having multiple subnets on the MAPI network, and multiple subnets on a replication
network. Therefore, subnets do not need to span a WAN link. However, there can be no routing between
the MAPI network and the replication network. The WAN link must support both networks.
In addition to the Mailbox server in the alternate data center, you also need to install a Client Access
server and a Hub Transport server. To reduce hardware requirements in the alternate data center, you can
place the Client Access server and Hub Transport server roles on the same computer as the Mailbox server
role. However, you should do so only if the computer has sufficient capacity.
An alternate witness server must be configured in the alternate data center. The alternate witness server is
used when recovery to the alternate data center begins. Until recovery to the alternate data center is
performed, the alternate witness server is not used.
Use Datacenter Activation Coordination (DAC) mode for DAGs with members that span two locations.
Previous versions of Exchange Server recommend the use of a third physical location for geographically
distributed clusters to prevent the split-brain syndrome. The split-brain syndrome occurs when more than
one DAG member mounts a database. This is a problem because there is no way to reconcile the different
content in the two mounted databases. In Exchange Server 2010, the DAG includes DAC to prevent the
split-brain syndrome.
Question: Why is the DAC mode important?

8-38

Planning and Deploying High Availability

How DAC Mode Works

A DAG that does not use DAC mode relies only on a quorum to determine which members of the DAG
can activate a database. A quorum is achieved when a majority of members can communicate. A witness
server is considered to be one of the members for the purposes of calculating the quorum. For example, if
there is a three-member DAG, and one member loses connectivity, the two remaining members achieve a
quorum and are able to activate databases. The single node is not part of the quorum, and cannot
activate databases.
The default configuration of a DAG creates problems in creating a DAG with site resiliency. A threemember DAG with two members in the primary site and one member in an alternate data center can
experience split-brain syndrome when the servers cannot determine which servers should be active. If the
primary data center fails and you activate the alternate data center, split-brain syndrome arises when you
restart the primary data center without connectivity to the alternate data center. The two servers in the
primary data center have a quorum when they restart and activate their databases. The databases are
active in both the primary site and the alternate data center, with no method to resolve the data changes
between them.
You can use the DAC mode to avoid split-brain syndrome in a DAG that spans multiple locations. When
you activate the DAC mode, each DAG member stores a Datacenter Activation Coordination Protocol
(DACP) bit in memory that indicates whether that member is allowed to mount databases. Each time a
DAG member starts, the DACP bit is set to 0, which indicates that mounting is not allowed. The DAG
member communicates with other DAG members to find out their status. When the DAG member finds
another DAG member with the DACP bit set to 1, it sets its own DACP bit to 1, and can now mount
databases.
Note: To enable DAC mode for a DAG, use the command Set-DatabaseAvailabilityGroup
dagname DatacenterActivationMode DagOnly in the Exchange Management Shell.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-39

Two node DAGs

Exchange Server 2010 with SP2 adds support for using DAC mode with two-node DAGs with two
locations. In versions before Exchange Server 2010 with SP2, a DAG needs three or more nodes to use
DAC mode. To support DAC mode with two-node DAGs, the evaluation of whether a node can mount
databases also includes the boot time of the alternate witness server in the alternate data center.
The remaining single node in a two node DAG and the alternate witness server should never be rebooted
at the same time, or else DAC mode may prevent the single remaining node from starting databases. At
this point, you would be forced to reset the DACP bit in the DAG by using the RestoreDatabaseAvailabilityGroup cmdlet.

8-40

Planning and Deploying High Availability

Designing Other Roles for Site Resilience

Key Points
For Mailbox servers, you can use a DAG across multiple physical locations to provide site resilience. For
other server roles, there is no special configuration to provide site resilience; those server roles must
already exist in the alternate data center.

Hub Transport
Message transport is performed based on Active Directory sites. Each Active Directory site with a Mailbox
server must have a Hub Transport server as well. When a database is activated in the alternate data center,
it uses the Hub Transport server in the alternate data center. No specific configuration is required for
message transport.
If you have applications that are configured to use a specific Hub Transport server for relaying messages,
you need to direct those applications to a new Hub Transport server. If the application is configured to
use the IP address of the Hub Transport server, you must reconfigure the application to use the IP address
of a Hub Transport server in the alternate data center. If the application is configured to use the hostname
of the Hub Transport server, you can modify the host record for the Hub Transport server to use the IP
address of the Hub Transport server in the alternate data center.
You should ensure that the Hub Transport servers in the alternate data center have sufficient capacity to
handle the volume of message processing that is expected when the alternate data center is used.

Client Access
It is not possible to span a client access array over multiple subnets. So, similar to a Hub Transport server,
you need to include a Client Access server in the Active Directory site in the alternate data center.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-41

If the client access array in the original site is still available, it can continue to provide services for clients,
and access the active database in the alternate data center. This is a good solution if the alternate data
center is going to be used for a short term. If the alternate data center is going to be used for a long term,
you should update the RPCClientAccessServer property on the database. This allows the redirection of
Outlook 2007 and Outlook 2010 clients to the Client Access server in the alternate data center.
If the client access array in the original site is not available, you should update the
RPCClientAccessServer property on the database. This allows Outlook 2007 and Outlook 2010 clients to
use Autodiscover to find the Client Access server in the alternate data center. You can also change the
DNS record for the original client access array to point to the IP address for the client access array in the
alternate data center.
Clients running Outlook Anywhere and the Microsoft Exchange ActiveSync technology locate a Client
Access server that is accessible on the Internet by using DNS records. If the original client access array is
unavailable, you need to change the host record for the external client access to point to the Client Access
server in the alternate data center.
A potential concern is the caching of DNS records. If the client computer caches the hostname of the
Client Access server, you can clear the cache on the client computer by using ipconfig /flushdns or by
restarting the client. However, many Internet DNS servers cache resolved hostnames for 24 hours. To
ensure that clients can access the Client Access servers in the alternate data center quickly, you must
provide clients with an alternate hostname to access services.

Edge Transport
To provide site resilience for Edge Transport servers, you must have a second Internet connection at the
alternate data center. The simplest way to configure site resiliency is by having the Edge Transport servers
already active and able to receive messages.
Incoming messages are directed to an Edge Transport based on MX records in DNS. The MX records are a
pointer to the hostname of the Edge Transport server. To have messages automatically redirected to the
alternate data center when the primary location is unavailable, you can configure multiple MX records.
The priority number for MX records determines the order in which they are used. An MX record with a
lower priority number is contacted first. The MX record for the alternate data center has a higher priority
number than the MX record for the primary data center. With this configuration, mail servers attempt
delivery to the primary data center first, and if the primary data center is unavailable, the messages are
delivered to the alternate data center.
Messages transported through the alternate data center automatically use the Edge Transport server in
the alternate data center for message delivery, because it is the closest Edge Transport server.

8-42

Planning and Deploying High Availability

Designing Failover and Failback Between Sites

Key Points
Failover and failback for databases within a site can be automatic, and clients may not even notice them.
But failover and failback between sites is disruptive and can impact service. Consequently, failover and
failback between sites is considered a disaster recovery event, and must be performed manually.

Failover Considerations
When you design the failover process for a DAG, you should fail over to servers in the primary data center
before failing over to the alternate data center. The failover process to an alternate data center can be
disruptive. For example, a three-member DAG with two servers in the primary data center should only
activate a database in the alternate data center if both the servers in the primary data center are
unavailable.
When the primary data center fails, you should consider whether repair is possible before failing over to
the alternate data center. If the primary data center is going to be offline temporarily, it may cause a
greater interruption to fail over to the alternate data center, than to wait for the primary data center to
become available again. This decision is influenced by the Service Level Agreement (SLA) associated with
the mailbox databases.

Failback
Just as the failover process to an alternate data center is manual, so is the failback process. Before failing
back any databases to the primary data center, you should ensure that all necessary servicessuch as
DNS, domain controllers, and global catalog serversare functioning properly. Hub Transport and Client
Access servers in the primary data center also need to be functional.
When the DAG members in the primary data center and all necessary services are functioning again, you
can replicate the databases back to the primary data center. When replication is complete, you can
activate the databases in the original site. The activation of databases in the primary site does not need to
be done during off-hours.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-43

Discussion: Failure Scenarios

It is important to understand how a DAG with site resilience responds when a node fails. You can create
an appropriate recovery plan only if you understand the failover process.
In scenario 1, Site A has two Mailbox servers and a witness server. Site B has a single Mailbox server and
an alternate witness server. All active mailbox databases are on the Mailbox servers in Site A. Each Mailbox
server has database copies of all mailbox databases.
Question: If the WAN link between Site A and Site B fails, what impact does it have on the
active databases in Site A?

Question: How can you ensure that mailbox databases fail over between the Mailbox servers
in Site A rather than failing over to the Mailbox server in Site B?

In scenario 2, Site A has one Mailbox server and a witness server. Site B has a single Mailbox server and an
alternate witness server. All active mailbox databases are on the Mailbox server in Site A. A passive copy of
each mailbox database is on the Mailbox server in Site B.
Question: If the WAN link between Site A and Site B fails, what impact does it have on the
active databases in Site A?

Question: If there were active mailbox databases in Site B when the WAN link failed, how
would they be affected?

Question: If the Mailbox server in Site A fails, does the Mailbox server in Site B automatically
mount the databases?

8-44

Planning and Deploying High Availability

Question: If all of the data center infrastructure in Site A fails, does the Mailbox server in
Site B automatically mount the databases?

Question: If you want two locations to have highly available mailbox databases, how many
DAGs should you have?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-45

Lab: Planning and Deploying High Availability

Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, you must:
1.

On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3 virtual

machines are running.

3.

If required, connect to the virtual machines. Log on to the virtual machines as

Adatum\Administrator using the password Pa$$w0rd.

Lab Scenario
You are a messaging engineer for the A. Datum Corporation, an enterprise-level organization with
multiple locations. A. Datum Corporation is an international corporation involved in technology research
and investment, and is planning to upgrade from Exchange Server 2003 to Exchange Server 2010.
Concerns have been raised about the availability of Exchange Server 2010. Messaging has been
designated as a critical service in the organization. The existing Exchange Server 2003 organization
experienced several outages, and you want to avoid these outages in the future. You need to create a
high availability design for Exchange Server 2010.
Finally, you are required to implement part of your proposed high availability design.
Note Your instructor may choose to do this lab as a group discussion rather than an
individual activity.

8-46

Planning and Deploying High Availability

Exercise 1: Designing High Availability for Exchange Servers

Scenario
In this exercise, you will examine the current topology and messaging infrastructure. You will determine
the appropriate high availability deployment based on the information supplied in the A. Datum
Exchange Server 2010 project documentation.

High Availability Interviews

Marcel Truempy, CIO
In the last five years since I became CIO, our email system has changed from being a useful tool for
business to being a critical part of our business processes, and everybody notices when email is not
available. To give you an example, a couple of months ago, all of the email servers in London were
unavailable for six hours due to a virus outbreak. A couple of months before that, one of the servers in
Vancouver failed, and we couldnt send any email to and from Vancouver for eight hours while the
hardware vendors came in to fix the hardware. This happened right in the middle of some 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 email system is availabilitythis system has to be available always.

Jason Carlson, Network Specialist

I can provide you with a Microsoft Office Visio diagram that has all of our WAN connections, and our
connections to the Internet. Our network right now is quite reliable, but we dont have much available
bandwidth between company locations.

Shane DeSeranno, Network Operations Manager

If you want to replicate a lot of messaging information over the WAN, then we need to consider the cost
of the links to these locations. Within a given continent, WAN links are relatively cheap when compared to
those that cross oceans. I guess that it costs a lot of money to run fiber optic cable on the bottom of the
ocean. Did you know that some WAN links between continents even use satellites? No wonder it costs so
much.
So, ultimately, if possible, from a cost perspective, were better off keeping traffic within a continent.

Conor Cunningham, Messaging Services Manager

Weve gone through a negotiation process for new SLAs that coincides with our Exchange Server 2010
implementation. Any site that has more than 3,000 users must have off-site disaster recovery of
messaging. We dont need to fail over within minutes, but within four hours. That gives us time to decide
whether we can recover a data center, or need to activate the disaster recovery site.
I still havent decided whether we need dedicated disaster recovery sites, or whether we should use some
of our own data centers as disaster recovery sites for each other. The initial setup cost for using our own
data centers is much less, and they have the capacity. I guess it comes down to the cost of network
connectivity with the disaster recovery sites, which would be an ongoing cost that could add up over time.
Smaller sites with less than 3,000 users must be highly available, but we dont need off-site disaster
recovery.

Andreas Herbinger, Messaging Specialist

The larger sites with more than 3,000 users have servers dedicated to specific server roles. The Vancouver
site has two Mailbox servers, a Hub transport server, and a Client Access server in the current plan.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

8-47

The smaller sites combine all server roles on a single physical server. The San Diego site has just one
Exchange server with all server roles in the current plan.
One other issue Im concerned about is logical corruption of database copies in a DAG. I know that this is
a very rare occurrence, but I think it makes sense to protect ourselves against the possibility. As I
understand it, we can configure a delay on a database copy so that a logical corruption in the transaction
logs wont be passed on to the database copy for a period of time. I think a delay of six hours would be
sufficient.

User Distribution Summary

Location

Internal users

Mobile users

London
Corporate Headquarters

12,000 currently
10,000 after the
new London
office is ready

1,000 Outlook Web Access users

500 Outlook Anywhere and mobile client users
800 Outlook users connecting through a virtual
private network (VPN)

London (new office)

4,000
(anticipated)

200 Outlook Web Access users

50 Outlook Anywhere and mobile client users

San Diego
500
Former head office
of Trey Research Corporation

50 POP3 client users

Vancouver

6,000

800 Outlook Web Access users

100 Outlook Anywhere and mobile client users

Tokyo

5,000

1,000 Outlook Web Access users

200 Outlook Anywhere and mobile client users
200 Outlook users connecting through a VPN

Chennai (new office)

800 (anticipated)

200 Outlook Web Access users

50 Outlook users connecting through a VPN

8-48

Planning and Deploying High Availability

Network Configuration

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

The main tasks for this exercise are as follows:

1.

Review the A. Datum Corporation documentation.

2.

Answer questions related to the documentation.

3.

Document the required configuration for the San Diego site.

4.

Document the required configuration for the Vancouver site.

Task 1: Review the A. Datum Corporation documentation

Review the following information:

High Availability Interviews

User Distribution Summary

Network Configuration

Task 2: Answer questions related to the documentation

Note

Your instructor may perform this task as a discussion.

Question: In the High Availability Interviews, what points are raised that impact your high
availability design, and how do they impact it?

Question: Is there anything in the User Distribution Summary that raises high availability issues?
If so, what is it?

Question: Is there anything in the Network Configuration that raises high availability issues? If so,
what is it?

8-49

8-50

Planning and Deploying High Availability

Task 3: Document the required configuration for the San Diego site

Complete the following proposal document by answering the questions.

A. Datum High Availability Design for San Diego
Document Reference Number: JC040422/1
Document Author
Date

Jason Carlson
24th April 2010

Requirement Overview
Determine how high availability will be provided for all server roles in San Diego.
Additional Information
Identify infrastructure changes that may be required due to the proposed deployment.
Proposals
Question: Will this site have offsite disaster recovery? If so, where should that site be located?

Question: How do you provide high availability for databases?

Question: How do you provide high availability for Client Access servers?

Question: How do you provide high availability for message transport?

Question: Is high availability required for the Edge Transport server role?

Question: How many Exchange servers will be located in this site? Which roles will they host?

Question: How will databases be configured on the DAG members?

Question: How will load balancing be performed for the Client Access server role?

Question: Is any additional configuration required for the Hub Transport server role

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

Task 4: Document the required configuration for the Vancouver site

Complete the following proposal document by answering the questions.

A. Datum High Availability Design for Vancouver
Document Reference Number: JC040422/2
Document Author
Date

Jason Carlson
24th April 2010

Requirement Overview
Determine how high availability will be provided for all server roles in Vancouver.
Additional Information
Identify infrastructure changes that may be required due to the proposed deployment.
Proposals
Question: Will this site have offsite disaster recovery? If so, where should that site be located?

Question: How do you provide high availability for databases?

Question: How do you provide high availability for Client Access servers?

Question: How do you provide high availability for message transport?

Question: Is high availability required for the Edge Transport server role?

Question: How many Exchange servers will be located in this site? Which roles will they host?

Question: How will databases be configured on the DAG members?

Question: How will load balancing be performed for the Client Access server role?

Results: After this exercise, you should have created a high availability design for the San Diego and
Vancouver sites.

8-51

8-52

Planning and Deploying High Availability

Exercise 2: Implementing High Availability for Exchange Servers

Scenario
In this exercise, you will implement part of the high availability plan for the Vancouver site. VAN-EX1 and
VAN-EX2 are the Mailbox servers located in Vancouver. VAN-EX3 is the Mailbox server located San Diego,
which will have a lagged copy of the database.
Note Due to restrictions in the virtualized environment, VAN-EX3 is not located in a
separate Active Directory site.
The main tasks for this exercise are as follows:
1.

Prepare VAN-DC1 to be a DAG witness server.

2.

Create a three-member DAG.

3.

Configure replication for Mailbox Database 1.

4.

Simulate the failure of VAN-EX1.

5.

Recover VAN-EX1.

Task 1: Prepare VAN-DC1 to be a DAG witness server

1.

On VAN-DC1, open Active Directory Users and Computers.

2.

Add Exchange Trusted Subsystem as a member of the Builtin\Administrators group.

Note This task configures the security to use a Domain Controller without Exchange
Server 2010 installed as the witness server. If a member server is used instead of a domain
controller, Exchange Trusted Subsystem should be added as a member of the local
Administrators group on the member server.

Task 2: Create a three-member DAG

1.

On VAN-EX3, open the Exchange Management Console.

2.

Under Organization Configuration, on the Mailbox node, select the Database Availability Groups
tab and create a new DAG with the following settings:

Database availability group name: VancouverDAG

Witness Server: VAN-DC1

Witness Directory: C:\VanDAGWitness

Note Step 2 generates a warning, because the witness server is not an Exchange server.
This does not indicate a problem. The necessary permissions were configured in Task 1.

3.

Open the properties of VancouverDAG, and then add 10.10.0.200 as an IP address for the DAG.
Note Step 3 generates a warning, because the witness server is not an Exchange Server.
This does not indicate a problem. The necessary permissions were configured in Task 1.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

4.

8-53

Use the context menu of VancouverDAG to add VAN-EX1, VAN-EX2, and VAN-EX3 as DAG
members.

Task 3: Configure replication for Mailbox Database 1

1.

On VAN-EX3, in the Exchange Management Console, on the Database Management tab, add a copy
of Mailbox Database 1 to VAN-EX2.

2.

Add a copy of Mailbox Database 1 to VAN-EX3.

3.

In the Exchange Management Shell, use the following command to configure a replay lag time of six
hours for Mailbox Database 1 copy on VAN-EX3:
Set-MailboxDatabaseCopy Identity Mailbox Database 1\VAN-EX3 ReplayLagTime 0.6:0:0

4.

Use the following command to verify that the replay lag is configured correctly:
Get-MailboxDatabase Mailbox Database 1 | Format-List ReplayLagTimes

5.

Use the following command to view the status of the Mailbox Database 1 copy on VAN-EX3:
Get-MailboxDatabaseCopyStatus Identity Mailbox Database 1\VAN-EX3

Task 4: Simulate the failure of VAN-EX1

1.

On the host computer, in the 10233B-VAN-EX1 window, turn off VAN-EX1.

2.

On VAN-EX3, refresh the Exchange Management Console to view the status of the Mailbox
Database 1 copies.

3.

If any database copy has a status of Disconnected, refresh the view again.

Question: What is the status for Mailbox Database 1 on each server?

Question: Why is the server where the database is mounted selected?

Task 5: Recover VAN-EX1

1.

On the host computer, in the 10233B-VAN-EX1 window, start VAN-EX1.

2.

On VAN-EX3, refresh the Exchange Management Console to view the status of the Mailbox
Database 1 copies.
Question: What is the status for Mailbox Database 1 on each server?

3.

If the status of Mailbox Database 1 on VAN-EX1 is initializing, wait a few minutes, and then click
Refresh again. You may need to select Mailbox Database 1 on VAN-EX1 to refresh its status.

Results: After this exercise, you should have implemented high availability for Mailbox Database 1 in
Vancouver.

8-54

Planning and Deploying High Availability

To prepare for the next module

When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the
following steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3. Close the virtual
machine connection windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then, in the Actions pane, click Start.

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then, in the
Actions pane, click Connect.
Important: Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully
started before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10233B-VAN-EX1. Connect to the virtual machine.

8.

Wait for 10233B-VAN-EX1 to start, and then start 10233B-VAN-CL1. Connect to the virtual machine.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

Module Review and Takeaways

Review Questions
1.

To make a highly available Exchange Server organization, which components must be highly
available?

2.

Which Exchange Server 2010 feature provides fault tolerance for message delivery?

3.

How many networks should be used for a DAG?

4.

What are the requirements for using the DAC mode?

Best Practices Related to High Availability for Client Access Servers

Supplement or modify the following best practices for your own work situations:

Use a client access array and load balancing to make client access highly available.

If a Client Access server is also a member of a DAG, then use hardware-based load balancing.

Ensure that Internet-accessible sites that proxy Client Access for multiple sites are highly available,
because their outage will affect many users.

When a DAG fails over to an alternate site for a short period of time, allow the clients to continue
using the client access array in the original site.

When a DAG fails over to an alternate site for an extended period of time, reconfigure the
RPCClientAccessServer property of the databases to direct clients to a client access array in the
alternate site.

8-55

8-56

Planning and Deploying High Availability

9-1

Module 9
Planning a Disaster Recovery Solution
Contents:
Lesson 1: Planning for Disaster Mitigation

9-3

Lesson 2: Planning Exchange Server Backup

9-17

Lesson 3: Planning Exchange Server Recovery

9-27

Lab: Planning a Disaster Recovery Solution

9-41

9-2 Planning a Disaster Recovery Solution

Module Overview

Disaster recovery planning is an essential requirement for fulfilling service level agreements (SLAs). These
agreements define when a service needs to be available, and how quickly it must be recovered if it fails.
To ensure that you meet SLA requirements, you need to plan how Microsoft Exchange Server 2010 will
be backed up and restored.
After completing this module, you will be able to:

Plan for disaster mitigation.

Plan Exchange Server 2010 backup.

Plan Exchange Server 2010 recovery.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 9-3

Lesson 1

Planning for Disaster Mitigation

Disaster mitigation avoids the need for disaster recovery, and it allows you to recover data much faster
than with a full restore. Exchange Server 2010 has improved the disaster mitigation methods that are
available to administrators, with features such as database availability groups (DAGs).
After completing this lesson, you will be able to:

Identify potential disasters or data loss scenarios.

List the Exchange Server 2010 features that can alleviate the impact of disaster or data loss scenarios.

Design Exchange Server 2010 for disaster mitigation.

Identify the relationship between high availability and disaster mitigation.

Design an Exchange Server 2010 high availability solution for disaster mitigation.

Describe backup-less Exchange Server.

Describe recovery time objective (RTO) and recovery point objective (RPO).

Identify scenarios that may require backup and restore.

9-4 Planning a Disaster Recovery Solution

Identifying Data Loss Scenarios

Key Points
To understand which type of disaster mitigation method is appropriate, first consider the potential data
loss scenarios. Each scenario requires different disaster mitigation methods.

Lost Item
A lost item from a mailbox often occurs because a user deleted that item. The item could be deleted by
accident, or the item could be deleted on purpose and the user may only realize later that the item was
required.
One lost mailbox item typically consists of a small amount of data. However, that small amount of data
can be very important. A lost item could be a mail message or a calendar item, and may include
attachments.

Lost Mailbox
A lost mailbox results in the entire contents of that mailbox being lost. A lost mailbox is typically the result
of deletion by an administrator. While this could occur accidentally, deletion is more commonly done
when a user leaves the organization. After the user account is deleted, a manager or former colleague
may need access to the mailbox to review what the user was working on.

Lost Database
A lost database results in a loss of all mailboxes in that database. Additionally, while the database is
missing, users with mailboxes in that database can no longer send or receive messages.
A lost database typically occurs because of a system malfunction, which can include disk failure or
database corruption. Lost database recovery is critical, because many users are affected by the outage.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 9-5

Lost Server
A lost server results in a loss of all databases on that server. A lost server typically occurs because of a
system or infrastructure failure. For example, the servers power supply could fail, or there could be a fire
in the server room. Lost server recovery is critical, because many users are affected.
Question: Can you think of any other ways that Exchange Server data can be lost?

9-6 Planning a Disaster Recovery Solution

Data Loss Mitigation Features

Key Points
Exchange Server 2010 includes a number of features that you can use to mitigate data loss. These are
important, because when you mitigate data loss, you do not need to perform recovery from backup. It is
typically much faster to use these data loss mitigation methods than to recover from backup.

Deleted Item Recovery

In earlier Exchange Server versions, user-deleted items were still recoverable until the items were purged
from the dumpster. A hard delete (SHIFT+DELETE) permanently removed messages. This is also the
default configuration in Exchange Server 2010. If the default times are not modified, then Exchange Server
purges mail messages after 14 days, and calendar items after 120 days.
Single-item recovery allows you to recover a message after a user deletes an item. The message is
recoverable even if the user performed a hard deletion. Also, the dumpster stores multiple versions of
edited items. If the default times are not modified, then Exchange Server purges mail messages after 14
days, and calendar items after 120 days.
If you enable a litigation hold, then items are never purged from the dumpster. This helps you to ensure
that no messages are lost.
Note For more information about single-item recovery, see Single Item Recovery in
Exchange Server 2010 on The Microsoft Exchange Team Blog
(http://go.microsoft.com/fwlink/?LinkID=185406).

Other Data Loss Mitigation Features

Other data loss mitigation features include:

Deleted mailbox retention. Use deleted mailbox retention to recover deleted mailboxes and their
contents. By default, Exchange Server retains deleted mailboxes in the mailbox database for 30 days.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 9-7

DAG. Use a DAG in most scenarios to recover from a lost server or a lost database. When a server or
database fails, Exchange Server mounts a replicated copy of that database onto another member of
the DAG. This process is much faster than restoring a database from backup.

Shadow redundancy. Shadow redundancy is automatically enabled for all Exchange Server 2010 Hub
Transport and Edge Transport servers. Transport servers keep a copy of the message they are sending
until it is delivered to the next Hub Transport or Mailbox server. This ensures that messages are not
lost in transport due to a server failure.
Question: Which of these data loss mitigation features do you think you will use most often?

9-8 Planning a Disaster Recovery Solution

Designing a Disaster Mitigation Strategy

Key Points
The default Exchange Server configuration is sufficient for many organizations. However, consider the
following when planning your disaster mitigation strategy:

Increase deleted item retention so that the items are recoverable for a longer time period. However,
the default 14 days is normally a sufficient time period, and lowering this value has a minimal impact
on database size.

Increase the deleted item retention time period for specific users. By increasing the deleted item
retention time period for critical users or users most likely to require item recovery, you limit the
increase in database size, and meet the needs of users.

Enable single-item recovery to ensure that all items are recoverable. Single-item recovery prevents
users from hard-deleting items and purging them from the dumpster. The items are invisible to the
user, but they are recoverable by an administrator.

Increase deleted mailbox retention so that mailboxes are recoverable for a longer period of time. The
default 30 days is normally a long-enough time period, and lowering the value has a minimal impact
on database size.

Use DAGs to provide server-level redundancy and avoid data loss. You must have the Enterprise
version of the Windows Server 2008 operating system. However, unlike with previous Exchange
Server versions, the Enterprise version of Exchange Server is not required.

Use replay lag time to prevent database corruption. Database corruption can occur when a
transaction is placed in the transaction logs. In such cases, replay lag times may prevent corruption of
the passive copy, because you can prevent the offending transaction from being replayed on the
passive copy.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 9-9

What Is the Relationship Between Disaster Recovery and High Availability?

Key Points
High availability provides fault tolerance for various parts of a system. Fault tolerance is typically provided
through redundant components. In servers, Redundant Array of Independent Disks (RAID) arrays provide
fault tolerance for hard drives. On a network, redundant routing paths provide fault tolerance. Exchange
Server 2010 enables you to make each server role highly available.
Disaster recovery is required when high availability fails. For example, a RAID 5 array can survive a singledisk failure. However, if multiple disks fail, then data loss occurs and you must perform disaster recovery
to retrieve the data.
You also need disaster recovery when high availability does not provide the required functionality. For
example, high availability does not provide for long-term data archiving. To recover historical data, you
must perform a restore from an archive. You typically use high availability to maintain the current state of
a system.

9-10 Planning a Disaster Recovery Solution

Designing a High Availability Solution for Disaster Mitigation

Key Points
Exchange Server 2010 provides methods to make each server role highly available. When properly
implemented, the need for disaster recovery is small.
Exchange Server 2010 supports the following high availability methods:

DAGs for mailbox databases. In a DAG mailbox, databases are replicated to multiple servers. If one
server or database fails, Exchange Server mounts a replica on another server and continues servicing
client requests. This avoids the need to recover a failed Mailbox server or corrupted mailbox database.

Replication for public folders. A public folder database cannot be replicated in a DAG. However, to
provide high availability, you can replicate individual public folders and their contents between public
folder databases on different servers, and between sites. This avoids the need to recover a failed
Mailbox server or corrupted public folder database.

Multiple Hub Transport servers for message transport. Message transport is automatically made
highly available when you have multiple Hub Transport servers in a site. If one Hub Transport server
fails, then the remaining Hub Transport servers service all requests. This avoids the need to recover a
failed Hub Transport server.

Client access arrays for client access. When you implement a client access array and configure load
balancing between Client Access servers, you make client access highly available. If one Client Access
server fails, then the remaining Client Access servers handle the client requests. This avoids the need
to recover a failed Client Access server.

Multiple Edge Transport servers for edge transport. To make edge transport highly available, you
need two Edge Transport servers in the perimeter network. Outgoing messages are automatically
load-balanced between the two Edge Transport servers, and if one fails, the other continues
delivering all messages. For inbound messages, you must either initiate load balancing, or configure
one mail exchanger (MX) resource record for each Edge Transport server. This avoids the need to
recover a failed Edge Transport server.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-11

When high availability is used for a server role, you are not required to recover a failed server. However, in
most cases you will replace the failed server with a new server that provides the same functionality. This is
required to continue providing the same level of high availability. For example, when a member if a DAG
fails, the databases will mount on other DAG members, and you will then add a new DAG member to
replace the functionality of the lost DAG member.
Question: Which of these high availability methods do you think your organization will
implement?

9-12 Planning a Disaster Recovery Solution

Exchange Native Data Protection

Key Points
Exchange native data protection is the combination of disaster mitigation technologies found in Exchange
Server 2010. When properly configured, you can use Exchange native data protection as an alternative to
traditional backups. To use Exchange native data protection as an alternative to traditional backups, at a
minimum you need a DAG and single-item recovery. You should also consider the use of personal
archives and litigation holds.

Database Copies
Exchange native data protection requires at least three database copies for each mailbox database. The
chance of all three database copies being lost is very small, and thus there is no need to perform a backup
for disaster recovery. If a Mailbox server fails, a database copy on another server is activated.
To mitigate the risk of a lost site due to a disaster such as a fire, you should have at least one database
copy in a remote site. This is the equivalent to having a backup tape stored offsite.
When using a traditional backup solution, the transaction logs for a mailbox database are truncated
during a full backup. Backups are not performed with Exchange native data protection, and transaction
logs are not truncated. You should enable circular logging on databases to prevent log files from taking
up unnecessary disk space. The DAG ensures that all log files are replicated before they are removed.

Lagged Database Copies

To mitigate the risk of logical corruption affecting all database copies, you should configure a lagged
database copy. A lagged database copy delays replay of logs for up to 14 days. When you activate the
lagged database copy, you can select the point in time to which it recovers. You can also specify a
truncation delay on the lagged database copy to keep transaction logs for up to 14 days after they are
replayed in the database.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-13

Single-Item Recovery
To ensure that you can recover individual items after users have deleted them, you enable single-item
recovery on each Mailbox. Single-item recovery keeps copies of deleted items even when they were
deleted by the user. The administrator can then use Multi-Mailbox Search to find and recover the items.
Single-item recovery is not enabled on mailboxes by default.
You need to determine an appropriate length of time in which you can recover items. The default time
that items are available for recovery is 14 days. You may want to extend this time when using Exchange
native data protection because deleted item recovery is the only option for recovering deleted items;
there is no backup to restore. However, as you extend the retention period, additional disk space is
consumed by the mailbox databases. If required, you can vary the retention time for individual users.

Archiving
The biggest concern many organizations have when considering Exchange native data protection is the
lack of long-term archiving. When deleted items are no longer available through single-item recovery,
they are not recoverable. Carefully consider the policies your organization has in place for Exchange
Server data retention. Most organizations rarely need to recover archived Exchange Server data.
The storage improvements in Exchange Server 2010 allow you to consider using larger and less expensive
storage. This in turn allows you to increase the time the items are retained by single-item recovery.
One alternative to consider is occasional backups for archival purposes. If specific data needs to be
archived, you should implement messaging records management (MRM). It may be possible to locate all
mailboxes that need to be archived in a single mailbox database that is backed up.

Reduced Costs
Exchange native data protection reduces costs in the following ways:

Simplified management. After the initial configuration, Exchange native data protection is much
easier to manage than backups. There is no ongoing need to manage backup media.

No backup software or hardware. The cost to purchase backup software and hardware can be
significant. This is no longer required.

No RAID. When three or more database copies are implemented, the recommended disk
configuration is just a bunch of disks (JBOD). This disk configuration is less expensive to implement
than RAID.
Note Remember that to implement a DAG, you need to use the Enterprise version of
Windows Server and multiple servers. In smaller organizations, this may increase costs.

9-14 Planning a Disaster Recovery Solution

Discussion: When Is Exchange Native Data Protection Appropriate?

Exchange native data protection offers a number of advantages over traditional backups. Your
organization may have specific needs for implementing Exchange native data protection.
Question: When compared to traditional backups, how does Exchange native protection
affect recovery time?

Question: How does using Exchange native data protection affect the backup window?

Question: Does Exchange native data protection meet the archiving needs of your
organization?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-15

What Are the Timelines for Disaster Recovery

Key Points
The timelines for disaster recovery are determined by the SLA. Each SLA should have an RTO and an RPO
that you use to determine how to perform backups and disaster recovery.
The RTO for a service defines how quickly you should recover the service. For example, after a Mailbox
server fails, the RTO for the Mailbox server might indicate that you need to recover the mailboxes stored
on that server within two hours.
In some cases, there may be an RTO for partial functionality. For example, after a Mailbox server fails, the
RTO for sending and receiving messages might be one hour, but the RTO for historical data in mailboxes
might be 12 hours.
The RPO for a service defines at what point in time you must recover the service. The RPO may indicate
that data from a specific timeframe can be lost, or that recovery must equal a certain point in time. For
example, the RPO for a Mailbox server may indicate that up to 12 hours of data may be lost, or that a
Mailbox server must be recovered to the backup at 02:00 the previous night.
Based on your RTO and RPO for Mailbox servers, you may choose to:

Keep databases small to shorten recovery times.

Keep transaction logs on separate drives from the databases to ensure that you can replay them after
a database restore.

Perform a backup every few hours to ensure minimal data loss.

Note If you are using a DAG with at least three database copies for high availability, then
backups will be less frequent, and it is not necessary to separate transaction logs and
databases on separate disks.
Question: Does your organization have formally defined RTOs and RPOs for messaging?

9-16 Planning a Disaster Recovery Solution

Scenarios Requiring Backup and Restore

Key Points
After implementing data loss mitigation and high availability for Mailbox servers, you will still encounter
scenarios that require backup and restore. Scenarios requiring backup and restore include:

Recovering a hard-deleted message when single-item recovery is not enabled. If single-item recovery
is not enabled on a Mailbox server and a user hard deletes an item, Exchange Server removes the
item from the database without placing it in the dumpster.

Recovering a message after the item retention period has passed. Even when you enable single-item
recovery, Exchange Server only retains deleted items for the specified time period. By default, this is
14 days for mail messages.

Recovering a public folder item after the item retention period has passed. Exchange Server only
retains a deleted item in a public folder for the specified time period. By default, this is 14 days.

Recovering a database when you are not using a DAG. You must recover failed mailbox databases
from backup when they are not replicated in a DAG. Alternatively, you can use database repair tools,
but it is typically faster to restore from backup than to repair a database.

Recovering from a server failure when you are not using a DAG. When a Mailbox server fails, all
mailbox databases on that server are lost if they are not replicated as part of a DAG. You must recover
the server from backup.

With a DAG in place, you may consider not backing up Mailbox servers regularly. With multiple database
copies and a replay lag time used to mitigate data corruption, you can avoid restoring a database.
Additionally, you can guarantee deleted-item recovery for a period of time by using single-item recovery.
You can extend the time period for single-item recovery to meet your organizational requirements.
Question: When did you last restore an Exchange server? Why did you need to restore it?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-17

Lesson 2

Planning Exchange Server Backup

When planning Exchange Server backup, consider which data you need to restore. You only need to back
up the data that needs restoring. Limiting the backup data size decreases the time it takes to perform the
backup, and allows you more flexibility in your backup schedule.
The software you use to perform backups can also influence your backup process. There are many thirdparty solutions for backing up Exchange Server 2010. You can also use Windows Server Backup in the
Windows operating system and Microsoft System Center Data Protection Manager.
After completing this lesson, you will be able to:

Identify backup requirements for Mailbox servers and data.

Identify backup requirements for non-Mailbox servers.

Choose Exchange Server Backup software.

Choose Exchange Server backup media.

Design an Exchange Server backup schedule.

Design an Exchange Server backup management process.

9-18 Planning a Disaster Recovery Solution

Identifying Backup Requirements for Mailbox Servers

Key Points
To support disaster recovery for database and Mailbox server failures, maintain backups for the following:

Mailbox databases. To recover the contents of the mailboxes in a mailbox database, you must
maintain a mailbox database backup. You can restore this database to the same server or to another
Mailbox server.

Public folder databases: To recover the contents of the public folders in a public folder database, you
must maintain a public folder database backup. You can restore this database to the same server, or
to another Mailbox server.

Transaction logs. Transaction logs are an important part of an Exchange Server 2010 backup. After
restoring a database, Exchange Server 2010 replays the transaction logs to bring the database up to
the current state and make it consistent with the previous version of the database. If you perform an
incremental backup, then only transaction logs are backed up.

You do not have to back up Mailbox server configuration data. All configuration data for a Mailbox server
is stored in the configuration partition of Active Directory Domain Services (AD DS). You can retrieve
any necessary configuration data required for a server restore from AD DS.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-19

Identifying Backup Requirements for Non-Mailbox Servers

Key Points
Non-Mailbox servers contain little data that you need to back up. As with Mailbox servers, the AD DS
configuration partition stores all non-Mailbox server configuration data. You can retrieve any necessary
configuration data required for a server restore from AD DS. However, a server restore is seldom
necessary, because you can replace the functionality with a new server instead of restoring a failed server.
The following table lists the data you may want to back up for specific server roles.
Server role

Data to back up

Client Access

Customized website pages and configuration settings. You do not need a

Hub Transport

Message transport logs. Backing up these logs may be useful for later

Edge Transport

Server configuration. This is stored locally rather than in AD DS. You should

Unified Messaging

Customized audio prompts. If not backed up, the prompts are lost when the

system state backup to back up configuration settings in Internet Information

Services (IIS) 7.0, just a backup of the configuration directory. If you do not
have this data backed up, you can reconfigure it.
Secure Sockets Layer (SSL) certificate with private key. However, if you do not
back up the SSL certificate, you can always purchase another one.
troubleshooting. However, no backups are required to restore functionality.

clone the configuration to back up the server configuration.

Unified Messaging servers fail.

Question: Do you customize Microsoft Office Outlook Web App or Outlook Web Access
pages in your organization?

9-20 Planning a Disaster Recovery Solution

Choosing Exchange Server Backup Software

You can back up by using the built-in Windows Backup software, System Center Data Protection Manager
(DPM), or third-party software. Choose the software based on the features that you require. At a
minimum, use backup software that the vendor indicates works properly with Exchange Server 2010.
The backup software that you choose must support Volume Shadow Copy Service (VSS) backups. A VSS
backup takes a snapshot of the database rather than streaming the data from Exchange Server. On the
Exchange server, the VSS writer is responsible for triggering the snapshot and for making the Exchange
Server databases consistent before the snapshot is taken.

Windows Server Backup

You can use Windows Server Backup that is included with Windows Server 2008 to back up Exchange
Server 2010 databases and other data. When Exchange Server 2010 is installed, the version of Windows
Server Backup is updated to support Exchange Server 2010 backups. However, Windows Server Backup
has the following critical limitations:

It must run locally on the server that has the Exchange Server data.

It must back up to a local disk or network share, not to tape.

It restores only full databases.

It cannot back up passive DAG copies.

Data Protection Manager

DPM is a backup solution for servers running Windows Server. It can back up basic file and print servers
and application servers. DPM performs disk-based backups first, and then you can use it to archive to
tape.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-21

DPM improves on Windows Server Backup in the following ways:

Unlike Windows Backup, DPM requires only an agent to be installed on the computer running
Exchange Server 2010. So you can use DPM to centralize the backups of multiple servers.

You can restore databases or mailboxes. Recovering a mailbox is easier than restoring a database to a
recovery database and then extracting the mailbox contents.

You can back up passive database copies. This means that you can back up databases from a server
without determining whether the server has an active or passive database copy.

Third-Party Backup Software

Most third-party backup software is similar to DPM. However, some third-party backup software has the
following additional features:

Individual item restore. Some third-party backup software can restore individual mail messages
directly from backup to a users mailbox. This is less complex than first recovering to a recovery
database and then extracting the required message.

Brick-level backup. Brick-level backups are backups of mailbox contents. To perform a brick-level
backup, the backup software creates a Messaging Application Programming Interface (MAPI)
connection to each mailbox that it is backing up. This can be useful for backing up specific mailboxes
more frequently. If you have implemented personal archives, you can use brick-level backups to back
up only the main mailboxes in a mailbox databases, and not the archive data.

9-22 Planning a Disaster Recovery Solution

Choosing Exchange Server Backup Media

Key Points
Tape backup is still a popular method of performing backups. Tapes are easy to transport, and very
durable. Tape capacity and speed have steadily grown as manufacturers bring out new products. If you
need to expand backup capacity beyond a single tape, you can use a tape changer that automatically
rotates several tapes in a single unit. In high-capacity environments, you can use a tape library. A tape
library is a cabinet with one or more tape backup units, and a robot arm that moves tapes in and out of
the tape backup units.
To increase backup performance, many organizations use disk-based backups instead of tapes. Disk
storage is often cheaper than tape storage when you use large capacity disks rather than faster
performing Small Computer System Interface (SCSI) disks.
The first backup to disk is a complete copy of the server. The second snapshot captures only changes and
writes them to disk. Multiple backup versions exist on the disk, but the tool uses only as much disk space
as the first backup plus changes. This is similar to VSS in that you can use it to store multiple versions of
files.
However, disk-based backups are not as well suited as tape-based backups for off-site storage. Disks tend
to be sensitive to physical movement, and become unreliable if you transport them regularly. Therefore,
many organizations use disks as a first backup tier, and then transfer backups to tape for off-site storage.
If your Exchange Server databases are located on a storage area network (SAN), then you can use SANbased snapshots to lessen backup traffic on the main network, and keep backup traffic on the SAN. The
backup is taken from the SAN snapshot rather than through the Exchange Server. To implement SANbased snapshots for Exchange Server backup, your backup application must support your specific SAN
hardware.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-23

Designing an Exchange Server Backup Schedule

Key Points
When determining an Exchange Server 2010 backup schedule, you must consider many factors, including
backup frequency, requirements for various server roles, the available backup window, and recovery
requirements.

Mailbox Servers
You must back up Mailbox servers more often than other Exchange Server roles. Mailbox servers contain
the messages that users receive each day, and therefore you must back them up regularly to ensure that
mailboxes and message are recoverable. One way to determine the backup frequency for Mailbox servers
is to determine the acceptable data loss if both the database and transaction logs are lost. If only 12 hours
of data loss is acceptable, you must back up every 12 hours, and then store the tapes off-site.
When you use tapes for backup, you typically keep enough tapes to maintain a recent data archive. For
example, you could have your daily backup tapes, but then also retain each Friday backup tape for one
month, and possibly each months last-Friday tape for a year. This is sometimes referred to as a
grandfather, father, son scheme.
When you use disks for backup, you can archive to tape at any time. In a similar way, you could create a
weekly tape each Friday, and then retain one weekly tape per month for a year.

Non-Mailbox Servers
Other server roles do not maintain user data, and you can back them up less often. Configuration data is
the main concern when backing up non-Mailbox servers. You may institute a policy in which you back up
non-Mailbox servers weekly, or only when you change your configuration.

9-24 Planning a Disaster Recovery Solution

Backup Window
You time window for performing backups may influence your backup schedule. For example, an
organization that operates 16 hours per day, five days per week, may not be able to perform a full backup
to tape each night. In this case, you can perform a weekly full backup on weekends, and incremental or
differential backups during the week. Incremental or differential backups to tape are much faster than full
backups. However, be aware that when you use differential backups, the transaction logs are not
truncated. On a busy Mailbox server, this can lead to large volumes of transaction logs.
The backup window is less of an issue when you back up to disk. VSS backups to disk capture only
changes since the last backup. Thus, VSS backups to disk effectively function like incremental backups,
because you are not backing up redundant data that was already backed up. You may choose to perform
VSS backups to disk frequently, because the backup sizes are small. In some cases, organizations perform
VSS backups multiple times a day.
You also can use passive database copies in a DAG to perform backups during normal production hours,
without affecting the Mailbox servers performance. By doing this, you can extend your backup window
beyond what is normally available. The ability to back up passive database copies is important when
selecting backup software.
Note

Windows Backup cannot back up a passive database copy in a DAG.

Recovery Requirements
Your SLA recovery requirements also influence how you perform backups. If recovery speed is the primary
concern, then you must perform full backups daily, because they are the fastest to restore. When you use
differential or incremental backups, you must replay many transaction logs after you restore the backup.
Depending on the amount of transaction logs, replaying the transaction logs can take a long time.
If you are doing frequent disk-based backups, each backup behaves as a full backup. This means that
recovery is fast. It is also generally faster to restore from disk backup than from tape.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-25

Designing an Exchange Server Backup Management Solution

Key Points
Backup management solutions define how the organization manages and monitors backups, and
manages the backup media that it uses. These solutions may include how the organization performs
backups, backup frequency, backup media, and various other details related to the backup schedule and
process.

Planning and Configuration

Assign a team or administrator to take primary responsibility for managing backups. Assigning
responsibility for managing backups ensures that backup management occurs. It also provides a single
contact for backup requests. When you centralize responsibility, there is a lower likelihood of conflicting
changes being made to the backup system.

Monitoring
Ensure that daily backup monitoring occurs, and address backup failures immediately. Failed backups
increase the risk to data. For example, if you fail to back up three days in a row and the hard disks fail, you
could lose three days of data. In most cases, configure backup software to automatically send you the
backup completion status.

Media
Backup media must be stored off-site daily. This can prevent data loss, even if you lose an entire physical
location. When transporting data offsite, you should secure the backups. Using a trusted courier service is
one way to secure offsite backups. Also, ensure that you are using a secure offsite location. Many thirdparty vendors provide secure storage facilities.
Finally, consider encrypting your backup contents. This ensures that no one can access the contents if the
tapes are lost or stolen.

9-26 Planning a Disaster Recovery Solution

Media Rotation
Most organizations reuse tapes after a mandated time defined by the organizations data storage
requirements. For example, some organizations rotate tapes on a weekly basis so that each Friday a
backup tape is transported offsite and remains archived for six months or longer. In this scenario, the
organization reuses the daily backup tapes from Monday through Thursday, from one week to the next.
Be sure to keep track of the average failure time for backup media, and remove tapes from the rotation
before failure occurs. For example, some types of backup tapes only guarantee a years life expectancy
when used weekly. The average failure time varies depending on the media type and the medias storage
conditionssuch as humidity and temperature.
When using disk-based backup, closely monitor disk status in the backup server. If a disk in a RAID array
fails, replace it quickly. Ideally, you always have a spare disk available in the server.

Test Restore Functionality

It is important to test the restore functionality in your backup and restore solution on a regular basis. This
ensures that you backup media actually contains a functional backup that can be used for recovery.
Testing restore functionality also ensures that your restore procedures are valid.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-27

Lesson 3

Planning Exchange Server Recovery

To restore lost servers and data in the most efficient manner, you need to understand the options
available for recovering Exchange Server functionality and data. The recovery process varies depending on
the specific server roles. To ensure that everyone in your organization understands the recovery process,
you should create and maintain a disaster recovery plan.
After completing this lesson, you will be able to:

Describe the options for recovering Exchange Server functionality.

Describe the options for recovering mailbox data and databases.

Plan Mailbox server recovery.

Plan non-Mailbox server recovery.

Plan Edge Transport server recovery.

Create a disaster recovery plan.

Maintain the disaster recovery plan.

9-28 Planning a Disaster Recovery Solution

Options to Recover Exchange Server Functionality

Key Points
You have two options when recovering Exchange Server functionality: replace the lost server roles or
restore the lost server. Both options allow you to recover full functionality.

Replace the Lost Server Roles

It is typically faster to replace a lost server role than to restore a lost server. Replacing a lost server role
means that you do not need to restore from backup any server roles other than the Mailbox server, which
must be restored from backup by using a DAG. If you are using a DAG, you can add a new server to the
DAG and create a new database copy on the server. Other server roles may have customizations that you
need to configure.

Restore the Lost Server

When a server fails, you can restore the lost server to recover the functionality provided by that server.
Restoring the server requires you to build a new server, and to join that server to the domain using the
same computer account name. You can restore the computers system state to recover the computer
name and recover some configuration information, such as the IP address and certificates.
After joining the domain, install Exchange Server 2010 using the Recovery mode. The Recovery mode
reads the Exchange Server configuration information from AD DS and automatically installs the
appropriate server roles that are linked to the computer account. After installation, the Exchange Server
configuration information stored in AD DS is used for that computer.
Never delete the computer account for a failed Exchange Server. If you do so, you cannot recover the
Exchange Server functionality for that server.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-29

When to Restore a Lost Server

Even though it is faster and easier to replace a lost server role than to recover a lost server, in the
following cases, you should recover the server:

To avoid reconfiguring Outlook 2003 clients. Outlook 2003 clients do not support the Autodiscovery
feature. Therefore, these clients cannot reconfigure a profile and find the location of a new mailbox.
Recovering the server with same name means that you do not need to reconfigure the Outlook 2003
clients.

To avoid reconfiguring firewalls. Internet-accessible servers such as Outlook Web App and the
Microsoft Exchange ActiveSync technology are protected by firewalls and proxy servers. Recreating
the original configuration means that you do not need to reconfigure firewalls to direct traffic to a
new server. If the Client Access server is part of a client access array, firewall reconfiguration is not a
concern because the replacement server will be a new node in the existing client access array.

To recover poorly documented customizations. If a lost servers customizations are poorly

documented, you may not be able to replicate the configuration. Restoring from backup may be the
only option to recover the configuration.

To avoid reconfiguring applications configured to use a specific server. Some applications are
configured to use a specific server. For example, an application may be using a specific Hub Transport
server as a mail relay. Recovering the server means that you do not need to reconfigure a new Hub
Transport server with an appropriate Simple Mail Transfer Protocol (SMTP) receive connector.

9-30 Planning a Disaster Recovery Solution

Options to Recover Mailbox Data and Databases

Key Points
If a database is intact, you can use single-item recovery to restore individual messages. If a database is lost
due to corruption or server failure, you need to recover the data that was stored in the lost database.
There are many options that you can use when performing a recovery. Each option is appropriate in
different circumstances. The available options are described in the following table.
Option

Description

Database restore

Recover a database lost due to corruption or disk failure by restoring the

database. After restoration, replay the transaction logs to bring the database up
to the current state just before it was lost.

Recovery database

Use a recovery database if you need to recover data from inside a database,
instead of recovering the entire database. A recovery database is a database
that is mounted on a Mailbox server, but is not directly accessible to users. After
restoring a database in the recovery database, extract the messages or
mailboxes that you want to restore.

Database portability

You do not need to restore databases on the same servers that backed them up.
You can restore and mount databases on any Exchange Server 2010 Mailbox
server in the organization. This is useful when one of several Mailbox servers
fails, and you want to recover the database to a functional Mailbox server. You
can also restore to a recovery database located on a different server.
After restoring a database to an alternate server, you must use the Set-Mailbox
cmdlet with the Database parameter to link the mailboxes with the new
location.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-31

(continued)
Option

Description

Dial-tone recovery

When a mailbox database fails, users with mailboxes in that database can no
longer send and receive messages. You can create a dial-tone database by
creating and mounting an empty database for the mailboxes contained in the
failed database. This quickly allows users to send and receive messages again.
After the dial-tone database is functional, restore historical data to a recovery
database, and then merge the data into the dial-tone database.
If the dial-tone database is located on a different server than the failed
database, use the Set-Mailbox cmdlet with the Database parameter to link
the mailboxes with the new location.

DAG recovery

Performing a DAG recovery means that you do not need to perform a database
restore. Assuming you have multiple database copies in a DAG, then when one
database copy fails, Exchange Server automatically mounts and redirects users
to another database copy. To restore redundancy, create another database copy
on a different server.

Note When a user with a cached mailbox connects to a dial-tone recovery database for
the first time, Exchange Server deletes the contents of the cache.
Question: Which recovery method is preferable?

9-32 Planning a Disaster Recovery Solution

Planning the Recovery of Mailbox Data and Databases

Key Points
When planning Mailbox server recovery, consider the following:

Using a DAG means you do not have to perform a recovery; Exchange Server uses a replica database
instead. This is much faster and easier than using other recovery methods, and improves the recovery
experience for users and administrators.

Place transaction logs and databases on physically separate disks if you do not use a DAG and if you
may need to restore from backup. This ensures that transaction logs will be available for replay if the
disks containing the database are lost.

Recover basic functionality as soon as possible if you do not use a DAG, and a Mailbox server or
database fails. Use a dial-tone recovery database to allow users to send and receive messages as
quickly as possible. This is much faster than waiting for a database to restore.

Ensure that you have enough free disk space to hold a restored database. Allocate enough free disk
space to hold any database from which you might need to recover data. You can allocate disk space
on each Mailbox server, or allocate one server to use for database recoveries.
Question: Will you allocate space for database recovery on each Mailbox server?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-33

Planning the Recovery of Non-Mailbox Servers

Key Points
Non-Mailbox servers provide various functions, and do not contain significant amounts of user or
configuration data. You can recover the basic functions of non-Mailbox servers without backing up
existing servers. Backups are required only if you are restoring additional configuration options that you
may have set after installation.

Adding a Server Role

One way you can replace a failed non-Mailbox server is to add the server role to an existing Exchange
server in the same site. This way, you can recover functionality quickly. In most cases, this is a temporary
solution until you can rebuild the failed server, or deploy a new server as a replacement.

Deploying a New Server

You also can deploy a new server with the same server role to replace a failed non-Mailbox server. A new
Hub Transport server immediately replaces the functionality of a failed Hub Transport server without
requiring further configuration. A new Client Access server role also immediately replaces the functionality
of a failed Client Access server. However, you must reconfigure clients to access the new Client Access
server role, or reconfigure the Domain Name System (DNS) to direct clients to the new Client Access
server role.
When replacing a Client Access server with a new one, you must perform additional configurations rather
than rebuild the failed server. Any configuration changes that you made to the websites used on a Client
Access serversuch as authentication optionsare lost when you replace a Client Access server. To return
the Client Access server role to its previous configuration state, you must have documented your previous
changes so that you can perform them again on the new server. When you rebuild a server, these changes
are restored from backup.

9-34 Planning a Disaster Recovery Solution

If you use a client access array, then you do not need to redirect clients to the new Client Access server.
The client access array continues to service user requests after a failure. You can add a new Client Access
server to the load-balancing cluster used for the client access array at any time. Configure a new Client
Access server in a client access array with the same customizations as other nodes in the client access
array. This includes the SSL certificate.

Considerations for Deploying a New Server

Deploying a new server may require you to reconfigure some applications. For example, if you configure a
Voice over IP (VoIP) gateway to communicate with the DNS name or IP address of the failed server, then
you must reconfigure the VoIP gateway.
If you choose not to rebuild a failed Exchange server, you must remove it manually from AD DS using the
LDP.exe tool.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-35

Planning the Recovery of Edge Transport Servers

Key Points
Unlike other server roles, Edge Transport servers store most configuration information locally in Active
Directory Lightweight Directory Services (AD LDS). AD LDS is used on Edge Transport servers, because
these servers are not members of the Exchange Server organizations domain.
Use a cloned configuration to recover an Edge Transport server. To create the cloned configuration, run
the ExportEdgeConfig.ps1 script in the C:\Program Files\Microsoft\Exchange Server\V14\Scripts folder.
When you run this script, Exchange Server writes the Edge Transport servers configuration information to
an XML file. Spam filtering settings are included in the cloned configuration.
Note

You must create the cloned configuration before the Edge Transport server fails.

The cloned configuration does not include the transport configuration object, which includes a few
settings, such as maximum message sizes and maximum number of recipients for a message. Exchange
Server configures the settings in the new servers transport configuration object with the default settings.
To restore customized settings, you must manually configure them according to your documentation.

Recovery Steps
To use a cloned configuration to recover an Edge Transport server, complete the following steps:
1.

Perform a clean installation of the Edge Transport server. Use the same server name as the server that
you are restoring. However, this server is not joined to a domain, so you do not need to reset a
computer account.

2.

Run the ImportEdgeConfig.ps1 script to validate the configuration. The script checks the existing
information in the XML file to verify that the settings are valid. If some settings in the XML file are not
valid, Exchange Server creates an answer file. The answer file specifies the server-specific information
necessary for the next step.

9-36 Planning a Disaster Recovery Solution

3.

Use the ImportEdgeConfig.ps1 script to import the configuration. The script validates the XML file,
and then uses the intermediate XML file and the answer file (if required) to restore the backed-up
configuration information.

4.

Run the Microsoft Exchange EdgeSync process to establish one-way recipient and configuration
information replication from AD DS to the AD LDS instance on an Edge Transport server. The cloned
configuration backup and restore process does not duplicate the Edge Subscription servers settings,
and does not clone the certificates that the Exchange EdgeSync service uses. You must run the
Exchange EdgeSync process separately for each Edge Transport server. The Exchange EdgeSync
service overwrites settings that are included in both the cloned configuration information and the
EdgeSync replication information. These settings include Send connectors, Receive connectors,
accepted domains, and remote domains.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-37

Creating a Disaster Recovery Plan

Key Points
A disaster recovery plan is a plan for restoring functionality when an event occurs that causes IT systems
to fail. It focuses on threats to servers and associated infrastructure, not on threats to business processes.
However, the order in which you restore components may be based on recovery of business processes.

Disaster Recovery Plan Components

Disaster recovery plans include the following components:

SLA and recovery requirements with the business impact statement

Risk assessment with risk probabilities and costs

Budget, including funds available to address specific risks

High-level process document with links to detailed recovery procedures

Testing plan, which determines the feasibility and compatibility of backup facilities and procedures

Auditing plan, which provides a methodology for demonstrating to the organization that the disaster
recovery plan works as designed

Maintenance plan, which details how team members keep current the disaster recovery plan and the
change-control procedures that control plan modifications

Training plan for team managers and members

9-38 Planning a Disaster Recovery Solution

Creating a Disaster Recovery Plan

Disaster recovery plans focus more on the technology team responsible for maintaining systems, than on
the business units. They are technical in nature, and do not require business unit approval. However, some
input from business units is desirable.
Like any project, creating a disaster recovery plan must have milestones and eventual sign-off for
acceptance. Sign-off may be an internal IT department process, which does not require business-unit signoff.
Developing a disaster recovery plan may be an incremental process. It is unlikely that you can
simultaneously address recovery processes for all systems. You should first address the systems that are
the most business critical.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-39

Maintaining a Disaster Recovery Plan

Key Points
Disaster recovery plans are not static documents; they change as organizations change. You need to
update your disaster recovery plan when you add new servers or services to the organization. Also, as you
test the disaster recovery plan, you will find opportunities for improvement.

Testing a Disaster Recovery Plan

Test and evaluate your disaster recovery plan thoroughly at least once a year, and document the
procedures to test the plan. Periodic testing ensures that the plan includes all necessary steps, especially
since it is unlikely that all business changes are communicated efficiently to the team responsible for
disaster recovery planning. Not only does regular testing capture items that change-management missed,
it also ensures that all members of the disaster recovery team are well-trained on the plans execution.
Your testing process should include the following:

Procedures for restoring specific componentssuch as servers and mailboxes

Media availability for performing a restore

Results of component failure and system failure

Server and infrastructure loads on remaining servers after a failure

Workstation impact of a specific failure, and the recovery method performed

Performance of procedures to meet time frames specified in the SLA

You typically test a disaster recovery plan during non-business hours to minimize the impact on users.
However, more ambitious testing could include testing during normal business hours to ensure that you
can perform recovery with minimal disruptions to the organizations overall operations.

9-40 Planning a Disaster Recovery Solution

Refining a Disaster Recovery Plan

Creating a disaster recovery plan is an incremental process. Testing reveals necessary modifications. In
large organizations, you may need to develop the disaster recovery plan in stages, and address the areas
with the highest business impact first.
During disaster recovery plan testing, analyze all data that you collect on the success and failure of the
various tests, and then use it to modify the plan. Most likely, you will find that the tests indicate that
numerous procedures are not sufficient to meet the RTOs and RPOs specified in the SLA. You may also
discover that some procedures are unnecessary or over-engineered. Save money by scaling back those
procedures. Catalog all of this information in a lessons-learned document.
Always retest disaster recovery plan components that you modify. Be aware that a change to one
component may directly or indirectly impact other systems. Disaster recovery plan testing may require
some time to ensure that you can test all changes.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-41

Lab: Planning a Disaster Recovery Solution

Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, you must do
the following:
1.

On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, and 10233B-VAN-CL1 virtual machines are
running.

3.

If required, connect to the virtual machines. Log on to the virtual machines as

Adatum\Administrator using the password Pa$$w0rd.

Lab Scenario
You are a messaging engineer for A. Datum Corporation, an enterprise-level organization with multiple
locations. A. Datum Corporation is an international corporation involved in technology research and
investment, and it is planning to upgrade from Exchange Server 2003 to Exchange Server 2010.
High availability planning is complete, but the disaster recovery plan needs to be further developed.
Specifically, you need to consider the details of the messaging SLA to ensure that disaster recovery is
possible within the appropriate time frame.
Finally, you must implement part of your proposed disaster recovery plan.
Note Your instructor may choose to perform this lab as a group discussion rather than an
individual activity.

9-42 Planning a Disaster Recovery Solution

Exercise 1: Planning Disaster Recovery for Vancouver

Scenario
The high-availability plan for Vancouver indicates that your organization will use a DAG to provide high
availability for mailbox databases. There will be two database copies in Vancouver, and another database
copy with a six-hour lag in San Diego, to provide site resilience. Each mailbox database has a maximum
size of 250 gigabytes (GB). Other messaging settings will use default values.
The Client Access servers in this site were customized with a company-specific look, including the
company logo. All changes have been documented.
There are customized Receive connectors configured on one Hub Transport server. The customized
Receive connectors support applications that need to relay messages through the Exchange Server
organization to the Internet.
There are two Edge Transport servers configured in the perimeter network of this location.

Disaster Recovery SLA Notes

The following requirements related to disaster recovery were taken from the messaging SLA:

There can be no data loss due the failure of a single server.

The failure of a single server should result in only minutes of downtime for users.

High availability can be considered a replacement for backup if there are at least two local copies of a
database, and a remote database copy in another site.

To consider high availability a replacement for backup, there must be one database copy that is
unaffected by logical corruption in another database copy for at least 12 hours.

Any message deleted by a user must be recoverable for 30 days.

Deleted mailboxes must be recoverable for 60 days.

Messaging functionality must be recoverable within one hour, while historical data can be recovered
up to 24 hours later.

When recovering data from a backup, there is a maximum data loss allowed of up to 4 hours.

Any location that is not configured with site resilience must archive weekly backups offsite.

The main tasks for this exercise are as follows:

1.

Review the A. Datum documentation.

2.

Answer questions related to the documentation.

3.

Document the required configuration for the Vancouver site.

Task 1: Review the A. Datum documentation

Review the following information:

Disaster Recovery SLA Notes

Task 2: Answer questions related to the documentation

Question: In the Disaster Recovery SLA Notes, what points are raised that impact your disaster
recovery plan for Vancouver?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

Task 3: Document the required configuration for the Vancouver site

Complete the following proposal document by answering the questions.

A. Datum Disaster Recovery Plan for Vancouver
Document Reference Number: JC040430/1
Document Author
Date

Jason Carlson
5th May 2010

Requirement Overview
Determine how disaster recovery will be provided for all server roles in Vancouver.
Proposals
Question: Does this site require backups?

Question: Do you need to make any changes to the DAG to meet the SLA requirements?

Question: Are any changes required for deleted item retention?

Question: Are any changes required for deleted mailbox retention?

Question: Do you need to back up data on Client Access servers?

Question: Do you need to back up data on Hub Transport servers?

Question: Do you need to back up data on Edge Transport servers?

Question: Would your backup plan change if public folders were present in Vancouver?

Results: After this exercise, you should have created a disaster recovery plan for the Vancouver site.

9-43

9-44 Planning a Disaster Recovery Solution

Exercise 2: Planning Disaster Recovery for San Diego

Scenario
The high-availability plan for San Diego indicates that a DAG will be used to provide high availability for
mailbox databases. There will be two database copies in San Diego. Each mailbox database has a
maximum size of 250 GB. Other messaging settings will use default values.
You evaluated various backup solutions, and determined that you can move 250 GB data over the
network in about 75 minutes. However, the available tape backup systems require about 120 minutes to
restore 250 GB of data.
The Client Access servers in this site were customized with a company-specific look, including the
company logo. All changes have been documented.
There are customized Receive connectors configured on one Hub Transport server. The customized
Receive connectors support applications that need to relay messages through the Exchange Server
organization to the Internet.
There are two Edge Transport servers configured in the perimeter network of this location.
The main tasks for this exercise are as follows:
1.

Review the A. Datum documentation.

2.

Answer questions related to the documentation.

3.

Document the required configuration for the San Diego site.

Task 1: Review the A. Datum documentation

Review the following information:

Disaster Recovery SLA Notes

Task 2: Answer questions related to the documentation

Question: In the Disaster Recovery SLA Notes, what points are raised that impact your
disaster recovery plan for San Diego?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

Task 3: Document the required configuration for the San Diego site

Complete the following proposal document by answering the questions.

A. Datum Disaster Recovery Plan for San Diego
Document Reference Number: JC040430/2
Document Author
Date

Jason Carlson
5th May 2010

Requirement Overview
Determine how disaster recovery will be provided for all server roles in San Diego.
Proposals
Question: Does this site require backups? If so, how will you perform backups?

Question: Do you need to make any changes to the DAG to meet the SLA requirements?

Question: Are any changes required for deleted-item retention?

Question: Are any changes required for deleted mailbox retention?

Question: How will you meet the recovery requirement of one hour?

Question: Would your backup plan change if public folders were present in San Diego?

Results: After this exercise, you should have created a disaster recovery plan for the San Diego site.

9-45

9-46 Planning a Disaster Recovery Solution

Exercise 3: Implementing Single-Item Recovery

Scenario
In this exercise, you will implement single-item recovery for a mailbox. This is part of the disaster recovery
plan for the Vancouver site.
To test the functionality of single-item recovery, you will configure Andreas as a member of the Discovery
Management role, with the ability to recover items after they have been purged and are no longer
accessible to users. Andreas will recover an item after it has been purged from a mailbox by performing a
mailbox search.
The main tasks for this exercise are as follows:
1.

Enable single-item recovery for a mailbox.

2.

Configure a user for message recovery.

3.

Delete and purge a message.

4.

Locate a recoverable message.

5.

Create a role group for exporting mailbox contents.

6.

Recover a message.

Task 1: Enable single-item recovery for a mailbox

1.

On VAN-EX1, open the Exchange Management Console.

2.

Browse to the Organization Configuration node and click Mailbox. On the Database
Management tab, configure the following settings for Mailbox Database 1:

Keep deleted items for (days) :30

Keep deleted mailboxes for (days): 60

3.

Open the Exchange Management Shell.

4.

In the Exchange Management Shell, use the following command to enable single-item recovery for
Lucas mailbox:
Set-Mailbox Luca SingleItemRecoveryEnabled $true

Task 2: Configure a user for message recovery

1.

On VAN-CL1, if necessary, log off, and then log on as Luca using the password Pa$$w0rd.

2.

Use the Microsoft Internet Explorer browser to connect to Outlook Web App at
https://van-ex1.adatum.com/owa.

3.

Log on to Outlook Web App as Adatum\Administrator using the password Pa$$w0rd.

4.

Go to Options, and then click See All Options.

5.

Click Manage Myself and select to manage My Organization.

6.

In Roles & Auditing, go to the Administrator Roles tab, and then add Andreas Herbinger to the
Discovery Management role group.

7.

Close Internet Explorer.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-47

Task 3: Delete and purge a message

1.

On VAN-CL1, use Outlook 2010 to send a message with the following settings:

To: Luca

Subject: Test of SIR

2.

Delete the Test of SIR message from the Inbox.

3.

Delete the Test of SIR message from Deleted Items.

4.

On the Folder tab, use the Recover Deleted Items option to purge the Test of SIR message.

Task 4: Locate a recoverable message

1.

On VAN-CL1, use Internet Explorer to connect to Outlook Web App at

https://van-ex1.adatum.com/owa.

2.

Log on to Outlook Web App as Adatum\Andreas using the password Pa$$w0rd.

3.

Go to Options, and then click See All Options.

4.

Select to manage My Organization.

5.

Go to Mail Control.

6.

Create a new Multi-Mailbox Search with the following settings:

Keywords: SIR

Mailbox to search: Luca Dellamore

Search name: Lucas lost message

Copy the search results to the destination mailbox

Mailbox to store the results: Discovery Search Mailbox

7.

Click the refresh icon to verify that the search succeeded.

8.

In the search results, click [open] to view the Discovery Search Mailbox.

9.

Expand the contents of the Lucas lost message folder until you see the Test of SIR message.

Task 5: Create a role group for exporting mailbox contents

On VAN-EX1, in the Exchange Management Shell, use the following command to create a new role
group with permissions to export and import mailbox contents with Andreas as a member:
New-RoleGroup Name ExportMail Roles Mailbox Import Export Members Andreas

9-48 Planning a Disaster Recovery Solution

Task 6: Recover a message

1.

On VAN-EX1, log off as Administrator, and then log on as Adatum\Andreas using the password
Pa$$w0rd.

2.

Open the Exchange Management Shell.

3.

In the Exchange Management Shell, use the following command to export the message from the
Discovery Search Mailbox to Lucas mailbox:
Search-Mailbox Discovery Search Mailbox SearchQuery Subject:SIR TargetMailbox
Luca TargetFolder Recovered

4.

On VAN-CL1, in Outlook 2010, expand all of the folders in the Recovered folder to locate the
recovered message.

Results: After this exercise, you should have implemented single-item recovery and recovered a message.

To prepare for the next module

When you finish the lab, revert the machines back to their initial state. To do this, complete the following
steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3. Close the
virtual machine connection windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then, in the Actions pane, click Start.

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then, in the
Actions pane, click Connect.
Important Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully
started before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10223B-VAN-EX1. Connect to the virtual machine.

8.

Wait for 10233B-VAN-EX1 to start, and then start 10223B-VAN-EX2. Connect to the virtual machine.

9.

Wait for 10233B-VAN-EX2 to start, and then start 10223B-VAN-EX3. Connect to the virtual machine.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

9-49

Module Review and Takeaways

Review Questions
1.

Why might older backup software not support Exchange Server 2010?

2.

How does Recovery mode help restore an Exchange server?

3.

Is it possible to use a DAG for archiving mailbox information?

4.

Why is it important to have a formal disaster recovery plan?

Best Practices Related to Recovery of Mailbox Databases and Data

Supplement or modify the following best practices for your own work situations:

Whenever possible, use a DAG to protect mailbox databases. DAG recovery is faster and easier than
backup recovery.

When you lose a database, use a dial-tone database to quickly recover basic messaging functionality.

Use a recovery database to retrieve specific items from a backup.

Allocate disk space for a recovery database when designing server storage.

Use single-item recovery to prevent users from purging messages before they reach the itemretention limit.

9-50 Planning a Disaster Recovery Solution

10-1

Module 10
Planning Microsoft Exchange Server 2010 Monitoring and
Troubleshooting
Contents
Lesson 1: Planning Exchange Server Monitoring

10-3

Lesson 2: Planning Exchange Server Troubleshooting

10-19

Lab: Planning Exchange Server 2010 Monitoring and Troubleshooting

10-27

10-2

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Module Overview

To ensure that your messaging system runs efficiently, you must perform routine monitoring and, where
necessary, make adjustments to your Microsoft Exchange Server 2010 servers. By understanding how to
implement a monitoring program and knowing what and how to monitor, you can optimize your
Exchange servers.
Occasionally, problems may arise with your messaging system. Therefore, it is important to understand
how to troubleshoot problems with Exchange Server 2010. Planning an effective troubleshooting
methodology and having familiarization with the troubleshooting tools helps you to quickly and
efficiently resolve even complex problems.
After completing this module, you will be able to:

Plan a monitoring solution for Exchange Server 2010.

Plan a troubleshooting solution for Exchange Server 2010.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-3

Lesson 1

Planning Exchange Server Monitoring

Monitoring practices are commonly an afterthought, and are often implemented sometime after
Exchange Server is deployed. However, having a well-tuned and consistently used monitoring solution can
greatly improve your ability to identify, troubleshoot, and repair issues before they are noticed by end
users.
After completing this lesson, you will be able to:

Identify the options for monitoring Exchange Server.

Plan performance monitoring for Mailbox servers.

Plan performance monitoring for Transport servers.

Plan performance monitoring for Client Access servers.

Plan message tracking and logging for Transport servers.

Plan for monitoring baselines and trend analysis.

10-4

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Options for Monitoring Exchange Server

There are several methods that you can use to collect performance data from Exchange servers in your
organization. You should use the method that best suits your requirements.
Real-time monitoring of Exchange servers is useful when you want to determine the effect of performing
a specific action or troubleshoot specific events. This type of monitoring can also help you to ensure that
you are meeting service level agreements (SLAs).
Analyzing historical data can be useful for tracking trends over time, determining when to relocate
resources, and deciding when to invest in new hardware to meet the changing requirements of your
business. You should use historical performance data to assist you when planning for future Exchange
Server requirements.
Exchange Server 2010 includes a range of tools to assist you in the monitoring of your Exchange Server
environment. The following table lists these tools.
Tool

Description

Windows Server 2008

Event Viewer

Collects information related to server operations. This data can help you to
identify performance issues on a server. You should search for specific
events in the event log file to locate and identify problems.

Windows System
Resource Manager
(WSRM)

By using WSRM, you can control how CPU resources are allocated to
applications, services, and processes. Managing these resources improves
system performance, and reduces the chance that these applications,
services, or processes interfere with the rest of the system.
WSRM is a feature of Windows Server 2008.

Network Monitor

Network Monitor is a protocol analyzer. It enables you to capture, view, and

analyze network data. You can use it to help troubleshoot problems with
applications on the network.
Network Monitor is provided with Windows Server 2008.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-5

(continued)
Tool

Description

Reliability and
Performance Monitor

You can use Windows Reliability and Performance Monitor to examine how
programs you run affect your computer's performance, both in real time,
and by collecting log data for later analysis. Windows Reliability and
Performance Monitor uses performance counters, event trace data, and
configuration information, which can be combined into Data Collector Sets.
Reliability and Performance Monitor is built in to Windows Server 2008.

Microsoft Exchange
Server 2010
Management Pack for
Microsoft System Center
Operations Manager
2010

System Center Operations Manager 2010 enables you to build a complete

picture of the past and current performance of your server infrastructure.
System Center Operations Manager can also automatically respond to
events and address problems before they become an issue for you. System
Center Operations Manager requires time to configure, and requires
additional licenses. The Microsoft Exchange Server 2010 Management Pack
is designed to be used for monitoring Exchange Server 2010 events,
collecting Exchange component-specific performance counters in one
central location, and for raising alerts when operator intervention is
necessary.

Microsoft Exchange
Server 2010
Management Pack for
System Center Essentials
2010

Microsoft System Center Essentials 2010 is a management solution that

provides: monitoring and alert resolution for servers, clients, applications,
hardware, and network devices; software distribution; update management;
and software and hardware inventory.

Note The Exchange 2010 SP1 version of the Exchange 2010 Management Pack includes a
number of improvements, including cross-premises mail flow monitoring and reporting; this
enables you to use mail flow monitoring and reporting features for Exchange Online. For
further information about additional changes in the Management Pack, see the Microsoft
TechNet website: http://blogs.technet.com/b/kevinholman/archive/2011/04/07
/exchange-2010-sp1-management-pack-ships-version-14-02-0071-0.aspx.
You should consider the cost that monitoring events incurs. The cost that is incurred to monitor systems is
an investment in ensuring that your systems continue to run effectively and efficiently. You can measure
costs by using several metrics, including:

Time allocated to personnel to perform monitoring tasks.

Money invested in monitoring systems.

An alternative view is to consider the cost of not monitoring your systems by asking the following
questions:

What is the monetary cost of reduced user productivity for your organization?

What is the cost of system outage that is caused by not monitoring systems?

What is the cost of a reactive approach to troubleshooting?

By using automated systems, you can monitor servers proactively, and possibly reduce the overall number
of staff who are required to perform monitoring. By using tools such as System Center Operations
Manager 2010, you can automatically monitor and fix certain server issues.

10-6

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

By providing an IT infrastructure that automatically responds to events, you create a server infrastructure
that is flexible and dynamic. Windows Server 2008 enables dynamic system responses through Task
Manager, other tools such as System Center Operations Manager 2010, and third-party offerings.
Since Exchange Server 2010 is complex, there are a number of aspects that you need to monitor.
Primarily, you should gather and monitor metrics from the processor, memory, disk, and the Exchange
services. You can monitor additional information depending on the Exchange Server roles that have been
installed.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-7

Planning Performance Monitoring for Mailbox Servers

The maximum level of performance for an Exchange Server is determined by the component in the server
that performs least well; in other words, the server bottleneck. Each of the server roles makes different
demands on the operating system and installed hardware, and it is therefore important to consider each
role separately.
When collecting performance data about Mailbox servers, much of the focus is around disk response time,
and how quickly the server responds to requests. The average response time for reading data should be
under 20 milliseconds (ms), and the average write response time should be less than 100 ms. Another
indicator that the disk system is not keeping up with demand is when the disk queue length starts to
grow. All of these indicators may require that you purchase additional or faster disks, or modify the disk
configuration.
There are many Mailbox server performance counters that you may find beneficial to trend, depending on
your messaging environment. However, the following counters are crucial, and are a good place to begin
when collecting performance data for the Mailbox server.

Logical Disk
Logical Disk counters determine whether the disk performance is meeting demands. As disk latency
increases, database Read and Write operations take more time.

10-8

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Monitor the following performance counters for Mailbox server logical disks.
Group

Counter

Description

Expected value

Logical
Disk

Avg. Disk
sec/Read

Shows the average time for

reading data from the disk.

On average, should be below 20 ms at all

times.

Avg. Disk
sec/Write

Shows the average time for

writing data to the disk.

On average, should be below 100 ms at all

times.

Avg. Disk
sec/Transfer

Shows the average number

of bytes transferred to or
from the disk during Read
or Write operations.

Should be below 20 ms on average, and

spikes should not be higher than 50 ms.

MSExchangeIS Mailbox and MSExchangeIS Public

When messages are being queued for submission to the local Hub Transport server, it may indicate a
problem with connectivity to the transport server.
Group

Counter

MSExchangeIS Messages
Mailbox and
Queued for
MSExchangeIS Submission
Public

Description

Expected value

Shows the current

number of submitted
messages that are not
yet processed by
transport.

Should be below 50 at all times, and not be

sustained for more than 15 minutes.
Otherwise, this counter may indicate
connectivity issues with the transport servers,
or that backpressure is occurring.

MSExchangeIS
The Client Access and Transport servers use remote procedure call (RPC) to communicate with Mailbox
servers. Therefore, it is important to monitor the response time for RPC requests to ensure that the
Mailbox server responds quickly enough to support the load.
Group

Counter

Description

Expected value

MSExchangeIS

RPC
Requests

Shows the overall RPC

requests that are
currently executing
within the information
store process.

Should be below 70 at all times.

RPC
Averaged
Latency

Shows the RPC latency

(in ms) averaged for all
operations in the last
1,024 packets.

Should not be higher than 25 ms on

average.

RPC
Operations
/sec

Shows the current

number of RPC
operations occurring per
second.

Should closely correspond to historical

baselines. Values much higher than
expected indicate that the workload has
changed, while values much lower than
expected indicate a bottleneck that is
preventing client requests from reaching
the server.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-9

(continued)
Group

Counter

Description

Expected value

MSExchangeIS

RPC Num.
Slow
Packets

Shows the number of

RPC packets in the past
1,024 packets that have
latencies longer than 2
seconds.

Should be less than 1 on average, and

should be less than 3 at all times.

10-10

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Planning Performance Monitoring for Transport Servers

The transport servers store message queue information to disk. The average response time for reading
data should be less than 20 ms, and the average write response time should be less than 100 ms. Another
indicator that the disk system is not keeping up with demand is when the disk queue length starts to
grow. All of these may require you to purchase additional or faster disks, or modify the disk configuration.

Logical Disk
Logical Disk counters determine whether disk performance is meeting demands. As disk latency increases,
database Read and Write operations take more time.
Monitor the following performance counters for transport server logical disks.
Group

Counter

Description

Expected value

LogicalDisk Avg. Disk

sec/Read

Shows the average time for

reading data from the disk.

On average, should be below 20 ms at all

times.

Avg. Disk
sec/Write

Shows the average time for

writing data to the disk.

On average, should be below 100 ms at

all times.

Avg. Disk
Queue Length

Shows the number of

messages in the poison
message queue.

Should be 0 at all times.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-11

MSExchange Database ==> Instances

Transport servers store message queue information in databases. Therefore, monitoring database
performance will help you identify issues with reading or storing queue information in the databases.
Group

Counter

Description

Expected value

MSExchange
Database
==>
Instances

Log
Generation
Checkpoint
Depth

Shows the amount of work (in count

of log files) that needs to be redone
or undone to the database file(s) if a
process crashes.

Should be less than 1,000 at all

times.

Version
buckets
allocated

Shows the total number of allocated

version buckets. Shows the default
backpressure values as listed in the
edgetransport.exe.config file.

Should be less than 200 at all

times.

Log Record
Stalls/sec

Shows the number of log records that

cannot be added to the log buffers
per-second, because they are full. If
this counter is non-zero most of the
time, then the log buffer size may be
a bottleneck.

Should be less than 10 per

second on average, and spikes
should not be greater than 100
per second.

MSExchange Transport Queues

In addition to the transport server databases, you should also monitor the transport server queues to
ensure email messages are being delivered.
Group

Counter

Description

Expected value

Shows the number of messages

queued for delivery in all queues.

Should be less than

5,000.

Active Remote
Delivery Queue
Length

Shows the number of messages in the

active remote delivery queues.

Should be less than 250

at all times.

Active Mailbox
Delivery Queue
Length

Shows the number of messages in the

active mailbox queues.

Should be less than 250

at all times.

Retry Mailbox
Delivery Queue
Length

Shows the number of messages in a

retry state that are attempting to
deliver a message to a remote
mailbox.

Should be less than 100

at all times.

Unreachable Queue
Length

Shows the number of messages in the

Unreachable queue.

Should not exceed 100.

Largest Delivery
Queue Length

Shows the number of messages in the

largest delivery queues.

Should be less than 200.

Poison Queue
Length

Shows the number of messages in the

poison message queue. Poison
messages are messages that were
detected as harmful. These messages
often cause a Transport service failure.

Should be 0 at all times.

MSExchange Aggregate Delivery

Queue Length (All
Transport
Queues)
Queues

10-12

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Planning Performance Monitoring for Client Access Servers

The Client Access server role performs many of the key client connectivity functions for Exchange Server
clients. Disk performance is important for determining overall server health. Additionally, you should
monitor the response time for services used by Client Access servers to ensure proper performance.

Logical Disk
Logical Disk counters determine whether the disk performance is meeting demands. As disk latency
creases, database Read and Write operations take more time.Monitor the following performance counters
for the Client Access server logical disk.
Group

Counter

Description

Expected value

LogicalDisk

Avg. Disk
sec/Read

Shows the average time for

reading data from the disk.

Should be below 20 ms on
average.

Avg. Disk
sec/Write

Shows the average time for

writing data to the disk.

Should be below 100 ms on

average.

ASP.NET Services and Applications

Microsoft Office Outlook Web App and Exchange Web Services rely heavily on the Microsoft .NET
Framework and Microsoft ASP.NET files, which are read, processed, and rendered for the end users.
Monitoring the response time and the number of times the application has had to restart can help you
verify the overall health of the services.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-13

The following table lists the counters related to ASP.NET and ASP.NET applications.
Group

Counter

Description

Expected value

ASP.NET

Application
Restarts

Shows the number of times the

application has been restarted during the
Web server's lifetime.

Should be a low value.

Worker Process
Restarts

Shows the number of times a worker

process has restarted on the computer.

Should be a low value.

Requests
Current

Shows the current number of requests

including those that are queued
currently executing, or waiting to be
written to the client. Under the ASP.NET
process model, when this counter exceeds
the request QueueLimit defined in the
process model configuration section,
ASP.NET begins rejecting requests. The
maximum value is 5,000. The server
returns a 503 error if the counter exceeds
this value.

Should be less than

5,000 at all times.

Request Wait
Time

Shows how long (in ms) the most recent

request was waiting in the queue.

Should be less than

1,000 ms at all times.

Requests in
Application
Queue

Shows the number of requests in the

application request queue. The maximum
value is 5,000. The server returns a 503
error if the counter exceeds this value.

Should be less than

5,000 at all times.

ASP.NET
Applications

MSExchange Web Services

Outlook Web App, the Outlook Anywhere Proxy, Microsoft Exchange ActiveSync, offline Address book
downloads, and the Availability Service response times are also valuable metrics to monitor.
Group

Counter

Description

Expected value

MSExchange
OWA

Average Response
Time

Shows the average time (in

ms) that elapsed for the
request. Used to determine
the latency that a client is
experiencing.

Should be less than 100 ms at

all times. Higher values may
indicate high user load, or
higher-than-normal CPU time.

Average Search
Time

Shows the average time (in

ms) that elapsed while
waiting for a search to
complete.

Should be less than 100 ms at

all times.

Number of failed
back end
connection
attempts per
second

Shows the rate at which the

RPC proxy attempts fail to
establish a connection to a
back end server.

Should be 0 at all times.

RPC/HTTP
Proxy

10-14

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

(continued)
Group

Counter

Description

Expected value

MSExchange
ActiveSync

Average Request
Time

Shows the average time that Varies by devices, carrier, or

elapsed while waiting for a
configuration. You must use a
request to complete.
baseline to set this threshold.
Determines the rate at which
the Availability Service
requests are occurring.

MSExchangeFS:
OAB

Download Task
Queued

Shows a value of 1 if the task Should be 0 at all times. Values

is queued for execution,
greater than 0 indicate a failure
otherwise shows 0.
to copy offline address book
data files from Mailbox servers.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-15

Planning Message Tracking and Logging for Transport Servers

Exchange Server Hub Transport and Edge Transport servers generate transport logs, which provide useful
information about messages in transit through your messaging pipeline. You can configure your transport
servers to generate logs that relate to:

Connectivity. These logs record the connection activity of outbound message queues. Specifically,
they track the connection activity from the sending queue to the destination Mailbox server, smart
host, or domain. The default maximum log file size is 10 megabytes (MB) and circular logging is
selected by default. Connectivity logging is disabled by default.

Protocols. These logs record Simple Mail Transfer Protocol (SMTP) conversations between email
servers. In Exchange Server, these conversations occur at the servers hosting Send or Receive
connectors. As with connectivity logging, the default maximum log file size is 10 MB, and circular
logging is selected by default. Protocol logging is disabled by default.

Message tracking. These logs provide a detailed log of all message activity as messages flow between
the Hub Transport and Edge Transport servers, and between the transport servers and the Mailbox
server role. Message tracking is enabled by default. Circular logging is also enabled by default, and
the maximum log file size defaults to 10 MB.

Agent activity. These logs record the actions performed by specific anti-spam agents on the transport
servers. The following agents can write to the log:

Connection Filter agent

Content Filter agent

Edge Rules agent

Recipient Filter agent

Sender Filter agent

Sender ID agent

10-16

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

As with the other logs, the default maximum log file size is 10 MB, and circular logging is enabled.
Agent logging is also enabled by default.

Routing tables. These logs record a snapshot of the Exchange Server routing tables on a periodic
basis. The default log file size is 50 MB. The routing log is updated when the following events occur:

A routing configuration change is detected.

The time interval specified by the RoutingConfigReloadInterval parameter in the

EdgeTransport.exe.config has passed.

The Microsoft Exchange Transport service is started.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-17

Planning How to Monitor Baselines and Trend Analysis

You should give careful consideration to the value of performance data to ensure that it reflects the real
server environment. Additionally, you should consider performance analysis in addition to business plans.
By analyzing performance trends, you can predict when existing capacity is likely to be exhausted. You
should review historical analysis with consideration to your business, and use this to determine when
additional capacity is required. Some peaks are associated with one-time activities, such as very large
orders. Other peaks occur on a regular basissuch as a monthly payrolland these peaks may require
increased capacity to meet increasing numbers of employees.
Planning for future server capacity is a requirement for all organizations. Business planning often requires
additional server capacity to meet targets. By aligning your IT strategy with the strategy of the business,
you can support the business objectives.
The introduction of new services and applicationssuch as the deployment of Exchange Server 2010
can affect the performance of your IT infrastructure. These services may receive dedicated hardware,
although they often use the same local area network (LAN) and wide area network (WAN) network
infrastructure.
Planning for future capacity should include all hardware components, and how the new Exchange Servers
and related services and applications affect the existing infrastructure. Factors such as power, cooling, and
rack space are often overlooked during initial exercises to plan capacity expansion. You should consider
how your infrastructure can scale up and scale out to support an increased workload.
Tasks such as upgrading to Exchange Server 2010 and updating operating systems may affect your servers
and network. It is not unknown for an update to cause a problem with an application. Careful
performance monitoring before and after you apply updates can help you identify problems.
Expanding business requires you to provide support for more users. You should consider business
requirements when you purchase hardware. This consideration will ensure that you can meet future
business requirements by increasing the number of servers, or by adding capacity to existing hardware.

10-18

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Capacity requirements include:

More servers.

Additional hardware.

Reducing application loads.

Reducing users.

To determine which thresholds denote an existing problem, set a monitoring baseline by reviewing
monitoring data over a full business cycle. Business cycles vary for each company, and your cycle should
include both busy and slow periods. For some businesses, busy periods might correlate with the end-ofmonth accounting-close processes, or periods with notably high sales figures. Gathering a broad data set
will provide sufficient data to determine the appropriate operating thresholds.
To use the collected performance data:
1.

Create a monitoring baseline by averaging performance metrics from a properly operating system:

Monitor performance for a full business cycle.

Note any peaks or troughs in the data.

2.

Set warning-level and error-level thresholds.

3.

Review growth trends regularly to:

Adjust thresholds.

Adjust server configurations.

It is important that you review your thresholds periodically, so you can adjust the serversor the
thresholds themselvesto ensure proper monitoring.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-19

Lesson 2

Planning Exchange Server Troubleshooting

Even in a well-maintained Exchange Server organization, problems can arise, which you must identify and
repair. Although general troubleshooting guidelines exist, often, experience and an analytical approach
provide the best tools for successfully discovering the problems source, and then fixing it.
After completing this lesson, you will be able to:

Describe Windows Server tools that can help you perform troubleshooting tasks.

Describe the Exchange Server tools that can help you perform troubleshooting tasks.

Develop a message delivery troubleshooting plan.

Develop a Client Access server troubleshooting plan.

Develop a mailbox database troubleshooting plan.

10-20

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Windows Server Tools

You can use many other toolsin addition to the Microsoft Management Console (MMC) snap-ins, the
Exchange Management Console, the Exchange Management Shell, and Active Directory Users and
Computersto manage and troubleshoot an Exchange Server 2010 organization.
The following table lists and describes additional Exchange Server 2010 troubleshooting tools.
Tool name

Description

ADSI Edit
(adsiedit.msc)

Use for low-level Active Directory Domain Services (AD DS) and Active
Directory editing. Install with the Remote Server Administration Tools.

DNS Resolver (DNSDiag)

(Dnsdiag.exe)

Use to troubleshoot Domain Name System (DNS) issues. The tool

simulates the SMTP service's internal code path, and prints diagnostic
messages that indicate how the DNS resolution is proceeding.

DSACLS
(dsacls.exe)

Use this command-line tool to query and change permissions and

security attributes of AD DS objects.

Error Code Look-up

(Err.exe)

Use to determine error values from decimal and hexadecimal error

codes in Windows products. This is a downloadable tool.

Event Viewer
(eventvwr.msc)

Use this MMC snap-in to view logged events such as errors and
warnings.

LDP
(ldp.exe)

Use to perform Lightweight Directory Access Protocol (LDAP) searches

against the Active Directory directory service or AD DS for specific
informationgiven search criteria. This tool also enables you to query
data that would otherwise not be visible through the administrative
tools included in Windows Server and Exchange Server.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-21

(continued)
Tool name

Description

Microsoft Error Reporting

Exchange Server 2010 uses Windows Error Reporting to collect crash

dumps and debug information. It enables administrators to track and
address errors related to the Windows operating system, Windows
components, and applications such as Exchange Server 2010. This
service gives administrators and users the opportunity to send data
about errors to Microsoft, and to receive information about errors.
Administrators can use Microsoft Error Reporting to address customer
problems in a timely manner, and to help improve the quality of
Microsoft products.

Process Monitor
(procmon.exe)

Use to monitor real-time file system, registry, and process or thread

activity.

10-22

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Exchange Server Tools

Over the years, a number of useful Exchange Server troubleshooting tools have been introduced. Each
tool has a specific use, but they all use detailed product knowledge and information about your
environment to suggest potential problem solutions.

Exchange Best Practices Analyzer (ExBPA). This is an invaluable tool for identifying potential issues
based on deviations from best practices, and for gathering a great deal of information about the
Exchange Server organization, which you can then use for reference and for troubleshooting
problems.

Performance Troubleshooter. This tool helps you locate and identify performance-related issues that
could affect Exchange servers. You diagnose problems by selecting the symptoms observed. Based on
the symptoms, the tool walks you through the correct troubleshooting path. Performance
Troubleshooter identifies possible bottlenecks, and suggests corrective actions.

The Exchange Mail Flow Troubleshooter. This tool helps provide easy access to various data sources
that are required to troubleshoot problems with mail flow, such as non-delivery reports (NDRs),
queue backups, and slow deliveries. The tool then automatically diagnoses the retrieved data,
presents an analysis of the possible root causes, and suggests corrective actions.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-23

Other toolssuch as the Performance and Reliability Monitorcheck the health of the Exchange Server
processes. You can use the Queue Viewer to view the message status in transport queues. Tools such as
Network Monitor and Telnet can help you troubleshoot network issues and message tracking, and the
Routing Log Viewer can help you troubleshoot message delivery issues. The following table lists additional
tools.
Tool name

Description

Exchange Server Database Utilities

(Eseutil.exe)

Use this tool to perform offline database procedures, such as

defragmentation and integrity checking.

Exchange Server Jetstress

Use this tool as a benchmarking tool to validate your storage

subsystem.

Exchange Profile Analyzer

(epa.msi)

Use this tool to collect estimated statistical information from a

single mailbox store, or from across an entire Exchange Server
organization. Use the collected data for tasks such as analyzing
the performance and health of a server that has mailboxes.

Exchange Store TreeView Control

(Extreeview.ocx)

Use this tool to display a hierarchical list of node objects that

correspond to folders in the Exchange Server store.

Information Store Integrity Checker

(isinteg.exe)

Use this tool to find and remove errors in the public and private
information store databases. This tool is intended for disaster
recovery situations, and not for routine maintenance.

Inter-Organization Replication
(exscfg.exe; exssrv.exe)

Use this tool to replicate public folder information (including

free/busy information) between Exchange Server organizations.
Can be used between forests.

Exchange Load Generator

(Loadgen.msi)

Use this tool as a benchmarking tool to test the response of

servers to mail loads.

Microsoft Baseline Security Analyzer Use this tool to scan local or remote systems for common
(MBSA)
configuration errors, and to verify security best practices.
GUI: MBSA.exe
Command line: mbsacli.exe
RPC Ping utility
(rpings.exe and rpingc.exe)

Use this tool to confirm RPC connectivity between the computer

that is running Exchange Server, and any of the client
workstations on the network.

Telnet
(telnet.exe)

Establish a direct connection to an SMTP connector on an

Exchange Server, in order to verify connectivity and inbound
mail-flow.

10-24

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Discussion: Developing a Message Delivery Troubleshooting Plan

You can apply standard troubleshooting techniques to the unique problems that can occur with Hub and
Edge Transport servers. Use tools such as the Queue Viewer, message tracking system, and Mail Flow
Troubleshooter to identify the problem, and then work toward a resolution.

Discussion Question
Question: Users are reporting non-deliverable and slow-to-deliver outbound email. What
process can you use to troubleshoot the problem?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-25

Discussion: Developing a Client Access Troubleshooting Plan

You can apply standard troubleshooting techniques to the unique problems that can occur with Client
Access servers. Use tools such as the Exchange Best Practices Analyzer and the Event Viewer to identify the
problem and work toward a resolution.

Discussion Question
Question: Office Outlook users can no longer connect to the system. What process can you use
to troubleshoot the problem?

10-26

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Discussion: Developing a Mailbox Database Troubleshooting Plan

You can apply standard troubleshooting techniques to the unique problems that can occur with Mailbox
servers. Use tools such as the Database Troubleshooter and the Event Viewer to identify the problem and
work toward a resolution.

Discussion Question
Question: A database has gone offline. What process can you use to troubleshoot the problem?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-27

Lab: Planning Exchange Server 2010 Monitoring and

Troubleshooting

Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, you must:
1.

On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, 10233B-VAN-EX2, and the 10233B-VAN-EX3

virtual machines are running.

3.

If required, connect to the virtual machines. Log on to the virtual machines as

Adatum\Administrator using the password Pa$$w0rd.

Lab Scenario
You are a messaging engineer for A. Datum Corporation, an enterprise-level organization with multiple
locations. You have been tasked with creating a performance baseline for the new Exchange Server 2010
messaging system that your colleagues are about to deploy.

10-28

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Exercise 1: Establishing a Baseline for Performance

Scenario
You have created a test environment that is representative of the production messaging environment.
You must use the Load Generator to simulate the expected load.
The main tasks for this exercise are as follows:
1.

Create a User Defined data collector set.

2.

Configure Load Generator with suitable values to simulate the required load.

3.

Gather performance data, and analyze results.

Task 1: Create a User Defined data collector set

1.

On VAN-EX1, open Exchange Management Console, and then load the Performance Monitor from
the Toolbox.

2.

Create a User Defined data collector set with the following properties:

3.

Name: Baseline

Create manually (Advanced)

Data type: Performance counter

Counters:

Memory

MSExchangeIS

MSExchangeIS Mailbox

MSExchangeTransport Queues

MSExchangeTransport SmtpReceive

MSExchangeTransport SmtpSend

Physical Disk

Processor

Server

System

Sample interval: 1

Data save location: default

Save, but do not start the data collector set.

Task 2: Configure Load Generator with suitable values to simulate the required load
1.

Switch to the VAN-DC1 computer.

2.

Open Exchange Load Generator 2010 by clicking the Start menu, pointing to All Programs, and then
clicking the Microsoft Exchange folder.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-29

3.

Start a new test using the following detailed steps:

a.

In Microsoft Exchange Load Generator 2010, click Start a new test.

b.

Click Create a new test configuration, and then click Continue.

c.

On the Specify test settings page, under Define the total length of the simulation, in the
Hours box, type 0.

d.

In the Minutes box, type 10.

Note

Do not configure the Define the length of a simulation day value.

e.

In the Directory Access Password box, type Pa$$w0rd.

f.

In the Mailbox Account Master Password box, type Pa$$w0rd, and then click Continue with
recipient management.

g.

On the User settings page, in the text box, type 12, and then click Distribute users evenly
across databases.

h.

Click Continue.

i.

On the Advanced recipient settings page, select the following check boxes.

Use distribution lists

Use dynamic distribution lists

Create one for all the users

Create one per mailbox database

Use contacts

j.

In the Number of contact box, type 20 and then click Continue.

k.

On the Specify test user groups page, click the PLUS SIGN (+).

l.

In the resulting item, in the Client Type list, click Outlook 2007 Online.

m. On the Specify test user groups page, click the PLUS SIGN(+).
n.

In the resulting item, in the Client Type list, click Outlook 2007 Cached, and in the Action
Profile list, click Heavy.

o.

Click Continue, and on the Remote configurations page, click Continue.

p.

On the Configuration summary page, click Save the configuration file as.

q.

In the Save As dialog box, in the File name box, type Baseline, and then click Save.

r.

In the Configuration Saved dialog box, click OK.

s.

Click Skip initialization phase and run the simulation immediately.

4.

Switch to VAN-EX1, and switch to Performance Monitor.

5.

Start the Baseline data collector set, and switch back to VAN-DC1. Once the simulation has
completed, switch back to VAN-EX1.
Note

This simulation runs for 10 minutes.

10-30

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Task 3: Gather performance data, and analyze results

1.

On VAN-EX1, switch to Performance Monitor.

2.

Stop the Baseline data collector set.

3.

Click System Monitor. Click the red X in the toolbar repeatedly to remove all counters from the
display.

4.

Press CTRL+L.

5.

Click Log files, and then select the DataCollector01.blg log located in the Admin > Baseline > xxxx000001 folder.

6.

From the Data tab, add the following counters:

Performance object

Counter

Memory

Pages/sec

MSExchangeIS

RPC Requests

MSExchangeIS

User Count

MSExchangeIS Mailbox

Local delivery rate

MSExchangeIS Mailbox

Messages Delivered/sec

MSExchangeIS Mailbox

Messages Queued For Submission

MSExchangeIS Mailbox

Messages Sent/sec

MSExchangeTransport Queues

Active Remote Delivery Queue Length

MSExchangeTransport Queues

Retry Remote Delivery Queue Length

MSExchangeTransport Queues

Submission Queue Length

MSExchangeTransport SmtpReceive

Messages Received/sec

MSExchangeTransport SmtpSend

Messages Sent/sec

Physical Disk

% Disk Time

Physical Disk

Avg. Disk Queue length

Processor

% Processor Time

Server

Pool Nonpaged Failures

Server

Work Item Shortages

System

Processor Queue Length

Note If Performance Monitor experiences problems, close and restart it. Then continue
from step 3.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-31

7.

Click OK twice, and then view the data as a report.

8.

Complete the following table.

Counter

Average

Memory Pages/sec
MSExchangeIS - User Count
MSExchangeIS - RPC Requests
MSExchangeIS Mailbox - Local delivery rate
MSExchangeIS Mailbox - Messages Delivered/sec
MSExchangeIS Mailbox - Messages Queued For Submission
MSExchangeIS Mailbox - Messages Sent/sec
MSExchangeTransport Queues - Active Remote Delivery Queue
Length
MSExchangeTransport Queues - Retry Remote Delivery Queue
Length
MSExchangeTransport Queues - Submission Queue Length
MSExchangeTransport SmtpReceive - Messages Received/sec
MSExchangeTransport SmtpSend Messages Sent/sec
Physical Disk - % Disk Time
Physical Disk - Avg. Disk Queue length
Processor - % Processor Time
Server - Pool Nonpaged Failures
Server - Work Item Shortages
System - Processor Queue Length

Note

Do not worry that some values are zero; this is a simulation.

Question: Do any counters indicate a bottleneck?

Results: After this exercise, you should have created an Exchange Server performance baseline.

10-32

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Exercise 2: Measuring the Production System Performance under

Additional Load
Scenario
The server deployment is complete, but users are now complaining of reduced performance. You must
monitor the messaging system, and then compare the newly recorded results with the baseline that you
previously established.
Note As this is a training exercise, you will use Load Generator to simulate the load.
The main tasks for this exercise are as follows:
1.

Generate additional load with Load Generator to simulate the environment of heavier than planned
for usage.

2.

Compare the data with the baseline data.

Task 1: Generate additional load with Load Generator to simulate the environment
of heavier than planned for usage
1.

Switch to VAN-DC1.

2.

In Microsoft Exchange Load Generator, click Start a new test.

3.

Start a new test using the following steps:

a.

Click Use the following saved configuration file, and then click Browse.

b.

In the Please select a configuration file dialog box, double-click Baseline.xml, and then click
Continue.

c.

On the Specify test settings page, click Continue with recipient management.

d.

On the User settings page, in the text box, type 20, and then click Distribute users evenly
across databases.

e.

Click Continue.

f.

On the Advanced recipient settings page, select the following check boxes.

Use distribution lists

Use dynamic distribution lists

Create one for all the users

Create one per server

Create one per mailbox database

Use contacts

g.

In the Number of contact box, type 50 and then click Continue.

h.

On the Specify test user groups page, click the PLUS SIGN (+).

i.

In the resulting item, in the Client Type list, click Outlook 2007 Online, and in the Action
Profile list, click Heavy.

j.

On the Specify test user groups page, click the PLUS SIGN (+).

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-33

k.

In the resulting item, in the Client Type list, click Owa2010Module, and in the Action Profile
list, accept the defaults.

l.

Click Continue, and on the Remote configurations page, click Continue.

m. On the Configuration summary page, click Save the configuration file as.
n.

In the Save As dialog box, in the File name box, type Adatum, and then click Save.

o.

In the Configuration Saved dialog box, click OK.

p.

Click Skip initialization phase and run the simulation immediately.

4.

Switch to VAN-EX1, and switch to Performance Monitor.

5.

Start the Baseline data collector set, and then switch back to VAN-DC1.

6.

When the simulation completes, switch to VAN-EX1.

Task 2: Compare the data with the baseline data

1.

In Performance Monitor, stop the Baseline data collector set.

2.

In the right pane, right-click, and then click Properties.

3.

In the Performance Monitor Properties dialog box, click the Source tab, and then click Remove.

4.

Click Log files, and then click Add.

5.

In the Select Log File dialog box, click Up One Level, double-click the folder ending in 000002,
double-click DataCollector01.blg, and then click OK.

6.

View the counter values, and then complete the following table.
Counter
Memory Pages/sec
MSExchangeIS - User Count
MSExchangeIS - RPC Requests
MSExchangeIS Mailbox - Local delivery rate
MSExchangeIS Mailbox - Messages Delivered/sec
MSExchangeIS Mailbox - Messages Queued For
Submission
MSExchangeIS Mailbox - Messages Sent/sec
MSExchangeTransport Queues - Active Remote Delivery
Queue Length
MSExchangeTransport Queues - Retry Remote Delivery
Queue Length
MSExchangeTransport Queues - Submission Queue
Length
MSExchangeTransport SmtpReceive - Messages
Received/sec

Average

10-34

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Counter

Average

MSExchangeTransport SmtpSend - Messages Sent/sec

Physical Disk - % Disk Time
Physical Disk - Avg. Disk Queue length
Processor - % Processor Time
Server - Pool Nonpaged Failures
Server - Work Item Shortages
System - Processor Queue Length
Question: How do the values compare to the baseline data?

Results: After this exercise, you should have determined which server resources are likely to become
bottlenecked if server load continues to increase.

To prepare for the next module

When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the
following steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3.

Note No virtual machines are required for the next lab.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 10-35

Module Review and Takeaways

Review Questions
1.

What is an advantage of using automated monitoring systems such as System Center Operations
Manager 2010?

2.

In terms of monitoring Mailbox server performance, what is the most likely performance bottleneck
you will encounter?

3.

Which components responsiveness can you monitor to ensure adequate performance of Outlook
Web App clients?

4.

Which transport logs should you enable in order to troubleshoot message flow?

5.

Why is it important to analyze performance trends?

10-36

Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

11-1

Module 11
Upgrading to Microsoft Exchange Server 2010
Contents:
Lesson 1: Overview of Upgrading to Exchange Server 2010

11-3

Lesson 2: Planning the Upgrade from Exchange Server 2003 to

Exchange Server 2010

11-12

Lesson 3: Planning the Upgrade from Exchange Server 2007 to

Exchange Server 2010

11-28

Lab: Upgrading to Exchange Server 2010

11-41

11-2

Upgrading to Microsoft Exchange Server 2010

Module Overview

Microsoft Exchange Server is a popular messaging system, and many organizations have selected it as
the foundation for their messaging infrastructure.
When you decide to implement Exchange Server 2010, if you already have a previous Exchange Server
version installed in your organization, then you must plan the upgrade from your existing version of
Exchange Server. Depending on your current Exchange Server version, you can perform a coexistence
upgrade to Exchange Server 2010 by deploying Exchange Server 2010 servers into an existing Exchange
organization; for convenience, we shall refer to this method as an upgrade.
Alternatively, you might choose to deploy the new Exchange Server 2010 organization in parallel to your
existing Exchange Server organization; we shall refer to this method as a migration. To avoid disruption to
users, it is important that you understand the implications of choosing between a coexistence upgrade,
and a side-by-side migration.
This module provides an overview of the options that organizations have when choosing to implement
Exchange Server 2010, and provides details on how to upgrade an existing Microsoft Exchange Server
2003 or Exchange Server 2007 organization to Exchange Server 2010.
After completing this module, you will be able to:

Describe the general Exchange Server 2010 upgrade scenarios and strategies.

Plan the upgrade from Exchange Server 2003 to Exchange Server 2010.

Plan the upgrade from Exchange Server 2007 to Exchange Server 2010.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-3

Lesson 1

Overview of Upgrading to Exchange Server 2010

While you perform the upgrade to Exchange Server 2010, users should still be able to send and receive
email, and perform scheduling tasks with the existing messaging system with minimal disruption.
Consequently, it is important to select the appropriate upgrade strategy to minimize user disruption.
After completing this lesson, you will be able to:

Describe the upgrade scenarios that are supported in Exchange Server 2010.

Select a suitable upgrade strategy.

Describe the components of coexistence and upgrade strategies.

Plan a multisite upgrade.

Determine how to support deprecated features in Exchange Server 2010.

11-4

Upgrading to Microsoft Exchange Server 2010

Supported Upgrade Scenarios

Key Points
Note It is important to understand that the term upgrade refers to the upgrade of your
Exchange Server organization, rather than specific servers within your organization; you
cannot perform an upgrade of an individual Exchange server to Exchange Server 2010. You
can perform an upgrade of your Exchange organization by deploying new Exchange Server
2010 servers, and then migrating mailboxes and services to them. For brevity, we shall refer
to this process as an upgrade.
Upgrading an Exchange Server organization to Exchange Server 2010 is usually the easiest option.
Therefore, most organizations choose this path for upgrading their existing Exchange Server deployments;
however, this option has several prerequisites.

Active Directory Domain Services Requirements

To upgrade from a previous Exchange Server version to Exchange Server 2010, you must meet the
following Active Directory Domain Services (AD DS) requirements:

Your schema master must be running the Windows Server 2003 operating system with Service Pack
1 (SP1) or newer.

You must deploy at least one global catalog server in each site that is running Windows Server 2003
with SP1 or newer.

You must have configured your AD DS forest to be at least at the Windows Server 2003 forestfunctional level or higher.

You must deploy at least one domain controller and one global catalog server with a writeable AD DS
copy in each Active Directory site; Exchange Server 2010 cannot use read-only domain controllers
(RODCs) or read-only global catalog servers running Windows Server 2008.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-5

Supported Upgrade Deployments

When you upgrade an existing Exchange Server organization to Exchange Server 2010, it is important to
know which upgrade strategies are supported. The following table identifies some common upgrade
strategies.

Exchange Server version

Exchange
organization
upgrade

Exchange 2000 Server

Not supported

Although an upgrade is not supported, you can use a

migration strategy to transition to Exchange
Server 2010. Alternately, you can upgrade the Exchange
2000 Server organization completely to Exchange
Server 2003 or Exchange Server 2007, and then perform
an in-place upgrade to Exchange Server 2010.

Exchange Server 2003

with SP2 or newer

Supported

Before you install Exchange Server 2010 servers into an

existing Exchange Server 2003 organization, you must
configure the organization to run in native mode.

Exchange Server 2007

with SP2 or newer

Supported

When upgrading from Exchange Server 2007, you must

upgrade all of your organizations Exchange Server
2007 servers to SP2.

Mixed Exchange
Server 2007and Exchange
Server 2003 organization

Supported

When you are ready to upgrade your mixed mode

environment, upgrade each Active Directory site
individually. If you have Active Directory sites with only
Exchange 2007 or Exchange 2003 in them, follow the
instructions for upgrading from that version for that
Active Directory site. For example, if you have Exchange
Server 2007 in Active Directory site A, then follow the
upgrade instructions for Exchange Server 2007. If you
have Exchange Server 2003 installed in Active Directory
site B, then follow the upgrade instructions for
Exchange Server 2003.

Comments

After you deploy a new Exchange Server 2010 organization, you cannot add servers running earlier
Exchange Server versions to the organization; Exchange Server 2010 does not support the addition of
earlier Exchange Server versions to an Exchange organization that includes only Exchange Server 2010
servers.

11-6

Upgrading to Microsoft Exchange Server 2010

Choosing an Upgrade Strategy

Key Points
Exchange Server 2010 supports several different options for upgrading from other messaging systems.

Exchange Server Upgrade Terminology

The following terminology describes the various upgrade scenarios:

Upgrade. In this scenario, you upgrade an existing Exchange Server organization to Exchange
Server 2010. To perform the upgrade, install Exchange Server 2010 servers into an existing Exchange
Server 2003 or Exchange Server 2007 organization, and then move data and functionality from the
existing Exchange servers to the new Exchange Server 2010 servers. This is the easiest and least
disruptive scenario for integrating Exchange Server-based messaging systems, because the different
Exchange Server versions share configuration and recipient information automatically.

Migration. In this scenario, you upgrade from either a non-Exchange Server messaging system or
from an existing Exchange Server organization, to a new Exchange Server 2010 organization, without
retaining any of the existing organizations Exchange server configuration data. This is more complex
to configure, because by default, the two messaging systems share no information, and consequently
you must configure all connections between the systems.
Note You must deploy a second AD DS forest when you perform a migration from one
Exchange Server organization to another. Then migrate all user accounts to the second
forest.

In-place upgrade. In this scenario, you upgrade a single computer that is running a previous
Exchange Server version to a newer Exchange Server version. Exchange Server 2010 does not support
in-place upgrades.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-7

Choosing a Single-Phase or Multiphase Upgrade

Once you have decided to perform an upgrade, you must select the appropriate upgrade strategy. You
can choose between several options. The selection you make depends upon your current environment,
your organizations requirements for data migration, and your project timeline.
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 2010, and move all required data and services to the new system. In a single-phase
upgrade, you do not need to plan for an extended period of coexistence between the two systems.
Typically, you perform this type of upgrade over a short period, perhaps a weekend. This enables you
to shut down the entire messaging system, and replace it with Exchange Server 2010, so that when
users return to work the new messaging system is operational. In this scenario, the period of
coexistence or interoperability is quite short.
While this upgrade is the fastest option, it also introduces a significant risk if the upgrade fails. This
scenario is feasible only for small organizations that must replace just a few servers, and there are only
a small 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 2010. Because you spread this incremental upgrade over a longer period,
you decrease your organizations risk. However, in this scenario, you also must plan for coexistence or
interoperability. This is the best approach for medium to large organizations, because of their
complex messaging requirements.

11-8

Upgrading to Microsoft Exchange Server 2010

Components of a Coexistence and Upgrade Strategy

Key Points
In most coexistence scenarios, you must ensure that users with mailboxes on both messaging systems
have access to the following:

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.

Email message flow. When you run two messaging systems, users must be able to send email to other
organizational users, and to and from users on the Internet. Message flow should be transparent to
users. Users do not need to knownor should it matterwhich messaging system contains the
recipients mailbox.

Global address list (GAL). To simplify the process of sending messages between messaging systems,
you must ensure that you synchronize the GAL between messaging systems.

Calendar information. To facilitate scheduling of meetings between the two messaging systems, you
must ensure that Free/Busy information replicates between the two messaging systems.

Administration of the system. It is important that during the upgrade you can continue to administer
the Exchange Server organization.

If you implement an upgrade to Exchange Server 2010, the design of the upgrade process ensures that
these coexistence components are maintained throughout the coexistence.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-9

Planning a Multisite Upgrade

Key Points
If your organization has multiple AD DS sites that contain Exchange servers, it is important to consider the
order in which you upgrade these sites.
When planning a multisite organization upgrade, remember that Exchange Server does not support the
upgrade of internal sites before you have upgraded Internet-facing sites; this is because Client Access
server-to-Client Access server proxying is only supported from Exchange Server 2010 to Exchange
Server 2007, and not the other way. Consequently, you must upgrade Internet-facing sites first.
Within the site, the recommended order in which you must upgrade the specific Exchange Server roles is
as follows:
1.

Client Access

2.

Hub Transport

3.

Mailbox

4.

Unified Messaging

Once you have upgraded all the Internet-facing sites, you can begin to upgrade the internal AD DS sites.
You should upgrade the server roles in the same order as your Internet-facing sites.
Exchange Server 2003 does not support AD DS sites for message routing; instead, all Exchange
Server 2010 servers are added as members of a single routing group called Exchange Routing Group
(DWBGZMFD01QNBJR). The implications of this are explored in the following lesson.

11-10

Upgrading to Microsoft Exchange Server 2010

Options for Supporting Deprecated Features

Key Points
Exchange Server 2010 does not implement certain features from earlier Exchange Server versions. It is
important to understand which features are affected, and to plan implementation of suitable alternatives
to these features.
The following Exchange Server 2003 features are not supported in Exchange Server 2010:

Novell GroupWise connector. This connector is a component of Exchange Server 2003, and enables
you to implement messaging coexistence between Exchange and Novell GroupWise organizations.
The connector provides mail flow connectivity, in addition to the ability to synchronize the two
directories. With directory synchronization in place, each GAL is updated with users from the other
organization. Exchange Server and Novell GroupWise users can send email to each other by selecting
the recipient from their address books. If you require this functionality, retain at least one Exchange
Server 2003 server.

Network News Transfer Protocol. The Network News Transfer Protocol (NNTP) retrieves newsgroup
content. If you require NNTP functionality, retain at least one Exchange Server 2003 server.

Microsoft Office Outlook Mobile Access. The Microsoft Exchange ActiveSync technology provides
much of this functionality.

Inter-Organization Replication Tool. In Exchange Server 2003, this utility is made up of two programs:
the Exchange Server Replication Configuration utility (Exscfg.exe), and the Exchange Server
Replication Service (Exssrv.exe). You can use these programs to coordinate meetings, appointments,
and contact information between members of two different legacy Exchange organizations. Exchange
Server 2010 uses the Microsoft Federation Gateway to establish and maintain federation between
Exchange Server organizations, so that users can share availability information, calendaring data, and
contacts.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-11

The following Exchange Server 2007 features are not supported in Exchange Server 2010:

Single copy clusters (SCC), local continuous replication (LCR), cluster continuous replication (CCR) and
standby continuous replication (SCR). In Exchange Server 2007, these Mailbox features are used to
provide for high availability of storage groups. In Exchange Server 2010, they are replaced by
database availability groups (DAGs) and mailbox database copies.

Microsoft Transporter Suite for Lotus Domino. Microsoft Transporter Suite is a set of interoperability
and migration tools that migrate content from Lotus Domino servers to Exchange Server. The suite
contains a set of tools for Directory and Free/Busy interoperability between Lotus Domino and
Exchange Server 2007, and AD DS. In addition, the suite contains migration tools to help migrate
users, groups, personal address lists, mailboxes, personal mail archives, and applications from Lotus
Domino to AD DS, Exchange Server 2007, and Windows SharePoint Services 3.0. If you require this
functionality, you must maintain an Exchange Server 2007 server in your Exchange organization.

Programmatic access to Exchange by using Exchange OLE DB Provider (ExOLEDB), Web Distributed
Authoring and Versioning (WebDAV) or CDO for Exchange 2000 Server (CDOEX). Replace the
ExOLEDB, WebDAV or CODEX functionality with Exchange Web Services (EWS) or EWS-Managed
application programming interface (API). Alternatively, maintain an Exchange Server 2007 server in
your organization for mailboxes of applications that use these technologies.

11-12

Upgrading to Microsoft Exchange Server 2010

Lesson 2

Planning the Upgrade from Exchange Server 2003 to

Exchange Server 2010

Many organizations still use Exchange Server 2003 for their messaging system, and they might not have
any plans of upgrading to Exchange Server 2007. Microsoft supports an upgrade from Exchange Server
2003 directly to Exchange Server 2010, specifically for these organizations. This lesson describes how to
upgrade an Exchange Server 2003 organization to Exchange Server 2010.
After completing this lesson, you will be able to:

Determine whether your Exchange Server 2003 organization is ready to upgrade to Exchange
Server 2010.

Describe the process for installing Exchange Server 2010 in an Exchange Server 2003 organization.

Design the Client Services coexistence.

Design external access for Exchange Server 2003 client services.

Design the Message Transport upgrade.

Plan the upgrade of administrative roles.

Plan the removal of Exchange Server 2003.

Troubleshoot the upgrade process.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-13

Prerequisites for Installing Exchange Server 2010 in an

Exchange Server 2003 Organization

Key Points
Before you start the upgrade process, you must prepare AD DS for the Exchange Server 2010 deployment.
To do this, you must run Exchange Server 2010 setup using the /PrepareLegacyExchangePermissions
parameter and the /PrepareAD parameter. Additionally, your current infrastructure must meet the
following conditions:

The schema master and at least one global catalog server in each site must be running Windows
Server 2003 with SP1 or newer.

Both the domain and forest functional levels must be at least Windows Server 2003.

Your Exchange Server 2003 servers must be running Exchange Server 2003 with a minimum of SP2.

Your existing Exchange Server 2003 organization must be in native mode.

Changes Made by the PrepareLegacyExchangePermissions Setup Parameter

You must run the PrepareLegacyExchangePermissions setup parameter so that the Exchange
Server 2003 Recipient Update Service functions correctly after you update the Active Directory schema for
Exchange Server 2010. In Exchange Server 2003, the Recipient Update Service updates some mailbox
attributessuch as the proxy addresson mail-enabled user objects. It can do this 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 2010, the schema is
modified so that the server running Recipient Update Services no longer has the required permissions to
update the recipient properties. Running setup with the PrepareLegacyExchangePermissions parameter
modifies the permissions to ensure that the server can continue to modify recipient properties.

11-14

Upgrading to Microsoft Exchange Server 2010

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 Server versions:

Creates the Active Directory universal security group, ExchangeLegacyInterop. This group receives
permissions that allow the Exchange Server 2003 servers to send email to the Exchange Server 2010
servers.

Creates the Exchange Server 2010 administrative group, which is called Exchange Administrative
Group (FYDIBOHF23SPDLT).

Creates the Exchange Server 2010 routing group, which is called Exchange Routing Group
(DWBGZMFD01QNBJR).

The PrepareAD command also extends the schema to include the Exchange Server 2010 schema objects
and attributes.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-15

Process for Installing Exchange Server 2010 in an Exchange Server 2003

Organization

Key Points
When deploying Exchange Server 2010 in a supported Exchange Server organization, you must follow a
specific process.

Installing Exchange Server 2010

If an organization has only a single Active Directory site, use the following process for deploying Exchange
Server 2010.
1.

Install the Exchange Server 2010 Client Access server. After you install the Client Access server, you
should use this as the primary connection point for all client connections.

2.

Install the Exchange Server 2010 Hub Transport server. When you install the Hub Transport server in
an Exchange Server 2003 environment, it prompts you for the name of an Exchange Server 2003
computer that will be the routing-group bridgehead server between the Exchange Server 2003
routing group, and the Exchange Server 2010 routing group. Exchange Server 2010 no longer uses
routing groups to manage message routing, but you install all Exchange Server 2010 servers in a
routing group for backwards compatibility.

3.

Install the Exchange Server 2010 Mailbox servers. After the rest of the infrastructure is in place, you
can deploy the Exchange Server 2010 Mailbox servers, and start moving mailboxes and public folders
to the new servers.
Note If you deploy Exchange Server 2010 in a small or medium-size organization, and you
plan to deploy only one or two Exchange Server 2010 servers, you can perform a typical
installation and install simultaneously the Client Access server role, Hub Transport server
role, and the Mailbox server role.

11-16

Upgrading to Microsoft Exchange Server 2010

4.

Install Exchange Server 2010 Unified Messaging servers.

5.

For organizations with multiple sites, there are typically two types of Active Directory sites: Internetaccessible sites, and non-Internet accessible sites. A single Exchange Server organization may have
one or more Internet-accessible sites. When upgrading Active Directory sites, you should upgrade
Internet-accessible sites before non-Internet accessible sites.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-17

Designing Client Services Coexistence

Key Points
After you deploy the Exchange Server 2010 Client Access and Mailbox servers, the process that nonMessaging Application Programming Interface (non-MAPI) clients use when accessing the user mailboxes
depends on the type of client you are using and the mailboxs location.

Maintaining Free/Busy Information

Clients using Office Outlook 2003 require the system public folders to access the Free/Busy information,
while Office Outlook 2007 or newer clients can use the availability service on a Client Access server to
access this information.
If your organization includes Office Outlook 2003 clients, you need to retain the SCHEDULE+ FREE BUSY
system public folder for these clients. When you install the first Exchange Server 2010 Mailbox server in an
organization that includes Exchange Server 2003 servers, you configure a public folder database on the
server. You then can replicate the SCHEDULE+ FREE BUSY system public folder to the Exchange
Server 2010 server.

Maintaining Access to the Offline Address Book

Another difference between Exchange Server 2003 and Exchange Server 2010 is the method that they use
to distribute the offline address book to Office Outlook 2007 clients. In Exchange Server 2003, a public
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 use a web service to
download the offline address book.
In an Exchange Server 2003 organization, one of the Exchange servers performs daily updates of the
offline address book. When you deploy an Exchange Server 2010 Mailbox server in your organization, you
can use the Exchange Server 2010 management tools to move this role to a server running Exchange
Server 2010. You also need to configure the offline address book so that it is distributed through the
Exchange Web Service.

11-18

Upgrading to Microsoft Exchange Server 2010

If your organization includes Outlook 2003 clients, you need to ensure that you create a replica on the
Exchange Server 2010 Mailbox server of the system folders for the offline address book.

Maintaining Public Folder Availability

When you install Exchange Server 2010, a public folder database is not created by default. If you are
maintaining public folders in Exchange Server 2010, you need to create public folder databases on
Exchange Server 2010 Mailbox servers and replicate the public folder contents to Exchange Server 2010.
Unless usage patterns have changed, in most cases you need to create a public folder database for
Exchange Server 2010 in each location that has a public folder database for Exchange Server 2003.
A common way to move public folders from Exchange Server 2003 to Exchange Server 2010 is by using
the MoveAllReplicates.ps1 script. If you use this script, you do not need to configure replication for each
individual public folder.
Users with an Exchange Server 2010 mailbox can access public folders on Exchange Server 2003. The
routing group connectors between Exchange Server 2010 and Exchange Server 2003 routing groups have
public folder referrals enabled by default. However, in the default referral configuration, Exchange
Server 2010 users are always directed to a public folder replica on Exchange Server 2010 over a replica on
Exchange Server 2003. If you want users to access a replica on Exchange Server 2003 that is physically
closer than replicas on Exchange Server 2010, you need to create a custom public folder referrals list on
the public folder database.
Exchange Server 2003 allows access to public folders by using Internet message access protocol (IMAP)
and NNTP clients. Exchange Server 2010 does not provide IMAP or NNTP access to public folders. You can
use only MAPI or Outlook Web App to access public folders on Exchange Server 2010. If you have users
who need to access public folders by using IMAP or NNTP, you need to maintain a replica of the public
folders on Exchange Server 2003.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-19

Designing External Access for Exchange Server 2003 Client Services

Client Access servers provide Internet users with access to their mailboxes by using Outlook Web App,
ActiveSync, and Outlook Anywhere. It is important to understand how each of these methods behave
during the upgrade process to ensure that user access is not interrupted.
The first step in the upgrade process is to add one or more Exchange Server 2010 Client Access servers to
the site being upgraded. Clients accessing their mailbox from the Internet connect to the Exchange 2010
Client Access server and are then redirected or proxied to the appropriate Exchange 2003 server.

Outlook Web Access

To support coexistence of Exchange Server 2010 Outlook Web App and Exchange Server 2003 Outlook
Web Access, you need to configure a legacy URL. When Exchange Server 2003 Outlook Web Access users
log on to the Exchange Server 2010 Client Access server, they are redirected to the legacy URL. In a small
organization with a single computer running Exchange Server 2003 and hosting mailboxes, the legacy
URL can point to that single computer.
Larger organizations with multiple computers running Exchange Server 2003 have a front-end server. The
front-end server proxies Outlook Web Access requests to the server hosting the users mailbox. This is
required because Outlook Web Access for a specific user can be accessed only on the server that is
hosting that users mailbox. In this scenario, the legacy URL points to the front-end server.
The process for implementing the legacy URL is as follows:
1.

Create a new DNS record for the legacy URL, such as legacy.contoso.com.

2.

Configure a new certificate on the Exchange Server 2003 front-end server that has a subject matching
the new DNS record for the legacy URL.

11-20

Upgrading to Microsoft Exchange Server 2010

3.

Configure the Exchange2003URL value on the Exchange Server 2010 Client Access servers. The
parameter is the legacy URL, such as https://legacy.contoso.com/exchange.

4.

Update your firewall rules or reverse proxy to direct requests for the original Outlook Web Access
requests to the Exchange Server 2010 Client Access server.

After this process is complete, users who access the original URL (http://mail.contoso.com/exchange)
are serviced by the Exchange Server 2010 Client Access server. The Exchange Server 2010 Client Access
server handles requests for users who have Exchange Server 2010 mailboxes, and it redirects users who
have Exchange Server 2003 mailboxes to the legacy URL.
Considerations for using a legacy URL:

To support the use of a legacy URL, you need to have two valid Internet IP addresses available. Or,
you can use a single valid Internet IP address if your reverse proxy server supports redirection based
on host headers.

The Exchange Server 2003 front-end server must be configured to use forms-based authentication for
Outlook Web Access or authentication will fail.

ActiveSync and Outlook Anywhere

An Exchange Server 2010 Client Access server also provides Exchange Server 2003 users with access to
their mailboxes through ActiveSync and Outlook Anywhere. No special configuration is required. The
connection process is as follows:

When an Exchange ActiveSync client connects to the Client Access server and the user mailbox is
located on an Exchange Server 2003 back-end server, the Client Access server connects to the
Exchange Server 2003 server by using the Hypertext Transfer Protocol (HTTP) and provides access to
the user mailbox.

When an Outlook Anywhere client connects to the Client Access server and the user mailbox is
located on an Exchange Server 2003 back-end server, the Remote Procedure Call (RPC) proxy service
on the Client Access server connects to the back-end server by using RPC.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-21

Designing the Message Transport Upgrade

Key Points
To support coexistence between different Exchange Server versions, all servers running Exchange
Server 2010 are added automatically to a single routing group when you install Exchange Server 2010.
The Exchange Server 2010 routing group includes all Exchange Server 2010 servers, regardless of the
Active Directory site in which they reside.

Integrating Exchange Server 2010 into Exchange Server 2003 Routing Groups
During the coexistence phase of your planned upgrade, the Exchange Server 2010 servers are presented
to Exchange Server 2003 servers as members of a single routing group called Exchange Routing Group
(DWBGZMFD01QNBJR). When planning your upgrade to Exchange Server 2010, it is important that you
consider these routing topology differences.
During your first Exchange Server 2010 Hub Transport server installation in an existing Exchange
organization, you must specify an Exchange 2003 bridgehead server to establish the first routing group
connector. You should select a bridgehead server that is located either in a hub routing group, or in a
routing group that has many mailboxes. The routing group connector links the routing group where the
Exchange Server 2003 server resides with the Exchange Server 2010 routing group. From the perspective
of the Exchange Server 2003 servers, the Exchange Server 2010 routing group includes all Exchange Server
2010 servers, regardless of the AD DS site in which they reside.
The Exchange Server 2010 Hub Transport server that you install and the Exchange Server 2003
bridgehead that you select are configured as the source and target servers on two reciprocal routing
group connectors. This routing group connector creates a single connection point between Exchange
Server 2003 and Exchange Server 2010.

11-22

Upgrading to Microsoft Exchange Server 2010

Supporting Multiple Routing Groups

However, if your existing Exchange Server 2003 organization includes multiple routing groups, you may
want to create additional connection points between Exchange Server 2003 and Exchange Server 2010 to
optimize mail flow. Bear in mind that if you create multiple paths between the Exchange Server 2010
routing group and your legacy Exchange Server organization, you must suppress minor link state updates
to ensure that message looping does not occur when Exchange Server 2003 recalculates a route; when
link state updates are suppressed, Exchange Server 2003 servers queue messages at the point of failure,
instead of recalculating the route, in a similar way to Exchange Server 2010.

Upgrade External Connectivity

You can deploy the Edge Transport server as a smart host and Simple Mail Transfer Protocol (SMTP) relay
server for an existing Exchange Server 2003 organization. You can add an Edge Transport server to an
existing Exchange organization without upgrading the internal Exchange servers, or making any
organizational changes. You do not need to perform any AD DS configuration changes in advance of
deploying an Edge Transport server, because it is deployed outside AD DS.
When you deploy an Edge Transport server in an Exchange organization in which you have not yet
deployed Exchange Server 2010, you cannot use some features of the Edge Transport server role. You
cannot create an Edge Subscription in this scenario; consequently, you cannot use the Recipient Lookup
or Safelist aggregation features.
Because you cannot enable Edge Synchronization, you must manually configure message routing on the
internal Exchange bridgehead servers and the Edge Transport server, rather than using the Edge
Subscription to configure the settings based on the internal AD DS configuration. You need to:

Configure the Exchange Server 2003 bridgehead servers to use the Edge Transport server as a relay
for outbound Internet messages. To do this, configure the appropriate 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 organizations mail exchanger (MX) resource 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 Server 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 email, and an
SMTP Receive connector for receiving email from the Exchange Server 2003 servers, and configure a
Send connector for sending email to Internet recipients. By default, a Receive connector is configured
on the Edge Transport server that accepts 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.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-23

Designing the Upgrade of Administrative Roles

Key Points
As you upgrade to Exchange Server 2010, you also must plan for continued administration of the
organization.

Replicating Exchange Administrative Designs

Due to the design differences of administrative permissions in Exchange Server 2010 compared to
previous Exchange Server versions, you cannot directly replicate the Exchange Server 2003 administrative
design in Exchange Server 2007. One of the main differences that you need to plan for is that Exchange
Server 2010 does not use administrative groups for delegating permissions.
The following table describes some options for creating an Exchange Server 2010 administrative design
that emulates an Exchange Server 2003 design.
Exchange 2003 administrative assignment
options

Exchange Server 2010 equivalent

Exchange Full Administrator role at the

organization level

Add users or groups to the Exchange Organization

Administrator role group.

Exchange Administrator role at the

organization level

Exchange Server 2010 does not have a role group

equivalent to the Exchange Administrator role. You
can create a role group and assign the required
permissions through role-based access control
(RBAC).

Exchange View Administrator role at the

organization level

Add users or groups to the Exchange View-Only

Administrator role.

Exchange Full Administrator role at the

administrative group level

Create a new role group that is assigned all

management roles, but with a limited scope.

11-24

Upgrading to Microsoft Exchange Server 2010

(continued)
Exchange 2003 administrative assignment
options

Exchange Server 2010 equivalent

Exchange View Administrator role at the

administrative group level

Create a new role group with View-Only permissions

and a limited scope.

Recipient administrators with Exchange View

Administrator role and AD DS permissions

Add users and groups to the Exchange Recipient

Administrator role group.

Using Administrative Tools in a Coexistence Scenario

In addition to planning permissions delegation in Exchange Server 2010, you also must consider the
administrative tools for the different Exchange Server versions. You must use Exchange Server 2010
administration tools to manage all Exchange Server 2010 settings. After installing an Exchange
Server 2010 server, you should configure any global settings by using Exchange Server 2010 tools.
Exchange Server 2003 servers are not listed in the Exchange Server 2010 Exchange Management Console.
To manage Exchange Server 2003 settings, you must use the Exchange System Manager. You also can
manage recipients who have mailboxes on Exchange Server 2003 servers by using Active Directory Users
and Computers. However, the Exchange Server 2010 Exchange Management Console also displays
mailboxes that are located on Exchange Server 2003 servers, and you can use the console to manage
mailbox properties. You cannot view mailboxes on Exchange Server 2010 servers in the Exchange System
Manager.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-25

Planning the Removal of Exchange Server 2003

Key Points
After you deploy the Exchange Server 2010 servers in the Exchange Server 2003 organization, you can
start moving the mailboxes and other resources from the existing servers to the Exchange Server 2010
servers. Then you can start removing the Exchange Server 2003 servers.

Removing Exchange Server 2003 Servers

As you move mailboxes and message delivery to the Exchange Server 2010 servers, you can start
removing the previous Exchange Server versions. Microsoft recommends that you follow the following
process for removing Exchange Server 2003 servers:
1.

Remove back-end servers first. As you move mailboxes from Exchange Server 2003 servers to
Exchange Server 2010 Mailbox servers, you can start decommissioning the previous back-end servers.

2.

Remove the Exchange Server 2003 bridgehead servers. A bridgehead server is a back-end server that
is configured to route messages between routing groups. After you remove the last back-end server
in a routing group, you also can remove the routing groups bridgehead servers.

3.

To send email to the Exchange Server 2010 Mailbox servers, you must configure at least one
Exchange Server 2003 server as the routing group connectors bridgehead server between Exchange
Server 2003 and the Exchange Server 2010 routing group. Do not remove this server until the last
user and required system mailboxes are moved to the Exchange Server 2010 servers. If you plan to
remove this bridgehead server before moving all the mailboxes, you must configure another
Exchange Server 2003 server as the new bridgehead server.

4.

Remove the Exchange Server 2003 front-end servers. These are now redundant, as all clients are
connecting to Exchange Server 2010 Client Access servers.

11-26

Upgrading to Microsoft Exchange Server 2010

Troubleshooting the Exchange Server 2010 Upgrade

Key Points
The installation of Exchange Server 2010 into an existing Exchange Server 2003 organization has a few
unique requirements that do not apply to a new installation of Exchange Server 2010. Some common
issues during installation include:

Incorrect forest or domain functional level. Both the forest and domain functional levels must be
Windows Server 2003. To resolve this problem, raise the forest or domain functional level to the
appropriate functional level.

Incorrect Exchange mode. Your existing Exchange Server 2003 organization must be in native mode;
if it is not, raise the Exchange Server 2003 organizational mode.

Insufficient AD DS permissions. When you upgrade to Exchange Server 2010, you need sufficient
permissions to update the Active Directory schema and modify the Active Directory configuration
partition. To perform the initial schema extension, you must be a member of the Enterprise Admins
and Schema Admins groups.

Insufficient Exchange permissions. To install Exchange Server 2010 into an existing organization, you
must be a member of the Exchange Admins group that has permissions to manage Exchange
Server 2003. You must also run Setup.exe with the /PrepareLegacyExchangePermissions switch.
Wait for replication throughout the Exchange Server organization before you continue.

Incorrect version of Exchange Server 2003. All computers running Exchange Server 2003 must have at
minimum SP2 installed.

In general, if there is a problem installing Exchange Server 2010 into an existing Exchange Server 2003
organization, there is no specific rollback mechanism required. Instead, use the error messages and setup
log to identify the source of the problem, resolve the issue, and then run the installation again.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-27

After installation, you may experience the following issues:

No message routing between Exchange Server 2003 and Exchange Server 2010. During installation
of the first Exchange Server 2010 Hub Transport server, a routing group connector should be
automatically created between a specified Exchange Server 2003 bridgehead server and the Exchange
Server 2010 Hub transport server. In some cases, this routing group connector is not automatically
created and you need to manually create it by using the New-RoutingGroupConnector cmdlet.

Inefficient message routing. Exchange Server 2003 identifies Exchange Server 2010 as one large
routing group. When you are upgrading a large organization with multiple routing groups, you may
need to create additional routing group connectors to ensure that message delivery is efficient. In
general, any site that has both Exchange Server 2010 and Exchange Server 2003 should have a local
routing group connector during coexistence.

Distribution groups not functional. As you remove computers running Exchange Server 2003, you
may find that some distribution groups cannot be expanded and messages to those groups fail. This
occurs if the distribution group is configured with an expansion server and the expansion server has
been removed. To resolve this issue, remove the expansion server from the distribution group.

Message moderation is being applied inconsistently. Moderation of messages sent to distribution

groups can be applied only by Exchange Server 2010 Hub Transport servers. If a computer running
Exchange Server 2003 expands the membership of the distribution list, moderation is not applied. To
ensure that moderation is applied to distribution groups, configure an Exchange Server 2010 Hub
Transport server as an expansion server.

Outlook 2003 clients cannot connect to mailboxes. The RTM release of Exchange Server 2010 requires
RPC encryption when connecting to a mailbox. Outlook 2003 does not support RPC encryption by
default. The solution is to enable RPC encryption in Outlook 2003 or to disable the requirement for
RPC encryption in Exchange Server 2010. New servers installed with media including SP1 or SP2 do
not require RPC encryption by default.

11-28

Upgrading to Microsoft Exchange Server 2010

Lesson 3

Planning the Upgrade from Exchange Server 2007 to

Exchange Server 2010

If your organization is currently running Exchange Server 2007, the upgrade process to Exchange
Server 2010 is similar to upgrading from Exchange Server 2003; however, there are some important
differences.
After completing this lesson, you will be able to:

Determine whether your Exchange Server 2007 organization is ready for Exchange Server 2010.

Describe the process for installing Exchange Server 2010 in an Exchange Server 2007 organization.

Design the Client Access server upgrade.

Design external access for Exchange Server 2007 client services.

Design the message transport upgrade.

Design the administrative roles upgrade.

Plan the removal of Exchange Server 2007 servers.

Troubleshoot the upgrade process.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-29

Prerequisites for Installing Exchange Server 2010 in an

Exchange Server 2007 Organization

Key Points
Before beginning the upgrade, you must prepare AD DS for Exchange Server 2010. Prior to performing
this step, confirm that your current infrastructure meets the following conditions:

The schema master and at least one global catalog server in each site must be running Windows
Server 2003 with SP1 or newer.

The forest functional level must be at least Windows Server 2003.

The domain functional level must be Windows Server 2003.

Your Exchange Server 2007 servers must be running Exchange Server 2007 SP2.

Changes Made by the PrepareSchema Setup Command

If your Exchange Server 2007 organization meets the preceding conditions, you must run the setup
PrepareSchema commandrunning this command prepares the AD DS schema for deployment of
Exchange Server 2010, and it must be run by a user who is a member of both the Enterprise Admins and
Schema Admins groups.

Changes Made by the PrepareAD Command

After running setup with the PrepareSchema command, you should run setup with the PrepareAD
command. This command must be run by a member of the Enterprise Admins group, and makes changes
to enable coexistence between Exchange Server versions.
The PrepareAD command also extends the schema to include the Exchange Server 2010 schema objects
and attributes; consequently, you might choose to run only the PrepareAD command rather than first
running the PrepareSchema command.

11-30

Upgrading to Microsoft Exchange Server 2010

Process for Installing Exchange Server 2010 in an Exchange Server 2007

Organization

Key Points
Exchange Server 2010 Setup checks the server versions of all Exchange servers; the requirement checks
will fail if a server is not upgraded to Exchange Server 2007 SP2. Exchange Server 2007 SP2 includes
several schema updates that are required for interoperability with Exchange Server 2010.
If an organization only has a single Active Directory site, use the following process for deploying Exchange
Server 2010.
1.

Install the Exchange Server 2010 Client Access server. After you complete this installation, you should
use this as the primary connection point for all client connections. This means that you should modify
the Autodiscover settingsboth internally and externallyto point to the Exchange Server 2010
Client Access server.

2.

Install the Exchange Server 2010 Hub Transport server. Both Exchange Server 2007 servers and
Exchange Server 2010 Mailbox servers must use a Hub Transport server that is the same version as the
Mailbox server for routing messages in the same site.

3.

Install the Exchange Server 2010 Mailbox servers. After the rest of the infrastructure is in place, you
can deploy the Exchange Server 2010 Mailbox servers, and start moving mailboxes and public folders
to the new servers.

4.

Install Exchange Server 2010 Unified Messaging servers. If you have deployed Unified Messaging in
Exchange Server 2007, add the Exchange Server 2010 Unified Messaging server to one of your
organizations dial plans.

5.

Install the Exchange Server 2010 Edge Transport servers. Exchange Server 2010 Edge Transport
servers can synchronize only with Exchange Server 2010 Hub Transport servers.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-31

For organizations with multiple sites, there typically are two types of Active Directory sites: Internetaccessible sites, and non-Internet accessible sites. A single Exchange Server organization may have one or
more Internet-accessible sites. When upgrading Active Directory sites, you must begin your upgrade by
upgrading Internet-accessible sites first, followed by non-Internet accessible sites.
You should follow the same process for deploying Exchange Server 2010 servers in both Internetaccessible and non-Internet accessible sites. Before deploying any Exchange Server 2010 Mailbox server in
any site, you must deploy Exchange Server 2010 Client Access and Hub Transport servers.

11-32

Upgrading to Microsoft Exchange Server 2010

Designing the Client Access Server Upgrade

Key Points
During coexistence of Exchange Server 2007 and Exchange Server 2010, the Client Access server that
clients use is determined by where the users mailbox is located. Internal users with Exchange Server 2007
mailboxes and Outlook 2010 are unaffected by the addition of Exchange Server 2010 Client Access
servers. Outlook 2010 accesses their mailbox directly on the Exchange Server 2007 Mailbox servers
hosting their mailbox. Other Client Access services, such as free/busy searches and offline address book
downloads, continue to be accessed from an Exchange Server 2007 Client Access server.
When you move a mailbox from an Exchange Server 2007 Mailbox server to an Exchange Server 2010
Mailbox server, the client profile is configured automatically to use the Exchange Server 2010 Client
Access server for MAPI connectivity; you do not need to modify the client profile manually. Outlook 2007
and Outlook 2010 clients use Autodiscover to determine the new configuration. Outlook 2003 clients are
redirected to the new mailbox location by their previous server.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-33

Designing External Access for Exchange Server 2007 Client Services

Client Access servers provide Internet users with access to their mailboxes by using Outlook Web App,
ActiveSync and Outlook Anywhere. It is important to understand how each of these methods behave
during the upgrade process to help ensure that user access is not interrupted.
The first step in the upgrade process is to add one or more Exchange Server 2010 Client Access servers to
the site being upgraded. To implement coexistence, you must configure all clients to connect to the
Exchange Server 2010 Client Access server. If you have been using an external URLsuch as
https://mail.adatum.comto connect to an Exchange Server 2007 Client Access server, you should modify
the Domain Name Service (DNS) or firewall configuration to forward connections to the URL of the
Exchange Server 2010 Client Access server. Clients accessing their mailbox from the Internet connect to
the Exchange 2010 Client Access server and are then redirected or proxied to the appropriate Exchange
Server 2007 server.

Outlook Web Access

Unlike Exchange Server 2003 coexistence, there is no legacy URL configured for coexistence of Outlook
Web Access with Exchange Server 2007. Instead, the external URL configured on the Exchange
Server 2007 Client Access server is used to redirect client requests to the appropriate Client Access server.
Consider the following:

Requests for an Exchange Server 2007 mailbox in the same site are redirected to the external URL of
the Exchange 2007 Client Access server in the same site. There is no option to proxy the connectivity
in the same site. Therefore, like the legacy URL for Exchange Server 2003, you must have two
externally accessible IP addresses for coexistence of Outlook Web Access and Outlook Web App.

Requests for an Exchange Server 2007 mailbox in a different site are redirected if an Exchange
Server 2007 Client Access server in the different site is configured with an external URL. This ensures
that existing externally accessible Exchange 2007 Client Access servers are still used.

11-34

Upgrading to Microsoft Exchange Server 2010

Requests for an Exchange Server 2007 mailbox in a different site are proxied if the Exchange
Server 2007 Client Access servers in the different site are not configured with an external URL. The
Exchange Server 2007 Client Access servers in the different site access the mailbox on the Exchange
Server 2007 Mailbox server.

Use the following process to transition to using the Exchange Server 2010 Client Access server:
1.

Install and configure the Exchange Server 2010 Client Access server. Configure the external URL to
match the existing external URL on the Exchange Server 2007 Client Access server.

2.

Create a new DNS record for legacy access to the Exchange Server 2007 Client Access server. For
example, legacy.contoso.com.

3.

Update the external URL on the Exchange Server 2007 Client Access server to match the new DNS
record for legacy access.

4.

Update the certificate on the Exchange Server 2007 Client Access server with the new legacy name.

ActiveSync
The connectivity process for ActiveSync clients varies depending on the site the mailbox is located in and
whether the ActiveSync client supports Autodiscover. The connection process is as follows:

If the Exchange Server 2007 mailbox is in the same site and the client supports Autodiscover,
Autodiscover is used to redirect the client to the external URL of the Exchange Server 2007 Client
Access server.

If the Exchange Server 2007 mailbox is in the same site and the client does not support Autodiscover,
the Exchange Server 2010 Client Access server proxies the request to the Exchange Server 2007 Client
Access server.

If the Exchange Server 2007 mailbox is in a different site that does not have an external URL
configured on the Exchange Server 2007 Client Access server, the request is proxied to an Exchange
Server 2007 Client Access server in the different site hosting the Exchange Server 2007 mailbox.

Outlook Anywhere
The Outlook Anywhere connection process is consistent regardless of the site the mailbox is located in.
When the Exchange Server 2010 Client Access server receives the request, the Exchange Server 2007
Mailbox server is contacted directly.
The RPC over HTTP service on the Exchange Server 2007 Client Access server is not used after the
Exchange Server 2010 Client Access server is in place. So, you can disable Outlook Anywhere on the
Exchange Server 2007 Client Access server and uninstall the RPC over HTTP feature.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-35

Designing the Message Transport Upgrade

Key Points
A second issue that coexists between the two Exchange Server versions is message transport. Message
transport coexistence is configured automatically, as long as the correct versions of Hub Transport servers
are available.

Message Routing During Coexistence

As you deploy Exchange Server 2010 Hub Transport and Mailbox servers in an Exchange Server 2007
organization, message transport operates as follows:

Each version of the Mailbox server must use an equivalent version of the Hub Transport server when
routing messages within the same site. Consequently, you must deploy the Exchange Server 2010
Hub Transport server before deploying the Exchange Server 2010 Mailbox servers. Additionally, you
must not remove the last Exchange Server 2007 Hub Transport server until you remove all of the
mailboxes from the Exchange Server 2007 Mailbox servers.

If you have both Exchange Server 2007 and Exchange Server 2010 servers deployed in a site,
messages flow from the Exchange Server 2010 Mailbox server to the Exchange Server 2010 Hub
Transport server, to the Exchange Server 2007 Hub Transport server, and then to the Exchange
Server 2007 Mailbox server. Messages sent from an Exchange Server 2007 mailbox follow the reverse
route.

Message routing between Active Directory sites can use Hub Transport servers on either Exchange
Server version. If you install an Exchange Server 2010 Hub Transport server in one site, it can send
messages to Exchange Server 2007 Hub Transport servers in another site.

11-36

Upgrading to Microsoft Exchange Server 2010

Message routing to and from the Internet can use either Exchange Server 2007 or Exchange
Server 2010 Edge Transport servers. If your current deployment uses Exchange Server 2007 Edge
Transport servers for inbound email, you can continue to have the Edge Transport servers forward all
messages to the Exchange Server 2007 Hub Transport server. For outbound messages, you can add
Exchange Server 2010 Hub Transport servers to the SMTP Send connector that is responsible for
sending messages to the Internet. This enables outbound messages to be sent through either
Exchange Server 2007 or Exchange Server 2010 Hub Transport servers.

Edge Transport Server Coexistence

If you have deployed the Exchange Server 2007 Edge Transport server role, you can retain or replace
these servers with Exchange Server 2010 Edge Transport servers.
You can implement edge synchronization between Exchange Server 2010 Hub Transport servers and
Exchange Server 2007 Edge Transport servers, but you cannot configure edge synchronization between
Exchange Server 2007 Hub Transport servers and Exchange Server 2010 Edge Transport servers. This
means that if you are using edge synchronization, you should not deploy an Exchange Server 2010 Edge
Transport server before deploying at least one Exchange Server 2010 Hub Transport server in the adjacent
Active Directory site.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-37

Designing the Administrative Roles Upgrade

Key Points
When implementing Exchange Server 2010 in an Exchange Server 2007 organization, you also need to
plan for administrative coexistence. In this scenario, you must consider how you will use the Exchange
Server management tools, and how you will delegate permissions.

Management Console Coexistence

The Exchange Management Console is available in both Exchange Server 2007 and Exchange Server 2010.
You can perform the following tasks and actions using either Exchange Management Console:

You can perform actions that create new objectssuch as new mailboxes or a new offline address
bookon a version of the Exchange Management Console that is the same as the target object. For
example, you must create a new mailbox on an Exchange Server 2007 Mailbox server by using the
Management Console in Exchange Server 2007.

You can view Exchange Server 2007 Mailbox databases from the Exchange Server 2010 Management
Console, although you cannot manage these databases across the different versions.

You can perform actions that require management on Exchange Server 2007 objects from the
Exchange Management Console in Exchange Server 2010. You cannot perform these actions from the
Management Console in Exchange Server 2007 on Exchange Server 2010 objects.

You can use any Exchange Management Console version to perform actions that require viewing of
any version of Exchange Server objects, with the following exceptions:

You can view Exchange Server 2007 and Exchange Server 2010 transport rule objects only from
the corresponding version of the Exchange Management Console.

You can view Exchange Server 2007 and Exchange Server 2010 servers only from the
corresponding version of the Exchange Management Console.

11-38

Upgrading to Microsoft Exchange Server 2010

The Queue Viewer tool in Exchange Server 2010 Management Console cannot connect to an
Exchange Server 2007 server to view queues or messages.

You cannot enable or disable Exchange Server 2007 Unified Messaging mailboxes from the Exchange
Server 2010 Management Console.

You cannot use the Exchange Server 2010 Management Console to manage mobile devices for users
who have mailboxes on an Exchange Server 2007 Mailbox server.

Delegating Administration During Coexistence

The model for delegating administrative permissions has changed significantly in Exchange Server 2010.
Exchange Server 2007 setup creates several AD DS groups with designated permissions in AD DS and in
the Exchange organization. To delegate permissions, you simply add users to the appropriate AD DS
groups.
RBAC replaces this model in Exchange Server 2010, where you use role groups to configure permissions.
When you install Exchange Server 2010 servers in an Exchange Server 2007 organization, this adds the
Exchange Server 2010 role groups to AD DS, and the Exchange Server 2007 groups are retained. When
you are assigning permissions on Exchange Server 2007 servers, use the Exchange Server 2007 groups.
When assigning permissions on the Exchange Server 2010 servers, use the Exchange Server 2010 role
groups.
You also can delegate permissions in an Exchange Server 2007 organization. The following table describes
some options for creating an Exchange Server 2010 administrative design that emulates an Exchange
Server 2007 design.
Exchange Server 2007 administrative option

Exchange Server2010 equivalent

Assign users to the Exchange Organization

Administrators group.

Add users or groups to the Organization

Management role group.

Assign users to the Exchange View-Only

Administrators group.

Add users or groups to the View-Only Organization

Management role group.

Assign users to the Exchange Recipient

Administratorsgroup.

Add users or groups to the Recipient Management

role group.

Assign users to the Exchange Public Folder

Administrators group.

Add users or groups to the Public Folder

Management role group.

Assign users as server administrators for a

specific Exchange Server 2007 server.

Create a custom role group that includes only server

management roles, and with a scope limited to a
single server.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-39

Planning the Removal of Exchange Server 2007

Key Points
After deploying the Exchange Server 2010 servers, you can start moving resources to the Exchange
Server 2010 servers, and removing the Exchange Server 2007 servers.

Removing Exchange Server 2007 Servers

As you move mailboxes and message delivery to the Exchange Server 2010 servers, you can start
removing the previous versions of Exchange servers. It is recommended that you remove the Exchange
Server 2007 servers using the following process.
1.

Remove Mailbox servers first. As you move mailboxes from Exchange Server 2007 servers to Exchange
Server 2010 Mailbox servers, you can start decommissioning the Exchange Server 2007 Mailbox
servers.

2.

Remove the Exchange Server 2007 Unified Messaging server role. Once you have migrated all the
user mailboxes, you can replace and remove the Unified Messaging servers.

3.

Remove the Exchange Server 2007 Hub Transport servers. The Exchange Server 2007 Mailbox server
must be able to communicate with an Exchange Server 2007 Hub Transport server. As you remove
Mailbox servers, you also can begin removing the Hub Transport servers. Do not remove the last Hub
Transport server until the last mailboxes are moved from the Exchange Server 2007 servers.

4.

Remove the Exchange Server 2007 Client Access servers.

After you remove the last mailbox and public folder from the Exchange Server 2007 Mailbox server, you
may remove all other Exchange Server 2007 servers in the Active Directory site.

11-40

Upgrading to Microsoft Exchange Server 2010

Troubleshooting the Exchange Server 2010 Upgrade

Key Points
As with the upgrade from Exchange Server 2003, the upgrade from Exchange Server 2007 should be
problem-free if you plan the upgrade carefully; however, unexpected problems can still occur.
Before you start your upgrade, you must ensure that your existing Exchange Server 2007 organization
meets the prerequisites for upgrading to Exchange Server 2010.
If your organization and the servers installed in it meet the specified requirements and you still encounter
problems when installing specific server roles, attempt to re-deploy any server role that fails.
Note For more information, see the topic Troubleshooting the Exchange Server 2010
Upgrade in Lesson 2: Planning the Upgrade from Exchange Server 2003 to Exchange Server
2010.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-41

Lab: Upgrading to Exchange Server 2010

Lab Setup
This lab does not require any virtual machines.

Lab Scenario
You are a messaging engineer for the A. Datum Corporation, an enterprise-level organization with
multiple locations. A. Datum Corporation is an international corporation involved in technology research
and investment, and is planning to upgrade from Exchange Server 2003 to Exchange Server 2010.
The A. Datum Corporation headquarters in London and two remote locations (Vancouver and Tokyo) are
running Exchange Server 2003 and Outlook 2003. A. Datum Corporation will be adding two new
locations, and within the next six months it plans to migrate all existing users to Exchange Server 2010 and
Outlook 2010. Much of the Exchange Server 2010 messaging system design is complete.
The Trey Research location continues to run a POP3/SMTP messaging system, which you need to migrate
to Exchange Server 2010 and integrate with the rest of the Exchange organization. The Trey Research
domain is already deployed as a separate tree in the A. Datum forest. This integration of Trey Research will
be completed after the current infrastructure is upgraded.
Use the references on the following pages for this lab.
Note Your instructor may choose to perform this lab as a group discussion rather than an
individual activity.

11-42

Upgrading to Microsoft Exchange Server 2010

Adatum_ProposedADSiteDesign.vsd

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

Adatum_ProposedPerimeterDesign.vsd

11-43

11-44

Upgrading to Microsoft Exchange Server 2010

A. Datum User Distribution Summary.doc

Location

Internal users

Mobile users

London
(corporate
headquarters)

12,000 currently
10,000 after the new
London office is ready

1,000 Outlook Web Access users

500 Outlook Anywhere and mobile client users
800 Outlook users connecting through a virtual private
network (VPN)

London
(new office)

4,000 (anticipated)

200 Outlook Web Access users

50 Outlook Anywhere and mobile client users

San Diego
(former head
office of Trey
Research)

500

50 POP3 client users

Vancouver

6,000

800 Outlook Web Access users

100 Outlook Anywhere and mobile client users

Tokyo

5,000

1,000 Outlook Web Access users

200 Outlook Anywhere and mobile client users
200 Office Outlook users connecting through a VPN

Chennai
(new office)

800 (anticipated)

200 Outlook Web Access users

50 Office Outlook users connecting through a VPN

A. Datum has deployed a single AD DS forest with a dedicated root domain named Adatum.com, and
three child domains in the same tree. These domains are:

EU.Adatum.com

NA.Adatum.com

AS.Adatum.com

Additionally, the organization has deployed a domain named TreyResearch.net in the San Diego location.
This domain is configured as a separate tree in the Adatum.com forest.

Exchange_Server_2003_Configuration.doc
Location

Description

London
(corporate
headquarters)

Configured as a routing group

12 Exchange Server 2003 servers hosting mailboxes
Two load-balanced front-end servers to provide access for remote
users (mail.adatum.com)
A SPAM filtering appliance is in place

Vancouver

Configured as a routing group

Eight Exchange Server 2003 servers hosting mailboxes

Tokyo

Configured as a routing group

Eight Exchange Server 2003 servers hosting mailboxes

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-45

Exercise 1: Discussion: Reviewing the Exchange Server 2010 Design

Scenario
In this exercise, you will design an upgrade strategy for the A. Datum organization. Based on the review of
the Exchange Server 2010 target state design, you will create an upgrade strategy for migrating from the
current environment to the target state design.
The main tasks for this exercise are as follows:
1.

Review the A. Datum documentation.

2.

Update the A. Datum Upgrade Design document.

Task 1: Review the A. Datum documentation

Review the following A Datum documentation:

Adatum_ProposedADSiteDesign.vsd

Adatum_ProposedPerimeterDesign.vsd

A. Datum User Distribution Summary.doc

Exchange_Server_2003_Configuration.doc

Task 2: Update the A. Datum Upgrade Design document

Answer the questions in the A. Datum Upgrade Design Questions document, and then complete the
A. Datum Upgrade Design document.
A. Datum Upgrade Design
Document Reference Number: JC060610/1
Document Author
Date

Jason Carlson
6th June 2010

Requirement Overview
Describe the upgrade strategy for the A. Datum organization.
Proposals
Question: Based on what you know about the A. Datum organization, what would be a reasonable
timeline for completing this migration?
Question: What are the factors that will affect the timeline?
Question: Where will you perform the schema upgrade?
Question: What is the process for preparing domains for Exchange Server 2010?
Question: How will you ensure that Exchange Server 2010 can coexist with Exchange Server 2003?
Question: Which site should be upgraded first?
Question: Which server role should be implemented first in that site?

11-46

Upgrading to Microsoft Exchange Server 2010

(continued)
A. Datum Upgrade Design
Question: Should coexistence occur in multiple sites or a single location?
Question: How will client access be configured to allow coexistence in the first site?
Question: How will message transport be configured to allow coexistence in the first site?
Question: How will mailboxes be moved in the first site?
Question: How will you move Internet message delivery from Exchange Server 2003 to Exchange
Server 2010 and use Edge Transport servers?
Question: When you begin migrating the second site to Exchange Server 2010, what process will you
use?
Question: How will you remove Exchange Server 2003?

Note

Be prepared to discuss your proposed design with the class.

Results: After this exercise, you should have completed the A. Datum Upgrade document.

To prepare for the next module

Note No virtual machines are required for the next lab.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

11-47

Module Review and Takeaways

Review Questions
1.

Contoso, Ltd., currently utilizes servers running Exchange 2000 Server in their organization. They are
excited about the features available in Exchange Server 2010, and want to upgrade to the new
platform. How would you recommend that they proceed?

2.

A. Datum Corporation has recently acquired Trey Research, an organization that implements Novell
GroupWise for messaging. A. Datum Corporation has Exchange Server 2003 installed, and it
implements the Novell GroupWise connector to ensure directory synchronization and message flow
between the two organizations. As A. Datum Corporation is planning to upgrade to Exchange
Server 2010, how would you advise they proceed with handling the Trey Research GroupWise
messaging system?

11-48

Upgrading to Microsoft Exchange Server 2010

Common Issues Related to Upgrading to Exchange Server 2010

Identify the causes for the following common issues related to upgrading to Exchange Server 2010.
Issue

Troubleshooting tip

When you try to remove an Exchange Server

2003 server, you receive an error message
that you cannot remove the server because it
is a bridgehead server for a routing-group
connector. You have upgraded all external
message routing to Exchange Server 2010.

The Exchange Server 2003 server may be the

designated routing group bridgehead server for the
routing-group connector between the Exchange Server
2003 routing group and the Exchange Server 2010
routing group. If this is the last Exchange Server 2003
server, you can remove it from the routing-group
connector. If you have other Exchange Server 2003
servers deployed, you need to designate one of them
as the routing-group connector bridgehead server.

You are upgrading your Exchange

Server 2007 organization to Exchange Server
2010, and you have configured Client Access
servers for Internet access. Users with
mailboxes on Exchange Server 2010 Mailbox
servers can access their mailbox by using
Outlook Web App from the Internet, but
users with mailboxes on the Exchange Server
2007 Mailbox servers cannot.

Check the DNS configuration to ensure that users from

the Internet can resolve the host name for the
alternate or legacy URL that you have configured. Also,
check the reverse proxy or firewall configuration to
ensure that all client requests to the legacy URL are
directed to the Exchange Server 2007 Client Access
server.

You have deployed Exchange Server 2010

You need to use the same version of the Exchange
servers in your Exchange Server 2007
Management Console as the server that you are
organization. You need to modify the settings managing.
on both Exchange Server 2007 and Exchange
Server 2010 servers, but you cannot see both
servers in the Exchange Management
Console.

Best Practices Related to Upgrading to Exchange Server 2010

Supplement or modify the following best practices for your own work situations:

If your Exchange Server 2003 organization has multiple routing groups, consider creating additional
routing group connectors between each of the routing groups, and an Exchange Server 2010 Hub
Transport server in each office location. By doing this, you can ensure that all messages are sent from
the Exchange Server 2003 servers to the Exchange Server 2010 servers without crossing the wide area
network (WAN) links between the routing groups.

Plan to increase the number of Client Access servers as you upgrade to Exchange Server 2010. For
Exchange Server 2003 and Exchange Server 2007 deployments, Microsoft recommends a 1:4 ratio of
Client Access server or front-end server processor cores to Mailbox server or back-end server cores. In
Exchange Server 2010, Microsoft recommends a 3:4 ratio.

12-1

Module 12
Integrating Microsoft Exchange Server 2010 with Other
Messaging Systems
Contents:
Lesson 1: Designing Exchange Server 2010 Integration with Other
Messaging Systems

12-3

Lesson 2: Designing Exchange Server 2010 Integration with

Federated Partners

12-15

Lesson 3: Designing Exchange Server 2010 Integration with Office 365

12-22

Lesson 4: Designing Single Sign-On for Office 365

12-35

Lab: Integrating Exchange Server 2010 with Other Messaging Systems

12-40

12-2

Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Module Overview

Microsoft Exchange Server 2010 provides options to integrate with other messaging systems, with other
organizations using Exchange Server 2010, and with Microsoft Exchange Online. Integration with other
messaging systems is useful when you are migrating from a legacy messaging system to Exchange
Server 2010. Integration with federated partners that are also using Exchange Server 2010 allows you to
share information with partner organizations. Integration with Exchange Online allows you to expand the
messaging system in your organization without adding additional servers.
After completing this module, you will be able to:

Design integration with other messaging systems.

Design integration with federated partners.

Design integration with Exchange Online.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-3

Lesson 1

Designing Exchange Server 2010 Integration with Other

Messaging Systems

When you upgrade from a legacy messaging system to Exchange Server 2010, it might be necessary for
the legacy messaging system and Exchange Server 2010 to coexist. There are several configurations you
can use to accomplish this goal. When you plan the coexistence of the two messaging systems, you must
consider several factors, such as message routing, address list synchronization, and calendar
interoperability.
After completing this lesson, you will be able to:

Describe possible coexistence scenarios.

Design the integration of Exchange Server 2010 with other Exchange Server organizations.

Design message routing with unique Simple Mail Transfer Protocol (SMTP) addresses during
coexistence.

Design message routing with the same SMTP addresses during coexistence.

Design the synchronization of the global address list (GAL).

Design calendar and free/busy availability.

12-4

Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Coexistence Scenarios for Exchange Server 2010

Key Points
Typically, only very small organizations can perform a complete migration to a new messaging system as a
single event. Most migrations to a new messaging system require coexistence between the legacy
messaging system and Exchange Server 2010.

Coexistence with Other Exchange Server Organizations

It is a common scenario after a merger and the integration of organizations, for multiple Exchange Server
organizations to coexist. Coexistence is typically a temporary state until the two messaging systems can be
merged.
During an upgrade from Exchange Server 2003 or Exchange Server 2007 to Exchange Server 2010, a
single global address list (GAL) is maintained, and the calendar data is shared between the Exchange
Server versions. When two separate Exchange Server organizations coexist, the calendar data and GALs
are not automatically synchronized between the two organizations. This can make collaboration between
the two organizations difficult.
You can configure message delivery between the Exchange Server organizations by using Send
connectors. This allows you to apply specific configuration settings to messages being transferred
between the organizations.
Integration with Microsoft Office 365 requires coexistence with another Exchange Server organization.
However, in the case of Office 365, coexistence is often long term. Office 365 also includes tools for
directory synchronization and calendar interoperability.

Coexistence with Other SMTP Messaging Systems

Coexistence between Exchange Server 2010 and an SMTP messaging system is typically required when
you upgrade from an SMTP messaging system. The two messaging systems coexist until you configure all
users on Exchange Server 2010.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-5

In this scenario, address lists are not automatically synchronized between the two messaging systems.
Calendars are typically not shared, because most simple SMTP messaging systems do not support
calendars.
You can configure message delivery from Exchange Server 2010 to the SMTP messaging system by using
a Send connector.

Coexistence with Non-SMTP Messaging Systems

Coexistence with non-SMTP messaging systems is typically required when you upgrade from a legacy
non-SMTP messaging system to Exchange Server 2010. The two messaging systems coexist until all users
are configured on Exchange Server 2010.
Most non-SMTP messaging systems support advanced features such as calendar functionality. However,
Exchange Server 2010 does not include connectors to synchronize calendar data or address lists with nonSMTP messaging systems, such as Lotus Notes or Novell GroupWise.
Note Both Lotus Notes and Novell GroupWise can be configured for coexistence by
treating them as SMTP messaging systems for exchanging email. There are also third-party
products available for coexistence.
Exchange Server 2010 includes support for foreign connectors, but you must obtain the foreign connector
from a third party. When you create configure a foreign connector, you define a namespace for the
foreign connector, and create a drop directory for the foreign connector. The foreign connector picks up
messages from the drop directory.

12-6

Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Designing Integration with Other Exchange Server Organizations

Key Points
Each Active Directory forest can support only a single Exchange Server organization. But when you
upgrade an Exchange Server organization from a previous version to Exchange Server 2010, both
Exchange Server versions exist in the same organization at the same time. Having a single Exchange
Server organization allows for interoperability between the previous version of Exchange Server, and
Exchange Server 2010.
Typically, you need to plan for coexistence and integration with a second Exchange Server organization
after a merger between two organizations. For example, say a large company with an Exchange Server
messaging system buys another company that also has an Exchange Server messaging system. Until the
two messaging systems are merged together, the two Exchange Server organizations need to coexist.
Integration with another Exchange Organization can also occur between partner organizations.
When you integrate two Exchange Server organizations, you need to determine:

The namespace to use. If a smaller organization merges with the larger organization, typically the
users in the smaller organization need to be given an email address that is in the domain of the larger
organization. If the organizations will share a single namespace, you need to determine how
messages will be routed to the appropriate mailbox. Alternatively, the two organizations can use
completely separate domain names.

Whether to synchronize the GAL. In most cases, you should synchronize the GAL between the two
organizations. This makes it easier for users in each organization to address messages to the
appropriate people. However, if the integration is for a very short time period, you might not want to
make the effort required to configure GAL synchronization.

Whether to synchronize free/busy information. If your organization uses calendars extensively for
booking meetings, you might want to configure synchronizing free/busy information between the
two organizations.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-7

Designing Message Routing with Unique SMTP Namespaces

Key Points
By properly configuring message routing, you can ensure that messages are delivered to the intended
recipient. When each organization is assigned a unique SMTP namespace, the message routing is easier to
understand and implement. However, unique SMTP namespaces may not be desirable from a business
perspective, because it creates the appearance of unique organizations.
Note An Edge Transport server can perform address rewriting to make multiple
messaging systems with unique namespaces appear as a single namespace. To use address
rewriting, the email names for each email account must be unique across organizations.
If you use unique SMTP namespaces, the email address for a user changes when the users mailbox is
moved between the two messaging systems. This can be a problem, because the user will not receive
messages sent to the old address in the new mailbox. Users may not get important messages from
customers or internal staff, because they are unaware of the new email address. You can mitigate this
problem by forwarding messages from the old mailbox to the new Exchange Server 2010 mailbox.
You can create unique SMTP namespaces by using:

Two separate domain names. You can use two separate domain names when two organizations are
merging. For example, in a merger between Contoso, Ltd., and A. Datum Corporation, the two
domains could be contoso.com and adatum.com.

A domain and a subdomain. You can use a domain name and a subdomain name when one
organization is a subsidiary of another. For example, if Contoso, Ltd., is a subsidiary of A. Datum
Corporation, the domain names could be adatum.com and contoso.adatum.com.

The configuration of message routing varies depending on how you implement the physical infrastructure
for communication. If the two organizations have completely separate data centers and no direct link
between the two locations, you can use standard SMTP delivery over the Internet for messages.

12-8

Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

If there are two data centers but there is a direct link between them, you can place messaging traffic on
the direct link instead of the Internet. To do this, create Send connectors in each organization to direct
messages to the appropriate IP address for delivery. Each Send connector is scoped with the domain
name for the other organization. If there are multiple locations with direct links, then you can create
multiple Send connectors to optimize delivery.
If there is a single physical location, you can configure both domains as accepted domains on the
Exchange Server 2010 organization. The second domain is configured as an external relay domain.
Exchange Server 2010 does not host any mailboxes for an external relay domain, but it does accept
messages for a forward relay domain. The messages for an external relay domain are forwarded from
Exchange Server 2010 to the external messaging system by using a Send connector. Centralizing message
delivery through Edge Transport servers simplifies antivirus scanning, and allows you to enforce
messaging policies, such as the application of a disclaimer.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-9

Designing Message Routing with the Same SMTP Namespace

Key Points
You can use a single namespace for two messaging organizations. The second messaging organization
can be an Exchange Server organization, or a different SMTP messaging system.
You typically use a single namespace for two messaging systems temporarily, while two organizations are
merged. You should also configure the recipients of the smaller organization to accept email for both
their old domain and the new domain during the transition period.
To use the same namespace for multiple organizations, all messages are delivered first to the Exchange
Server 2010 organization. The Exchange Server 2010 organization is responsible for determining whether
the recipient is in the Exchange Server 2010 organization, or if the recipient is part of the second
messaging system. If the recipient is part of the second messaging system, the Exchange Server
organization forwards the message to that system for delivery.
To use a single namespace with two messaging organizations, you must perform the following
configuration steps:
1.

Configure connectivity between the two messaging systems. The connectivity can be a direct link
between the two systems, or over the Internet.

2.

Configure the shared namespace as an accepted internal relay domain. This allows Exchange
Server 2010 to relay messages for which there is no matching recipient in the Exchange Server 2010
organization.

3.

Configure a Send connector for the shared namespace. Exchange Server 2010 uses this Send
connector to forward messages to the other messaging system. This Send connector is only used
when there are no matching recipients in the Exchange Server 2010 organization.

4.

Configure mail exchanger (MX) resource records for the Exchange Server 2010 organization. Internet
messaging systems use the MX records to locate the Edge Transport servers of the Exchange
Server 2010 organization.

12-10 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

In addition to configuring the Exchange Server 2010 organization, you must also configure the other
messaging system to accept messages from the Exchange Server 2010 organization. In most cases,
outgoing messages from the other messaging system are also relayed through the Exchange Server 2010
Edge Transport servers to centralize management of external message delivery.
Question: When a namespace is shared between two messaging systems, is it possible for
one of the messaging systems to also have an additional domain name that is unique to that
messaging system?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-11

Designing Global Address List Synchronization

Key Points
GAL synchronization is an important part of maintaining two separate messaging systems. If you do not
configure GAL synchronization, users in each messaging organization have only recipients from their own
messaging organization available in the GAL when they address messages. By synchronizing GALs, you
can ensure that all recipients are available for addressing in both organizations.
When you synchronize the GAL of an external messaging system into Exchange Server 2010, the external
recipients are created as contacts. If only a small number of recipients are required, you can create the
contacts manually in the Exchange Server 2010 organization.
When you migrate mailboxes from the external messaging system to the Exchange Server 2010
organization, you need to synchronize the address lists. Before you migrate each mailbox to the Exchange
Server 2010 organization, you need to remove the contact for that user. When you migrate the mailbox,
the mailbox replaces the contacts in the GAL. On the external messaging system, you must remove the
mailbox and replace it with a contact containing the email address for that user in the Exchange
Server 2010 organization. If you plan to move a large number of mailboxes, you should automate this
process.
To automate GAL synchronization, you can use:

Lightweight Directory Access Protocol (LDAP) replication scripts. To use LDAP replication scripts, the
external messaging system must support the use of LDAP to query mailbox information and create
contacts. Although this is possible for other Exchange Server organizations, it might not be possible
with other messaging systems. You must run LDAP replication scripts manually, or schedule them to
run periodically.

12-12 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Microsoft Forefront Identity Manager 2010. This is a flexible tool for synchronizing information
between directories. Forefront Identity Manager has additional capabilities for synchronizing
information compared to LDAP, and can therefore synchronize data between a wider range of
systems. It can also perform dynamic updates based on events such as creation of new users, and
mailbox moves.
Note Previous versions of Forefront Identity Manager 2010 are called Microsoft Identity
Lifecycle Manager, and Microsoft Identity Integration Server.

Federated sharing is another alternative for sharing contact information between organizations. You can
implement federated sharing to allow specific users in your Exchange Server 2010 organization to share
contacts with specific users in another Exchange Server 2010 organization. This does not synchronize the
GAL between the two Exchange Server organizations, but can be useful for organizations where limited
integration is desired, such as for partners or subsidiaries.
Question: Which GAL synchronization methods should you use to migrate 5,000 users from
an external messaging system to Exchange Server 2010?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-13

Designing Calendar Interoperability

Key Points
By implementing calendar sharing between messaging systems, you can allow users to view the schedule
of users in the other organization when sending meeting requests. The level of importance for this
capability is based on how your organization uses meeting requests, and how long coexistence of the two
messaging systems will be in place. For example, calendar interoperability is important for your
organization if you configure all meeting rooms in your organization as resources, and users in both
messaging systems need to book those rooms. Typically, you configure calendar interoperability only
between Exchange Server organizations.
You have the following options for sharing calendar data:

The Availability service in Exchange Server 2010 or Exchange Server 2007. You can configure a Client
Access server in one Exchange Server organization to use the Exchange Server Availability service on
the Client Access server in the other Exchange Server organization. This gives the first organization
the ability to read calendar information of the second organization.

Federated sharing for Exchange Server 2010. This solution is designed for ongoing interoperability
between Exchange Server organizations. One feature of federated sharing is the ability to share
calendar information in a selective and controlled way. However, both organizations must be using
Exchange Server 2010.

The Inter-Organization Replication (IORepl) tool in Exchange Server 2003. The use of IORepl to
synchronize public folder data is supported for Exchange Server 2010 with Service Pack 1 (SP1) or
newer. However, IORepl must be run on the Windows Server 2003 operating system, and one of the
endpoints for replication must be Exchange Server 2003 with SP2. So, it is not possible to use IORepl
for replication between two Exchange Server 2010 organizations.

12-14 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Sharing calendar information can be complex to implement. In some cases, it may be preferable to use an
alternative. Alternatives to sharing calendar information between Exchange Server organizations are:

Mailboxes in both systems. If only a few users need access to calendars in the second Exchange Server
organization, the simplest method may be to give those few users a second mailbox in the second
Exchange Server organization. The user now has two mailboxes that you need to maintain. However,
you can configure a forwarding address on one of the mailboxes to centralize all messages in a single
mailbox.

Shared calendar in the Microsoft SharePoint services. SharePoint is a web-based solution designed
for collaboration. One feature of SharePoint is calendars that multiple users can access. This can be
useful for shared events calendars, and for booking resources, such as meeting rooms.
Question: Can you think of an advantage for using federated sharing over the Exchange
Server Availability service between organizations?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-15

Lesson 2

Designing Exchange Server 2010 Integration with

Federated Partners

Integration with federated partners allows you to share calendaring information and contacts between
organizations. To configure federated partners, you must understand how to create a federated trust, and
then implement an organization relationship or a sharing policy.
After completing this lesson, you will be able to:

Describe federated sharing.

Describe the considerations for designing federated trust and certificates.

Design organization relationships.

Design sharing policies.

12-16 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

What Is Federated Sharing?

Key Points
If you implement a federation trust for your organization, you can implement federated sharing with
other organizations and external users. The external organization must also have configured a federation
trust.

Federated Sharing
You can use federated sharing to configure your Exchange Server 2010 organization to share information
with other Exchange Server 2010 organizations. This shared information can include availability
information, calendar information, and contacts.
To configure federated sharing, you must create a federation trust for your organization, and configure
organization relationships or sharing policies. This is a much simpler process than other methods for
sharing calendar and contact information between organizations. However, this method does not
synchronize all GAL information; only user contacts are shared.
To participate in federated sharing, user mailboxes must be on an Exchange Server 2010 Mailbox server.
Organization relationships or sharing policies define the information that is shared.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-17

Considerations for Designing Federation Trusts and Certificates

Key Points
To perform federated sharing, you need to configure a federation trust. The Microsoft Federation
Gateway is used as a central point for federation trusts. You can create a single federation trust with the
Microsoft Federation Gateway, and have the other organizations do the same. You cannot create
federation trusts directly with other organizations.
To implement a federation trust with the Microsoft Federation Gateway, you need to obtain a certificate
from a trusted certification authority (CA). The certificate is used to sign and encrypt tokens, but not to
identify your organization. Therefore, the subject name in the certificate is not relevant.
After you create the federation trust, you are provided with an application identifier for your organization.
To identify ownership of your Domain Name System (DNS) domain, you must create a text (TXT) resource
record in your domain that contains the application identifier.
The specific requirements for a certificate are:

A trusted CA should issue the certificate. The accepted list of trusted CAs is provided in the Exchange
Server 2010 online help.

The certificate must contain the subject key identifier (SKI) field. This is typical in certificates from
third-party CAs.

You must create the certificate by using the CryptoAPI, and not by Cryptography Next Generation.
Both of these cryptography providers are available in Windows Server 2008. To ensure that you use
CryptoAPI, create the certificate request by using the New-ExchangeCertificate cmdlet, or by using
the New Certificate Wizard in the Exchange Management Console.

12-18 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

The certificate must use the RSA signature algorithm. Select this option during certificate creation.

The certificate must have an exportable private key. Select this option during certificate creation.
Question: How will you obtain the list of acceptable CAs?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-19

Designing Organization Relationships

Key Points
You can use organization relationships to enable federated sharing with an external Exchange Server
2010 organization. The external Exchange Server 2010 organization must also have a federation trust in
place with the Microsoft Federation Gateway. Each organization relationship is for a single external
organization identified by its domain name and application identity.
When you create an organization relationship, you can select the following options:

Enable this organization relationship. Use this option to toggle the organization relationship off and
on. If your organization no longer wants to share information with the external organization, you can
quickly disable the organization relationship to stop sharing information.

Enable free/busy information access. Use this option to specify that your organization will obtain
free/busy information from the external organization. Your access to free/busy information in the
external organization is determined by the configuration of the organization relationship in the
external organization. In most cases, this is enabled.

Specify free/busy data access level. Use this option to control the free/busy information that your
organization provides to the external organization. You can allow no access, access to times only, or
access to time, subject, and location. To preserve privacy for your organization, prevent access to
subject and location when only basic meeting bookings are required.

Specify a security distribution group that indicates what internal users free/busy data is accessible.
Use this option to limit the user calendars that are accessible to the external organization. This can be
useful if only one part of your organization is collaborating with a partner on a project.
Note: Even if an organization relationship specifies that all user calendars are shared, users
can override this. Users can configure the default permissions for their own calendars to
prevent sharing. However, changing the default permission also affects sharing with internal
users.

12-20 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

To identify the external organization when creating the organization relationship, you typically use the
domain name of the external organization to automatically populate the necessary information into the
organization relationship. When you specify the domain name, all of the necessary configuration
information is obtained from the Microsoft Federation Gateway.
When you use the Exchange Management Shell, you can still obtain the federation information for the
external organization, but you must use the Get-FederationInformation cmdlet. This information can be
piped to the New-OrganizationRelationship cmdlet when creating the organization relationship.
You can obtain the URL for the Availability Web Service of the external organization by using
Autodiscover. If the external organization has not configured Autodiscover for access from the Internet,
you can enter the URL manually.
Sharing of availability performs best when users are using Microsoft Office Outlook 2010 or Microsoft
Outlook Web App on an Exchange Server 2010 Client Access server. Office Outlook 2007 users can view
availability information for external users, but the users must be selected from the GAL, which means that
GAL synchronization must be in place. Users with mailboxes on Exchange Server 2007 with SP2 can use
Microsoft Outlook Web Access to view availability information for external users.
Question: Can you vary the users that share calendar information as part of each
organization relationship?

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-21

Designing Sharing Policies

Key Points
For controlling federated sharing, sharing policies are an alternative to organization relationships. You can
assign a sharing policy to specific mailboxes, and to determine what information a user can share with
external users. Instead of information being automatically available for users in an external organization,
the user in your organization sends a sharing invitation to the external user to share the calendar or
contacts. Although the organization containing the external users mailbox does not need to have a
federation trust, you should configure a federation trust to enable a two-way sharing relationship.
When you create a sharing policy, you can control the calendar information that is shared. You can
choose if you want to allow sharing of only free/busy information, or if you want to include the subject
and location, or the body. You also have the option to allow sharing of contacts. The information that is
allowed to be shared is controlled on a per-domain basis.
For a sharing policy to take effect, you must apply it to mailboxes. You can do this by using the properties
of the sharing policy, or the properties of the recipient. You can apply only a single sharing policy in each
mailbox.
After installation, a sharing policy called the Default Sharing Policy is created. This policy is automatically
applied to all Exchange Server 2010 mailboxes, and allows sharing of free/busy information with all
domains. Because of this policy, users can share their free/busy information with external users
immediately after you create a federation trust.
Only Outlook 2010 and Outlook Web App are capable of creating sharing invitations. Also, an Exchange
Server 2010 Mailbox server must host the user mailbox.
Question: Can you create a sharing policy to enable GAL synchronization between two
users?

12-22 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Lesson 3

Designing Exchange Server 2010 Integration with

Office 365

Office 365 is a suite of cloud-based services that includes Exchange Online. You can integrate Exchange
Online with your on-premises implementation of Exchange Server 2010. When you use Office 365, you
can implement single sign-on and directory synchronization to support your use of Exchange Online.
When you plan your implementation of Office 365, you need ensure uninterrupted service for users. Part
of your planning process needs to include message routing and how mailbox moves will be performed.
After completing this lesson, you will be able to:

Describe Office 365.

Identify the deployment options for Exchange Online.

Describe the options available for identify management with Office 365.

Design directory synchronization with Office 365.

Design message routing with Office 365.

Describe mailbox moves for hybrid deployments.

Design mailbox moves for non-hybrid deployments.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-23

What Is Office 365?

Office 365 is a suite of Microsoft could-based services. The services included in Office 365 are:

Exchange Online. A hosted version of Exchange Server 2010 with services that vary depending on the
service plan.

Microsoft Lync Online. A hosted version of Lync that provides instant messaging and presence,
online meetings, audio and video calling, and screen sharing.

SharePoint Online. A hosted version of SharePoint 2010 that you can use to host SharePoint sites in
the cloud.

Office Professional Plus 2010. A suite of Office desktop applications that includes on-demand peruser subscription licensing that is connected to the cloud.

Office Web Apps. Web-based versions of Microsoft Office applications that you can access by using a
web browser rather than by installing locally.
Note Documentation often uses the term Office 365 when referring to Exchange Online.
Any reference to Office 365 email features refers to Exchange Online.

Exchange Online
You can obtain Exchange Online as a standalone product or as part of Office 365. The features available
to users vary depending on the service plan. The service plans available for Exchange Online are:

Exchange Online Kiosk. This service plan limits mailboxes to 500 MB and allows only Outlook Web
App or a POP3 client to be used for accessing mail messages. Advanced features such as delegate
access or inbox rules are not supported.

12-24 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Exchange Online Plan 1. This service plan limits mailboxes to a total of 25 GB for the mailbox and
associated archive. Additional client protocols such as Internet message access protocol 4 (IMAP4),
Outlook Anywhere, the ActiveSync technology, and Exchange Web Services are allowed. The
features supported by this plan are very similar to an on-premises implementation of Exchange
Server 2010.

Exchange Online Plan 2. This service plan limits mailboxes to a size of 25 GB but allows an unlimited
archive size. All of the features of Exchange Online Plan 1 are supported, and in addition, litigation
hold is available.

Considerations for using Exchange Online

You can use Exchange Online to completely replace an on-premises implementation of Exchange Server
or to integrate with an existing on-premises implementation of Exchange Server. Some benefits of using
Exchange Online include:

Reduction in server hardware and software maintenance.

Predictable cost for Exchange Server 2010 services.

Reduction in network utilization on the Internet connection for roaming users.

Anti-spam and antivirus scanning is provided by Forefront Online Protection for Exchange (FOPE).

In most cases, organizations use Outlook Anywhere to connect to Exchange Online. This provides the
same features as an on-premises implementation of Exchange Server 2010.
Potential concerns for using Exchange Online include:

Public folders are not included.

Increased network utilization on the Internet for internal users.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-25

Deployment Options for Exchange Online

You can use Exchange Online for all mailboxes in your organization, or you can implement a hybrid
deployment with some mailboxes hosted on-premises. Which option you select depends on your business
needs.

Exchange Online only

If all mailboxes are hosted in Exchange Online, users typically access their mailbox by using Outlook
Anywhere. Both roaming and local users connect to Exchange Online over the Internet to send and
receive email and to perform other mailbox actions. All incoming Internet email is delivered directly to
Exchange Online.
By moving all mailboxes to Exchange Online, you gain the following benefits:

No local hardware.

Flexible licensing based on current needs.

Automatic upgrades and updates for Exchange Server 2010.

Many Exchange Server 2010 management functions, such as performance monitoring and tuning, are
managed by Microsoft.

Hybrid Deployment
A hybrid deployment has a combination of mailboxes hosted in an on-premises deployment and in
Exchange Online. This allows for coexistence that includes the following functionality:

Mail routing between Exchange Online, the on-premises deployment, and the Internet for a single
namespace.

Management of all mailboxes can be performed by using the Exchange Management Console or
Exchange Management Shell in the on-premises location.

Mailboxes can be moved between Exchange Online and the on-premises deployment.

12-26 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Calendars, including free/busy information, are shared between Exchange Online and the onpremises deployment.

GAL synchronization is performed between Exchange Online and the on-premises deployment.

Multi-mailbox search can be performed across mailboxes in Exchange Online and in the on-premises
deployment.
Note A hybrid deployment manages messaging between two separate Exchange
organizations. Consequently, some functions do not work across organizational boundaries.
For example, you cannot assign a Full Mailbox, Send As, or Send on Behalf of permissions
across organizations.

A hybrid deployment is often used when larger organizations are migrating to Exchange Online. The
hybrid deployment helps to ensure uninterrupted messaging functionality for users during the migration.
A hybrid deployment can also support mobile users. Mobile users may have faster or more reliable
connectivity to Exchange Online than they do to the on-premises implementation of Exchange Server.
You can also use Exchange Online to store only personal archives. In this scenario, user mailboxes are in
the on-premises implementation of Exchange Server 2010, but archives are stored in Exchange Online.
Messages can be moved to the personal archive manually by the users or automatically by using archive
policies.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-27

Options for Identity Management

One of the important considerations for implementing Office 365 is how users log on. You can use either
non-federated identity or single sign-on.

Non-federated identity
If you use non-federated identity, you manage user accounts in Office 365 and your local Active Directory
Domain Services (AD DS) implementation separately. Users have two sets of credentials for accessing
resources, and passwords are not synchronized between the two accounts. This can result in user
confusion when passwords are changed.
Non-federated identity is easy to implement, but it generally requires more user training and additional
help desk resources.

Single sign-on
Single sign-on is more complex to implement than non-federated identity, but it allows users to access
their Office 365 mailbox by using the same username and password that they use for AD DS in your
location. Using the same username and password for authentication reduces user confusion and help desk
calls.
You enable single sign-on by installing Active Directory Federation Services (AD FS). AD FS is installed on a
server at your site and manages credentials in coordination with Office 365 servers. You must also be
using the Microsoft Online Services Directory Synchronization Tool.
For medium-sized and large organizations, the extra complexity of single sign-on is typically outweighed
by the benefit of lower support costs. In most

12-28 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Designing Directory Synchronization with Office 365

You can use the Microsoft Online Directory Synchronization tool to synchronize information between
Office 365 and your on-premises deployment of AD DS. To implement a hybrid deployment or single
sign-on, you must use this tool.
When all mailboxes are hosted in Office 365, use the Directory Synchronization tool to add user accounts
from AD DS to Office 365. When the accounts are synchronized from AD DS, the user information is the
same in Office 365 as it is in the on-premises deployment of AD DS. New users in AD DS are automatically
added to Office 365, where mailboxes can be created. The default configuration of Directory
Synchronization is one way.
In a hybrid deployment, you should enable two-way synchronization. This way, the GAL is properly
synchronized between Office 365 and the on-premises Exchange Server organization. For example, a
mailbox created in Office 365 is synchronized as a contact in the on-premises Exchange Server
organization.
Two-way synchronization is required for the following features:

Archiving on-premises mailboxes to Office 365.

Moving mailboxes from Office 365 to the on-premises Exchange Server organization.

Synchronizing Safe Sender and Blocked Sender lists from Office 365 to the on-premises Exchange
Server organization.

Synchronizing voice mail notifications from Office 365 to the on-premises Exchange Server
organization.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-29

Designing Message Routing with Office 365

For organizations with all mailboxes hosted in a single Exchange Server organization, message routing can
be as simple as configuring a single MX record for inbound messages and configuring a single Send
connector for outbound messages. If your organization has all mailboxes hosted in Office 365, configure
the MX record to deliver mail to the Office 365 servers.

Inbound message routing

In a hybrid deployment, Office 365 and the on-premises Exchange Server organization both share the
same address space. You can configure inbound messages to be delivered either to Office 365 or to the
on-premises Exchange Server organization. In either case, the receiving organization delivers the message
locally if possible, and it passes the message on to the other organization if no local recipient exists. For
example, a message received by the on-premises Exchange Server organization is delivered locally if the
recipient mailbox is in the on-premises Exchange Server organization. If the recipient is not in the onpremises Exchange Server organization, the message is forwarded through a Send connector to
Office 365.
The main reason to direct incoming messages through Office 365 is for the anti-spam and antivirus
protection provided by FOPE. All Office 365 mailboxes are licensed for FOPE. You need to purchase
additional user licenses for FOPE if you want to route messages for on-premises mailboxes through
Office 365.

Outbound message routing

Outbound message delivery can be centralized or decentralized. If you implement decentralized message
delivery, all messages are delivered directly from the on-premises Exchange Server organization or
Office 365 to the Internet.
Centralized message delivery is supported only from the on-premises Exchange Server organization. The
primary purpose of centralized message delivery is compliance, which is implemented in the on-premises
Exchange Server organization. For example, you can archive a copy of all outbound messages to the
Internet, or you can apply a legal notification to all messages.

12-30 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Messages between the on-premises Exchange Server organization and Office 365 are treated as internal
email. This means features that differentiate internal and external messages such as out of office
messages, operate correctly for all users regardless of the mailbox location.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-31

Mailbox Moves for Hybrid Deployments

If you have a hybrid deployment and you move mailboxes between Office 365 and the on-premises
Exchange Server organization, the moves are remote mailbox moves. To perform remote mailbox moves,
you need to enable the Mailbox Replication Proxy Service (MRSProxy) on your Client Access servers. The
MRSProxy is not enabled by default.
In the RTM version of Exchange Server 2010 and with SP1, you need to modify a web.config file located in
the ews folder to enable the MRSProxy. In Exchange Server 2010 with SP2, you enable the MRSProxy by
using the Set-WebServicesVirtualDirectory cmdlet with the MSRProxyEnabled $true parameter.
The speed of mailbox moves is limited by the speed and latency of your Internet connection. However,
you can move a mailbox much faster than you can copy a file of the same data size. You should perform
tests to determine the throughput of your move process to understand how quickly you can move
mailboxes.
You can move individual mailboxes from the on-premises Exchange Server organization to Office 365, but
you need to understand the impact of those moves:

The mailbox is soft deleted when the move is complete. If there are problems with the moved
mailbox, you can recover the soft deleted mailbox for the time period that is set in the deleted
mailbox retention limit for the mailbox database.

The user account becomes a mail-enabled user account after the mailbox is moved. This way, the
account remains in the GAL of the on-premises Exchange Server organization.

Distribution list memberships are not affected. In each Exchange Server organization, the user
account is already a member of the distribution list. In the on-premises Exchange Server organization,
the group member changes from being a mailbox user to being a mail-enabled user.

12-32 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Delegate and folder permissions are migrated. When you move a resource mailbox, the delegates
for the mailbox are preserved. However, the permissions are not valid unless the delegate and the
resource mailbox are both migrated. If you move a resource mailbox first and the delegate later, the
delegate has proper permissions after the delegate mailbox move is complete.

Send As and full mailbox permissions are not migrated. When you move a mailbox, the Send As
and full mailbox permissions are not retained. Send As and full mailbox permissions are also not
supported for users outside of the Exchange Server organization.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-33

Designing Mailbox Moves for Non-Hybrid Deployments

If you are not using a hybrid deployment, there are still several other methods for moving mailboxes from
an existing messaging system to Office 365. Which method you select depends on the source messaging
system, whether you want to maintain coexistence, and the number of mailboxes to be moved.

Cutover Migration
A cutover migration can be used to migrate mailboxes from Exchange Server 2010, Exchange Server 2007,
or Exchange Server 2003 to Office 365. In a cutover migration, there is no coexistence between the
existing messaging system and Office 365. When the cutover migration is complete, all mailboxes and
other messaging information are located exclusively in Office 365. This method is suitable only for
organizations of 1,000 mailboxes or less, because there is no coexistence.
During the migration, the following data is migrated:

Mailboxes

Distribution lists

Contacts

Staged Migration
A staged migration can be used to migrate mailboxes from Exchange Server 2007 or Exchange
Server 2003 to Office 365. In a staged migration, there is coexistence between the existing messaging
system and Office 365. You must configure coexistence and directory synchronization between the onpremises Exchange Server organization and Office 365 before you perform a staged migration.
During the migration, only user and resource mailboxes are migrated. Directory synchronization is used to
migrate user accounts, distribution lists, and contacts before mailboxes are migrated. While directory
synchronization is active, the on-premises AD DS is authoritative, and any changes to user properties
should be done in AD DS.

12-34 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

IMAP Migration
IMAP migration uses the IMAP protocol to copy mailbox contents from to mailboxes in Office 365. Like in
a cutover migration, there is no coexistence between the source messaging system and Office 365. After
IMAP migration is complete, all messages are delivered to Office 365.
In most cases, IMAP migration is used to non-Exchange Server messaging systems or Exchange 2000
Server. IMAP migration does not migrate calendar data. However, you can select which folders are
migrated, so you can avoid migrating deleted items and junk mail.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-35

Lesson 4

Designing Single Sign-On for Office 365

Single sign-on simplifies access to Office 365 resources. When it is implemented, users can log on by using
AD DS credentials, just as they would on-premises. To implement single sign-on, you need to understand
how to implement AD FS. This includes the AD FS topology and certificates.
After completing this lesson, you will be able to:

Describe the requirements to implement single-sign on.

Design an AD FS topology.

Select appropriate certificates for AD FS.

12-36 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Preparing for Single Sign-On

Single sign-on allows a user to access a mailbox in Office 365 by using the credentials stored in the onpremises AD DS. This makes access to Office 365 mailboxes easy for users.
AD FS 2.0 is required to implement single sign-on for Office 365. You can use an existing deployment of
AD FS, or you can create a new deployment. AD FS 2.0 is a server role in Windows Server 2008 and
Windows Server 2008 R2.
A federated trust is also required to implement single-sign on. The federated trust allows authentication
tokens from AD FS to be securely passed between the on-premises environment and Office 365.
AD DS requirements for single sign-on are as follows:

AD DS must be running on Windows Server 2003 or newer.

You must configure a user principal name (UPN) suffix that matches the domain you are using for
single sign-on. This should match the users email address.

The domain must be a publicly registered domain name.

The Office 365 UPN for the user must match the UPN in the on-premises AD DS. If you modify the
UPN after configuring directory synchronization, you must use the Set-MsolUserPrincipalName
cmdlet in the Microsoft Online Service Module for the Windows PowerShell command-line
interface in order to modify the users UPN on Office 365.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-37

Designing an AD FS Topology

AD FS uses a trust relationship between organizations to allow users in one organization to access
resources in another organization. In the case of Office 365, users in the on-premises AD DS are allowed
to access Office 365 mailboxes. User authentication is performed by on-premises AD FS servers, and the
security tokens generated by AD FS are trusted by Office 365.
AD FS has the following server roles:

Federation server. A federation server issues security tokens that contain claims. Claims in a security
token can include a users name or role. The security token is provided to the trusting organization.
This role is placed on the internal network.

Federation server proxy. A federation server proxy is used to provide access to the federation server
from the Internet. To support any user that is not located on the internal network, you must
implement a federation server proxy. This role is placed in a perimeter network.
Note You can use a third-party reverse proxy, Microsoft Forefront Unified Access Gateway
(UAG), or Forefront Threat Management Gateway (TMG) as an alternative to using
federation server proxies.

To provide high availability, we recommend that you perform load balancing both for federation servers
and for federation server proxies. At least two federation servers and two federation server proxies should
be deployed.
The load balanced DNS names that are used to access the federation servers and the federation server
proxies must be the same. They must also be accessible from the Internet and must match the Federation
Service name that you configure. If these are not correct, the authentication request will fail.

12-38 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Scalability
The number of federation servers and federation server proxies you require depends on the number of
users accessing Office 365. Use the guidelines in the following table.

Number of users

Recommendation

1,000 users or less

No dedicated AD FS servers are required. Install federation servers on

two existing domain controllers. Install federation server proxies on two
existing web or proxy servers in the perimeter network.

1,000 to 15,000 users

Use dedicated AD FS servers. Install two federation servers and two

federation server proxies.

15,000 to 60,000 users

Use dedicated AD FS servers. Install 3 to 5 federation servers and two

federation server proxies.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-39

AD FS Certificate Requirements

Certificates are a critical part of implementing AD FS. You need to configure the certificates correctly on
both the federation servers and the federation server proxies.

Federation server certificates

Each federation server requires two certificates:

SSL certificate. This certificate is configured on the Default Web Site in Internet Information Services
(IIS) to help to secure communication between the federation server, the clients, and the federation
server proxies. The subject in this certificate needs to match the DNS name that is configured as the
Federation Service name, which also matches the DNS name configured for load balancing. This
certificate should be issued by a third-party CA to ensure that it is trusted by all computers.

Token-signing certificate. This certificate is used to digitally sign security tokens for validation by
Office 365. The default configuration uses a self-signed certificate that is trusted within AD FS. We
recommend that you use the default certificate because AD FS manages this certificate automatically
and renews it as required. There is no need for this certificate to be issued by a CA.

Federation server proxy certificates

A federation server proxy requires a single certificate:

SSL certificate. This certificate is configured on the Default Web Site in IIS to help to secure
communication between the federation server proxies, the Internet clients, and the federation servers.
The subject in this certificate needs to match the DNS name that is configured as the Federation
Service name, which also matches the DNS name configured for load balancing. This certificate
should be issued by a third-party CA to ensure that it is trusted by all computers. Use the same
certificate as the SSL certificate on the federation servers, because they use the same subject name.

12-40 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Lab: Integrating Exchange Server 2010 with Other

Messaging Systems

Lab Scenario
You are a messaging engineer for A. Datum Corporation, an enterprise-level organization with multiple
locations. A. Datum Corporation is an international corporation involved in technology research and
investment, and has successfully implemented Exchange Server 2010 for messaging and collaboration.
As part of the growth strategy for A. Datum Corporation, your organization has purchased their
competitor company, Northwind Traders. You must design the integration of your Exchange Server 2010
organization, and the POP3/IMAP messaging system of Northwind Traders.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-41

Exercise: Designing Exchange Server 2010 Integration with Office 365

Scenario
After the purchase of Northwind Traders was finalized, the network group created a direct link between
the A. Datum Corporation data center and the Northwind Traders data center. User accounts, computers
accounts, and servers have been moved into the existing adatum.com domain.
The Northwind Traders data center is low on space. To reduce data center utilization, the existing
POP3/IMAP email system will be migrated to Office 365. You need to ensure that those users can receive
messages at their current email address ([email protected]) in addition to the new adatum.com
domain that your organization uses. The adatum.com address will be configured as the primary address.
All incoming messages for A. Datum Corporation are scanned by an Edge Transport server in London. All
outbound messages are stamped with a legal disclaimer that includes a graphical company logo. It is not
possible to add a graphical logo with Exchange Server 2010 transport rules. So, third-party software is
installed on the Edge Transport server in London to add the legal disclaimer.
There are 800 mailboxes at Northwind Traders.
The main task for this exercise is as follows:
5.

Document the required configuration for migrating Northwind Traders email to Office 365.

Task 1: Document the required configuration for migrating Northwind Traders email to
Office 365

Complete the following proposal document by answering the questions.

A. Datum Corporation and Northwind Traders Integration Plan
Document Reference Number: JC040495/1
Document Author
Date

Jason Carlson
5th June 2010

Requirement Overview
Determine how to migrate Northwind Traders email to Office 365.
Proposals
Question: Does this scenario require a hybrid implementation of Office 365?
Question: Will inbound routing be to the on-premises Exchange Server organization or to
Office 365?
Question: Will outbound routing be centralized or decentralized?
Question: How will you configure MX records?
Question: How will you migrate mailboxes to Office 365?
Question: Will you configure single sign-on?

12-42 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

(continued)
A. Datum Corporation and Northwind Traders Integration Plan
Question: Do you need to configure a UPN to support single sign-on?
Question: What AD FS servers do you require to support single sign-on?
Question: What certificates do you need to support single sign-on?

Note

Be prepared to discuss your proposed plan with the class.

Results: After this exercise, you should have created a plan to migrate Northwind Traders email to
Office 365.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

12-43

Module Review and Takeaways

Review Questions
1.

Does Exchange Server 2010 include specialized connectors for other messaging systems?

2.

How can Forefront Identity Manager help with GAL synchronization between two Exchange Server
organizations?

3.

Which option for sharing calendar information can you use for both Exchange Server 2010 and
Exchange Server 2007?

4.

Can Exchange Online be integrated with an on-premises Exchange Server organization?

Best Practices Related to Federated Sharing

Supplement or modify the following best practices for your own work situations:

Use organization relationships for a large number of users to share calendar information with an
external organization such as a partner or subsidiary.

Specify a security distribution group in an organization relationship to limit the sharing of calendar
data to specific users.

Use sharing policies to allow users to share information directly with external users, and control the
information that can be shared.

Provide users with Outlook 2010 or Outlook Web App to allow them to send sharing invitations.

12-44 Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

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.

A-1

Appendix A
Unified Messaging in Microsoft Exchange Server 2010
Contents:
Lesson 1: Planning the Unified Messaging Infrastructure

A-3

Lesson 2: Planning the Unified Messaging Configuration

A-17

Lesson 3: Planning the Unified Messaging Integration with Lync Server 2010

A-29

A-2

Unified Messaging in Microsoft Exchange Server 2010

Module Overview

Unified Messaging in Exchange Server 2010 enables the integration of email messaging and voice
messaging into a single infrastructure. Once you deploy Unified Messaging in Exchange Server 2010, the
Exchange servers can provide services to voice messaging clients. For example, your users can access the
email messages in their mailbox by using a phone, and access voice messages in their mailbox by using a
messaging client such as Outlook. With Unified Messaging, users can also use their mobile device, Lync
Server 2010 client or Lync Server 2010 integrated phones to access information in their mailboxes.
After completing this appendix, you will be able to:

Plan the Unified Messaging 2010 infrastructure.

Plan the Unified Messaging 2010 configuration.

Plan the Unified Messaging integration with Lync Server 2010.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-3

Lesson 1

Planning the Unified Messaging Infrastructure

When you plan your Exchange Server 2010 Unified Messaging infrastructure deployment, you must
consider several design issues that may affect your ability to reach your organizational goals. These design
issues include:

The goal of the Unified Messaging deployment

Current telephony infrastructure

Types of users (local and remote)

After completing this lesson, you will be able to:

Describe the Unified Messaging architecture and topology.

Describe Unified Messaging infrastructure requirements.

Identify business requirement.

Identify Unified Messaging planning considerations.

Discuss planning considerations for IP gateways.

Plan for server scalability.

Plan for high availability.

A-4

Unified Messaging in Microsoft Exchange Server 2010

Unified Messaging Architecture and Topology

Key Points
Understanding how the signal or messaging flow in Unified Messaging 2010 occurs is important in the
design phase. The architecture of the Unified Messaging environment determines the topology. The signal
flow in Unified Messaging is the process by which communications traffic that is received by a Unified
Messaging server is routed in an Exchange Server 2010 organization. Depending on the type of incoming
message or call that is received by a Unified Messaging server, various transport protocols are used.
Voice calls that come into an Exchange Server 2010 organization can be received from users who are
inside or outside the organization. When a caller places a call to a Unified Messaging-enabled user's
telephone extension, and the user is unavailable to answer the call, the Private Branch Exchange (PBX)
forwards or routes the incoming call to an IP gateway, and then to the Unified Messaging server.

IP PBX
In a Unified Messaging system that uses an IP PBX, the IP PBX forwards the incoming message to the
Unified Messaging server. Either the IP gateway or the IP PBX translates or converts the incoming stream
into a voice over Internet Protocol (VoIP) protocol, such as the Session Initiation Protocol (SIP) for
incoming voice messages. The stream of IP data is then passed on to the Unified Messaging server. After
the Unified Messaging server receives the call, the Unified Messaging server processes the message, and
determines how to route the message to determine the destination of the message.

Voice
In an incoming call scenario that includes incoming voice messages, a Hub Transport server uses the
Simple Mail Transfer Protocol (SMTP) transport to submit the voice mail message to the Mailbox server. In
a routing scenario that includes multiple Hub Transport servers, the incoming voice mail message is first
submitted to the closest Hub Transport server, and is then routed to the appropriate Mailbox server that
contains the Unified Messaging-enabled mailbox.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-5

Protocols
The Unified Messaging solution provides access to telephony systems by using the standard VoIP
protocols including SIP, and Real-Time Transport Protocol (RTP).

A-6

Unified Messaging in Microsoft Exchange Server 2010

Infrastructure Requirements

Key Points
In each Unified Messaging deployment, there are required Exchange Server 2010 server roles that must be
deployed. These Exchange Server 2010 roles are in addition to other required infrastructure components
that must also be installed.

Mailbox Server Role

The Unified Messaging server communicates with the Mailbox server role to access user-mailbox contents.
This happens in two scenarios. The Mailbox server stores the personal greetings that users create to play
for their callers. The Unified Messaging server retrieves these greetings from the Mailbox server and plays
them when applicable.
When Unified Messaging subscribers call the Unified Messaging server to access their mailbox contents
via Outlook Voice Access, the Unified Messaging server directly accesses the Mailbox server to extract the
mailbox contents. All communications between the Unified Messaging server and the Mailbox server use
MAPI.

Hub Transport
The Unified Messaging server communicates with the Hub Transport server role to send messages to the
Mailbox server. When a caller leaves a voice mail for a Unified Messaging subscriber or sends a fax to a
Unified Messaging subscriber, the Unified Messaging server attaches the voice mail or fax to a message
and forwards it to the Hub Transport server using Simple Mail Transfer Protocol (SMTP).

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-7

Client Access
The Unified Messaging server communicates with the Client Access server role when a subscriber uses the
Play on Phone feature or when they reset their personal identification number (PIN) through Outlook
Web App. Using Play on Phone, a Unified Messaging subscriber can use Outlook 2007 or later, or Outlook
Web App to instruct the Unified Messaging server to send a voice mail to a telephone number. When the
user does this, the client communicates with Unified Messaging Web Services, which you install on a
Client Access server. Unified Messaging Web Services then uses SIP to communicate with the Unified
Messaging server, which instructs the VoIP gateway to place the phone call.

Unified Messaging Server

The Unified Messaging server works as the integration point between the voice messaging system and the
email messaging system. The Unified Messaging server accepts incoming calls and provides a variety of
services for voice clients, and then uses the other Exchange Server roles to store voicemail, or to provide
phone access to user mailboxes.
The Client Access server role, Hub Transport server role, Mailbox server role, and Unified Messaging server
role can coexist on the same computer in any combination.

VoIP Phone
There are two types of VoIP phones available: software-based, and hardware-based. A software-based
phonesuch as the Microsoft Lync 2010is a communications program that runs from a computer. A
hardware-based phone is similar to the types of phones found currently on desktops, except that they
have added functionality. Lync Server 2010 supports several types of phones, including IP desk phones
and USM phones.

Active Directory Domain Services

Active Directory Domain Services (AD DS) acts as a container for all the Unified Messaging objects and
their configuration settings. Each Unified Messaging object within Exchange Server 2010 is necessary to
support Unified Messaging in an Active Directory environment. Some Unified Messaging Active Directory
objects are created to logically represent a telephony hardware device, such as an IP with VoIP gateway.
Other Unified Messaging Active Directory objects are created to represent a telephony dial plan for an
organization, or to support a specific feature of Unified Messaging.

PBX
Exchange Server 2010 Unified Messaging relies on an IP gateway that can receive incoming calls from a
legacy PBX. Part of the planning process for PBX support is verifying that your PBX is supported by
Microsoft, and that there are configuration notes for the PBX.
The PBX configuration notes contain the configuration and other settings required to deploy a PBX with
Unified Messaging. The notes are organized based on manufacturer and model.

VoIP Gateway
If organizations have deployed a traditional PBX, they need to deploy a VoIP gateway. VoIP gateways are
located between your telephony network and data network. A VoIP gateway converts the protocols
coming from the telephony network to a protocol understood by the Unified Messaging Server, such as
Session Initiation Protocol over Transmission Control Protocol (SIP/TCP). When you deploy Unified
Messaging, you must configure a Unified Messaging IP gateway to provide the connection to the VoIP
gateway.

A-8

Unified Messaging in Microsoft Exchange Server 2010

Business Requirements

Key Points
There are a number of questions that must be answered in the planning stages of a Unified Messaging
deployment, to ensure that business requirements are met. These requirements must be researched prior
to planning for the deployment of Unified Messaging.

Determining the Overall Number of Clients and Volume of Calls

View call logs and monitor the network for voice sessions, when determining the overall number of a
clients and volume of calls for a customer. It is typical for a customer to underestimate both the volume
and duration of calls. A thorough analysis of customer voice traffic is required to ensure there are enough
servers and other equipment to support the voice traffic and other traffic.

Determining the Number of Supported Users

The total number of expected supported users will influence the number of servers deployed. A small
company can be easily supported by a single Unified Messaging server. However, medium and large
companies will require a reliable determination of the total number of expected users. Another factor
often overlooked is growth. Do not forget to include any expected or potential growth in the future.
What will the users use mainly? Will they just use voice mail available on the PBX, or will they use voice
mail that is voice-enabled for Lync Server 2010? If users are voice-enabled, you must factor in the
bandwidth for phone users. This does not include any bandwidth that conferencing might use. Bandwidth
for conferencing must be determined as well.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-9

General Types of Codecs Used in Unified Messaging

A codec is a software program that transformsor codesdigital data into an audio file format or audio
streaming format. It then converts the audio file, or decode, back to the digital format. The term codec is a
combination of the words "coding" and "decoding" and is used with digital audio data. Codecs can vary in
sound quality, the amount of bandwidth required to use them, and the system requirements needed to
do the encoding.
In Exchange Server 2010 Unified Messaging, there are two general types of codecs used:

The codec that is used between IP/VoIP gateways

The codec that is used to encode voice messages

Deciding which codec to use is dependent on the advantages and disadvantages inherent with each.
Deciding which to use is dependent on bandwidth and compression.

How Codecs Are Used to Encode Voice Messages

The Windows Media Audio (WMA) is the default codec used in Unified Messaging. It was selected for this
role due its sound quality and compression properties. The Group System Mobile 06.10, and G.711 Pulse
Code Modulation (PCM) Linear audio codecs are used to create .wma and .wav audio files for voice
messages in support of other messaging systems. However, the file type that is used depends on the
audio codec that creates the voice message audio file.
In Exchange Server Unified Messaging, the .wma audio codec creates .wma audio files, and the Global
System for Mobile Communications (GSM) 06.10 and G.711 Pulse-code modulation (PCM) Linear audio
codecs produce .wav audio files. However, depending on the codec that is used, an audio file in .wma or
.wav format is sent together with the email message to the intended voice mail recipient. The size of the
Unified Messaging voice message depends on the size of the attachment that holds the voice data.
Additionally, the size of the attachment depends on the following factors:

The duration of the voice mail recording

The audio codec that is used

The audio file storage format

The Effect That Concurrent Connections Have on Planning the Number of Servers
Remote users and the number of concurrent connections will influence the number of servers. A Unified
Messaging server can accept 100 concurrent voice messages by default. Single Unified Messaging servers
can be configured to accept a maximum of 200 concurrent voice messages.
In branch office scenarios or over wide area network (WAN) connections, use the G.723.1 codec instead of
the G.711 or G.711A codec to minimize the network traffic that is passed between your IP gateways and
your Unified Messaging servers.

A-10

Unified Messaging in Microsoft Exchange Server 2010

The following table outlines codecs and how they can be used.
Codec

Description

G.723.1

Provides for high quality and high compression

Must be licensed

G.711 -law

Is a standard codec used for audio codes

Is used in North America and Japan

G.711 A-law

Is a standard codec used for audio codes

Is used in Europe and elsewhere

G.711 VoIP codec

Uses 64 kilobits per second (Kbps) bandwidth

G.723.1

Uses 5.3/6.3 compressed Kbps bandwidth

G.711

Requires very low processing, but does require 128Kbps for two-way
communication

Offers poorer audio quality

G.723.1

Offers high compression, with increased processing time

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-11

Planning Considerations

Key Points
In most deployment scenarios, it is generally advisable to keep the Unified Messaging topology as simple
as possible. Large enterprises with complex network and telephony environments, multiple business units,
or other complexities, require more planning than smaller organizations with relatively straightforward
Unified Messaging needs. This is especially true when integrating Unified Messaging with a legacy PBX
system.
There are many areas that you must consider or evaluate to be able to successfully deploy the
infrastructure required by Exchange Server 2010 Unified Messaging. You must understand the different
aspects of Exchange Server 2010 Unified Messaging, and each component and feature, so that you can
plan your Unified Messaging infrastructure and deployment appropriately.

Typical Issues
Allocating time to plan and work through the following issues will make deployment more successful.

Telephony network and current voice mail system. What is your current telephony network, and can it
be used in a Unified Messaging environment? Is your PBX supported by Microsoft? Are there
configuration notes available?

Current data network design. What is your physical topology? Do you have multiple sites? How are
these sites connected? Are the multiple sites based on a Hub-Spoke method? Are the sites based on a
full-mesh method?

AD DS environment. What is your logical topology? Do have more than one forest? Do you have
multiple Active Directory sites? What are the links between the sites?

Are the PBXs networked? Are they centralized, or located in multiple locations? Placement of IP/VoIP
gateways, telephony equipment, and Unified Messaging servers is very important. In most design
scenarios, you must minimize the number of hops the packets must make between the PBX to the
VoIP gateway and telephony equipment.

A-12

Unified Messaging in Microsoft Exchange Server 2010

Place the physical components in close proximity to each other. The connection point between the
phone system and the Unified Messaging server is the IP gateway. These means that both the PBX
and the Unified Messaging servers should be deployed on the same fast physical network as the IP
gateway.

Exchange Server roles and Unified Messaging servers. Are any roles collocated, and if so, does the
server have the capacity to run multiple roles at once?

WAN termination. This is important if you have multiple sites. You should consider terminating them
close to where your telephony equipment is located.

Codec. The higher the sampling rate, the more bandwidth used and the larger the attachments for
voicemail. The most highly compressed codec used is WMA, where a 5 minute voice mail would be
approximately 250 kilobytes (KB). If other codecs are used, that same 5 minute voice mail would easily
exceed 5 megabytes (MB) in size.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-13

Planning Considerations for VoIP Gateways

Key Points
Properly configuring and deploying IP/VoIP gateways for your organization is a critical step. This must be
done correctly to successfully deploy Exchange Server 2010 Unified Messaging. Microsoft maintains a
website that lists compatible IP gateways, as well as the required configuration notes and files that you
must have to correctly deploy your organization's IP/VoIP gateways to work with Exchange Server 2010
Unified Messaging. It is equally important to match the number of IP/VoIP gateways that you have in your
environment, to the number of Unified Messaging servers that are available.

Unified Messaging and IP/VoIP

Unified Messaging relies on the ability of the IP/VoIP gateway to translate time division multiplexing
(TDM) or telephony circuit-switched based protocolssuch as Integrated Services Digital Network (ISDN)
or Q signaling (QSIG)from a PBX, to protocols based on VoIP or IPsuch as SIP, RTP, or T.38for realtime facsimile transport.
IP/VoIP gateways are available from multiple manufacturers, in sizes and models that range from 4 to 32
ports. You can deploy as many IP/VoIP gateways as necessary to provide for capacity and fault tolerance.
If the number of calls or ports that are required is larger than the number of calls or ports that are
supported by a single IP/VoIP gateway, you can increase the number of ports or the number of calls that
can be accepted by installing and configuring additional IP/VoIP gateways, creating the Unified
Messaging IP gateway object, and configuring the appropriate hunt groups to support your environment.

Multiple IP Gateways
IP gateways that are supported by Unified Messaging can be configured to route calls to Unified
Messaging servers in a round-robin (a local balancing mechanism used by Domain Name System (DNS)
servers to share and distribute network resource loads) manner. To enable an IP gateway, you must
configure each IP gateway with the IP address (or addresses) of your Unified Messaging servers that
answer calls from the IP gateway. These are the Unified Messaging servers that are associated with the
same dial plan as the Unified Messaging IP gateway object, which logically represents the IP/VoIP

A-14

Unified Messaging in Microsoft Exchange Server 2010

gateway. This enables all the Unified Messaging IP gateways to forward incoming calls to the Unified
Messaging servers that are associated with the same dial plan. Then, if an IP gateway fails, the PBX will
send the call to another IP gateway, one that can answer the call. The IP gateway, in turn, forwards the call
to a Unified Messaging server within the same dial plan. If the call is sent to a Unified Messaging server
that is not available, the IP gateway tries a second time to contact the Unified Messaging server. If it is
once again unsuccessful, it then uses the next Unified Messaging server in the list to answer the call.

Multiple Locations
A company with multiple physical locations will most likely have the same number of logical sites. If this is
the case, then each of those sites would have their own PBX and IP gateway. Each site would also have to
configure one or more Unified Messaging Dial Plans, Unified Messaging Mailbox policies, and hunt
groups.
You must also consider site links between the physical sites. Ensure that the links have the necessary
bandwidth to support the required network traffic, and the increased Unified Messaging traffic. This is of
special concern if you deploy Lync Server 2010 to support voice calls and conferencing. Adding these two
new elements requires even more bandwidth.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-15

Planning for Server Scalability

At a high level, there are two options for increasing the capacity of the Unified Messaging server
environment. One option is to deploy more powerful servers as Unified Messaging servers. For example,
you can increase the speed or number of processors on the servers, increase the RAM or increase the
network adapter capacity to enable a single server to handle more concurrent calls.
The second option for increasing capacity is to deploy more Unified Messaging servers. As a single server
reaches its capacity for concurrent calls, you can simply deploy another server and associate it with the
same dial plan as the existing server.
Choosing the best option for an organization will depend on several factors:

Exchange Server deployment. If the organization has a single data center and all Exchange servers are
deployed in that data center, then you will need to deploy all Unified Messaging servers in that data
center as well. This makes it more likely that you will increase the power of the Unified Messaging
server. If the organization has multiple locations with Exchange servers deployed, you are more likely
to deploy multiple Unified Messaging servers across the locations. If the number of users in an office
is low, you may choose to deploy a less powerful Unified Messaging server, or even collocate the
Unified Messaging server with other Exchange Server roles.

Availability requirements. If your Unified Messaging environment must be highly available, you may
choose to deploy multiple less powerful Unified Messaging servers in the same dial plan so that they
can provide redundancy for each other.

IP gateway deployment. There are many different capacity options available when choosing an IP
gateway. It is important to match the capacity of the IP gateways with the capacity of the Unified
Messaging servers that will use the IP gateways.

A-16

Unified Messaging in Microsoft Exchange Server 2010

Planning for High Availability

In most organizations, email messaging and the phone system are considered critical components that
must always be available. Because the Unified Messaging server role provides an integration point
between the two systems, it is important that this server role also be highly available. To implement high
availability, consider the following:

Configure the Unified Messaging servers with redundant hardware components. Like any other
Exchange Server role, you should begin the high availability design by ensuring that the server has
redundancy at the hardware level. This might include adding multiple network adapters to the server
and configuring network teaming or adding multiple power supplies to the server.

Deploy multiple Unified Messaging servers. To protect against a single server failure, you can deploy
multiple Unified Messaging servers and add them to the same dial plan. When you add multiple
servers to a single dial plan, the IP gateway will try to connect to the first Unified Messaging server. If
the Unified Messaging server is unavailable, the IP gateway will try to connect to the Unified
Messaging server again after 5 seconds. If there is no response from the server, the IP gateway will try
to connect to the next configured Unified Messaging server.

Deploy multiple IP gateways. The IP gateway must also be highly available to ensure that the
connections between the PBX and the Unified Messaging server are available.

Ensure the high availability of the other Exchange Server roles. The Unified Messaging server depends
on the other Exchange 2010 server roles to provide full functionality. As part of planning the Unified
Messaging server availability, you also need to make sure that the other server roles are also highly
available.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-17

Lesson 2:

Planning the Unified Messaging Configuration

Planning and deploying Exchange Server 2010 Unified Messaging requires the coordination of telephony,
IT, and Exchange Server administrators. This lesson discusses how to develop a plan to deploy and
configure Exchange Server 2010 Unified Messaging for your organization.
After completing this lesson, you will be able to:

Plan hardware infrastructure requirements.

Plan the Unified Messaging dial plan object.

Plan the hunt group object.

Plan the server objects.

Plan the mailbox policy objects.

Discuss Unified Messaging clients.

Plan the deployment process for Unified Messaging.

A-18

Unified Messaging in Microsoft Exchange Server 2010

Hardware Infrastructure Requirements

Key Points
There are many factors to consider when selecting hardware for Exchange Server 2010. Three of the most
critical factors to consider are: choice of processor, amount of memory, and selection of storage.

Processors
For production environments, you must use a X64-bit processor. These include Intel processors that
support Intel Extended Memory 64 Technology, or AMD processors that support AMD64. Extensive
testing on dual-core processors shows that Exchange Server benefits significantly when using multi-core
processor technology, with four cores being optimal. The performance benefit for Exchange Server from
dual-core technology depends upon the specific processor.

Memory
Having enough memory is critical to ensure the best performance for Unified Messaging. The minimum
memory requirement for Unified Messaging is 4 gigabytes (GB), which is 2 GB per core with a minimum of
4 GB total. Having more than 8 GB is not shown to improve overall performance. You should also review
the physical memory specifications for the physical server, to verify the type and size of memory modules.

Hard Drive Requirements for Storage

To install Exchange Server 2010, you need at least 1.2 GB on the installation hard drive, plus an additional
500 MB for each Unified Messaging language pack you install. Another consideration is the duration of
recorded messages in Unified Messaging. By default, there is a 20 minute maximum recording duration.
You can modify this setting to anywhere between 5 and 100 minutes. Using the WMA codec, a 5 minute
voice mail is approximately 250 KB in size.
You must also consider the number of voice-enabled users, and the size of their mailboxes to help
determine hard drive space. Users who receive large numbers of voice mails may quickly fill their
mailboxes if mailbox quotas are implemented.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-19

Unified Messaging Dial Plan Object

Key Points
A dial plan object is a container object in AD DS that logically represents a set or grouping of PBXs that
share common user extension numbers. In practical terms, users' extensions hosted on PBXs share a
common extension number. Users can dial one anothers telephone extensions without appending a
special number to the extension, or dialing a full telephone number. A UM dial plan is a logical
representation of a telephony dial plan. All users within a dial plan have a unique extension number, and
the combination of dial plan and the user extension uniquely identifies each Unified Messaging user. After
creating the UM dial plan, you need to associate it with a UM server.
The UM dial plan is the basic administration unit in Unified Messaging. It is the telephony extension
numbering plan. Within Unified Messaging, the dial plan plus the extension number provides the unique
identifier for each Unified Messaging user. The dial plan controls the numbering scheme and the
outbound dialing plan. It also represents a logical link that establishes a connection between the users
within a UM dial plan and their telephony network.

Determining an Effective Numbering Plan

Determining an effective numbering plan is based on several factors:

Does the numbering plan denote the physical sites or departments? One option is to have a different
numbering plan for each physical location, similar to a Dynamic Host Configuration Protocol (DHCP)
address scheme.

What is the number of users, and is growth factored into the numbering plan? Basing a dial plan on
the current number of users may make your ability to expand the plan more difficult at a later time.

A-20

Unified Messaging in Microsoft Exchange Server 2010

Numbering plans are determined by several factors: the number of employees in your organization,
the departments, and their physical structure. You may use a numbering plan that denotes not only
the extension, but where the extension is located or the department.

How are international sites numbered? You are likely limited in your ability to have a standardized
numbering plan with overseas offices.

How Unified Messaging Uses Dial Plans

The UM dial plan is an Active Directory container object that is a logical representation of a telephony dial
plan configured on a PBX. The UM dial plan establishes a link from an Exchange Server 2010 recipients
telephone extension number in AD DS, to a Unified Messaging-enabled mailbox. Unified Messaging uses
dial plan information, such as the number of digits on an extension. When you configure an Exchange
Server 2010 UM dial plan, you enter the extension length.

Other Dial-Plan Settings

You also can configure many other dial-plan settings, including:

Greetings for when dial-plan subscribers call into the UM server.

Dial codes for dialing external phone numbers and international numbers. This is designed to limit
the range of calls a user can place. You might allow users to call only local numbers, and control this
by specifying the specific area codes that can be dialed. You can also use this to prohibit calls to a
specific area code, such as area code 900 numbers. You must remember that some metropolitan
areas have a number of area codes associated with them, or may border another state with differing
area codes. For example, Chicago, Illinois has seven area codes to encompass the downtown area, as
well as the suburbs.

Features such as whether subscribers can transfer callers to other users, and who callers can contact.
By default, the ability to transfer calls is enabled. If you need to disable this feature due to corporate
policy, you can disable it.

Time limits for calls, messages, and idle timeouts. You can limit the amount of time that an incoming
call can be connected to the system without being transferred to a valid extension. You can set this
timeout value from 10 to 120 minutes. Setting the time too short could cause a call to be dropped
before finally connecting. The usual setting for this value is 30 minutes.

Default language for voice prompts. If you are in a multi-language environment, you can install the
appropriate Unified Messaging language pack. A user can then access a second language to play
their personal greeting, use the text-to-speech engine, or play Calendar items.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-21

UM Hunt Group Object

Key Points
A hunt group is an extension that is defined as a group or section, such as with a help desk or call center.
It is the means of forwarding calls from a single inbound number to a group or hunt group of extensions.
In most cases, a hunt group represents a set of identical resources shared by an application or a group.
This provides more efficient access to applications such as voice mail or an auto attendant, so callers will
not experience a busy signal; instead, the PBX hunts for an open line to which to connect them.
The UM hunt group object is a logical representation of an existing PBX or IP-PBX hunt group. When the
pilot number of a hunt group receives a call, the PBX or IP-PBX looks for the next available extension
number to which to deliver the call. When an incoming call is unanswered or busy, the PBX or IP-PBX
routes the call to the UM server. UM hunt group objects act as a connection or link between the UM IP
gateway and the UM dial plan. Therefore, you must associate a single UM hunt group with at least one
UM IP gateway and one UM dial plan.
UM hunt group objects locate the PBX hunt group from which the incoming call was received. A pilot
number that is specified for a hunt group in the PBX also must be specified within the UM hunt group.
The pilot number enables the UM server to interpret the call with the correct dial plan so that it can route
the call correctly.

Implementing UM Hunt Groups

When you create a new hunt group object, you enable UM servers in the specified dial plan to
communicate with the IP gateway object. When creating a new UM hunt group object, you need to
specify the dial plan and the pilot identifier or pilot number to be used with the new UM hunt group.
You can implement a hunt group between the PBX and the VoIP gateway when you need a VoIP gateway
for Exchange Server Unified Messaging. This hunt group accesses Exchange Server Unified Messaging. It is
also the target for diverted calls for an auto attendant, for phone calls that are not answered, or for
phones that are busy.

A-22

Unified Messaging in Microsoft Exchange Server 2010

You can have multiple UM servers associated with a single hunt group. A UM server can be configured to
support up to 200 simultaneous calls. If you estimate having more than that many simultaneous calls in
one group, then you would need to have multiple UM servers.

Pilot Number
A pilot number is the way the PBX identifies a hunt group. In other words, a pilot number is the address or
label for the hunt group. It is a dummy extension, one that does not have a person or phone associated
with it. It is the number to which a coverage path routes a call.
A PBX, when used with Exchange Server Unified Messaging, uses a pilot number to target a diverted ring,
no answer, or busy call to Exchange Server Unified Messaging so a message can be taken. This same pilot
numberor a different numbercan be used by subscribers to access the messages in their Exchange
Server mailbox. A pilot number is also used for top-level access to an Exchange Server UM auto attendant.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-23

Unified Messaging Server Object

Key Points
The UM server object performs directory lookups for recipient information in AD DS. Each Unified
Messaging-enabled user must be added to a dial plan, and must be assigned an extension number in AD
DS. This provides the user mailbox with a unique identifier.

How the UM Server Object Is Connected

The UM server is connected to either the UM IP gateway and the PBX, or both, which is dependent on
specific topology and existing telephony architecture. This connection is from the current telephony
structure outside of the Active Directory forest. Inside the Active Directory forest, the Client Access server
is connected to the UM server to provide access from the Internet for clients using Office Outlook,
Outlook Web App, and Exchange Server.

Default Concurrent Connections

A default deployment of the UM server can support up to 100 concurrent voice mail connections. A UM
server can be configured to support up to a maximum of 200 concurrent voice mail connections.
Estimating the number of concurrent connections is critical to ensuring there are enough UM servers.

Unified Messaging Server Directory Lookups

The Unified Messaging server performs directory lookups in AD DS in several different scenarios,
including:

To locate the Mailbox server hosting the user mailbox so the Unified Messaging server can send voice
messages to the mailbox, or to extract the users personal greeting from the mailbox server.

To locate a users prerecorded, spoken name from AD DS.

To locate subscriber extensions and other attributessuch as department names or email

addresseswhen users call the auto attendant.

A-24

Unified Messaging in Microsoft Exchange Server 2010

Unified Messaging Mailbox Policy Object

Key Points
UM mailbox policies are created in the Configuration container in AD DS by using the Exchange
Management Shell or the Exchange Management Console. By default, a single UM mailbox policy is
created every time you create a UM dial plan.

Using UM Mailbox Policies

You can use UM mailbox policies to set Unified Messaging user settings, such as:

Personal Identification Number (PIN) policies

Dialing restrictions

Other general UM mailbox policy properties

For example, you can create a UM mailbox policy for a specific group of Unified Messaging-enabled
userssuch as executivesto increase the level of PIN security by reducing the maximum number of
logon failures before a user is locked out.

Planning UM Mailbox Policies

Planning ideas for UM Mailbox policies include:

Creating additional UM mailbox policies based on the needs of your organization.

Requiring a single UM mailbox policy to enable users for Unified Messaging.

Creating additional UM mailbox policies, and applying a common set of mailbox policy settings for
other groups of users.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-25

Requiring that the mailbox of each Unified Messaging-enabled user is linked to a single UM mailbox
policy. After you create a UM mailbox policy, you link one or more UM-enabled mailboxes to the UM
mailbox policy. This lets you control PIN security settingssuch as the minimum number of digits in a
PIN, or the maximum number of logon attempts for the Unified Messaging-enabled users who are
associated with the UM mailbox policy.

Linking multiple Unified Messaging-enabled users to a single UM mailbox policy. A single user can be
associated with only one UM mailbox policy.

UM mailbox policy settings are applied to the Unified Messaging-enabled users. The settings that are
defined on a UM dial plan and a UM mailbox policy are applied to all users who are associated with
the UM mailbox policy.

A-26

Unified Messaging in Microsoft Exchange Server 2010

Unified Messaging Clients

Key Points
This topic describes Unified Messaging client features that give Unified Messaging-enabled users access to
their email and messages in their Exchange Server 2010 mailbox. The Unified Messaging client capabilities
enable you to provide users with simplified voice mail and email access options, and an improved overall
user experience.

Outlook Voice Access

Outlook Voice Access is an Exchange Server 2010 feature that enables subscribers to retrieve email
messages from their individual mailbox using an analog, digital, or mobile telephone. They can then
interact with their mailbox using touchtone or voice commands. When Unified Messaging-enabled users
access their Exchange Server 2010 mailbox using a telephone, they are presented with a series of voice
prompts. These voice prompts help users navigate the Unified Messaging system, and enable users to
access their Exchange Server 2010 Inbox. Outlook Voice Access lets users retrieve, listen to, reply to,
create, and forward voice or email messages, and listen to or change calendar information.

Unified Messaging and ActiveSync Clients

The Exchange ActiveSync protocol is used to connect mobile clientssuch as those found on Internetcapable mobile phonesto an Exchange Server 2010 server and mailbox. There are many mobile phone
types that users can use to access their Exchange Server 2010 mailbox and view email messages, view and
change calendar information, and listen to their voice messages. When you use Exchange ActiveSync on a
mobile phone, you can listen to the attached .wma file that contains the voice mail message.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-27

Unified Messaging Integration with Office Outlook 2007 and Office Outlook 2010
Clients
Using Office Outlook 2007 or later, users can access their individual Exchange Server 2010 mailboxes and
view email messages in their Inbox, view and change calendar information, and listen to voice messages
using a Windows Media Player. The Windows Media Player is embedded inside the email messages on
their portable device or computer. Using the Outlook 2010 client, users gain additional features, such as
Play on Phone.

Unified Messaging Integration with Outlook Web App Clients

Outlook Web App provides users with a set of Unified Messaging interfaces and tools comparable to a
full-featured email clientsuch as Exchange Server 2010. As in earlier versions (known as Outlook Web
Access), users can access their Exchange Server 2010 mailbox using a Web browser. However, similar to
the Exchange Server 2010 email client, Outlook Web App offers users a Windows Media Player embedded
in the email message, which can be used to listen to voice messages, and enables users to access other
features such as Play on Phone.

Note The advanced Unified Messaging features found in the Outlook Web App Premium
clientsuch as the voice mail configuration optionsare not available in Outlook Web App
Light.

A-28

Unified Messaging in Microsoft Exchange Server 2010

Process for Deploying Unified Messaging

Key Points
There are several steps involved in deploying Unified Messaging. First, you must decide upon a UM dial
plan configuration. To integrate with VoIP gateway, you must then configure a UM IP gateway. A hunt
group is created when you create an IP gateway. For users to have Unified Messaging capability, you must
enable them for Unified Messaging.

UM IP Gateway Object
You must create a UM IP gateway object. A UM IP gateway object represents a physical VoIP gateway
with an IP address, from which a Unified Messaging server can receive calls. The Unified Messaging server
requires this information to connect to the VoIP gateway and the PBX.

Hunt Group Object

An IP gateway object contains hunt groups. You can associate one or more hunt groups with an IP
gateway. A default hunt group is created automatically if you create an IP gateway and associate it with a
UM dial plan. You can customize that hunt group, or create additional ones.

Enabling Users
User mailboxes must be UM-enabled to access Unified Messaging services. You must associate each user
mailbox with a UM mailbox policy, and a unique extension number. A UM mailbox policy specifies policy
properties, such as: the maximum greeting length, the number of unsuccessful login attempts before the
Unified Messaging server resets the password, the minimum digits that a PIN requires, and restrictions on
international calling.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-29

Lesson 3:

Planning the Unified Messaging Integration with Lync

Server 2010

The integration of Lync Server 2010 and Unified Messaging is built around the concept of user presence.
Lync Server 2010 uses user availability, communication endpoints, and user relationships to connect
people using the most appropriate medium at any point in time. Since Lync Server 2010 ties together
voice, email, instant messaging (IM) and other communication paths, it can help you route messages in
the most productive way possible.
Note Lync Server 2010 is the newest version of Microsofts instant messaging,
conferencing and voice server. Lync Server 2010 replaces Office Communications Server
2007 R2, but many of the same Unified Messaging integration options are available in both
Lync Server 2010 and Office Communications Server 2007 R2.
After completing this lesson, you will be able to:

Describe the Lync Server 2010 features.

Describe how Unified Messaging integrates with Lync Server 2010.

Plan for Unified Messaging and Lync Server 2010 integration.

A-30

Unified Messaging in Microsoft Exchange Server 2010

Lync Server 2010 Features

Key Points
Lync Server 2010 changes how users access network communications. A central feature in Lync Server
2010 is the concept of user presence. User presence displays information about the current state for the
user they may be online and available, online but in a meeting or busy, or offline. The users presence
follows them when they log on to a different computer, when they log on to their laptop at home, or
even when using a mobile device with a Lync client installed. Users are not denoted by a telephone
numberlike they would be in a traditional PBX system, although they do have a number associated for
their accountbut rather by their presence.

Lync Server 2010 Features

Some of the features in Lync Server 2010 include:

Instant messaging. The Lync 2010 client provides IM functionality that is hosted by Lync Server 2010.
The solution provides IM features such as group IM, and extends the internal IM infrastructure to
external IM providers.

Presence information. Lync Server 2010 tracks presence information for all Lync Server 2010 enabled
users. It provides this information to the Lync Server 2010 client and other applications, such as Office
Outlook 2007 or later, or within the Outlook Web App interface.

Web and audio/video conferencing. Lync Server 2010 can host on-premise conferences, which can be
scheduled or unscheduled. They can include IM, audio, video, application sharing, slide presentations,
and other forms of data collaboration.

VoIP telephony. Enterprise voice enables Lync Server 2010 users to place calls from their computers
by clicking an Office Outlook or Lync Server 2010 contact. Users receive calls simultaneously on all
their registered user endpoints, which may be a VoIP phone, mobile phone, or Lync 2010 client.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-31

Benefits of Unified Messaging Integration with Lync Server 2010

Voicemail, Email, and IM Benefits

When Lync Server 2010 and Lync 2010 clients are integrated with the Unified Messaging capability in
Exchange Server 2010 SP1:

Users can see if they have new voice mail either from the main Lync 2010 window or by looking at
the icon in the notification area at the bottom of the screen.

Users can click the Play button on the voice message to hear the audio portion of messages, or use
Exchange Server 2010 SP1 to open the message in Outlook 2010 and view the transcript.

Lync Server 2010 can divert calls to Exchange Unified Messaging, dynamically or on a static basis, as
well as allow users to connect to the Unified Messaging service to change their greetings or access
other voice functionality.

Lync Server 2010 presence features encourage instant communication when possible, but also
provide information about whether a user is in a meeting or out of the office, indicating that instant
communication is not possible.

Message Waiting Indicator

Message Waiting Indicator is an Exchange Unified Messaging feature that notifies a user that they have a
new voice mail message. With Lync 2010, you no longer need to switch to Outlook to manage your voice
mail. You do not even need Outlook on your computer, because Lync 2010 will instead use Exchange
Web Services (EWS). Lync 2010 can manage the read/unread state as you listen to the voice mail. Voice
mail can be played back from within Lync 2010. You can also reply directly to the voice mail from within
Lync 2010.

A-32

Unified Messaging in Microsoft Exchange Server 2010

Unified Contacts
In environments that integrate Lync Server 2010 with Exchange Server 2010 SP1 Unified Messaging,
Exchange Server maintains a single unified contact store for contacts across Lync 2010, the Outlook 2010
messaging and collaboration client, and other endpoints, eliminating the need to maintain multiple
contact lists, and provides a consistent experience across programs.
All contact identities between Lync Server 2010, Exchange Server 2010, and other endpoints are shared
and remain one identity, with Exchange Server acting as the single contact store. Users may also rename
contacts or add other details to their contacts cards for additional context or personal reference.

Unified Conferencing
Lync 2010 integrates with Outlook to make scheduling, joining, and facilitating meetings easier. Lync 2010
is the only client needed for all types of meetings, both scheduled and spontaneous.
Outlook 2010 calendar integration also reflects Lync 2010 presence settings; for example:

In a Meeting. The contacts Outlook calendar shows that the contact has a scheduled meeting.

Out of Office. The contacts Outlook calendar or Out of Office Assistant indicates that he or she is out
of the office.

Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010 SP2 A-33

Integrating Exchange Server 2010 Unified Messaging with

Lync Server 2010

If you want to integrate Exchange Unified Messaging with Lync Server 2010, you must perform the tasks
described in this section. This topic assumes that you have deployed Lync Server 2010 with a collocated
Mediation server and that you have enabled users for Lync Server 2010, but that you have not necessarily
performed all deployment and configuration steps to enable Enterprise Voice.

Step 1: Create and Configure a New Exchange UM SIP Dial Plan

On the Exchange UM server, create a SIP dial plan based on your organizations specific deployment
requirements, and then associate the UM servers and users with the appropriate SIP dial plan.
To perform this task, you must have Exchange Organization Administrator permissions.

Step 2: Configure Security Settings for the Exchange UM SIP Dial Plan
To encrypt Enterprise Voice traffic, configure the security settings on the Exchange UM SIP dial plan as SIP
Secured or Secured. This is an especially important step if you have deployed or plan to deploy Lync 2010
Phone Edition devices in your environment. For Lync 2010 Phone Edition devices to function in an
environment with Exchange Unified Messaging integration, Lync Server 2010 encryption settings must
align with the Exchange Unified Messaging dial plan security settings.

Step 3: Add UM Servers to the Exchange UM SIP Dial Plan

To enable a newly installed UM server to answer and process incoming calls, you must add the UM server
to a UM dial plan. In this case, add the server to the Exchange UM SIP dial plan.

Step 4: Configure Mailboxes with SIP Addresses

Assign SIP addresses to the mailboxes of Enterprise Voice users who will be using Exchange Unified
Messaging features.

A-34

Unified Messaging in Microsoft Exchange Server 2010

Step 5: Run the exchucutil.ps1 Script

On the Exchange UM server, open the Exchange Management Shell and run the exchucutil.ps1 script,
which does the following:

Grants Lync Server 2010 permission to read Exchange UM AD DS objects; specifically, the SIP dial
plans created in the previous task.

Creates a UM IP gateway object in AD DS for each Lync Server 2010 Enterprise Edition pool or
Standard Edition server that hosts users who are enabled for Enterprise Voice.

Creates an Exchange UM hunt group for each gateway. The hunt group pilot identifier will be the
name of the dial plan that is associated with the corresponding gateway. These need to be mapped
one-to-one if there is more than one dial plan.

Step 6: Configure Lync Server 2010 Dial Plans

If you are integrating with Exchange Server 2007 (SP1) or higher, or Exchange Server 2010, create a new
Enterprise Voice dial plan with a name that matches the Exchange UM dial plan fully qualified domain
name (FQDN).
If you are integrating with Exchange Server 2010 SP1, ensure that suitable global/site-level or pool-level
Enterprise Voice dial plans have been configured.
Note If you are integrating with Exchange Server 2010 SP1, the Lync Server 2010 dial plan
and Exchange UM SIP dial plan names do not need to match.

Step 7: Run the Exchange Unified Messaging Integration Utility

On the Lync Server 2010 server, run ocsumutil.exe, which:

Creates Subscriber Access and Auto Attendant contact objects.

Validates that there is an Enterprise Voice dial plan with a name that matches the Exchange UM dial
plan FQDN.

If you are running Exchange Server 2010 (SP1), the dial plan names do not need to match, and you can
ignore the tools warning about this.
This utility works by scanning AD DS for Exchange Unified Messaging settings and allowing the
Lync Server 2010 administrator to view, create, and edit contact objects.

Step 8: Enable Enterprise Voice Users for Exchange Unified Messaging

On the Exchange UM server, ensure that a UM mailbox policy has been created and that each user has a
unique extension number assignment, and then enable the user for Unified Messaging.

L1-1

Module 1: Introduction to Designing a Microsoft Exchange

Server 2010 Deployment

Lab: Introduction to Designing an Exchange

Server 2010 Deployment
Exercise 1: Evaluating an Existing Messaging Infrastructure
Task 1: Review A. Datum documentation

Review the following information:

Adatum_Info.vsd

Requirements interview notes document

Task 2: Complete the appropriate sections in the Current Network Infrastructure

Analysis document

Complete the Current Network Infrastructure Analysis document.

A. Datum Current Network Infrastructure Analysis
Document Reference Number: JC310110/1
Document Author
Date

Jason Carlson
31st January 2010

Active Directory Infrastructure Sites

Active Directory site name

Directory servers in each site

LondonSite

RD-LON-DC1
RD-LON-DC1
EU-LON-DC1
EU-LON-DC2

LondonSite2

EU-LON-DC3

VancouverSite

RD-TOR-DC1
NA-TOR-DC1
NA-TOR-DC2

SanDiegoSite

AD-SAN-DC1
AD-SAN-DC2

TokyoSite

RD-TOK-DC1
AS-TOK-DC1
AS-TOK-DC2

Chennai

AS-CHE-DC1

L1-2 Module 1: Introduction to Designing a Microsoft Exchange Server 2010 Deployment

(continued)
A. Datum Current Network Infrastructure Analysis
Additional notes

Active Directory Infrastructure Forest and domain topology

Forest

Domains in each forest

Adatum.com Adatum.com
EU.Adatum.com
NA.Adatum.com
AS.Adatum.com
TreyResearch.net
Additional notes

Task 3: Complete the appropriate sections in the Current Messaging Infrastructure

Analysis document

Complete the relevant sections of the following document.

A Datum Current Messaging Infrastructure Analysis
Document Reference Number: JC310110/2
Document Author
Date

Jason Carlson
31st January 2010

Exchange Server Configuration

Server name

Exchange version and

SP level

Server role

Location

LON-MSG-FE1

Exchange Server 2003

Front-end server

London

LON-MSG-BH1

Exchange Server 2003

Front-end server

London

LON-MSG-BE1

Exchange Server 2003

Back-end server

London

LON-MSG-BE2

Exchange Server 2003

Back-end server

London

LON-MSG-BE3

Exchange Server 2003

Back-end server

London

LON-MSG-BE4

Exchange Server 2003

Back-end server

London

LON-MSG-BE5

Exchange Server 2003

Back-end server

London

LON-MSG-BE6

Exchange Server 2003

Back-end server

London

Lab: Introduction to Designing an Exchange Server 2010 Deployment

(continued)
A Datum Current Messaging Infrastructure Analysis
Exchange Server Configuration
Exchange version and
SP level

Server name

Server role

Location

LON-MSG-PF1

Exchange Server 2003

Public Folder server

London

VAN-MSG-FE1

Exchange Server 2003

Front-end server

Vancouver

VAN-MSG-BH1

Exchange Server 2003

Front-end server

Vancouver

VAN-MSG-BE1

Exchange Server 2003

Back-end server

Vancouver

VAN-MSG-BE2

Exchange Server 2003

Back-end server

Vancouver

VAN-MSG-BE3

Exchange Server 2003

Back-end server

Vancouver

VAN-MSG-PF1

Exchange Server 2003

Public Folder server

Vancouver

TOK-MSG-FE1

Exchange Server 2003

Front-end server

Vancouver

TOK-MSG-BH1

Exchange Server 2003

Front-end server

Vancouver

TOK-MSG-BE1

Exchange Server 2003

Back-end server

Vancouver

TOK-MSG-BE2

Exchange Server 2003

Back-end server

Vancouver

TOK-MSG-BE3

Exchange Server 2003

Back-end server

Vancouver

TOK-MSG-PF1

Exchange Server 2003

Public Folder server

Vancouver

Additional notes

Exchange Organization information

Configuration

Settings

Administrative
groups

LondonAG, VancouverAG, TokyoAG, RoutingGroupAG

Administrator groups

LondonExAdmins, VancouverExAdmins, TokyoExAdmins,

EnterpriseExAdmins

Routing groups

LondonRG, VancouverRG, TokyoRG

SMTP namespaces

Adatum.com, TreyResearch.net

Additional notes

L1-3

L1-4 Module 1: Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Results: After this exercise, you should have completed the appropriate sections in the Current Messaging
Infrastructure Analysis document.

Exercise 2: Creating a Requirements Document

Task 1: Discuss the questions
Discuss as a group. You will incorporate your answers in to the requirements documentation.
1.

2.

What are A. Datum Corporations requirements and pain points? Answers below:

Madeleine Kelly, the CEO, anticipates rapid growth and multiple acquisitions.

Karen Toh, VP Europe, says her Sales staff needs access to e-mail from anywhere.

Marcel Truempy, CIO, cited a period of unavailability that resulted in business lost; highavailability is important.

Scott MacDonald, VP North America, is concerned about legal and corporate regulatory
compliance issues.

Gareth Chan, VP Asia, needs a means of confidential communication with Contoso, Ltd.

Shane DeSeranno, Network Operations Manager, requires that all network traffic entering the
corporate network is encrypted.

Jason Carlson, Network Specialist, states that the wide area network (WAN) is pretty reliable, but
that it lacks bandwidth between some company locations.

Tzipi Butnaru, Directory Services Manager, explains that all domain controllers are running
Windows Server 2008 Service Pack 1 (SP1), and does not anticipate wanting to make additional
Active Directory Domain Services (AD DS) infrastructure changes.

Conor Cunningham, Messaging Services Manager, wants to make Outlook Web App available
to users currently using Post Office Protocol (POP) from home. Additionally, he states that many
users are requesting access to e-mail services from their mobile phones.

How can Exchange Server 2010 help address the requirements? Answers below:

Exchange Server 2010 is very scalable, and can easily support the anticipated mergers and
acquisitions.

Exchange Server 2010 supports e-mail from many devices, including web browsers and mobile
phones.

Exchange Server 2010 provides a number of high-availability features, including Database

Availability Groups, Mailbox Database Copies, and Active Manager.

Exchange Server 2010 implements features that enable organizations to remain compliant with
legal and corporate messaging policies. Features include: messaging records management, Multimailbox search, legal hold, information rights management protection, personal archive, and
transport rules.

Exchange Server 2010 can support secure communication channels between partner
organizations.

Exchange Server 2010 supports a number of encryption methods so that only encrypted traffic
can enter the corporate network through the internal firewall.

Lab: Introduction to Designing an Exchange Server 2010 Deployment

L1-5

Exchange Server 2010 can be configured to use the existing site configuration, or to use an
Exchange-specific site configuration; this enables a network administrator to get the most out of
their WAN links.

There is no reason why the AD DS configuration needs to be modified in order to support

Exchange Server; however, Exchange Server does support an Exchange-specific site configuration.

Exchange Server 2010 supports the POP protocol. It also supports e-mail access from web
browsers and mobile phones. The users requirement for secure anywhere-access to their e-mail
is supported.

Task 2: Complete the appropriate sections in the Project Requirements Analysis

document
You will complete these sections as a group.

Complete the relevant section of the following document.

A Datum Project Requirements Analysis
Document Reference Number: JC310110/3
Document Author
Date

Jason Carlson
31st January 2010

Summary of business requirements

This section provides a summary of the information collected during the business requirements
analysis task. It is important to clearly define the needs that must be addressed so that the
organization can perform its business tasks more effectively and efficiently:
The messaging solution must be very flexible and easily expanded.
The messaging solution must provide users with e-mail access anywhere in the world at any
time.
The messaging solution must be able to enforce compliance requirements.
Need to provide access to the mailbox servers for more messaging clients, including clients
with more functionality than POP3 and mobile clients.
Summary of functional requirements
This section lists the functional requirements identified during the requirements analysis task. The
functional requirements define how the proposed technology will address the projects business
requirements. This section may be quite extensive, as it relates to many areas such as performance,
security, manageability, usability, availability, and scalability:
The messaging system must have very high availability.
The messaging system must provide a high level of security for exchanging e-mail with
partner organizations.
Summary of additional requirements
This section lists the additional requirements identified during the requirements analysis task.
Additional requirements may include data related to additional stakeholders, required technology,
and user requirements:
Mailbox size limits need to be increased.

L1-6 Module 1: Introduction to Designing a Microsoft Exchange Server 2010 Deployment

(continued)
A Datum Project Requirements Analysis
Project priorities and constraints
This section outlines the identified project priorities and constraints. During the requirements
analysis task, specific priorities should have been identified related to the schedule, resources, or
features that must, or must not, be included in the project:
The budget may be a constraint on the project.
Unencrypted traffic can be allowed into the perimeter network, but not to the internal network.
There may be resistance to making any changes to the Active Directory configuration.

Task 3: Discuss the components that you will need to include in the Exchange Server
design to meet the company requirements
You will complete these sections as a group.

Discuss the following questions:

1.

2.

What components will you need to include in the Exchange Server 2010 deployment to meet the
business requirements?

Answer: Configure the Client Access server role to provide users with e-mail access
anywhere in the world at any time.

Answer: Configure the Hub Transport server role to enforce compliance requirements.

Answer: Configure the Client Access server role to provide access to the mailbox servers for
more messaging clients, including clients with more functionality than POP3 and mobile
clients.

What components will you need to include in the Exchange Server 2010 deployment to meet the
technical and additional requirements?

Answer: Configure Database Availability Groups, Mailbox Database Copies, and Active
Manager to provide for high availability.

Answer: Configure the messaging transport to provide a high level of security for
exchanging e-mail with partner organizations.

Answer: Configure Mailbox policies to increase the mailbox size limits.

Results: After this exercise, you should have completed the A. Datum Project Requirements documents.

Lab: Introduction to Designing an Exchange Server 2010 Deployment

L1-7

Exercise 3: Discussion: Real-World Best Practices for Setting Budget

Expectations
Task: Answer the following questions
1.

What information is required to set the preliminary budget?

Answer: Answers include:

2.

Project vision and scope

Business requirements (What business problems is this project expected to solve?)

Functional requirements

Project constraints

How do you resolve scenarios where addressing all of the requirements will cost significantly more
than the proposed budget?
Answer: This can be very complicated. In the projects 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.

Results: After this exercise, you should have answered the preceding questions.

L1-8 Module 1: Introduction to Designing a Microsoft Exchange Server 2010 Deployment

Exercise 4: Discussion: Refining the Scope of SLA Requirements

Task 1: Review the High Availability Requirements document that the CIO and COO
have created

Review the High Availability Information Requirements document.

Task 2: Create a list of additional information needed to create the SLA

1.

Working with group members, brainstorm a list of other information that is required to create the
SLA.

2.

Complete the relevant section of the following document.

A Datum Refining the Scope of SLA Requirements
Document Reference Number: JC310110/4
Document Author
Date

Jason Carlson
31st January 2010

Questions

Are these objectives specific and measurable?

Are these objectives reasonable and attainable?
Do these objectives add value to the organization?
What types of users are accessing the system and when?
Do all users have the same availability requirements?
How does an internal or Internet e-mail outage affect various user groups?
What availability percentage is our goal?
Which users have priority when restoring mailboxes?
Which business processes does an internal e-mail outage affect?
What is the cost of an internal e-mail outage?
Which business processes does an Internet e-mail outage affect?
What is the cost of an Internet e-mail outage?
What budget is available for high-availability infrastructure improvements?
What times are available for maintenance?
How will we measure internal message delivery times?
Within exactly how many minutes should message delivery occur?
Exactly what outage types are acceptable when an Exchange Server fails? Seconds? Minutes?
Hours?
When an Exchange Server fails, is it acceptable to quickly recover users ability to send and
receive e-mail, or do we also need to recover mailbox contents quickly?
Do all users have a requirement to lose no messages during a server failure?
How quickly do we need to recover if an entire physical location is lost?
What is the reliability of our existing network infrastructure?
What is the reliability of our existing Internet connection?

Lab: Introduction to Designing an Exchange Server 2010 Deployment

L1-9

Task 3: Discuss your solution with the class

Participate in the discussion led by your instructor.

Results: After this exercise, you should have completed the High Availability Information document.

To prepare for the next module

When you finish the lab, start the virtual machines that will be required for the next lab. To do this,
complete the following steps:
1.

On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2.

In Hyper-V Manager, click 10233B-NYC-DC1, and in the Actions pane, click Start.

3.

In the Actions pane, click Connect. Wait until the virtual machine starts.

4.

Log on using the following credentials:

5.

User name: Administrator

Password: Pa$$w0rd

Domain: Contoso

Repeat steps 2 to 4 for virtual machines 10233B-NYC-SVR1.

L1-10

Module 1: Introduction to Designing a Microsoft Exchange Server 2010 Deployment

L2-11

Module 2: Designing Microsoft Exchange Server 2010

Integration with the Current Infrastructure

Lab: Designing Exchange Server Integration

with the Current Infrastructure
Exercise 1: Evaluating the Current Network Infrastructure at Contoso
Task 1: Review the supplied documentation

Review the diagram and read the supporting documentation.

Task 2: Answer questions relating to the documentation

Note Your instructor may choose to perform this lab as a group discussion rather than an
individual activity.
Question: Based on the supplied information, is there anything you might need to
reconfigure before deploying Exchange Server?
Answer: Answers will vary. However, it depends on how you propose to implement the
Microsoft Exchange Server for users in Branch Office 2. Exchange Server 2010 does not
support deployment in sites that contain read only domain controllers (RODCs). Therefore,
you must either remove the RODC and replace it with a domain controller, or else store user
mailboxes for that branch in the head office site in NYC. This latter solution may have
implications for the available bandwidth over the 10 megabits per second Mbps) link
between the head office and Branch Office 2. To mitigate, you could consider deploying
Microsoft Outlook Web App to Branch Office 2.
Question: What else do you need to know before you can begin deploying Exchange Server
2010?
Answer: Answers will vary. You will need to know:

Whether there is an existing version of Exchange Server or other messaging system installed.

What email clients users are currently using.

What the firewall configuration is (in terms of allowed ports) and both the Windows Firewall
settings and any firewalls that separate the corporate network from the Internet.

The specifics of the delegated administration Ed Meadows envisages at the branches.

Whether the current Domain Name System (DNS) configuration is appropriate to support
Exchange Server 2010, and both the internal DNS and external DNS.

Whether there is a certification authority (CA) in place to provide the necessary certificates for
Exchange Server. In the early test phases, using the self-signed certificates is acceptable; however,
thereafter, commercial certificates should be sought in the absence of a suitable internal Public
Key Infrastructure (PKI).

L2-12

Module 2: Designing Microsoft Exchange Server Integration with the Current Infrastructure

Task 3: Complete a report that provides information about necessary changes

required to the network and AD DS infrastructure to enable support for Exchange Server
2010

Complete the following proposal document by answering the questions.

Contoso Exchange Server network infrastructure
Document Reference Number: JC110210/1
Document Author
Date

Jason Carlson
11th February 2010

Requirement Overview
To determine what changes, if any, are required to the existing network and AD DS infrastructure to
support Exchange Server 2010.
Contoso Exchange Server network infrastructure
Proposals
Question: The internal and external DNS zone names are the same for Contosoi.e. Contoso.com.
What issue does this raise for clients connecting to their mailboxes using Outlook Web App from
their home computers?
Answer: You may need to configure split DNS to ensure host names are resolved the appropriate
internal or external IP address.
Question: What DNS records must you configure in the external Contoso.com DNS zone?
Answer: Host (A or AAAA) resource records, mail exchanger (MX) resource records, and Sender
Policy Framework (SPF) resource records are required.
Question: How do you propose to support the messaging needs of users in Branch Office 2?
Answer: As Exchange Server 2010 does not support deployment in sites that contain an RODC; the
RODC must either be removed and replaced with a full domain controller, or else the users must
use an Exchange Mailbox server in the head office site.
Question: What messaging client will you deploy to Branch Office 2?
Answer: That depends on how the RODC issue is resolved. If the RODC is removed, the users could
use Outlook Web App to ensure that the bandwidth of the connection to the head office is not
excessively consumed. If a full DC is deployed to the Branch Office 2 site, then any suitable client
including Microsoft Office Outlook 2007 or 2010could be deployed.
Question: What server role must you consider deploying in the head office to facilitate inbound
and outbound messaging to and from the Internet?
Answer: An Exchange Edge Transport server should be deployed in the perimeter network.
Question: How many Client Access servers do you envisage needing?
Answer: At least one per site where mailboxes reside; if Branch Office 2 does not host a Mailbox
server, then there is no need to provide a Client Access server there. For high availability, consider
deploying at least two Client Access servers per site.

Lab: Designing Exchange Server Integration with the Current Infrastructure

L2-13

(continued)
Contoso Exchange Server network infrastructure
Question: How many Hub Transport servers are required?
Answer: At least one per site where mailboxes reside. If Branch Office 2 does not host a Mailbox
server, then there is no need to provide a Hub Transport server there. For high availability, consider
deploying at least two Hub Transport servers per site.
Question: Ed Meadows has explained that the administrators at the Branch Office 1 site needs to
be able to perform limited recipient management tasks. To which built-in role group should you
assign these branch administrators?
Answer: They should be assigned to the Help Desk role group.
Note

Be prepared to discuss your proposed design with the class.

Results: After this exercise, you should have completed the Contoso Exchange Server network
infrastructure report.

L2-14

Module 2: Designing Microsoft Exchange Server Integration with the Current Infrastructure

Exercise 2: Determining Suitability for Exchange Server 2010

Task 1: Evaluate the AD DS requirements
1.

On NYC-DC1, click Start, right-click Computer, and then click Properties.

2.

On the System page, in the Windows edition section, verify that the domain controller operating
system is compatible with Exchange Server 2010 requirements.

3.

Close the System page.

4.

Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.

5.

Right-click Contoso.com, and then click Properties.

6.

In the Contoso.com Properties dialog box, verify that the domain and forest functional levels are
compatible with the Exchange Server 2010 requirements.

7.

Click OK, and then close Active Directory Users and Computers.

8.

Click Start, in the Search box, type adsiedit.msc, and then press Enter.

9.

Right-click ADSI Edit, and then click Connect to.

10. In the Connection Settings dialog box, in the Connection Point section, in the Select a well known
Naming Context list, click Configuration, and then click OK.
11. In the left pane, expand Configuration[NYC-DC1.Contoso.com], and then click
CN=Configuration,DC=Contoso,DC=com.
12. Expand CN=Services, and verify that the CN=Microsoft Exchange has not been created.
13. Close ADSI Edit.

Task 2: Evaluate the DNS requirements

1.

On NYC-SVR1, click Start, in the Search box, type cmd, and then press Enter.

2.

At the command prompt, type IPConfig /all, and then press Enter. Verify that the DNS server IP
address for the Local Area Connection is 10.10.10.10.

3.

At the command prompt, type Ping NYC-DC1.contoso.com. Verify that you have network
connectivity with the domain controller.

4.

At the command prompt, type Nslookup, and then press Enter.

5.

At the command prompt, type set type=all, and then press Enter.

6.

At the command prompt, type _ ldap._tcp.dc._msdcs.Contoso.com, and then press Enter. Verify that
an SRV record is returned.

7.

Close the command prompt.

Lab: Designing Exchange Server Integration with the Current Infrastructure

L2-15

Task 3: Evaluate the server requirements

1.

On NYC-SVR1, click Start, point to Administrative Tools, and then click Server Manager.

2.

In the left pane, click Features. Verify that no Windows Server 2008 features are installed, including
the Active Directory Domain Services (AD DS) management tools.

3.

In the left pane, click Roles. Verify that no Windows Server 2008 roles are installed.

4.

Click Start, and point to Administrative Tools. Verify that Internet Information Services (IIS)
Management is not listed.

5.

Click Start, click All Programs, click Accessories, click Windows PowerShell, and then click
Windows PowerShell.

6.

At the Windows PowerShell prompt, type help about_windows_powershell, and then press Enter.
Verify that about_Windows_PowerShell_2.0 is listed. It is installed with Windows PowerShell 2.0.

7.

Close Windows PowerShell.

8.

Click Start, and then click Control Panel.

9.

In Control Panel, click Programs.

10. In the Programs and Features window, click Programs and Features. Verify that Microsoft Filter
Pack 2.0 is installed.
11. Close the Programs and Features window.
Results: After this exercise, you should have evaluated whether your organization meets the AD DS, DNS,
and server requirements for installing Exchange Server 2010. You should have identified the additional
components that need to be installed or configured to meet the requirements.

L2-16

Module 2: Designing Microsoft Exchange Server Integration with the Current Infrastructure

Exercise 3: Preparing the AD DS Forest for Exchange Server 2010

Task 1: Install the Windows Server 2008 server roles and features
1.

On NYC-SVR1, in Server Manager, click Features, and then click Add Features.

2.

In the Select Features page, expand Remote Server Administration Tools, expand Role
Administration Tools, expand AD DS and AD LDS Tools, expand AD DS Tools, and then select the
AD DS Snap-Ins and Command-Line Tools check box.

3.

Expand .NET Framework 3.5.1 Features, and then select the .NET Framework 3.5.1 check box.

4.

Expand WCF Activation, select the HTTP Activation check box, and then click Add Required Role
Services.

5.

Select the RPC over HTTP Proxy check box, click Add Required Role Services, and then click Next.

6.

On the Web Server (IIS) page, click Next.

7.

On the Select Role Services page, under Security, select the Digest Authentication check box.

8.

Under Performance, select the Dynamic Content Compression check box.

9.

Under IIS 6 Management Compatibility, select the IIS 6 Management Console check box.

10. Click Next, and then click Install.

11. Click Close.
12. Click Start, point to Administrative Tools, and then click Services.
13. In the Services list, double-click Net.Tcp Port Sharing Service.
14. In the Net.TCP Port Sharing Service Properties dialog box, in the Startup type drop-down list,
click Automatic, and then click Apply.
15. Click Start, wait for the service to start, and then click OK.
16. Close the Services console.

Task 2: Prepare AD DS for the Exchange Server 2010 installation

This task requires that the Exchange Server 2010 .iso be attached to the NYC-SVR1 virtual machine as a
DVD drive. Complete the following steps to attach it.
1.

In the 10233B-NYC-SVR1 on localhost Virtual Machine Connection window, on the File menu, click
Settings.

2.

Click DVD Drive, and then click Image File.

3.

Click Browse, and browse to C:\Program Files\Microsoft Learning

\10233\Drives.

4.

Click EXCH2010SP2.iso, click Open, and then click OK.

5.

On NYC-SVR1, close the autoplay dialog box, and open a command prompt.

6.

Type D:\setup.com /PrepareAD /OrganizationName:Contoso, and then press Enter.

7.

When the task completes, close the command prompt window.

Results: After this exercise, you should have prepared the AD DS and server configuration for the
Exchange Server 2010 installation.

Lab: Designing Exchange Server Integration with the Current Infrastructure

L2-17

Exercise 4: Configuring Exchange Server Delegation

Task: Configure permissions for Adam Carter, the branch administrator
1.

On NYC-SVR1, open Active Directory Users and Computers.

2.

Expand Users, right-click Users, point to New and then click User.

3.

In the New Object User dialog box, in the Full Name box, type Adam Carter.

4.

In the User logon name box, type Adam, and then click Next.

5.

In the Password and Confirm password boxes, type Pa$$w0rd.

6.

Click Next and then click Finish.

7.

In Active Directory Users and Computers, click Microsoft Exchange Security Groups, and then
double-click Help Desk.

8.

On the Members tab, click Add.

9.

In the Enter the object names to select field, type Adam Carter, and then click OK twice.

Results: After this exercise, you should have delegated administration.

To prepare for the next module

When you finish the lab, revert the virtual machines to their initial state. To do this, complete the
following steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-NYC-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for virtual machines 10233B-NYC-SVR1.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then in the Actions pane, click Start.
Note Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully started
before starting the other virtual machines.

6.

Wait for 10233B-VAN-DC1 to start, and then start 10233B-VAN-EX1. Connect to the virtual machine.

7.

Wait for 10233B-VAN-EX1 to start, and then start 10233B-VAN-EX2. Connect to the virtual machine.

8.

Wait for 10233B-VAN-EX2 to start, and then start 10233B-VAN-CL1. Connect to the virtual machine.

L2-18

Module 2: Designing Microsoft Exchange Server Integration with the Current Infrastructure

L3-19

Module 3: Planning and Deploying Mailbox Services

Lab: Planning and Deploying Mailbox

Services
Exercise 1: Designing the Mailbox Server Deployment
Task 1: Review the A. Datum Corporation documentation

Review the following information:

Server Design Interviews

Server Design Statistics

Task 2: Answer questions related to the documentation

Note

Your instructor may perform this task as a discussion.

Question: In the Server Design Interviews, what points are raised that impact your Mailbox server
deployment plan, and how do they impact it?
Answer:

A single server or component failure cannot be the cause of messaging system unavailability. Multiple
Mailbox servers must be deployed in each site.

The system must be scalable to grow capacity by at least 30 percent over 3 years.

There is a Storage Area Network (SAN) in London, Tokyo, and Toronto. These will be high
performance, but expensive.

San Diego and Chennai do not have a SAN and need to use direct access storage (DAS).

Mailbox sizes are increasing to 500 megabytes (MB) for basic users, and a personal archive of 1 GB.
Exceptional usersabout 25 percent of userswill have a mailbox of 1 GB and a personal archive of
2 GB.

Question: In the Server Design Statistics, what information is relevant to determining a server design, and
why?
Answer: All of the information in this document is relevant to developing a server design. This document
describes the size of mailboxes and the amount of user activity.

L3-20

Module 3: Planning and Deploying Mailbox Services

Task 3: Perform high level planning for Mailbox server storage in London

Complete the following proposal document by answering the questions.

A. Datum high level planning for mailbox servers in London
Document Reference Number: JC040400/1
Document Author
Date

Jason Carlson
2nd April 2010

Requirement Overview
Create a high level plan for Mailbox server storage in London.
Additional Information
N/A
Question: Assuming that there are 12,000 users in London, how much disk space is required for
mailbox databases?
Answer: There will be 9,000 users with a 500 MB mailbox and a personal archive of 1 GB. There will
be 3,000 users with a 1 GB mailbox and a 2 GB personal archive. The total storage space potentially
required is 22.5 terabytes (TB).
The initial deployment will not require this much space because user mailboxes will not all be at
their limit, but this shows the maximum potential size.
Question: Should the disk space for Mailbox servers be SAN or DAS?
Answer: The SAN has only 10 TB free and cannot support holding even a single copy of all mailbox
data. Expanding the SAN will be very expensive. Therefore, DAS should be used.
Question: If DAS is used, will the disk space use RAID or JBOD?
Answer: Because there are three replicated copies of the data, consider using JBOD. From a
performance perspective, there is no reason to use RAID. If the final design includes more than
three data copies, JBOD should be used.
Question: What size and speed of disk do you think is appropriate?
Answer: To support the large volume of data, slower and less expensive disks such as 7200 RPM
SAS disks should be used. The 7200 RPM SAS disks are close to the same price as SATA drives but
are more reliable. You do not need disks with a higher RPM because Exchange Server 2010 has
lower I/O requirements.
Question: Should transaction logs be stored on a separate LUN from database files?
Answer: When there are multiple replicated copies, you do not need a separate LUN for
transaction logs. Recovery is performed by using an alternate copy of the database rather than by
restoring and then replaying transaction logs. In most cases, circular logging is used and there is no
option to replay transaction logs.

Lab: Planning and Deploying Mailbox Services

L3-21

Task 4: Use the Exchange 2010 Mailbox Server Role Requirements Calculator
spreadsheet to determine the configuration
1.

On VAN-CL1, open the \\VAN-EX1\E$\Labfiles\LabResources\E2010Calc18.2.xlsm spreadsheet.

Click Enable Content and then click Yes.

2.

Enter the following data on the Input tab:

Exchange Environment Configuration

Global Catalog Architecture: 64-bit

Server Multi-Role Configuration: No

Server Role Virtualization: No

High Availability Deployment: YES

Number of Mailbox Servers Hosting Active Mailboxes/DAG (Primary Datacenter): 2

Number of Database Availability Groups: 1

Mailbox Database Copy Configuration

Total Number of HA Database Copy Instances (Includes Active Copy) within DAG: 3

Total Number of Lagged Database Copy Instances within DAG: 0

Number of HA Database Copy Instances Deployed in Secondary Datacenter: 1

Exchange Data Configuration

Data Overhead Factor: 20%

Mailbox Moves / Week Percentage: 1%

Dedicated Maintenance / Restore LUN: Yes

LUN Free Space Percentage: 20%

Exchange I/O Configuration

I/O Overhead Factor: 20%

Additional I/O Requirement / Server: 0

Site Resilience Configuration

Site Resilient Deployment: Yes

Site Resilience User Distribution Model: Active/Passive

Site Resilience Recovery Point Objective (Hours): 24

Activation Block Secondary Datacenter Mailbox Servers: Yes

Database Configuration

Maximum Database Size Configuration: Default

Automatically Calculate Number of Unique Databases / DAG: Yes

Calculate Number of Unique Databases / DAG for Symmetrical Distribution: No

Tier 1 User Mailbox Configuration

Total Number of Tier 1 User Mailboxes: 3000

L3-22

Module 3: Planning and Deploying Mailbox Services

Projected Mailbox Number Growth Percentage: 30%

Total Send/Receive Capability / Mailbox / Day: 100 messages

Average Message Size (KB): 50

Mailbox Size Limit (MB): 1000

Personal Archive Mailbox Size Limit (MB): 2000

Deleted Item Recovery Window (Days): 14

Single Item Recovery: Enabled

Calendar Version Storage: Enabled

IOPS Multiplication Factor: 1.00

Megacycles Multiplication Factor: 1.00

Desktop Search Engines Enabled (for Online Mode Clients): No

Predict IOPS Value: Yes

Tier 2 User Mailbox Configuration

Total Number of Tier 2 User Mailboxes: 9000

Projected Mailbox Number Growth Percentage: 30%

Total Send/Receive Capability / Mailbox / Day: 50 messages

Average Message Size (KB): 25

Mailbox Size Limit (MB): 500

Personal Archive Mailbox Size Limit (MB): 1000

Deleted Item Recovery Window (Days): 14

Single Item Recovery: Enabled

Calendar Version Storage: Enabled

IOPS Multiplication Factor: 1.00

Megacycles Multiplication Factor: 1.00

Desktop Search Engines Enabled (for Online Mode Clients): No

Predict IOPS Value: Yes

Backup Configuration

Backup Methodology: Exchange Native Data Protection

Database and Log Isolation Configured: No

Backup/Truncation Failure Tolerance: 3

Network Failure Tolerance (Days): 0

Storage Options

Consider Storage Designs Utilizing JBOD (if applicable): Yes

Primary Datacenter Disk Configuration

Lab: Planning and Deploying Mailbox Services

3.

Database + Log: 2000 GB, 7.2K RPM SAS 3.5

Restore Lun: 2000 GB, 7.2K RPM SAS 3.5

Secondary Datacenter Disk Configuration

Database + Log: 2000 GB, 7.2K RPM SAS 3.5

Restore Lun: 2000 GB, 7.2K RPM SAS 3.5

Server Configuration

Primary Datacenter Mailbox Servers: 12 cores per server, SPECint2006 Rate of 400

Primary Datacenter Mailbox Servers: 12 cores per server, SPECint2006 Rate of 400

Log Replication Configuration

For Hours 1-5,20-24: 1%

For Hours: 6-7,18-19: 5%

For Hours 8-17, 7%

Network Configuration:

Network Link Type: Fast Ethernet

Network Link Latency: 50.00

Log off of VAN-CL1.

Task 5: Update the A. Datum Large Mailbox server design document

Complete the following proposal document by answering the questions.

A. Datum Large Mailbox server design
Document Reference Number: JC040400/2
Document Author
Date

Jason Carlson
2nd April 2010

Requirement Overview
Determine the hardware configuration for large Mailbox servers that use DAS.
Additional Information
N/A
Proposals
Question: What is the processor configuration for each server?
Answer: 12 server cores with a SPECint2006 Rate value of 400
Question: What type of disks are being used?
Answer: 2000 GB, 7.2K RPM SAS
Question: How many databases are recommended?
Answer: The DAG requires 30 databases.

L3-23

L3-24

Module 3: Planning and Deploying Mailbox Services

(continued)
A. Datum Large Mailbox server design
Question: How many mailboxes are recommended for each database?
Answer: 500 mailboxes are recommended for each database.
Question: What is the recommended RAM for this server?
Answer: 96 GB
Question: What is the expected CPU utilization for this server?
Answer: 33 percent
Question: What is the recommended number of LUNs on the server?
Answer: Total recommended LUNs for Exchange are 31:
30 LUNs for databases and logs
1 LUN for restores
Question: How many databases are recommended per LUN?
Answer: 1
Question: What is the total disk space required per server?
Answer: The total disk space required is approximately 53 TB (53118 GB):
51553 GB for database and log LUNs
1565 GB for a restore LUN
Question: What type of RAID is recommended?
Answer: JBOD is recommended for the primary datacenter because there are three database
copies. RAID 1/0 (also known as RAID 10) is recommended for the secondary datacenter LUNs that
hold database copies and logs. RAID 5 is recommended for the secondary datacenter restore LUN.
Question: How many database disks are recommended for the primary datacenter servers?
Answer: 31
Question: How many database disks are recommended for the secondary datacenter server?
Answer: 59

Note

Be prepared to discuss your proposed design with the class.

Lab: Planning and Deploying Mailbox Services

L3-25

Exercise 2: Designing Recipient Management

Task 1: Review the A. Datum Corporation documentation

Review the following information:

Recipient Management Interviews

Task 2: Answer questions relating to the documentation

Note

Your instructor may perform this task as a discussion.

Question: In the Recipient Management Interviews, what points are raised that impact your Mailbox
server deployment plan, and how do they impact it?
Answer: This entire document is relevant to the planning of recipient management. However, the specific
points raised are:

When sending mail, users must use the email address associated with their business unit, but when
receiving email, all domains must be allowed.

Information Technology (IT) Client Services staff in each location must be able to manage recipients
in that location only. Team leaders must be able to manage recipients throughout the entire
organization.

Automated booking of meeting rooms is desired, with exceptions approved by a designated person.

Group management by department representatives is desired.

Task 3: Document the required configuration

Complete the following proposal document by answering the questions.

A. Datum recipient management configuration
Document Reference Number: JC040400/3
Document Author
Date

Jason Carlson
2nd April 2010

Requirement Overview
Determine the configuration required to meet recipient management needs.
Proposals
Question: How will you ensure that recipients are assigned the correct email addresses?
Answer: Two email address policies need to be created:
The first e-mail address policy will have a condition that matches only A. Datum recipients.
The condition could be based on recipients in specific organizational units (OUs) or
recipients with the Company defined in Active Directory Domain Services.
The second e-mail address policy will have a condition that matches only Trey Research
recipients.
Each policy will be configured with both domains. The e-mail address policy for A. Datum
Corporation will use adatum.com as the Reply To address. The e-mail address policy for Trey
Research will use TreyResearch.net as the Reply To address.

L3-26

Module 3: Planning and Deploying Mailbox Services

(continued)
A. Datum recipient management configuration
Question: How will you enable the IT Client Services staff to perform recipient management?
Answer: Team leaders can be made members of the Recipient Management role group. This group
has management permissions for the recipients in the entire Exchange Server organization.
New Recipient Management role groups should be created for each physical location. These role
groups will be scoped to limit management permissions to manage recipients only within a specific
OU that represents each physical location.
Question: How will you meet the needs for meeting room bookings?
Answer: Each meeting room will be created as a resource mailbox. You can then determine the inpolicy and out-of-policy settings for each meeting room. A delegate for each meeting room will be
configured to arbitrate conflicts, and approve or deny out-of-policy requests.
Question: How will you address the needs for distribution group management?
Answer: Exchange Server 2010 supports delegation of distribution group membership
management. The person that is configured as group manager is able to modify the distribution list
membership by using the Exchange Control Panel.
Question: How will you address the need for separating the address books for A. Datum and Trey
Research?
Answer: Create separate address lists for each organization and then distribute the appropriate
address lists by using address book policies. The appropriate address book policy must be
associated with each user. To simplify this you must have an identifying attribute that can be
queried when performing the assignment. You should also have an identifying attribute that can be
queried when specifying GAL members.
Note

Be prepared to discuss your proposed design with the class.

Lab: Planning and Deploying Mailbox Services

L3-27

Exercise 3: Designing a Public Folder Deployment

Task 1: Review the A. Datum Corporation documentation

Review the following information:

Public Folder Interviews

Server Design Interview

Task 2: Answer questions relating to the documentation

Note

Your instructor may perform this task as a discussion.

Question: In the Public Folder Interviews, what points are raised that impact your public folder
deployment plan, and how do they impact it?
Answer: This entire document is relevant to the planning of recipient management. However, the specific
points raised are:

The Executives want a new public folder for private communication that is available quickly from any
location, and is not impacted by a server failure.

Requests for new public folders are being encouraged to evaluate Microsoft SharePoint as an
alternative.

IT Client Services would like a new collaboration tool.

Question: In the Server Design Interview, what points are raised that impact your public folder
deployment plan, and how do they impact it?
Answer: Many clients still use Microsoft Office Outlook 2003. Office Outlook 2003 clients require public
folders to access free/busy information, and to download offline address books.

L3-28

Module 3: Planning and Deploying Mailbox Services

Task 3: Document the required configuration

Complete the following proposal document by answering the questions.

A. Datum public folder configuration
Document Reference Number: JC040400/4
Document Author
Date

Jason Carlson
2nd April 2010

Requirement Overview
Determine the configuration required to meet public folder needs.
Proposals
Question: How will you address the executives desire for public folders?
Answer: Since Erik has made it clear that he does not want to use SharePoint, a public folder
should be created. This public folder should be replicated to all locations in the organization for fast
access regardless of location. The replication also helps ensure high availability.
Question: How will you address the IT Client Services request for a public folder?
Answer: IT Client Services should be encouraged to use SharePoint instead of public folders. This
will provide them with many more options for collaboration.
Question: Other than the public folder for executives, which other public folders are required?
Answer: To support Office Outlook 2003 clients, the system public folders for free/busy searches
and offline address books must be available in all locations. This requires that you create at least
one public folder database in each physical location. Public folder databases will not exist in each
physical location by default.

Note

Be prepared to discuss your proposed design with the class.

Lab: Planning and Deploying Mailbox Services

L3-29

Exercise 4: Implementing Mailbox Services

Task 1: Configure an address book policy for Trey Research
1.

On VAN-EX1, click Start, point to Administrative Tools, and click Active Directory Users and
Computers.

2.

In Active Directory Users and Computers, right-click Adatum.com, point to New, and click
Organizational Unit.

3.

In the New Object Organizational Unit window, in the Name box, type Trey, and click OK.

4.

In the left pane, click Marketing then click and drag Wei Yu to the Trey organizational unit.

5.

In the Active Directory Domain Services window, click Yes.

6.

Close Active Directory Users and Computers.

7.

Click Start, point to All Programs, click Microsoft Exchange Server 2010, and then click Exchange
Management Console.

8.

In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand

Organization Configuration, and then click Mailbox.

9.

In the Actions pane, click New Address List.

10. In the New Address List wizard, on the Introduction page, enter the following settings and click
Next.

Name: Trey Users

Display Name: Trey Users

Container: \

11. On the Filter Settings page, click Browse, click Trey, and click OK.
12. Click The following specific types, select the Users with Exchange mailboxes check box, and click
Next.
13. On the Conditions page, click Next.
14. On the Schedule page, click Next to apply all changes immediately.
15. On the New Address List page, click New.
16. On the Completion page, click Finish.
17. In the Actions pane, click New Address List.
18. In the New Address List wizard, on the Introduction page, enter the following settings and click
Next.

Name: Trey Rooms

Display Name: Trey Rooms

Container: \

19. On the Filter Settings page, click Browse, click Trey, and click OK.
20. Click The following specific types, select the Resource mailboxes check box, and click Next.
21. On the Conditions page, click Next.

L3-30

Module 3: Planning and Deploying Mailbox Services

22. On the Schedule page, click Next to apply all changes immediately.
23. On the New Address List page, click New.
24. On the Completion page, click Finish.
25. Click Start, point to All Programs, click Microsoft Exchange Server 2010, and then click Exchange
Management Shell.
26. In the Exchange Management Shell, type the following command, and then press ENTER.
New-GlobalAddressList TreyGAL RecipientContainer ou=Trey,dc=adatum,dc=com

27. In the Exchange Management Shell, type the following command, and then press ENTER.
New-OfflineAddressBook TreyOAB AddressLists TreyGAL

28. In the Exchange Management Console, click New Address Book Policy.
29. In the New Address Book Policy wizard, in the Name box, type TreyABP.
30. Beside the Global address list box, click Browse, click TreyGAL, and click OK.
31. Beside the Offline address list box, click Browse, click TreyOAB, and click OK.
32. Beside the Room list box, click Browse, click Trey Rooms, and click OK.
33. Under Address lists, click Add, click Trey Users, and click OK.
34. Click New.
35. On the Completion page, click Finish.
36. Close the Exchange Management Console.
37. In the Exchange Management Shell, type the following command, and then press ENTER.
Get-Mailbox OrganizationalUnit Trey | Set-Mailbox AddressBookPolicy TreyABP

38. Close the Exchange Management Shell.

39. On NYC-CL1, log on as Adatum\Wei with the password Pa$$w0rd.
40. Click Start, point to All Programs, click Microsoft Office, and click Microsoft Outlook 2010.
41. In the Microsoft Outlook 2010 Startup wizard, click Next three times to configure Outlook.
42. Click Finish to close the wizard.
43. In the User Name window, click OK.
44. In the Welcome to Microsoft Office 2010 window, click Dont make changes and then click OK.
45. On the Home tab, click Address Book.
46. Notice that the Global Address List does not have any content because the OAB has not been
generated yet.
47. Select the Trey Users address book and verify that Wei is the only user listed.
48. Close all open windows and log off of VAN-CL1.

Lab: Planning and Deploying Mailbox Services

L3-31

Task 2: Create and configure a resource mailbox

1.

On VAN-EX1, open the Exchange Management Console, browse to Recipient Configuration, and
then click Mailbox.

2.

In the Actions pane, click New Mailbox.

3.

In the New Mailbox window, click Room Mailbox, and then click Next.

4.

On the User Type page, click New user, and then click Next.

5.

On the User Information page, enter the following information, and then click Next.

First name: Room 100

User logon name: Room100

6.

On the Mailbox settings page, in the Alias box, type Room100, and then click Next.

7.

On the New Mailbox page, click New.

8.

On the Completion page, click Finish.

9.

Right-click Room 100, and then click Properties.

10. In the Room 100 Properties window, click the Resource General tab, and then select the Enable the
Resource Booking Attendant check box.
11. Click the Resource Policy tab. Under Specify delegates of this mailbox, click Add, click Andreas
Herbinger, and then click OK.
12. Click the Resource Out-of-Policy Requests tab, click Add, click Luca Dellamore, and then click OK.
13. In the Room 100 Properties window, click OK.

Task 3: Test the delegation of a resource mailbox

1.

On VAN-CL1, log on as Adatum\Luca using the password Pa$$w0rd.

2.

Click Start, point to All Programs, click Microsoft Office, and then click Microsoft Outlook 2010.

3.

In Outlook, click New Items and Meeting.

4.

In the Untitled Meeting window, enter the following, and then click the Check Names button.

To: Luca; Conor

Subject: Exchange Planning

Start time: Tomorrow 1pm

End Time: Tomorrow 2pm

5.

Click Rooms, double-click Room 100, and then click OK.

6.

Click Send.
Notice that an automatic response is received indicating that the booking was accepted by Room
100, because the request is in-policy. The response may take a minute or so to appear.

7.

In Outlook, click New Items, and then click Meeting.

L3-32

Module 3: Planning and Deploying Mailbox Services

8.

9.

In the Untitled Meeting window, enter the following, and then click the Check Names button.

To: Luca; Conor

Subject: Exchange Project Review

Start time: 9 months from today at 1pm

End Time: 9 months from today at 2pm

Click Rooms, double-click Room 100, and then click OK.

10. Click Send.

11. Wait for the response to be delivered, and then click the new message.
Notice that the request was received, but is pending approval. Because the request is Out-of-Policy, it
has been forwarded to the delegate.
12. On the taskbar, click Internet Explorer.
13. In the address bar for the Internet Explorer browser, type https://van-ex1.adatum.com/owa, and
then press ENTER.
14. Log on as Adatum\Andreas using the password Pa$$w0rd.
15. If prompted for language and time zone settings, click OK to accept the default.
16. If necessary, click the Exchange Project Review item in the Inbox.
17. In the reading pane, click the check mark, and then click Send the response now.
18. In Outlook, verify that the request is now accepted by Room 100.

Task 4: Configure a distribution group for delegated management and moderation

1.

On VAN-EX1, in the Exchange Management Console, in the console tree, expand Recipient
Configuration, and then click Distribution Group.

2.

Right-click Executives, and then click Properties.

3.

In the Executives Properties window, click the Group Information tab.

4.

Under Managed by, click Add, click Conor Cunningham, and then click OK.

5.

Click the Membership Approval tab, and verify that group membership is closed.

6.

Click the Mail Flow Settings tab.

7.

Click Message Moderation, and then click Properties.

8.

Select the Messages sent to this group have to be approved by a moderator check box.

9.

In the Message Moderation window, under Specify group moderators, click Add, click Luca
Dellamore, and then click OK.

10. Under Specify senders who dont require message approval, click Add, click Executives, and then
click OK.
11. In the Message Moderation window, click OK.
12. In the Executives Properties window, click OK.

Lab: Planning and Deploying Mailbox Services

L3-33

Task 5: Test moderation of a distribution group

1.

On VAN-CL1, in Outlook Web App, click New.

2.

In the Untitled Message window, enter the following information and then click Send.

To: Executives

Subject: New Public Folder

Body: The Executives public folder has been created for you.

3.

In the left pane, click Sent Items, right-click New Public Folder, and then click Open Delivery
Report.

4.

When prompted to allow the pop-up, click Yes.

5.

In the Delivery Report window, notice that the message has been sent to the moderator, and then
click Close.

6.

In Office Outlook, in the Inbox, click the Approval requested: New Public Folder message, and read
the contents.

7.

Click the New Public Folder message, and then click Approve.

8.

In Outlook Web App, right-click New Public Folder, and then click Open Delivery Report.

9.

When prompted to allow the pop-up, click Yes.

10. In the Delivery Report window, notice that the message has been delivered to both group members,
and then click Close.

To prepare for the next module

When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the
following steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-CL1. Close the virtual
machine connection windows

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then in the Actions pane, click Start.

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then in the
Actions pane, click Connect.
Important Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully
started before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10233B-VAN-EX1. Connect to the virtual machine.

8.

Wait for 10233B-VAN-EX1 to start, and then start 10233B-VAN-EX2. Connect to the virtual machine.

L3-34

Module 3: Planning and Deploying Mailbox Services

L4-35

Module 4: Planning and Deploying Client Access Services in

Microsoft Exchange Server 2010

Lab: Planning and Deploying Client Access

Services in Exchange Server 2010
Exercise 1: Designing the Client Access Server Deployment
Task 1: Review the A. Datum documentation

Review the following A Datum documentation:

Server Design Interview Notes.doc

Requirements Interview Notes.doc

AD DS and Routing Interview Notes.doc

Adatum_CurrentPerimeterDesign.vsd

Adatum_CurrentADSiteDesign.vsd

Task 2: Answer questions related to the documentation

Question: In the Server Design Interview Notes document, what points are raised that
impact your Client Access server deployment plan, and why?
Answer:

A single server or component failure cannot be the cause of messaging system unavailability.
Multiple Client Access servers must be deployed in each site that has a deployed Mailbox server.

Microsoft Office Outlook 2003 is still in use throughout the organization. Public folders are
required to support free/busy schedule information and offline address book distribution.

Question: In the Requirements Interview Notes document, what points are raised that
impact your Client Access server deployment plan, and why?

Answer:

The sales team requires anywhere access to their email, most likely by using their cell phones.
Microsoft Exchange ActiveSync addresses this need.

Various examples cite unavailable messaging and subsequent business losses because of this
unavailability. High availability is important.

The requirements allow unencrypted traffic into the perimeter network from the Internet, but not
into the corporate network. The inner firewalls block unencrypted network traffic. When planning
Client Access protocols, consider using Secure Sockets Layer (SSL) to secure traffic.

Question: In the AD DS and Routing Interview Notes document, what points are raised
that impact your Client Access server deployment plan, and why?
Answer:

There is currently widespread use of Outlook Web App in Exchange Server 2003, so ensure that
Outlook Web App makes a positive impact on users.

L4-36

Module 4: Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Simple Mail Transfer Protocol (SMTP) traffic for the Adatum.com organization currently passes to
and from the Internet through the London site.

Hypertext Transfer Protocol/Secure (HTTPS) traffic is allowed through most firewalls. Configure
Client Access servers to use SSL for services.

Question: Is there anything in the Adatum_CurrentPerimeterDesign.vsd diagram that

raises Client Access server deployment issues? If so, what?
Answer:

Only the firewall in the San Diego site allows Post Office Protocol version 3 (POP3) inbound
network traffic.

Only the London and San Diego sites allow for inbound and outbound SMTP traffic.

Question: Is there anything in the Adatum_CurrentADSiteDesign.vsd diagram that raises

Client Access server deployment issues? If so, what?
Answer: Answers will vary, but there do not appear to be any issues that will impact Client
Access server deployment decisions.

Task 3: Update the A. Datum Client Access server deployment plan document

Complete the following proposal document by answering the questions.

A Datum Client Access Server Deployment Plan
Document Reference Number: JC040410/1
Document Author
Date

Jason Carlson
4th April 2010

Requirement Overview
Determine the number and placement of Client Access servers within the existing network
infrastructure.
Additional Information
Identify infrastructure changes that may be required due to the proposed deployment.
Proposals
Question: With reference to the Adatum_CurrentADSiteDesign diagram, how many Client Access
servers do you propose to deploy in each site?
Answer: Deploy at least two in each site to address the high availability concerns raised in the
documentation.
Question: Do you have sufficient information from the documents reviewed so far, to determine
whether some sites require additional Client Access servers?
Answer: No. You also need information about the number of users connecting to the Client Access
servers. This information is provided in a supplemental document that you will review in the next
exercise.
Question: Based on the documentation you have reviewed, what client types must you support?
Answer: Messaging Application Programming Interface (MAPI), Microsoft Exchange ActiveSync,
POP3/SMTP, and Outlook Web App. Outlook Anywhere is not mentioned in this documentation.

Lab: Planning and Deploying Client Access Services in Exchange Server 2010

L4-37

(continued)
A Datum Client Access Server Deployment Plan
Question: Is it clear from the documentation that you have reviewed which sites support which
client types?
Answer: No. Additional information is supplied in the A. Datum User Distribution Summary
document that you will review in the next exercise.
Question: While maintaining compliance with the requirements mentioned in the documentation,
can you propose changes to the client types that will simplify the configuration?
Answer: Answers will vary, but might include:
Upgrading the Office Outlook 2003 clients to Outlook 2010 would mean that Public folders
are no longer required. Additionally, this would mean that free/busy information would be
provided to users more quickly.
Replacing POP3 clients with another client type would simply firewall configuration. By
using either Outlook Anywhere or Outlook Web App, only HTTPS traffic (already permitted)
would be configured through the firewalls.
Question: Which Client Access servers do you propose to make Internet-facing?
Answer: Answers will vary. There are two choices:
Deploy Internet-facing Client Access servers in one site, and rely on redirection and/or
proxying (depending on the client type) to enable clients to connect to the appropriate
Client Access server in other sites. With this approach, you only need to configure one
namespace, which simplifies certificate deployment. However, not all client types support
redirection and proxying. For example, POP3 clients do not support redirection and
proxying.
Deploy Internet-facing Client Access servers in each site, and provide users with the
necessary URLs for the servers in the site that hosts their mailboxes. This means you must
obtain a certificate for each Client Access server, or else use a certificate that supports
multiple host names.
Question: How will you configure Autodiscover to support your Client Access server model?
Answer: Register a server connection point for each Client Access server on the Active Directory
site. This server connection point is the fully qualified domain name (FQDN) of the server that hosts
the role and is used by domain-joined computers to locate the Autodiscover service. Domaindisjoined computers use Domain Name System (DNS) to locate the Autodiscover service. Consider
modifying both these values (the server connector point and the DNS records) to match.
Note

Be prepared to discuss your proposed design with the class.

Results: After this exercise, you should have completed the A. Datum Client Access server deployment
plan document.

L4-38

Module 4: Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

Exercise 2: Designing Client Access

Task 1: Review the A. Datum documentation

Review the contents of the following documents:

Policy Requirements.doc

A Datum User Distribution Summary.doc

Task 2: Answer questions relating to the documentation

Question: In the Policy Requirements document, what points are raised that impact your
Client Access server deployment plan, and why?
Answer: Mobile messaging will be very importantas far as executives are concerned, this is
principle reason for upgrading to Exchange Server 2010.
Security issues:

All users who access email on the Exchange server must be required to have an alphanumeric
password that is at least six characters long.

Users who want to download attachments to the device must have encryption enabled on the
device, and the device must be configured to lock after five failed logon attempts.

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 a user gets a new mobile
device, but they also do not want users to have many mobile devices associated with their
mailboxes.

Question: In the A. Datum User Distribution Summary document, what points are raised
that impact your Client Access server deployment plan, and why?
Answer:

The number of internal users at each location will affect the number of required Client Access
servers.

There are a mix of remote client types at many locations, including Outlook Web App users,
Outlook Anywhere users, Office Outlook (over a virtual private network (VPN)) users, POP3 users,
and Exchange ActiveSync users.

Placement of Internet-facing Client Access servers in various sites raises the issue of the
namespace that you will use.

Using multiple Internet-facing Client Access servers means that you must carefully plan the
external URLs used on certificates. Certificates must support multiple computer names.

Lab: Planning and Deploying Client Access Services in Exchange Server 2010

L4-39

Task 3: Update the A. Datum Client Access server configuration document

Complete the following proposal document by answering the questions.

A. Datum Client Access Server Configuration
Document Reference Number: JC040410/2
Document Author
Date

Jason Carlson
4th April 2010

Requirement Overview
Determine the feature configuration for Client Access servers in the A Datum Exchange Server 2010
upgrade.
Proposals
Question: Based on the information in the A. Datum User Distribution Summary document, do you
envisage deploying additional Client Access servers in any sites?
Answer: Answers will vary. However, London, Toronto, and Tokyo have large numbers of users.
Two Client Access servers are probably insufficient to support timely connections to user mailboxes
and features.
Question: Which features must you enable on the Client Access servers to support the current
client-types?
Answer: Enable MAPI, Exchange ActiveSync, POP3/SMTP, Outlook Web App, and Outlook
Anywhere.
Question: Which client protocols must you enable through the firewalls?
Answer: Enable HTTPS, POP3, and SMTP.
Question: What would you do to address the security concerns raised regarding mobile clients?
Answer: Configure the following settings in Exchange ActiveSync:
At the organizational level, configure two Exchange ActiveSync Mailbox policies, one for Managers
and Executives, and one for everyone else. Configure both with the following security settings:
Require passwords
Require minimum password length of 6
Require encryption on storage card
Require encryption on device
Disallow simple password
Restrict number of failed attempts to 5
To support attachment downloads for executives and managers only, in Sync Settings, configure
the Allow attachments to be downloaded to device only for the Managers and Executives
policy.
Use Exchange Management Shell to assign the appropriate Exchange ActiveSync Mailbox policy to
the appropriate users.

L4-40

Module 4: Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

(continued)
A. Datum Client Access Server Configuration
Question: To support the other client types, what other configuration changes must you make?
Answer: You must:
Configure the external URLs for services that you want to make available across the
Internet. For example, to support Exchange ActiveSync, configure the external URL value on
servers providing this feature.
Start the POP3 service on Client Access servers that provide this service.
Configure a SMTP connector to support remote client relaying. Typically, you do this on the
Hub Transport server role, and then publish using a reverse proxy such as a Microsoft
Internet Security and Acceleration (ISA) Server.
Configure the required authentication settings on all services. For example, Outlook Web
App uses forms-based authentication by default.
Obtain and install the required certificates to enable SSL.
Question: While maintaining compliance with the requirements mentioned in the documentation,
can you propose changes to the client types that will simplify the configuration?
Answer: Aside from those mentioned already, you should migrate Office Outlook users that
implement a connection over a VPN to Outlook Anywhere. This avoids the need for VPNs.
Note

Be prepared to discuss your proposed design with the class.

Results: After this exercise, you should have completed the A. Datum Client Access server configuration
document.

Lab: Planning and Deploying Client Access Services in Exchange Server 2010

L4-41

Exercise 3: Implementing Client Access

Task 1: Verify the Exchange ActiveSync virtual directory configuration
1.

On VAN-EX2, click Start, point to All Programs, point to Microsoft Exchange Server 2010, and
then click Exchange Management Console.

2.

In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand Server
Configuration, and then click Client Access.

3.

In the result pane, click VAN-EX2, and then in the work pane, click the Exchange ActiveSync tab.

4.

Right-click Microsoft-Server-ActiveSync (Default Web Site), and then click Properties.

5.

Review the information on the General tab.

6.

Click the Authentication tab. Notice that Basic authentication is enabled. This is acceptable, because
SSL will be used to secure the credentials in transit.

7.

Click OK.

Task 2: Create a new Exchange ActiveSync mailbox policy

1.

On VAN-EX2, in Exchange Management Console, in the console tree, expand Organization

Configuration, and then click Client Access.

2.

In the Actions pane, click New Exchange ActiveSync Mailbox Policy.

3.

In the Mailbox policy name box, type Executive Policy.

4.

Select the Allow non-provisionable devices check box. Confirm that the Allow attachments to be
downloaded to device option is selected.

5.

Select the Require password check box.

6.

Select the Enable password recovery check box. This will enable users to recover their Windows
Mobile password through the Exchange Control Panel.

7.

Select the Require encryption on device check box.

8.

Clear the Allow simple password check box.

9.

Select the Minimum password length check box, and then in the Minimum password length box,
type 6.

10. Click New to create the mobile mailbox policy.

11. Read the completion summary, and then click Finish.
12. Right-click Executive Policy, and then click Properties.
13. Click the Password tab, and then select the Require encryption on storage card check box.
14. Select the Number of failed attempts allowed check box, and then in the Number of failed
attempts allowed box, type 5.
15. On the Sync Settings tab, review the configuration options.
16. On the Device tab, review the configuration options.
17. On the Device Applications tab, review the configuration options. To implement these settings, you
must have an Enterprise Client Access License for each mailbox.
18. On the Other tab, review the options for allowing or blocking specific applications, and then click OK.

L4-42

Module 4: Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

19. Close Exchange Management Console.

20. Click Start, point to All Programs, point to Microsoft Exchange Server 2010, and then click
Exchange Management Shell.
21. In the Exchange Management Shell, type the following command, and then press Enter.
Get-Mailbox -OrganizationalUnit Executives | Set-CASMailbox
-activesyncmailboxpolicy "Executive Policy"

22. Close the Exchange Management Shell.

Task 3: Configure Exchange ActiveSync settings from the Exchange Control Panel
(ECP)
1.

Click Start, point to All Programs, and then click Internet Explorer.

2.

In the address bar, type https://van-ex2.adatum.com/ecp and then press Enter.

3.

On the Outlook Web App webpage, in the Domain\user name box, type adatum\administrator.

4.

In the Password box, type Pa$$w0rd and then click Sign in.

5.

In the Exchange Control Panel, in the navigation pane on the left, click Phone & Voice.

6.

In the center pane, click ActiveSync Device Policy.

7.

In the results pane, click Executive Policy and then click Details.

8.

In the Executive Policy dialog box, expand Device Security. Review the settings.

9.

Expand Sync Settings. Review the settings.

10. Expand Device Settings. Notice that text messaging is allowed. Click Cancel.
11. In the center pane, click ActiveSync Access.
12. Under Device Access Rules, click New.
13. In the New Device Access Rule dialog box, under Device family, click Browse.
14. Select All families and click OK.
15. Under When devices of the selected family or model try to connect, click Quarantine Let me
decide to block or allow later, and then click Save.
16. In the Error dialog box, click Close. There are currently no devices in use in the Adatum organization.
Click Cancel.
17. Close Internet Explorer.
Results: After this exercise, you should have deployed and configured Exchange ActiveSync for members
of the Executives group.

Lab: Planning and Deploying Client Access Services in Exchange Server 2010

L4-43

To prepare for the next module

When you finish the lab, revert the machines back to their initial state. To do this, complete the following
steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, and 10233B-VAN-EX2. Close the virtual machine connection
windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then in the Actions pane, click Start.

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then in the
Actions pane, click Connect.
Important Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully
started before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10223A-VAN-EX1. Connect to the virtual
machine.

8.

Wait for 10233B-VAN-EX1 to start, and then start 10223A-VAN-EX2. Connect to the virtual machine.

9.

Wait for 10233B-VAN-EX2 to start, and then start 10223A-VAN-EDG. Connect to the virtual
machine.

L4-44

Module 4: Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

L5-45

Module 5: Planning and Deploying Message Transport in

Microsoft Exchange Server 2010

Lab: Planning and Deploying Message

Transport in Exchange Server 2010
Exercise 1: Designing a Message Routing Topology
Task 1: Review the A. Datum Corporation documentation

Review the contents of the following files:

AD DS and Routing Interview Notes.doc

Adatum_CurrentADSiteDesign.vsd

Adatum_Info.vsd

Task 2: Modify the A. Datum current AD DS site design diagram with proposed
changes to the site design
1.

Use callouts in the following diagram to document proposed changes to the site design. For each
proposed change, provide:

The proposed change.

A rationale for the proposed change.

2.

Indicate which server roles need to be deployed in each AD DS site.

3.

Document message flow within the organization. Document the changes that you will need to make
to the AD DS configuration to enable optimal message flow.
Note

Be prepared to discuss your proposed design with the class.

L5-46

Module 5: Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Adatum_ProposedADSiteDesign.vsd

Results: After this exercise, you should have successfully modified the A. Datum AD DS site design.

Lab: Planning and Deploying Message Transport in Exchange Server 2010

L5-47

Exercise 2: Designing a Messaging Perimeter

Task 1: Review the A. Datum Corporation documentation

Review the contents of the following files:

AD DS and Routing Interview Notes.doc

Adatum_CurrentPerimeterDesign.vsd

Adatum_Info.vsd

Task 2: Modify the A. Datum current perimeter design diagram with proposed
changes to the site design
1.

Use callouts in the following diagram to document proposed changes to the perimeter design. For
each proposed change, provide:

The proposed change.

A rationale for the proposed change.

2.

Indicate whether you need to deploy any additional server roles in each AD DS site.

3.

Indicate the required firewall changes to meet your design requirements.

4.

Indicate any other infrastructure changes that you must implement to meet your design
requirements.

5.

For each company location, document how messages are delivered to the Internet, and how inbound
messages are delivered to internal recipients.
Note

Be prepared to discuss your proposed design with the class.

L5-48

Module 5: Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Adatum_ProposedPerimeterDesign.vsd

Results: After this exercise, you should have successfully designed the A. Datum messaging perimeter.

Lab: Planning and Deploying Message Transport in Exchange Server 2010

L5-49

Exercise 3: Discussion: Improving an AD DS and Message Routing Design

Task 1: Discuss as a class, and then answer the following questions
Question: What changes did you make to the AD DS site configuration and the
organizations message routing?
Answer: 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 LondonSiteVancouverSite-SanDiegoSite connection.

The LondonSite to ChennaiSite connection must have a higher cost than the LondonSiteTokyoSite-ChennaiSite connection.

The VancouverSite to TokyoSite connection must have a higher cost than the VancouverSiteLondonSite-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

VancouverSite to TokyoSite

The cost for the new site links must be 201 or higher, or the routes 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 email services will be very slow. As an alternative, you could propose upgrading the
network connection between Chennai and London, or between Chennai and Tokyo.

Question: If your recommended changes are implemented, how will messages flow between
the AD DS sites? Where will messages be queued in the event of a server or network
connection failure?
Answer: Message routing will flow as follows:

From San Diego: San Diego-Vancouver-London-Tokyo-Chennai

From Vancouver: Vancouver-London-Tokyo-Chennai, and Vancouver-San Diego

From London: London-Tokyo-Chennai, and London-Vancouver-San Diego

L5-50

Module 5: Planning and Deploying Message Transport in Microsoft Exchange Server 2010

From Tokyo: Tokyo-London-Vancouver-San Diego, and Tokyo-Chennai

From Chennai: Chennai-Tokyo-London-Vancouver-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.

Question: How did you design message routing to the Internet?

Answer: To save network bandwidth and to decrease the messages queued on the Hub
Transport server in London, install an Edge Transport server in Vancouver 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 email, the Edge Transport server could be configured to send email
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 mail exchanger (MX) resource records in the Adatum.com
zone with equal priorities. One MX record should be created for the TreyResearch.net
domain, and should use the Edge Transport server in Vancouver.
Question: What conflicting requirements were presented in the scenario? How did you
resolve conflicting requirements?
Answer: Conflict may result from resistance to changing the AD DS structure. If this arises,
emphasize the fact that creating the additional site links is the only way to meet message
routing requirements. Thus, you either have to change the requirements, or modify the AD
DS structure. Suggest that if you do not change the AD DS site link costs, AD DS 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 Microsoft Outlook Web App users
conflicts with the network administrators requirement to reduce firewall changes.
In particular, this will create a problem in Chennai. If Outlook Web App 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 App users from Chennai to London or Tokyo.

Significantly increase the bandwidth between Tokyo and Chennai, or between London and
Chennai.

Question: What additional information should you consider when designing message
routing in this scenario?
Answer: In a real-world scenario, an important additional piece of information that you need
is how many messages are sent between company locations. This may affect the design, and
in particular, this information may help to resolve some of the conflicting requirements.
Results: After this exercise, you should have successfully improved on the A. Datum AD DS and message
routing design.

Lab: Planning and Deploying Message Transport in Exchange Server 2010

L5-51

Exercise 4: Modifying the Routing Topology

Task 1: Determine the current organizational settings
1.

On VAN-EX1, click Start, point to All Programs, click Microsoft Exchange Server 2010, and then
click Exchange Management Console.

2.

In the navigation tree, expand Microsoft Exchange On-Premises, expand Organization

Configuration, click Hub Transport, and in the results pane, click the Send Connectors tab.
Question: Have any connectors been configured?
Answer: No

3.

Click the Edge Subscriptions tab.

Question: Has an Edge Subscription been defined?
Answer: No

Task 2: Examine the current routing topology

1.

In Exchange Management Console, click Toolbox, and then double-click Routing Log Viewer.

2.

In Routing Log Viewer, click the File menu, and then click Open log file.

3.

In the Open Routing Table Log File dialog box, click Browse server files.

4.

In the Open dialog box, double-click the most recently created file in the list.

5.

In Routing Log Viewer, on the Active Directory Sites & Routing Groups tab, expand Active
Directory sites.

6.

Expand Default-First-Site-Name.
Question: Is Default-First-Site-Name a hub site?
Answer: No

7.

Expand Servers.

8.

Under Servers, click the VAN-EX1.Adatum.com link.

Question: What is the AD DS cost of the link to VAN-EX1.Adatum.com?
Answer: 0

9.

Click the Send Connectors tab.

10. Expand Delivery agent connectors.

Question: What Send Connectors are listed?
Answer: The following Send Connector is listed: Text Messaging Delivery Agent Connector.
11. Click the Address Spaces tab.
12. Expand OTHER.
Question: What Address Spaces are listed?
Answer: The following Address Space is listed: MOBILE:*
13. Close Routing Log Viewer.

L5-52

Module 5: Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Task 3: Add a new accepted domain

1.

In Exchange Management Console, and in the navigation pane, click Organization Configuration.

2.

In Organization Configuration, click Hub Transport, and in the results pane, click the Accepted
Domains tab.

3.

In the Actions pane, click New Accepted Domain.

4.

In the New Accepted Domain Wizard, in the Name box, type Contoso.

5.

In the Accepted Domain box, type Contoso.com.

6.

Click External Relay Domain, and then click New.

7.

On the Completion page, click Finish.

Task 4: Configure a send connector to support the new accepted domain

1.

In the Actions pane, click New Send Connector.

2.

In the New Send Connector Wizard, in the Name box, type Contoso Connector.

3.

In the Select the intended use for this Send Connector list, click Partner, and then click Next.

4.

On the Address space page, click Add.

5.

In the SMTP Address Space dialog box, in the Address box, type Contoso.com.

6.

Select the Include all subdomains check box, in the Cost box, type 10, and then click OK.

7.

On the Address space page, click Next.

8.

On the Network settings page, click Next.

9.

On the Source Server page, click Next.

10. On the New Connector page, click New.

11. Click Finish.

Task 5: Update the default site configuration with Exchange Server-specific values
1.

Click Start, point to All Programs, click Microsoft Exchange Server 2010, and then click Exchange
Management Shell.

2.

At the Shell, type the following command, and then press Enter:
set-AdSite id Default-First-Site-Name HubSiteEnabled $true

3.

At the Shell, type the following command, and then press Enter:
set-AdSiteLink id DEFAULTIPSITELINK ExchangeCost 25

4.

Close the shell.

Task 6: Add an Edge subscription

1.

Switch to VAN-EDG.

2.

Click Start, point to All Programs, click Microsoft Exchange Server 2010, and then click Exchange
Management Shell.

Lab: Planning and Deploying Message Transport in Exchange Server 2010

3.

L5-53

At the Exchange Management Shell, type the following command, and then press Enter:
new-edgesubscription filename C:\EdgeSubscriptionExport.xml

4.

When prompted, type Y, and then press Enter.

5.

At the Exchange Management Shell, type the following command, and then press Enter:
copy c:\EdgeSubscriptionExport.xml \\VAN-EX1\c$

6.

Switch to the VAN-EX1 server.

7.

In the Exchange Management Console, in the Actions pane, click New Edge Subscription.

8.

In the New Edge Subscription Wizard, on the New Edge Subscription page, adjacent to the Active
Directory site box, click Browse.

9.

In the Select Active Directory Site dialog box, double-click Default-First-Site-Name.

10. On the New Edge Subscription page, adjacent to the Subscription file box, click Browse.
11. In the File name box, type C:\EdgeSubscriptionExport.xml, and then click Open.
12. On the New Edge Subscription page, click New.
13. When prompted, click Finish.
Note

You may receive a warning. This is expected.

Task 7: Review the updated topology

1.

In Exchange Management Console, click Toolbox, and then double-click Routing Log Viewer.

2.

In Routing Log Viewer, click the File menu, and then click Open log file.

3.

In the Open Routing Table Log File dialog box, click Browse server files.

4.

In the Open dialog box, double-click the most recent file in the list.

5.

In Routing Log Viewer, on the Active Directory Sites & Routing Groups tab, expand Active
Directory sites.

6.

Expand Default-First-Site-Name.
Question: Is Default-First-Site-Name a hub site?
Answer: Yes.

7.

Click the Send Connectors tab.

8.

Expand SMTP connectors.

Question: What SMTP Send Connectors are listed?
Answer: The following Send Connectors are listed:

9.

Contoso Connector

EdgeSync Default-First-Site-Name to Internet

EdgeSync Inbound to Default-First-Site-Name.

Click the Address Spaces tab.

L5-54

Module 5: Planning and Deploying Message Transport in Microsoft Exchange Server 2010

10. Expand SMTP.

Question: What SMTP Address Spaces are listed?
Answer: *; --; *.contoso.com.
11. Expand *.contoso.com, expand Connectors, and then expand Contoso Connector.
Question: What is the connector cost for the Contoso Connector?
Answer: 10
12. Close the Routing Log Viewer.
Results: After this exercise, you should have modified the message routing topology.

To prepare for the next module

When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the
following steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EDG. Close the virtual
machine connection windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then in the Actions pane, click Start.

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then in the
Actions pane, click Connect.
Note Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully started
before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10233B-VAN-EX1. Connect to the virtual
machine.

8.

Wait for 10233B-VAN-EX1 to start, and then start 10233B-VAN-CL1. Connect to the virtual machine.

L6-55

Module 6: Planning and Deploying Messaging Security

Lab: Planning and Deploying Messaging

Security
Exercise 1: Designing Message Security
Task 1: Review the A. Datum documentation

Review the contents of the Message Security Requirements section in the Security Requirements.doc.

Task 2: Modify the A. Datum Proposed Security Policies document with a proposed
message security plan

Complete the relevant section of the following document. In the document, provide:

The type of component you will need to configure.

The configuration details for each component.

A. Datum Proposed Security Policies

Document Reference Number: JC120310/1
Document Author
Date

Jason Carlson
12th March 2010

Message Security Components

Component type

Configuration details

Hub Transport rule

Adds a disclaimer to all messages sent to the Internet.

Apply to all users, and then configure an exception for members of the
Sales team.

Hub Transport rule

Adds a disclaimer to all messages sent to the Internet.

Apply to members of the Sales team.

Hub Transport rule

Block all messages with a Company Internal classification from being sent
to the Internet.
Send a response to users indicating they are not allowed to send messages
with this classification to the Internet.

Classification

Create a new classification named Strategic Acquisitions.

Hub Transport rule

Block messages with a classification of Strategic Acquisitions from being

sent to any user not on the Strategic Acquisitions team.

L6-56

Module 6: Planning and Deploying Messaging Security

(continued)
A. Datum Proposed Security Policies
Message Security Components
Component type

Configuration details

SMTP Send and

Receive connectors

Install a certificate trusted by Contoso Simple Mail Transfer Protocol (SMTP)

servers on the Edge Transport server that will be used to send and receive
email from Contoso, Ltd.
Configure a Receive connector that will accept connections only from the
Contoso SMTP servers IP address.
Configure a Send connector that will use the Contosos SMTP servers as a
smart host.
Configure an address space on the SMTP Send connector of Contoso.com.
Configure inbound and outbound Domain Security.

SMTP Send and

Receive connectors

Configure a Receive connector that will accept connections only from the
Brussels law firms SMTP servers IP address.
Configure a Send connector that will use the law firms SMTP server as a
smart host.
Configure an address space on the SMTP Send connector that matches the
domain name of the law firm.
Configure the security on the Send and Receive connector as externally
secured.

S/MIME
configuration for
Office Outlook

Install an Enterprise certification authority (CA) on a Windows Server

2008. Configure the CA as a subordinate server to a commercial CA by
obtaining a subordinate CA certificate.
Configure an Active Directory Group Policy object that will assign a
certificate to all users in the Active Directory forest.
Provide instructions for users to configure Secure/Multipurpose Internet
Mail Extensions (S/MIME) in Office Outlook.

Additional notes

Note

Be prepared to discuss your proposed design with the class.

Lab: Planning and Deploying Messaging Security

Task 3: Answer questions relating to the documentation

Note

Your instructor may perform this task as a discussion.

Question: How did you address the need to exchange secure email between A. Datum
Corporation and Contoso, Ltd.?
Answer: The design calls for the Domain Security solution to ensure that all email messages
are encrypted and connections are authenticated.
Question: Does your organization have a requirement for the Domain Security solution?
What barriers will there be to adopting this solution?
Answer: 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.
Results: After this exercise, you should have successfully designed message security for A Datum.

L6-57

L6-58

Module 6: Planning and Deploying Messaging Security

Exercise 2: Designing Antivirus and Anti-Spam Solutions

Task 1: Review the A. Datum Corporation documentation

Review the contents of the Virus and Spam Filtering Requirements in the Security Requirements.doc.

Task 2: Modify the A. Datum Proposed Security Policies document with a proposed
antivirus and anti-spam solution

Complete both the Anti-Spam and Antivirus Solution Components section of the following
document. In the document, provide:

The type of component you will need to configure.

The configuration details for each component.

A. Datum Proposed Security Policies

Document Reference Number: JC120310/2
Document Author
Date

Jason Carlson
12th March 2010

Anti-Spam Solution Components

Component type

Configuration details

Anti-spam software

Must be installed on each Edge Transport server that will accept incoming
email from the Internet.

IP Allow List provider

Configure the IP Allow List setting on the Edge Transport server to use the
IP Allow List provider.

IP Block List provider

Configure the IP Block List setting on the Edge Transport server to use the
IP Block List providers.

SMTP connectors

The messages from Contoso, Ltd will not be scanned for spam, because the
messages are Domain Secured. The messages from the law firm will not be
scanned for spam, because the messages will be treated as authenticated.

Content filter and

quarantine mailbox

In order to implement content filtering, but still ensure that not too many
false positives are filtered, configure a content filtering Quarantine mailbox,
and then regularly monitor the Quarantine mailbox for false positives.
Modify the content filter as required to reduce false positives.

Sender ID filtering

In order to reduce the number of messages with spoofed addresses, enable

Sender ID filtering. Configure the filter to mark all messages that do not
pass the Sender ID filter. Most of these messages will then be filtered by the
content filter.

Safelist aggregation

Implement edge synchronization between the Edge Transport server and

the Active Directory sites where inbound messages will be allowed. Then
implement safelist aggregation for all user mailboxes in the organization.

Blocked recipient lists

Add the SMTP addresses for all distribution lists with more than 200
members to the blocked recipients list on the Edge Transport servers.
Note: You can also configure the distribution list properties to accept
messages from only authenticated users.

Lab: Planning and Deploying Messaging Security

L6-59

(continued)
A. Datum Proposed Security Policies
Antivirus Solution Components
Component type

Configuration details

Antivirus software

Must be installed on each Edge Transport server that will accept incoming
email from the Internet, and on each Hub Transport server in the
organization.

Antivirus software

Must be installed on each client computer in the organization.

Antivirus stamping

The Hub Transport servers in the organization should be configured to not

scan any messages that have a valid antivirus stamp.
Edge Transport servers should scan all outbound and inbound messages,
whether the message has a valid antivirus stamp or not.

Antivirus update

Configure to automatically update the antivirus files on the Hub Transport

servers daily, and to update the antivirus files on the Edge Transport servers
every six hours.
On the Hub Transport servers, configure an alert if the files have not been
updated for two days. On the Edge Transport servers, configure an alert if
the files have not been updated for 12 hours.

Additional notes

Note

Be prepared to discuss your proposed design with the class.

Task 3: Answer questions relating to the documentation

Note

Your instructor may perform this task as a discussion.

Question: How did you design the antivirus and anti-spam solution for A. Datum
Corporation? How does this compare to the solution you would implement for your
organization?
Answer: Organizations will have varying requirements for designing the antivirus and antispam solutions.
Results: After this exercise, you should have successfully designed an antivirus and anti-spam strategy for
A Datum.

L6-60

Module 6: Planning and Deploying Messaging Security

Exercise 3: Implementing Message Security

Task 1: Create a new certificate template
1.

On VAN-DC1, click Start, in the Search box, type mmc, and then press Enter.

2.

On the File menu, click Add/Remove Snap-in.

3.

In the Add or Remove Snap-ins dialog box, in the Available snap-ins list, double-click Certificate
Templates, and then click OK.

4.

In the console tree, click Certificate Templates.

5.

In the details pane, right-click the User template, and then click Duplicate Template.

6.

In the Duplicate Template dialog box, click Windows Server 2003 Enterprise, and then click OK.

7.

In Properties of New Template dialog box, on the General tab, in the Template display name box,
type S/MIME Certificate.

8.

Click the Security tab.

9.

In the Group or user names list, click Domain Users (ADATUM\Domain Users).

10. In Permissions for Domain Users, under Allow, select the Enroll and Autoenroll check boxes, and
then click OK.
11. Close Console1, and do not save changes.

Task 2: Import the certificate template

1.

Click Start, point to Administrative Tools, and then click Certification Authority.

2.

In certsrv [Certification Authority (Local)], expand AdatumCA, and then click Certificate
Templates.

3.

Right-click Certificate Templates, point to New, and then click Certificate Template to Issue.

4.

In the Enable Certificate Templates dialog box, in the Name list, double-click S/MIME Certificate.

5.

Close certsrv [Certification Authority (Local)].

Task 3: Configure user certificate auto-enrollment

1.

Click Start, point to Administrative Tools, and then click Group Policy Management.

2.

If necessary, expand Forest: Adatum.com, expand Domains, expand Adatum.com, and then click
Default Domain Policy. Click OK to close the Group Policy Management Console prompt.

3.

Right-click Default Domain Policy, and then click Edit.

4.

In Group Policy Management Editor, expand User Configuration, expand Policies, expand Windows
Settings, expand Security Settings, and then click Public Key Policies.

5.

In the Object Type list, double-click Certificate Services Client Auto-Enrollment.

6.

In the Certificate Services Client Auto-Enrollment Properties dialog box, in the Configuration
Model list, click Enabled.

Lab: Planning and Deploying Messaging Security

L6-61

7.

In the Certificate Services Client Auto-Enrollment Properties dialog box, select both the Renew
expired certificates, update pending certificates, and remove revoked certificates and the
Update certificates that use certificate templates check boxes, and then click OK.

8.

Close Group Policy Management Editor, and then close Group Policy Management.

Task 4: Update the group policy on VAN-CL1

1.

Switch to VAN-CL1.

2.

Click Start, in the Search box, type cmd, and then press Enter.

3.

At the command prompt, type gpupdate /force, and then press Enter.

4.

Close the command prompt.

5.

Log off VAN-CL1.

Task 5: Verify the presence of the certificate for Scott

1.

Log on to VAN-CL1 using the following credentials:

User name: Scott

Password: Pa$$w0rd

Domain: Adatum

2.

Click Start, in the Search box, type mmc, and then press Enter.

3.

On the File menu, click Add/Remove Snap-in.

4.

In the Add or Remove Snap-ins dialog box, in the Available snap-ins list, double-click Certificates,
and then click OK.

5.

In the console tree, expand Certificate Current User, expand Personal, and then click Certificates.

6.

Verify the presence of a certificate based on the Secure/Multipurpose Internet Mail Extensions
(S/MIME) Certificate template, and then close Console1. Do not save settings.

Task 6: Configure Outlook for Scott

1.

Click Start, point to All Programs, click Microsoft Office, and then click Microsoft Outlook 2010.

2.

In the Outlook 2010 Startup Wizard, click Next.

3.

On the Email Accounts page, click Yes, and then click Next.

4.

On the Auto Account Setup page, click Next.

5.

When prompted, click Finish.

6.

In User Name dialog box, click OK.

7.

In the Welcome to the Microsoft Office 2010 wizard, click Dont make changes and then click OK.

8.

Close Microsoft Outlook.

9.

Log off.

L6-62

Module 6: Planning and Deploying Messaging Security

Task 7: Verify the presence of the certificate for Marcel

1.

Log on to VAN-CL1 using the following credentials:

User name: Marcel

Password: Pa$$w0rd

Domain: Adatum

2.

Click Start, in the Search box, type mmc, and then press Enter.

3.

On the File menu, click Add/Remove Snap-in.

4.

In the Add or Remove Snap-ins dialog box, in the Available snap-ins list, double-click Certificates,
and then click OK.

5.

In the console tree, expand Certificate Current User, expand Personal, and then click Certificates.

6.

Verify the presence of a certificate based on the S/MIME Certificate template, and then close
Console1. Do not save settings.

Task 8: Configure Outlook for Marcel

1.

Click Start, point to All Programs, click Microsoft Office, and then click Microsoft Outlook 2010.

2.

In the Outlook 2010 Startup Wizard, click Next.

3.

On the E-mail Accounts page, click Yes, and then click Next.

4.

On the Auto Account Setup page, click Next.

5.

When prompted, click Finish.

6.

In User Name dialog box, click OK.

7.

In the Welcome to the Microsoft Office 2010 wizard, click Dont make changes and then click OK.

Task 9: Send a signed and sealed message to Scott

1.

Click New E-mail.

2.

In the Untitled Message (HTML) dialog box, in the To box, type Scott, and then press the CTRL+K
keys.

3.

In the Subject box, type S/MIME Test.

4.

Click the Options tab.

5.

On the ribbon, expand More Options.

6.

In the Properties dialog box, click Security Settings.

7.

In the Security Properties dialog box, select the following check boxes, and then click OK:

Encrypt message contents and attachments

Add a digital signature to this message

Request S/MIME receipt for this message

8.

In the Properties dialog box, click Close, and then click Send.

9.

Close Microsoft Outlook.

10. Log off.

Lab: Planning and Deploying Messaging Security

L6-63

Task 10: Verify receipt of the secured message

1.

Log on to VAN-CL1 using the following credentials:

User name: Scott

Password: Pa$$w0rd

Domain: Adatum

2.

Click Start, point to All Programs, click Microsoft Office, and then click Microsoft Outlook 2010.

3.

Double-click the new message called S/MIME Test.

4.

In the message, click the padlock symbol. Read the information, and then click Close.

5.

In the message, click the symbol next to the padlock symbol. Read the information, and then click
Close.

Results: After this exercise, you should have successfully implemented some aspects of the messaging
security design for A Datum.

To prepare for the next module

When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the
following steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1 and 10233B-VAN-CL1. Close the virtual machine connection
windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then in the Actions pane, click Start.

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then in the
Actions pane, click Connect.
Note Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully started
before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10233B-VAN-EX1. Connect to the virtual machine.

L6-64

Module 6: Planning and Deploying Messaging Security

L7-65

Module 7: Planning and Deploying Messaging Compliance

Lab: Planning and Deploying Messaging

Compliance
Exercise 1: Planning a Message Transport Implementation
Task 1: Review the A. Datum documentation

Review the points related to message transport in the Exercise 1 scenario.

Task 2: Document the required configuration for message transport

Complete the following proposal document by answering the questions.

A. Datum Message Transport Plan
Document Reference Number: JC040417/1
Document Author
Date

Jason Carlson
15th Apr 2010

Requirement Overview
Determine how you will manage message transport.
Proposals
Question: Are transport rules required? If so, how should you configure them?
Answer: Yes. Four transport rules are required.
The first transport rule applies to Internet-delivered messages for the Sales group, and adds a
disclaimer to each email message.
The second transport rule applies to Internet-delivered messages for everyone except the Sales
group, and adds a disclaimer to each email message. An exception excludes members of the Sales
group.
The third transport rule applies to Internet-delivered messages with the Company Internal
classification, and blocks these messages.
The fourth transport rule applies to messages classified as Acquisitions Confidential. Exchange
Server blocks these messages if they are addressed to anyone other than the Strategic Acquisitions
team.
Question: Is message moderation required? If so, how should you configure it?
Answer: No. There are no requirements that indicate a need for message moderation.
Question: Are message classifications required? If so, how should you configure them?
Answer: Yes. You must create two classifications: Company Internal, and Strategic Acquisitions.
Note

Be prepared to discuss your proposed plan with the class.

Results: After this exercise, you should have created a message transport plan.

L7-66

Module 7: Planning and Deploying Messaging Compliance

Exercise 2: Planning a Message Journaling and Archiving Solution

Task 1: Review the A. Datum documentation

Review the following information:

Message Compliance Interview

Task 2: Answer questions related to the documentation

Note

Your instructor may perform this task as a discussion.

Question: In the Message Compliance Interview, what points are raised that impact your message
journaling and archiving plan?
Answer:

You must create personal archives to replace personal folders (PST) files.

Auditors must be able to prevent specific users from deleting messages and must be able to review
the saved messages for those users.

Auditors need to monitor and review messages sent to the Executives group.

Task 3: Document the required configuration for journaling and archiving

Complete the following proposal document by answering the questions.

A. Datum Journaling and Archiving Plan
Document Reference Number: JC040417/2
Document Author
Date

Jason Carlson
15th Apr 2010

Requirement Overview
Determine how you will configure journaling and archiving.
Proposals
Question: Are personal archives required?
Answer: Yes. That is an explicit requirement.
Question: Should you remove PST files?
Answer: Yes. PST files are a management problem. You should prevent users from creating new
PST files, and you should provide them with instructions about how to move the content from PST
files to personal archives.
Question: How can users access personal archives? Does this affect which users will receive
personal archives usage?
Answer: Users can access personal archives by using the Microsoft Office Outlook 2010
messaging client, Office Outlook 2007, or Microsoft Outlook Web App. You may want to enable
personal archives only after users upgrade to a version of Outlook that supports personal archives.

Lab: Planning and Deploying Messaging Compliance

L7-67

(continued)
A. Datum Journaling and Archiving Plan
Question: Is journaling required? If so, how should you configure it?
Answer: Yes. The Executives group requires journaling. You can create a journal rule for messages
sent to this group.
Question: How can you prevent users from deleting messages?
Answer: Enable mailboxes with litigation holds to prevent the mailbox owners from deleting
messages.
Question: Can auditors prevent users from deleting messages?
Answer: Yes. You can assign auditors to the Legal Hold management role. The auditors can then
enable a litigation hold on a mailbox-by-mailbox basis.
Note

Be prepared to discuss your proposed plan with the class.

Results: After this exercise, you should have created a journaling and archiving plan.

L7-68

Module 7: Planning and Deploying Messaging Compliance

Exercise 3: Planning a Messaging Records Management Implementation

Task 1: Review the A. Datum documentation

Review the following information:

Message Compliance Interview

Task 2: Answer questions related to the documentation

Note

Your instructor may perform this task as a discussion.

Question: In the Message Compliance Interview, what points are raised that impact your MRM plan?
Answer:

Archiving should affect only Exchange Server 2010 mailboxes.

Archive all messages after one year.

Archive deleted items after 30 days.

Allow users to mark individual items not to be archived.

Task 3: Document the required MRM configuration

Complete the following proposal document by answering the questions.

A. Datum Messaging Records Management Plan
Document Reference Number: JC040417/3
Document Author
Date

Jason Carlson
15th Apr 2010

Requirement Overview
Determine how you will implement MRM.
Proposals
Question: Will you use managed folder policies for MRM? If so, how should you configure them?
Answer: No, you will not use managed folder policies, because there are no requirements for them.
Managed folder policies cannot archive messages.
Question: Will you use retention policies for MRM? If so, how should you configure them?
Answer: Yes, you will use retention policies, because you can meet all of the requirements by using
them. The retention policies apply if a mailbox is on Exchange Server 2010.
Create one retention policy, in which the:
Default policy tag archives messages after one year.
Archive policy tag removes deleted items after 30 days.
Personal tag allows items to not be archived.
Apply the retention policy to all mailboxes on the Exchange Server 2010 Mailbox servers.
Note

Be prepared to discuss your proposed plan with the class.

Results: After this exercise, you should have created an MRM plan.

Lab: Planning and Deploying Messaging Compliance

L7-69

Exercise 4: Implementing a Message Compliance Plan

Task 1: Prevent Company Internal classification messages from being sent to the
Internet
1.

On VAN-EX1, click Start, point to All Programs, click Microsoft Exchange Server 2010, and then
click Exchange Management Shell.

2.

At the shell, type the following command, and then press ENTER:
New-MessageClassification -name Company Internal DisplayName Company Internal
-DisplayPrecedence Highest -RetainClassificationEnabled $true
-SenderDescription This message is for internal distribution only; it will not be
forwarded on to the Internet

3.

At the shell, type the following command, and then press ENTER:
New-SystemMessage DsnCode 5.7.999 Text Internal recipients only
Internal $True Language En

4.

Click Start, point to All Programs, click Microsoft Exchange Server 2010, and then click Exchange
Management Console.

5.

Expand Microsoft Exchange On-Premises (van-ex1.adatum.com), and then expand Organization

Configuration.

6.

Click the Hub Transport node, and then, in the Actions pane, click New Transport Rule.

7.

In the New Transport Rule Wizard, on the Introduction page, in the Name box, type Company
Internal Rule, and then click Next.

8.

On the Conditions page, in the Step 1: Select condition(s) list, select the sent to users that are
inside or outside the organization, or partners check box.

9.

In the Step 2: Edit the rule description by clicking an underlined value box, click Inside the
organization.

10. In the Scope list, click Outside the organization, and then click OK.
11. In the Step 1: Select condition(s) list, select the marked with classification check box.
12. In the Step 2: Edit the rule description by clicking an underlined value box, click classification.
13. In the Select message classification window, click Company Internal, and then click OK.
14. On the Conditions page, click Next.
15. On the Actions page, in the Step 1: Select actions list, select the send rejection message to sender
with enhanced status code check box.
16. In the Step 2: Edit the rule description by clicking an underlined value box, click rejection
message.
17. In the Specify rejection message dialog box, in the Bounce message box, type Messages
classified as Company Internal cannot be sent to the Internet, and then click OK.
18. In the Step 2: Edit the rule description by clicking an underlined value box, click enhanced
status code.
19. In the Specify Enhanced Status Code dialog box, in the text box, type 5.7.999, and then click OK.

L7-70

Module 7: Planning and Deploying Messaging Compliance

20. On the Actions page, click Next.

21. On the Exceptions page, click Next.
22. On the Create Rule page, click New.
23. On the Completion page, click Finish.

Task 2: Test the classification rules

1.

On VAN-EX1, click Start, point to All Programs and then click Internet Explorer.

2.

In the address bar for the Microsoft Internet Explorer browser, type
https://van-ex1.adatum.com/owa, and then press ENTER.

3.

Click This is a private computer.

4.

In the Domain\user name box, type adatum\paul.

5.

In the Password box, type Pa$$w0rd, and then click Sign in.

6.

On the Language page, click OK.

7.

In Outlook Web App, click New.

8.

In the To box, type [email protected].

9.

In the Subject box, type Company financial results.

10. In the menu bar, click the Permission button, and then click Company Internal.
11. Click Send.
12. After a moment, click the new message.
Question: Was the delivery successful?
Answer: No.
13. Scroll through the message.
Question: What error do you see?
Answer: #550 5.7.999 Messages classified as Company Internal cannot be sent to the Internet # #
14. Close Internet Explorer.

Task 3: Enable personal archives for all mailboxes in Mailbox Database 1

1.

ON VAN-EX1, in the Exchange Management Console, expand Recipient Configuration, and then
click Mailbox.

2.

In the Mailbox Entire Forest pane, click Create Filter.

3.

Configure the filter as Database Equals Mailbox Database 1, and then click Apply Filter.

4.

Select all visible mailboxes by using SHIFT+click.

5.

Right-click the selected mailboxes, and then click Enable Archive.

6.

In the Enable Archive Mailbox window, click Create a local archive.

7.

Select the Select a specific mailbox database rather than having on selected automatically
check box.

Lab: Planning and Deploying Messaging Compliance

8.

Click the Browse button, click Mailbox Database 1, and then click OK.

9.

In the Enable Archive Mailbox window, click OK.

L7-71

10. In the warning window, click Yes.

Task 4: Review the default policy tags and retention policies

1.

In the Exchange Management Console, in Organization Configuration, click Mailbox.

2.

Click the Retention Policy Tags tab, and then read the list of retention policy tags.

3.

Click the Retention Policies tab, and then double-click Default Archive and Retention Policy.

4.

In the Default Archive and Retention Policy Properties window, on the General tab, review the list
of retention policy tags that are part of this policy.

5.

Click the Mailboxes tab, and then review the list of mailboxes that this retention policy is applied to.

6.

Click Cancel.

Task 5: Create the Standard Mailbox Retention Policy

1.

On VAN-EX1, in the Exchange Management Console, in the Actions pane, click New Retention
Policy Tag.

2.

In the New Retention Policy Tag Wizard, on the Introduction page, enter the following, and then
click New:

Tag Name: Default 1 year archive

Tag Type: All other folders in the mailbox

Age Limit for retention (days): 365

Action to take when the age limit is reached: Move To Archive

Comment: Archive messages after 1 year

3.

On the Completion page, click Finish.

4.

In the Actions pane, click New Retention Policy Tag.

5.

In the New Retention Policy Tag Wizard, on the Introduction page, enter the following, and then
click New:

Tag Name: Deleted Items 30 day removal

Tag Type: Deleted Items

Age Limit for retention (days): 30

Action to take when the age limit is reached: Delete and Allow Recovery

Comment: Remove deleted items after 30 days

6.

On the Completion page, click Finish.

7.

In the Actions pane, click New Retention Policy.

8.

In the New Retention Policy Wizard, on the Introduction page, in the Name box, type Standard
Mailbox Retention Policy.

9.

Click Add, click Default 1 year archive, and then click OK.

L7-72

Module 7: Planning and Deploying Messaging Compliance

10. Click Add, click Deleted Items 30 day removal, and then click OK.
11. Click Next.
12. On the Select Mailboxes page, click Next.
13. On the New Retention Policy page, click New.
14. On the Completion page, click Finish.

Task 6: Apply the retention policy to the mailboxes in Mailbox Database 1

1.

On VAN-EX1, in the Exchange Management Console, in Recipient Configuration, click Mailbox.

Notice that the filter for Mailbox Database 1 is still applied.

2.

Click Add Expression.

3.

Configure the new expression as Recipient Details Does Not Equal Discovery Mailbox, and then
click Apply Filter.

4.

Select all visible mailboxes by using SHIFT+click.

5.

Right-click the selected mailboxes, and then click Properties.

6.

In the User Mailbox Properties window, click the Mailbox Settings tab.

7.

On the Mailbox Settings tab, click Messaging Records Management, and then click Properties.

8.

In the Messaging Records Management window, select the Apply Retention Policy check box.

9.

Click Browse, click Standard Mailbox Retention Policy, and then click OK.

10. In the Messaging Records Management window, click OK.

11. In the User Mailbox Properties window, click OK.
12. In the Bulk Edit Summary window, click OK.
13. Click Paul West, and then click Properties.
14. In the Paul West Properties window, click the Mailbox Settings tab, and then double-click
Messaging Records Management.
15. In the Messaging Records Management window, confirm that the Standard Mailbox Retention
Policy is applied, and then click Cancel.
16. In the Paul West Properties window, click Cancel.
Results: After this exercise, you should have prevented messages classified as Company Internal from
being sent to the Internet, created a retention policy, and applied it to all of the mailboxes in Mailbox
Database 1.

To prepare for the next module

When you finish the lab, revert the machines to their initial state. To do this, complete the following steps:
1.

On the host computer, start the Microsoft Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

Lab: Planning and Deploying Messaging Compliance

L7-73

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3. Close the virtual
machine connection windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then, in the Actions pane, click Start.

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then, in the
Actions pane, click Connect.
Important: Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully
started before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10223B-VAN-EX1. Connect to the virtual machine.

8.

Wait for 10233B-VAN-EX1 to start, and then start 10223B-VAN-EX2. Connect to the virtual machine.

9.

Wait for 10233B-VAN-EX2 to start, and then start 10223B-VAN-EX3. Connect to the virtual machine.

L7-74

Module 7: Planning and Deploying Messaging Compliance

L8-75

Module 8: Planning and Deploying High Availability

Lab: Planning and Deploying High

Availability
Exercise 1: Designing High Availability for Exchange Servers
Task 1: Review the A. Datum Corporation documentation

Review the following information:

High Availability Interviews

User Distribution Summary

Network Configuration

Task 2: Answer questions related to the documentation

Note

Your instructor may perform this task as a discussion.

Question: In the High Availability Interviews, what points are raised that impact your high availability
design, and how do they impact it?
Answer: The High Availability Interviews raises the following points:

The Chief Information Officer (CIO) wants all locations to be highly available. A single server failure
should not affect functionality. This means that all server roles in all locations must be highly
available.

There is limited bandwidth on the wide area network (WAN) links. The WAN links may need to be
upgraded if transaction logs are replicated across them.

The major sites with more than 3,000 users should be configured with an alternate site for disaster
recovery. The alternate site for disaster recovery should be in a different city, in case of a major
infrastructure problem.

The major sites are using dedicated mailbox servers. Any restrictions caused by combining roles do
not apply in the major sites.

Existing Mailbox servers are at capacity, and should not be used to host passive database copies. The
major sites require additional Mailbox servers specifically for hosting failed-over databases.

Smaller sites will be highly available only within the site.

Smaller sites are currently supported by only a single server with combined roles. An additional server
must be added to support high availability.

Logical corruption should be prevented for 6 hours in each database availability group (DAG). There
should be one lagged copy in each DAG with a 6 hour delay.

L8-76

Module 8: Planning and Deploying High Availability

Question: Is there anything in the User Distribution Summary that raises high availability issues? If so,
what is it?
Answer: The User Distribution Summary raises the following points:

It provides information about the number of users in each site. These figures are used to determine
whether offsite disaster recovery is required.

Question: Is there anything in the Network Configuration that raises high availability issues? If so, what is
it?
Answer: The Network Configuration raises the following points:

All sites except for LondonSite2 have a connection to the Internet. All sites with a connection to the
Internet have Edge Transport servers.

SanDiegoSite does not allow inbound traffic to Client Access servers. Access to the SanDiego Client
Access servers will be proxied through other sites.

Task 3: Document the required configuration for the San Diego site

Complete the following proposal document by answering the questions.

A. Datum High Availability Design for San Diego
Document Reference Number: JC040422/1
Document Author
Date

Jason Carlson
24th April 2010

Requirement Overview
Determine how high availability will be provided for all server roles in San Diego.
Additional Information
Identify infrastructure changes that may be required due to the proposed deployment.
Proposals
Question: Will this site have offsite disaster recovery? If so, where should that site be located?
Answer: No, this is a small site with only 500 users. Offsite disaster recovery is not part of the
requirements.
Question: How do you provide high availability for databases?
Answer: Provide high availability by creating a DAG.
Question: How do you provide high availability for Client Access servers?
Answer: Provide high availability by creating a client access array.
Question: How do you provide high availability for message transport?
Answer: Provide high availability by installing a second Hub Transport server.
Question: Is high availability required for the Edge Transport server role?
Answer: Yes, outgoing mail is routed through a local Edge Transport server. To make it highly
available, there should be two Edge Transport servers in the San Diego site.

Lab: Planning and Deploying High Availability

L8-77

(continued)
A. Datum High Availability Design for San Diego
Question: How many Exchange servers will be located in this site? Which roles will they host?
Answer: There will be four servers, and in the perimeter network there will be two Edge Transport
servers.
On the internal network, there will be two Exchange servers. Each Exchange server on the internal
network will have the Mailbox, Hub Transport, and Client Access server roles.
Question: How will databases be configured on the DAG members?
Answer: Half of the active databases will be located on each server, with passive copies on the
other server. Even though a single server has the capacity to support all mailboxes, splitting the
load may improve performance.
Each passive database copy will be configured with a 6-hour replay lag to prevent logical
corruption of both databases.
Question: How will load balancing be performed for the Client Access server role?
Answer: Hardware load balancing must be used, because DAG members cannot be part of a
Network Load Balancing (NLB) cluster.
Question: Is any additional configuration required for the Hub Transport server role?
Answer: No, you can achieve high availability just by having two Hub Transport servers.

Task 4: Document the required configuration for the Vancouver site

Complete the following proposal document by answering the questions.

A. Datum High Availability Design for Vancouver
Document Reference Number: JC040422/2
Document Author
Date

Jason Carlson
24th April 2010

Requirement Overview
Determine how high availability will be provided for all server roles in Vancouver.
Additional Information
Identify infrastructure changes that may be required due to the proposed deployment.
Proposals
Question: Will this site have offsite disaster recovery? If so, where should that site be located?
Answer: Yes, this is a large site with 5,000 users. Offsite disaster recovery is required.
To reduce the cost of network connectivity, the offsite disaster recovery should be located in North
America. The San Diego site can be used for offsite disaster recovery. Network links to San Diego
from Vancouver may need to be improved with increased bandwidth for communication.
Question: How do you provide high availability for databases?
Answer: Provide high availability by creating a DAG, which will include a server in San Diego for
offsite disaster recovery.

L8-78

Module 8: Planning and Deploying High Availability

(continued)
A. Datum High Availability Design for Vancouver
Question: How do you provide high availability for Client Access servers?
Answer: Provide high availability by creating a client access array in Vancouver. The client access
array in San Diego can be used when offsite disaster recovery is performed.
Question: How do you provide high availability for message transport?
Answer: Provide high availability by installing a second Hub Transport server in Vancouver. The
Hub Transport servers in San Diego will be used when offsite disaster recovery is performed.
Question: Is high availability required for the Edge Transport server role?
Answer: Yes, incoming and outgoing mail is routed through a local Edge Transport server. To make
it highly available, there should be two Edge Transport servers in the San Diego site.
Question: How many Exchange servers will be located in this site? Which roles will they host?
Answer: In the perimeter network, there will be two Edge Transport servers.
On the internal network there will be:
Two dedicated Hub Transport servers to provide high availability for message transport
within the site and between sites.
Three dedicated Client Access servers in a client access array. This ensures that even if a
Client Access server fails, there is sufficient capacity to support all users.
Three mailbox servers in Vancouver, and two additional Mailbox servers in San Diego. To
support the 6,000 users in Vancouver, two Mailbox servers are required. To provide high
availability in Vancouver, a third server is required. To provide site resilience, two Mailbox
servers are located in San Diego.
Question: How will databases be configured on the DAG members?
Answer: One third of the active databases will be located on each server, with passive copies on
another local server, and on a server in San Diego. Evenly spreading the load in Vancouver can
increase performance. In San Diego, two servers provide sufficient capacity to host all mailboxes, if
required.
Each passive database copy in San Diego will be configured with a 6-hour replay lag to prevent
logical corruption of the databases. Logical corruption is a very rare event. So, there will be no
replay lag for passive database copies in Vancouver.
Question: How will load balancing be performed for the Client Access server role?
Answer: The Client Access server role is not combined with the Mailbox server role. Therefore, NLB
can be used. It is also possible to use hardware load balancing, if desired.

Note

Be prepared to discuss your proposed design with the class.

Lab: Planning and Deploying High Availability

L8-79

Exercise 2: Implementing High Availability for Exchange Servers

Task 1: Prepare VAN-DC1 to be a DAG witness server
1.

On VAN-DC1, click Start, point to Administrative Tools, and then click Active Directory Users and
Computers.

2.

In Active Directory Users and Computers, expand Adatum.com, and then click Builtin.

3.

Right-click Administrators, and then click Properties.

4.

In the Administrators Properties window, on the Members tab, click Add.

5.

In the Enter the object names to select box, type Exchange Trusted Subsystem, and then click
OK.

6.

In the Administrators Properties window, click OK.

7.

Close Active Directory Users and Computers.

Task 2: Create a three-member DAG

1.

On VAN-EX3, click Start, point to All Programs, click Microsoft Exchange Server 2010, and then
click Exchange Management Console.

2.

In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand

Organization Configuration, and then click Mailbox.

3.

Click the Database Availability Groups tab.

4.

In the Actions pane, click New Database Availability Group.

5.

In the New Database Availability Group window, in the Database availability group name box,
type VancouverDAG.

6.

Select the Witness Server check box, and then type VAN-DC1.

7.

Select the Witness Directory check box, type C:\VanDAGWitness, and then click New.
Note Step 7 will generate a warning, because the witness server is not an Exchange Server.
This does not indicate a problem. The necessary permissions were configured in Task 1.

8.

On the Completion page, click Finish.

9.

In the Exchange Management Console, right-click VancouverDAG, and then click Properties.

10. In the VancouverDAG Properties window, click the IP Addresses tab.

11. On the IP Addresses tab, click Add.
12. In the Add database availability group IP address(es) window, type 10.10.0.200 and click OK.
13. In the VancouverDAG Properties window, click OK.
Note Step 13 generates a warning, because the witness server is not an Exchange server.
This does not indicate a problem.
14. Open the properties of VancouverDAG, and then add 10.10.0.200 as an IP address for the DAG.
15. In the Microsoft Exchange Warning window, click OK.

L8-80

Module 8: Planning and Deploying High Availability

16. In the Exchange Management Console, right-click VancouverDAG, and then click Manage Database
Availability Group Membership.
17. In the Manage Database Availability Group Membership window, click Add.
18. In the Select Mailbox Server window, press the CTRL key while clicking to select VAN-EX1, VANEX2, and VAN-EX3, and then click OK.
19. In the Manage Database Availability Group Membership window, click Manage.
20. On the Completion page, click Finish.

Task 3: Configure replication for Mailbox Database 1

1.

On VAN-EX3, in the Exchange Management Console, click the Database Management tab, and then
click Mailbox Database 1.

2.

In the Actions pane, under Mailbox Database 1, click Add Mailbox Database Copy.

3.

In the Add Mailbox Database Copy window, click the Browse button.

4.

In the Select Mailbox Server window, click VAN-EX2, and then click OK.

5.

In the Add Mailbox Database Copy window, click Add.

6.

On the Completion page, click Finish.

7.

In the Actions pane, under Mailbox Database 1, click Add Mailbox Database Copy.

8.

In the Add Mailbox Database Copy window, click the Browse button.

9.

In the Select Mailbox Server window, click VAN-EX3, and then click OK.

10. In the Add Mailbox Database Copy window, click Add.

11. On the Completion page, click Finish.
12. Click Start, point to All Programs, click Microsoft Exchange Server 2010, and then click Exchange
Management Shell.
13. In the Exchange Management Shell, type the following command, and then press ENTER:
Set-MailboxDatabaseCopy Identity Mailbox Database 1\VAN-EX3 ReplayLagTime 0.6:0:0

14. In the Exchange Management Shell, type the following command, and then press ENTER:
Get-MailboxDatabase Mailbox Database 1 | Format-List ReplayLagTimes

15. In the Exchange Management Shell, type the following command, and then press ENTER:
Get-MailboxDatabaseCopyStatus Identity Mailbox Database 1\VAN-EX3

Lab: Planning and Deploying High Availability

L8-81

Task 4: Simulate the failure of VAN-EX1

1.

On the host computer, in the 10233B-VAN-EX1 window, click the Action menu, and then click Turn
Off.

2.

In the Turn Off Machine window, click Turn Off.

3.

On VAN-EX3, in the Exchange Management Console, in the Actions menu, click Refresh.

4.

If any database copy has a status of Disconnected, click Refresh again.

Question: What is the status for Mailbox Database 1 on each server?
Answer: The status for Mailbox Database 1 on each server is as follows:

VAN-EX1: ServiceDown

VAN-EX2: Mounted

VAN-EX3: Healthy

Question: Why is the server where the database is mounted selected?

Answer: The database on VAN-EX3 is a lagged copy. During a failover, a non-lagged copy is
selected over a lagged copy.

Task 5: Recover VAN-EX1

1.

On the host computer, in the 10233B-VAN-EX1 window, click the Action menu, and then click Start.

2.

On VAN-EX1, select Start Windows Normally, and then press ENTER.

3.

Wait a few minutes for VAN-EX1 to start.

4.

On VAN-EX3, in the Exchange Management Console, in the Actions menu, click Refresh.
Question: What is the status for Mailbox Database 1 on each server?
Answer: The status for Mailbox Database 1 on each server is as follows:

5.

VAN-EX1: Healthy

VAN-EX2: Mounted

VAN-EX3: Healthy

If the status of Mailbox Database 1 on VAN-EX1 is initializing, wait a few minutes, and then click
Refresh again. You may need to select Mailbox Database 1 on VAN-EX1 to refresh its status.

L8-82

Module 8: Planning and Deploying High Availability

To prepare for the next module

When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the
following steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3. Close the virtual
machine connection windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then, in the Actions pane, click Start.

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then, in the
Actions pane, click Connect.
Important Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully
started before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10233B-VAN-EX1. Connect to the virtual machine.

8.

Wait for 10233B-VAN-EX1 to start, and then start 10233B-VAN-CL1. Connect to the virtual machine.

L9-83

Module 9: Planning a Disaster Recovery Solution

Lab: Planning a Disaster Recovery Solution

Exercise 1: Planning Disaster Recovery for Vancouver
Task 1: Review the A. Datum documentation

In the Exercise 1 scenario, review the Disaster Recovery SLA Notes.

Task 2: Answer questions related to the documentation

Question: In the Disaster Recovery SLA Notes, what points are raised that impact your
disaster recovery plan for Vancouver?
Answer:

There can be no data loss due to the failure of a single server.

The failure of a single server should result in only minutes of downtime for users.

You can consider high availability as a replacement for backup if there are at least two local
copies of a database, and a remote database copy in another site.

To consider high availability as a replacement for backup, you must have one database copy that
is unaffected by logical corruption in another database copy for at least 12 hours.

Any message deleted by a user must be recoverable for 30 days.

Deleted mailboxes must be recoverable for 60 days.

Task 3: Document the required configuration for the Vancouver site

Complete the following proposal document by answering the questions.

A. Datum Disaster Recovery Plan for Vancouver
Document Reference Number: JC040430/1
Document Author
Date

Jason Carlson
5th May 2010

Requirement Overview
Determine how disaster recovery will be provided for all server roles in Vancouver.
Proposals
Question: Does this site require backups?
Answer: No. According to the service level agreement (SLA) requirements, you do not need to back
up a database availability group (DAG) with three copies, including site resilience. A three-member
DAG meets the requirement for no data loss when a single server fails. It also meets the
requirement for only minutes of downtime.
Question: Do you need to make any changes to the DAG to meet the SLA requirements?
Answer: Yes. The database copies in San Diego have only a 6-hour replay lag. The SLA specifies
that to use a DAG as a replacement for backup, you must have at least a 12-hour replay lag. A
longer replay lag provides more time to discover a corruption, and to stop the replay process.

L9-84

Module 9: Planning a Disaster Recovery Solution

(continued)
A. Datum Disaster Recovery Plan for Vancouver
Question: Are any changes required for deleted item retention?
Answer: Yes. The default retention time for deleted items is 14 days. The SLA specifies that you
must increase deleted-item retention to retain messages for 30 days. Also, you should enable
single-instance recovery on the Mailbox servers. This ensures that you can recover even harddeleted messages for the full 30 days.
Question: Are any changes required for deleted mailbox retention?
Answer: Yes. The default retention time for deleted mailboxes is 30 days. The SLA specifies that you
must increase deleted-mailbox retention to 60 days.
Question: Do you need to back up data on Client Access servers?
Answer: No, you do not need to back up each Client Access server. However, you do need to
document your configuration changes. If a Client Access server fails, you can replace it with a new
one, and then make the required configuration changes. You can copy customized webpages from
a remaining server, but it would be easier to have a copy of those pages stored elsewhere so that
you can easily restore them.
Question: Do you need to back up data on Hub Transport servers?
Answer: No. All Hub Transport configuration data is stored in Active Directory Domain Services
(AD DS), including the customized Receive connectors. When replacing a failed Hub Transport
server, reuse the same computer account to retain the configuration by installing in Recovery
mode.
Question: Do you need to back up data on Edge Transport servers?
Answer: No. There are two Edge Transport servers, so, you can export the configuration data from
the remaining server, and then import it to the new server. However, to speed up this process, you
could have a copy of the configuration data already exported and waiting for recovery.
Question: Would your backup plan change if public folders were present in Vancouver?
Answer: It depends on the type of data that is stored in the public folders. If the public folders
were being used only to support free/busy searches and offline address book downloads for
Microsoft Office Outlook 2003 clients, then a backup is not required. You can regenerate that
data. If the public folders are used for collaboration between users, then they do need to be backed
up, because public folder databases are not replicated in a DAG.

Note

Be prepared to discuss your proposed plan with the class.

Results: After this exercise, you should have created a disaster recovery plan for the Vancouver site.

Lab: Planning a Disaster Recovery Solution

L9-85

Exercise 2: Planning Disaster Recovery for San Diego

Task 1: Review the A. Datum documentation

Review the following information:

Disaster Recovery SLA Notes

Task 2: Answer questions related to the documentation

Question: In the Disaster Recovery SLA Notes document, what points are raised that impact
your disaster recovery plan for San Diego?
Answer:

There can be no data loss due to the failure of a single server.

The failure of a single server should result in only minutes of downtime for users.

You can consider high availability as a replacement for backup if there are at least two local
copies of a database, and a remote database copy in another site.

Any message deleted by a user must be recoverable for 30 days.

Deleted mailboxes must be recoverable for 60 days.

Messaging functionality must be recoverable within one hour. You can recover historical data up
to 24 hours later.

When recovering data from a backup, the maximum allowable data loss is four hours.

Any location that is not configured with site resilience must archive backups offsite for one week.

L9-86

Module 9: Planning a Disaster Recovery Solution

Task 3: Document the required configuration for the San Diego site

Complete the following proposal document by answering the questions.

A. Datum Disaster Recovery Plan for San Diego
Document Reference Number: JC040430/1
Document Author
Date

Jason Carlson
5th May 2010

Requirement Overview
Determine how disaster recovery will be provided for all server roles in San Diego.
Proposals
Question: Does this site require backups? If so, how will you perform backups?
Answer: Yes, the site requires backups, because the DAG does not have site resilience. Therefore,
you must perform a backup for mailbox databases. The two-member DAG will mean that the
backup is seldom required.
A disk-based backup solution is the most efficient way to perform backups. The data loss
requirements mean that a backup must be performed every four hours. If you use a disk-based
backup solutionsuch as Microsoft System Center Data Protection Managerthen each backup
will finish very quickly.
To meet the archive requirements, you must back up to tape once a week for offsite storage.
Question: Do you need to make any changes to the DAG to meet the SLA requirements?
Answer: No, this DAG does not require replay as part of the SLA, because a backup is being
performed.
Question: Are any changes required for deleted-item retention?
Answer: Yes. The default retention time for deleted items is 14 days. The SLA specifies that deleteditem retention must be increased to retain messages for 30 days. Also, you should enable singleinstance recovery on the Mailbox servers. This ensures that you can recover even hard-deleted
messages for 30 days.
Question: Are any changes required for deleted mailbox retention?
Answer: Yes. The default retention time for deleted mailboxes is 30 days. The SLA specifies that you
must increase deleted mailbox retention to 60 days.
Question: How will you meet the recovery requirement of one hour?
Answer: If a server or database fails, you can use dial-tone recovery to quickly restore basic
messaging functionality. Next, you can restore historical data to a recovery database, and merge
the historical data into the dial-tone database.
Question: Would your backup plan change if public folders were present in San Diego?
Answer: No, backups are already being performed.
Note

Be prepared to discuss your proposed plan with the class.

Results: After this exercise, you should have created a disaster recovery plan for the San Diego site.

Lab: Planning a Disaster Recovery Solution

L9-87

Exercise 3: Implementing Single-Item Recovery

Task 1: Enable single-item recovery for a mailbox
1.

On VAN-EX1, click Start, point to All Programs, click Microsoft Exchange Server 2010, and then
click Exchange Management Console.

2.

In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand

Organization Configuration, and then click Mailbox.

3.

On the Database Management tab, right-click Mailbox Database 1, and then click Properties.

4.

In the Mailbox Database 1 Properties window, click the Limits tab.

5.

In the Keep deleted items for (days) box, type 30.

6.

In the Keep deleted mailboxes for (days) box, type 60, and then click OK.

7.

Click Start, point to All Programs, click Microsoft Exchange Server 2010, and then click Exchange
Management Shell.

8.

In Exchange Management Shell, type the following command, and then press ENTER:
Set-Mailbox Luca SingleItemRecoveryEnabled $true

Task 2: Configure a user for message recovery

1.

On VAN-CL1, if necessary, log off, and then log on as Luca using the password Pa$$w0rd.

2.

On the taskbar, click Internet Explorer.

3.

In the Address bar of the Microsoft Internet Explorer browser, type

https://van-ex1.adatum.com/owa, and then press ENTER.

4.

Log on as Adatum\Administrator using the password Pa$$w0rd.

5.

Click OK to accept the default time zone.

6.

Click Options, and then click See All Options.

7.

Click Manage Myself, and then click My Organization.

8.

Click Roles & Auditing, and then click the Administrator Roles tab.

9.

Click the Discovery Management role group, and then click Details.

10. In the Role Group window, scroll to Members, click Add, double-click Andreas Herbinger, and then
click OK.
11. Click Save.
12. Close Internet Explorer.

Task 3: Delete and purge a message

1.

On VAN-CL1, click Start, point to All Programs, click Microsoft Office, and then click Microsoft
Outlook 2010.

2.

Click New E-mail to create a new message.

L9-88

Module 9: Planning a Disaster Recovery Solution

3.

In the Untitled Message (HTML) window, type the following, and then click Send:

To: Luca

Subject: Test of SIR

4.

In the Inbox, right-click the Test of SIR message, and then click Delete.

5.

Click the Deleted Items folder.

6.

Right-click the Test of SIR message, and then click Delete.

7.

Click Yes to permanently delete the item.

8.

Click the Folder tab, and then click Recover Deleted Items.

9.

In the Recover Deleted Items From Deleted Items window, click Test of SIR, and then click the X
to purge the message.

10. Click OK to confirm purging the message.

Task 4: Locate a recoverable message

1.

On VAN-CL1, on the taskbar, click Internet Explorer.

2.

In the Address bar, type https://van-ex1.adatum.com/owa, and then press ENTER.

3.

Log on as Adatum\Andreas using the password Pa$$w0rd.

4.

Click OK to accept the default time zone.

5.

Click Options, and then click See All Options.

6.

Click Manage Myself, and then click My Organization.

7.

Click Mail Control.

8.

In Multi-Mailbox Search, click New.

9.

In the New Mailbox Search window, in the Keywords area, type SIR.

10. Click Mailboxes to Search to expand the settings.

11. Click Search specific mailboxes or the mailboxes of members of distribution groups, and then
click Add.
12. In the Select Mailbox window, double-click Luca Dellamore, and then click OK.
13. In the New Mailbox Search window, click Search Name, Type, and Storage Location to expand
the settings.
14. In the Search name box, type Lucas lost message.
15. Click Copy the search results to the destination mailbox.
16. In Select a mailbox in which to store the search results, click Browse, click Discovery Search
Mailbox, and then click OK.
17. Click Save.
18. Click Lucas lost message to view the results. You may need to click the refresh button.
19. In the search results, click [open].

Lab: Planning a Disaster Recovery Solution

L9-89

20. In the new Outlook Web App window, click OK to accept the default language and time zone.
21. Click the Lucas lost message folder.
22. Expand Lucas lost message, and then click Results -date and time,.

Task 5: Create a role group for exporting mailbox contents

On VAN-EX1, in the Exchange Management Shell, type the following command, and then press
ENTER:
New-RoleGroup Name ExportMail Roles Mailbox Import Export Members Andreas

Task 6: Recover a message

1.

On VAN-EX1, log off as Administrator, and then log on as Adatum\Andreas using the password
Pa$$w0rd.

2.

Open the Exchange Management Shell.

3.

In the Exchange Management Shell, type the following command, and then press ENTER:
Search-Mailbox Discovery Search Mailbox SearchQuery Subject:SIR TargetMailbox
Luca TargetFolder Recovered

4.

On VAN-CL1, in Microsoft Outlook 2010, in the folder list, expand Recovered, expand Discovery
Search MailboxDateandTime, expand Primary Mailbox, expand Lucas lost message, and then
click ResultsDateandTime.

Results: After this exercise, you should have implemented single-item recovery and recovered a message.

To prepare for the next module

When you finish the lab, revert the machines back to their initial state. To do this, complete the following
steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3. Close the
virtual machine connection windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then, in the Actions pane, click Start.

6.

To connect to the virtual machine for the next modules lab, click 10233B-VAN-DC1, and then, in the
Actions pane, click Connect.
Important: Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully
started before starting the other virtual machines.

7.

Wait for 10233B-VAN-DC1 to start, and then start 10223B-VAN-EX1. Connect to the virtual machine.

8.

Wait for 10233B-VAN-EX1 to start, and then start 10223B-VAN-EX2. Connect to the virtual machine.

Wait for 10233B-VAN-EX2 to start, and then start 10223B-VAN-EX3. Connect to the virtual machine.

L9-90

Module 9: Planning a Disaster Recovery Solution

L10-91

Module 10: Planning Microsoft Exchange Server 2010

Monitoring and Troubleshooting

Lab: Planning Exchange Server 2010

Monitoring and Troubleshooting
Exercise 1: Establishing a Baseline for Performance
Task 1: Create a User Defined data collector set
1.

On VAN-EX1, click Start, point to All Programs, point to Microsoft Exchange Server 2010, and
then click Exchange Management Console.

2.

In the console tree, expand Microsoft Exchange On-Premises (van-ex1.adatum.com), and then
click Toolbox.

3.

In the results pane, double-click Performance Monitor.

4.

In the left pane, expand Performance Logs and Alerts.

5.

Expand Data Collector Sets, right-click User Defined, click New, and then click Data Collector Set.

6.

In the Name box, type Baseline, click Create manually (Advanced), and then click Next.

7.

On the What type of data do you want to include page, select the Performance counter check
box, and then click Next.

8.

On the Which performance counters would you like to log page, click Add.

9.

In the Available counters list, click and expand each of the following objects, and for each, click Add.

Memory

MSExchangeIS

MSExchangeIS Mailbox

MSExchangeTransport Queues

MSExchangeTransport SmtpReceive

MSExchangeTransport SmtpSend

Physical Disk

Processor

Server

System

10. Click OK.

11. In the Sample Interval box, type 1, and then click Next.
12. On the Where would you like the data to be saved page, click Next.
13. On the Create the data collector set page, click Finish.

L10-92 Module 10: Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Task 2: Configure Load Generator with suitable values to simulate the required load
1.

Switch to the VAN-DC1 computer.

2.

Click Start, point to All Programs, click Microsoft Exchange, and then click Exchange Load
Generator 2010.

3.

In Microsoft Exchange Load Generator 2010, click Start a new test.

4.

Click Create a new test configuration, and then click Continue.

Note

Do not configure the Define the length of a simulation day value.

5.

On the Specify test settings page, under Define the total length of the simulation, in the Hours
box, type 0.

6.

In the Minutes box, type 10.

7.

In the Directory Access Password box, type Pa$$w0rd.

8.

In the Mailbox Account Master Password box, type Pa$$w0rd, and then click Continue with
recipient management.

9.

On the User settings page, in the text box, type 12, and then click Distribute users evenly across
databases.

10. Click Continue.

11. On the Advanced recipient settings page, select the following check boxes:

Use distribution lists

Use dynamic distribution lists

Create one for all the users

Create one per mailbox database

Use contacts

12. In the Number of contacts box, type 20 and then click Continue.
13. On the Specify test user groups page, click the PLUS SIGN (+).
14. In the resulting item, in the Client Type list, click Outlook 2007 Online.
15. On the Specify test user groups page, click the PLUS SIGN (+) sign.
16. In the resulting item, in the Client Type list, click Outlook 2007 Cached, and in the Action Profile
list, click Heavy.
17. Click Continue, and on the Remote configurations page, click Continue.
18. On the Configuration summary page, click Save the configuration file as.
19. In the Save As dialog box, in the File name box, type Baseline, and then click Save.
20. In the Configuration Saved dialog box, click OK.
21. Click Skip initialization phase and run the simulation immediately.
22. Switch to the VAN-EX1 computer.

Lab: Planning Exchange Server 2010 Monitoring and Troubleshooting

L10-93

23. Switch to Exchange Server Performance Monitor.

24. Right-click Baseline, and then click Start.
25. Switch back to VAN-DC1, and wait until the simulation has finished.
26. After the simulation has finished, switch back to the VAN-EX1 server.
Note

This simulation runs for 10 minutes.

Task 3: Gather performance data, and analyze results

1.

On VAN-EX1, switch to Exchange Server Performance Monitor.

2.

Right-click Baseline, and then click Stop.

3.

In the left pane, click System Monitor. Click the red X in the toolbar repeatedly to remove all
counters from the display.

4.

Press Ctrl+L.

5.

Click Log files, and then click Add.

6.

In the Select Log File dialog box, double-click Admin, double-click Baseline, double-click the folder
that ends 000001, and then double-click DataCollector01.blg.

7.

Click the Data tab.

8.

Click Add.

9.

In Performance object list, expand Memory.

10. In Available counters list, select Pages/sec, and then click Add.
11. Use the information in the following table to add additional counters.
Performance object

Counter

MSExchangeIS

RPC Requests

MSExchangeIS

User Count

MSExchangeIS Mailbox

Local delivery rate

MSExchangeIS Mailbox

Messages Delivered/sec

MSExchangeIS Mailbox

Messages Queued For Submission

MSExchangeIS Mailbox

Messages Sent/sec

MSExchangeTransport Queues

Active Remote Delivery Queue Length

MSExchangeTransport Queues

Retry Remote Delivery Queue Length

MSExchangeTransport Queues

Submission Queue Length

L10-94 Module 10: Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

(continued)
Performance object

Counter

MSExchangeTransport SmtpReceive

Messages Received/sec

MSExchangeTransport SmtpSend

Messages Sent/sec

Physical Disk

% Disk Time

Physical Disk

Avg. Disk Queue length

Processor

% Processor Time

Server

Pool Nonpaged Failures

Server

Work Item Shortages

System

Processor Queue Length

Note If Performance Monitor experiences problems, close and restart it. Then continue
from step 3.
12. Click OK, and then click OK again.
13. Click the down arrow on the toolbar, and then click Report.
14. View the counter values, and then complete the following table.
Counter
Memory Pages/sec
MSExchangeIS - User Count
MSExchangeIS - RPC Requests
MSExchangeIS Mailbox - Local delivery rate
MSExchangeIS Mailbox - Messages Delivered/sec
MSExchangeIS Mailbox - Messages Queued For
Submission
MSExchangeIS Mailbox - Messages Sent/sec
MSExchangeTransport Queues - Active Remote
Delivery Queue Length
MSExchangeTransport Queues - Retry Remote Delivery
Queue Length
MSExchangeTransport Queues - Submission Queue
Length

Average

Lab: Planning Exchange Server 2010 Monitoring and Troubleshooting

(continued)
Counter

Average

MSExchangeTransport SmtpReceive - Messages

Received/sec
MSExchangeTransport SmtpSend - Messages Sent/sec
Physical Disk - % Disk Time
Physical Disk - Avg. Disk Queue length
Processor - % Processor Time
Server - Pool Nonpaged Failures
Server - Work Item Shortages
System - Processor Queue Length

Note

Do not worry that some values are zero; this is a simulation.

Question: Do any counters indicate a bottleneck?

Answer: No.
Results: After this exercise, you should have created an Exchange Server performance baseline.

L10-95

L10-96 Module 10: Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Exercise 2: Measuring the Production System Performance under

Additional Load
Note As this is a training exercise, you will use Load Generator to simulate the load.

Task 1: Generate additional load with Load Generator to simulate the environment
of heavier than planned for usage
1.

Switch to VAN-DC1.

2.

In Microsoft Exchange Load Generator, click Start a new test.

3.

Click Use the following saved configuration file, and then click Browse.

4.

In the Please select a configuration file dialog box, double-click Baseline.xml, and then click
Continue.

5.

On the Specify test settings page, click Continue with recipient management.

6.

On the User settings page, in the text box, type 20, and then click Distribute users evenly across
databases.

7.

Click Continue.

8.

On the Advanced recipient settings page, select the following check boxes.

9.

Use distribution lists

Use dynamic distribution lists

Create one for all the users

Create one per server

Create one per mailbox database

Use contacts

In the Number of contacts box, type 50 and then click Continue.

10. On the Specify test user groups page, click the PLUS SIGN (+).
11. In the resulting item, in the Client Type list, click Outlook 2007 Online, and in the Action Profile
list, click Heavy.
12. On the Specify test user groups page, click the PLUS SIGN (+).
13. In the resulting item, in the Client Type list, click Owa2010Module, and in the Action Profile list,
accept the defaults.
14. Click Continue, and on the Remote configurations page, click Continue.
15. On the Configuration summary page, click Save the configuration file as.
16. In the Save As dialog box, in the File name box, type Adatum, and then click Save.
17. In the Configuration Saved dialog box, click OK.
18. Click Skip initialization phase and run the simulation immediately.
19. Switch to VAN-EX1.

Lab: Planning Exchange Server 2010 Monitoring and Troubleshooting

L10-97

20. Switch to Exchange Server Performance Monitor.

21. Expand Data Collector Sets, expand User Defined, right-click Baseline, and then click Start.
22. Switch to VAN-DC1.
23. When the simulation completes, switch to VAN-EX1.

Task 2: Compare the data with the baseline data

1.

Switch to Exchange Server Performance Monitor.

2.

Right-click Baseline, and then click Stop.

3.

In the right pane, right-click, and then click Properties.

4.

In the Performance Monitor Properties dialog box, click the Source tab, and then click Remove.

5.

Click Log files, and then click Add.

6.

In the Select Log File dialog box, click Up One Level, double-click the folder ending in 000002,
double-click DataCollector01.blg, and then click OK.

7.

View the counter values, and then complete the following table.
Counter
Memory Pages/sec
MSExchangeIS - User Count
MSExchangeIS - RPC Requests
MSExchangeIS Mailbox - Local delivery rate
MSExchangeIS Mailbox - Messages Delivered/sec
MSExchangeIS Mailbox - Messages Queued For
Submission
MSExchangeIS Mailbox - Messages Sent/sec
MSExchangeTransport Queues - Active Remote
Delivery Queue Length
MSExchangeTransport Queues - Retry Remote Delivery
Queue Length
MSExchangeTransport Queues - Submission Queue
Length
MSExchangeTransport SmtpReceive - Messages
Received/sec
MSExchangeTransport SmtpSend - Messages Sent/sec
Physical Disk - % Disk Time
Physical Disk - Avg. Disk Queue length

Average

L10-98 Module 10: Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

(continued)
Counter

Average

Processor - % Processor Time

Server - Pool Nonpaged Failures
Server - Work Item Shortages
System - Processor Queue Length
Question: How do the values compare with those you previously recorded in the baseline
data?
Answer: Answer may vary.

Processor resources are influenced by the increased load.

There has been an increase in paging suggesting additional memory load.

Disk load has not increased.

Results: After this exercise, you should have determined which server resources are likely to become
bottlenecked if server load continues to increase.

To prepare for the next module

When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the
following steps:
1.

On the host computer, start Hyper-V Manager.

2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.

In the Revert Virtual Machine dialog box, click Revert.

4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3.

Note

You do not need to start any virtual machines, as this is the last lab of the course.

L11-99

Module 11: Upgrading to Microsoft Exchange Server 2010

Lab: Upgrading to Microsoft Exchange

Server 2010
Exercise 1: Designing an Exchange Server 2010 Upgrade Strategy
Task 1: Review the A. Datum documentation

Review the following A Datum documentation:

Adatum_ProposedADSiteDesign.vsd

Adatum_ProposedPerimeterDesign.vsd

A. Datum User Distribution Summary.doc

Exchange_Server_2003_Configuration.doc

Task 2: Update the A. Datum Upgrade Design document

Answer the questions in the A. Datum Upgrade Design Questions document, and then complete the
A. Datum Upgrade Design document.
A. Datum Upgrade Design
Document Reference Number: JC060610/1
Document Author
Date

Jason Carlson
6th June 2010

Requirement Overview
Describe the upgrade strategy for the A. Datum organization.
Proposals
Question: Based on what you know about the A. Datum organization, what would be a reasonable
timeline for completing this migration?
Answer: Answers will vary. Because this upgrade does not require any client reconfigurations for
users, the organization could pursue a fairly aggressive timeline. Estimates for completing the
upgrade should range from 3 to 12 months.
Question: What are the factors that will affect the timeline?
Answer: Factors that will impact the upgrade time line include:
Project budget
Resource availability (both personnel and hardware)
Test requirements
Question: Where will you perform the schema upgrade?
Answer: The schema upgrade must be done in the domain where the Schema Master is located. As
a best practice, you should disable schema replication on the Schema Master while performing the
upgrade. After the upgrade is successfully completed, you can re-enable replication. In a large
organization, allow enough time for the schema upgrade to replicate to all domain controllers
before you prepare the domains.

L11-100

Module 11: Upgrading to Microsoft Exchange Server 2010

(continued)
A. Datum Upgrade Design
Question: What is the process for preparing domains for Exchange Server 2010?
Answer: Each domain with Exchange Server 2010 users or servers must be prepared. After the
schema upgrade has replicated to all domain controllers, you can run the setup with the
PrepareAllDomains option.
Question: How will you ensure that Exchange Server 2010 can coexist with Exchange Server 2003?
Answer: Run setup with the PrepareLegacyExchangePermissions option.
Question: Which site should be upgraded first?
Answer: London is the best site to upgrade first. The most experienced Exchange Server
administrators are likely located in London, as well as the central team of administrators who have
permission throughout the organization. London is also the site with the most users and the frontend servers for Exchange Server 2003.
Question: Which server role should be implemented first in that site?
Answer: The Client Access server role should be implemented first. It is required to provide
coexistence between Exchange Server 2003 and Exchange Server 2010.
Question: Should coexistence occur in multiple sites or a single location?
Answer: In general, it is better to limit coexistence to a single location to simplify the migration
process. If only a single location has coexistence, it is easy to configure message routing with a
single routing group connector. If time constraints dictate that multiple locations must have
coexistence, it is possible, but complexity increases.
Question: How will client access be configured to allow coexistence in the first site?
Answer: A client access array will be configured in the London site. The client access array will use
the external name of mail.adatum.com, which is currently used by the load-balanced front-end
servers for Exchange Server 2003. A new legacy.adatum.com name will be configured for the loadbalanced front-end servers. The Exchange Server 2010 Client Access servers will be configured with
the legacy URL for the Exchange Server 2003 front-end servers.
All users will initially connect to mail.adatum.com. Outlook Web Access users with Exchange
Server 2003 mailboxes will be redirected to the Exchange Server 2003 front-end servers. The
Exchange Server 2010 Client Access server will proxy connections for ActiveSync users. The
Exchange Server 2010 Client Access server will communicate directly with Exchange Server 2003
computers hosting mailboxes for Outlook Anywhere users.
Question: How will message transport be configured to allow coexistence in the first site?
Answer: The initial installation will have a single routing group connector between Exchange
Server 2010 and the London routing group. This will allow messages to be delivered between
Exchange Server 2003 and Exchange Server 2010.
Question: How will mailboxes be moved in the first site?
Answer: Mailboxes can be moved from Exchange Server 2003 to Exchange Server 2010 as soon as
all of the Exchange Server 2010 infrastructure is in place in London. Live mailbox moves are not
supported from Exchange Server 2003 to Exchange Server 2010. So, you will need to move
mailboxes outside of standard business hours or arrange for downtime to move mailboxes.

Lab: Upgrading to Microsoft Exchange Server 2010

11-101

(continued)
A. Datum Upgrade Design
Question: How will you move Internet message delivery from Exchange Server 2003 to Exchange
Server 2010 and use Edge Transport servers?
Answer: Edge transport servers can be introduced before Exchange Server 2010 Hub Transport
servers, but there is no reason to do so because there is already an anti-spam solution in place.
After Exchange Server 2010 Hub Transport servers are introduced, then you can implement Edge
Synchronization, which simplifies the management of Edge Transport servers.
After Edge Synchronization is configured, then you can direct incoming messages to the new Edge
Transport servers rather than the existing anti-spam appliances. To support outgoing mail directly
from Exchange Server 2010 to the Internet, you must create a send connector. Then you must
disable outbound mail delivery from Exchange Server 2003 to the Internet.
Question: When you begin migrating the second site to Exchange Server 2010, what process will
you use?
Answer: The same process as was used in London. The Client Access server will be implemented
first, and then other server roles. After you verify that message delivery and all services work
correctly, you can begin migrating mailboxes in the site.
To ensure that message delivery is efficient, you should create an additional routing group
connector between Exchange Server 2010 and the routing group for the second site.
Question: How will you remove Exchange Server 2003?
Answer: Exchange Server 2003 cannot be completely removed until all mailboxes are migrated to
Exchange Server 2010. Any Exchange Server 2003 computers that no longer have mailboxes can be
uninstalled. Care should be taken to ensure that bridgehead servers are not accidentally removed,
which could affect message routing.
The Exchange Server 2003 front-end servers should be the last servers removed. They must remain
in place to provide external Outlook Web Access connectivity for all external users with Exchange
Server 2003 mailboxes.

Note

Be prepared to discuss your proposed design with the class.

Results: After this exercise, you should have completed the A. Datum Upgrade document.

To prepare for the next module

Note No virtual machines are required for the next lab.

L11-102

Module 11: Upgrading to Microsoft Exchange Server 2010

L12-103

Module 12: Integrating Microsoft Exchange Server 2010

with Other Messaging Systems

Lab: Integrating Exchange Server 2010 with

Other Messaging Systems
Exercise: Designing Exchange Server 2010 Integration with Office 365
Task 1: Document the required configuration for migrating Northwind Traders email to
Office 365

Complete the following proposal document by answering the questions.

A. Datum Corporation and Northwind Traders Integration Plan
Document Reference Number: JC040495/1
Document Author
Date

Jason Carlson
5th June 2010

Requirement Overview
Determine how to how migrate Northwind Traders email to Office 365.
Proposals
Question: Does this scenario require a hybrid implementation of Office 365?
Answer: Yes. For the best interoperability between the on-premises Exchange Server organization
for A. Datum and Office 365, you should implement a hybrid scenario.
Question: Will inbound routing be to the on-premises Exchange Server organization or to
Office 365?
Answer: Inbound routing should be through the on-premises Exchange Server organization. This
allows the Edge Transport server in London to perform anti-spam and antivirus scanning for all
messages. Using Microsoft Forefront Online Protection for Exchange (FOPE) in Office 365 to scan
all messages would be expensive because additional licenses for FOPE would need to be purchased
for thousands of A. Datum Corporation users that do not have Office 365 mailboxes.
Question: Will outbound routing be centralized or decentralized?
Answer: Outbound routing will be centralized through the on-premises Exchange Server
organization. This is the only way that the legal disclaimer that includes the company logo can be
applied to all outbound messages.
Question: How will you configure mail exchanger (MX) resource records?
Answer: After the mailboxes are moved, you should direct the MX records for
northwindtraders.com to the Edge Transport servers in the A. Datum Corporation data center in
London. The MX records for adatum.com are already directed to the Edge Transport server in the A.
Datum Corporation data center in London.
Question: How will you migrate mailboxes to Office 365?
Answer: The only option for migrating mailboxes from a POP3/IMAP messaging system to
Office 365 is to use the IMAP migration. This migrates mailbox contents through an Internet
message access protocol (IMAP) connection.

L12-104 Module 12: Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

(continued)
A. Datum Corporation and Northwind Traders Integration Plan
Question: Will you configure single sign-on?
Answer: Yes. There are 800 users at Northwind Traders. That large number of users will generate
many help desk calls if they cannot use the same user credentials for email logon as they use
internally for AD DS.
Question: Do you need to configure a user principal name (UPN) to support single sign-on?
Answer: Yes. You need to verify that the UPN for the adatum.com domain is configured to be
adatum.com. This matches the email addresses of the users. This should be configured before
directory synchronization begins as part of the hybrid deployment.
Question: What Active Directory Federation Services (AD FS) servers do you require to support
single sign-on?
Answer: To be highly available, there should be two load balanced federation servers and two load
balanced federation server proxies. The federation servers can be installed on existing domain
controllers because there are fewer than 1,000 users. The federation server proxies can be installed
on existing web or proxy servers in the perimeter network.
Question: What certificates do you need to support single sign-on?
Answer: Single sign-on with AD FS requires two certificates. One SSL certificate is installed on the
Default Web Site of the federation servers and federation server proxies. The subject of this
certificate needs to be an Internet routable domain name that matches the DNS name configured
for load balancing on federation servers and federation server proxies. The subject name also needs
to match the DNS name that is configured as the Federation Service name.
The federation servers also use a token-signing certificate that is automatically generated. No
configuration is required for the token-signing certificate.

Results: After this exercise, you should have created a plan to migrate Northwind Traders email to
Office 365.