10135B ENU TrainerHandbook

MCT USE ONLY.
STUDENT USE PROHIBITED

O F F I C I A L M I C R O S O F T L E A R N I N G P R O D U C T
10135B
Configuring, Managing and
Troubleshooting Microsoft
Exchange Server 2010 Service Pack 2
MCT USE ONLY. STUDENT USE PROHIBITED
ii Configuring, Managing and Troubleshooting Microsoft Exchange Server 2010 Service Pack 2
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: 10135B
Part Number: X18-30632
Released: 05/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 instructor-
led 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

x Configuring, Managing and Troubleshooting Microsoft Exchange Server 2010 Service Pack 2
Configuring, Managing and Troubleshooting Microsoft Exchange Server 2010 Service Pack 2 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.
Siegfried Jagott Content Developer

Siegfried Jagott is a Principal Consultant and Team Lead for the Messaging and Collaboration team in
Siemens IT Solutions, which is located in Munich, Germany. He has planned, designed, and implemented
some of the worlds largest Windows Server and Microsoft Exchange Server infrastructures for
international customers. Additionally, he hosted a monthly column for Windows IT Magazine called
Exchange & Outlook Perspectives. He writes for international magazines and lectures about Windows
and Exchange Server-related topics. He received an MBA from Open University in England, and has been
a Microsoft Certified Systems Engineer (MCSE) since 1997.
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 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 a Microsoft Certified Trainer (MCT) for 11 years.
Joel Stidley Content Developer

Joel Stidley is a Microsoft Certified IP Professional (MCITP), MCSE, and Microsoft Certified IT Specialist
(MCTS), and a Microsoft Exchange Most Valuable Professional (MVP) with more than 13 years of IT
experience. Currently, he is a principal systems architect at Terremark Worldwide, Inc., where he works
with a variety of directory, storage, virtualization, and messaging technologies. Joel has authored several
books and courses on Microsoft Technologies, including Windows PowerShell, Microsoft Exchange
Server, and Windows Server 2008. He also manages an Exchange Server blog and forum site.
Damir Dizdarevic Technical Reviewer

Damir Dizdarevic is a manager of the Learning Center at Logosoft d.o.o. (Sarajevo, Bosnia and
Herzegovina) and an MCT. He has worked as a subject-matter expert and technical reviewer on several
Microsoft Official Course (MOC) courses, and has published more than 350 articles in various IT
magazines, such as Windows ITPro. He is an MVP for Windows Server Infrastructure Management, and an
MCSE, MCTS, and MCITP (Windows Server 2008 and Exchange Server 2007). He specializes in Windows
Server and Exchange Server.
xii Configuring, Managing and Troubleshooting Microsoft Exchange Server 2010 Service Pack 2
Contents
Module 1: Deploying Microsoft Exchange Server 2010
Lesson 1: Overview of Exchange Server 2010 Requirements 1-3
Lesson 2: Installing Exchange Server 2010 Server Roles 1-18
Lab A: Installing Exchange Server 2010 1-38
Lesson 3: Completing an Exchange Server 2010 Installation 1-42
Lab B: Verifying an Exchange Server 2010 Installation 1-51
Module 2: Configuring Mailbox Servers

Lesson 1: Overview of Exchange Server 2010 Administrative Tools 2-3
Lesson 2: Configuring Mailbox Server Roles 2-16
Lesson 3: Configuring Public Folders 2-33
Lab: Configuring Mailbox Servers 2-41
Module 3: Managing Recipient Objects

Lesson 1: Managing Mailboxes 3-3
Lesson 2: Managing Other Recipients 3-21
Lesson 3: Configuring Email Address Policies 3-28
Lesson 4: Configuring Address Lists and Address Book Policies 3-33
Lesson 5: Performing Bulk Recipient Management Tasks 3-40
Lab: Managing Exchange Recipients 3-46
Module 4: Managing Client Access

Lesson 1: Configuring the Client Access Server Role 4-3
Lesson 2: Configuring Client Access Services for Outlook Clients 4-24
Lab A: Configuring Client Access Servers for Outlook Anywhere Access 4-44
Lesson 3: Configuring Outlook Web App 4-48
Lesson 4: Configuring Mobile Messaging 4-57
Lab B: Configuring Client Access Servers for Outlook Web App
and Exchange ActiveSync 4-67
Module 5: Managing Message Transport

Lesson 1: Overview of Message Transport 5-3
Lesson 2: Configuring Message Transport 5-18
Lab: Managing Message Transport 5-33
Configuring, Managing and Troubleshooting Microsoft Exchange Server 2010 Service Pack 2 xiii
Module 6: Implementing Messaging Security

Lesson 1: Deploying Edge Transport Servers 6-3
Lesson 2: Deploying an Antivirus Solution 6-18
Lab A: Configuring Edge Transport Servers and
Forefront Protection 2010 for Exchange Server 6-25
Lesson 3: Configuring an Anti-Spam Solution 6-29
Lesson 4: Configuring Secure SMTP Messaging 6-41
Lab B: Implementing Anti-Spam Solutions 6-52
Module 7: Implementing High Availability

Lesson 1: Overview of High Availability Options 7-3
Lesson 2: Configuring Highly Available Mailbox Databases 7-6
Lesson 3: Deploying Highly Available Non-Mailbox Servers 7-26
Lesson 4: Deploying High Availability with Site Resilence 7-33
Lab: Implementing High Availability 7-43
Module 8: Implementing Backup and Recovery

Lesson 1: Planning Backup and Recovery 8-3
Lesson 2: Backing Up Exchange Server 2010 8-12
Lesson 3: Restoring Exchange Server 2010 8-22
Lab: Implementing Backup and Recovery 8-35
Module 9: Configuring Messaging Policy and Compliance

Lesson 1: Introducing Messaging Policy and Compliance 9-3
Lesson 2: Configuring Transport Rules 9-9
Lesson 3: Configuring Journaling and Multi-Mailbox Search 9-30
Lab A: Configuring Transport Rules, Journal Rules, and
Multi-Mailbox Search 9-41
Lesson 4: Configuring Messaging Records Management 9-47
Lesson 5: Configuring Personal Archives 9-54
Lab B: Configuring Personal Archives and Retention Policies 9-66
Module 10: Securing Microsoft Exchange Server 2010

Lesson 1: Configuring Role-Based Access Control 10-3
Lesson 2: Configuring Audit Logging 10-24
Lesson 3: Configuring Secure Internet Access 10-30
Lab: Securing Exchange Server 2010 10-47
Module 11: Maintaining Microsoft Exchange Server 2010

Lesson 1: Monitoring Exchange Server 2010 11-3
Lesson 2: Maintaining Exchange Server 2010 11-19
Lesson 3: Troubleshooting Exchange Server 2010 11-25
Lab: Maintaining Exchange Sever 2010 11-34
xiv Configuring, Managing and Troubleshooting Microsoft Exchange Server 2010 Service Pack 2
Module 12: Upgrading from Exchange Server 2003 or

Exchange Server 2007 to Exchange Server 2010
Lesson 1: Overview of Upgrading to Exchange Server 2010 12-3
Lesson 2: Upgrading from Exchange Server 2003 to
Exchange Server 2010 12-12
Lesson 3: Upgrading from Exchange Server 2007 to
Exchange Server 2010 12-31
Module 13: Implementing Microsoft Exchange Online with

Microsoft Office 365
Lesson 1: Introduction to Exchange Online 13-3
Lesson 2: Deploying Exchange Online 13-13
Lesson 3: Implementing Federated Delegation 13-27
Appendix A: Implementing Unified Messaging

Lesson 1: Overview of Telephony A-3
Lesson 2: Introducing Unified Messaging A-12
Lesson 3: Configuring Unified Messaging A-29
Lab: Implementing Unified Messaging A-42
Appendix: Lab Answer Keys

Module 1 Lab A: Installing Exchange Server 2010 L1-1
Module 1 Lab B: Verifying an Exchange Server 2010 Installation L1-5
Module 2 Lab: Configuring Mailbox Servers L2-8
Module 3 Lab: Managing Exchange Recipients L3-12
Module 4 Lab A: Configuring Client Access Servers for
Outlook Anywhere Access L4-22
Module 4 Lab B: Configuring Client Access Servers for Outlook
Web App and Exchange ActiveSync L4-27
Module 5 Lab: Managing Message Transport L5-31
Module 6 Lab A: Configuring Edge Transport Servers and
Forefront Protection 2010 for Exchange Server L6-38
Module 6 Lab B: Implementing Anti-Spam Solutions L6-42
Module 7 Lab: Implementing High Availability L7-46
Module 8 Lab: Implementing Backup and Recovery L8-52
Module 9 Lab A: Configuring Transport Rules, Journal Rules,
and Multi-Mailbox Search L9-58
Module 9 Lab B: Configuring Personal Archives and Retention Policies L9-65
Module 10 Lab: Securing Exchange Server 2010 L10-68
Module 11 Lab: Maintaining Exchange Sever 2010 L11-78
Appendix A Lab: Implementing Unified Messaging LA-85
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 will provide you with the knowledge and skills to configure and manage a Microsoft
Exchange Server 2010 messaging environment. This course will teach you how to configure Exchange
Server 2010, as well as provide guidelines, best practices, and considerations that will help you optimize
your Exchange server deployment.
Audience
This course is intended for people aspiring to be enterprise-level messaging administrators. Others who
may take this course include IT generalists and help-desk professionals who want to learn about Exchange
Server 2010. People coming into the course are expected to have at least 3 years experience working in
the IT fieldtypically in the areas of network administration, help desk, or system administration. We do
not expect them to have experience with previous Exchange Server versions.
Student Prerequisites
This course requires that you meet the following prerequisites:
Experience managing Windows Server 2003 or Microsoft Window Server 2008 operating systems.
Experience with Active Directory Domain Services (AD DS).
Fundamental knowledge of network technologies including Domain Name System (DNS) and firewall
technologies.
Experience managing backup and restore on Windows Servers.
Experience using Windows management and monitoring tools such as Microsoft Management
Console, Active Directory Users and Computers, Performance Monitor, Event Viewer, and Internet
Information Services (IIS) Administrator.
Experience using Windows networking and troubleshooting tools such as Network Monitor, Telnet,
and NSLookup.
Fundamental knowledge of certificates and Public Key Infrastructure (PKI).
xvi About This Course
Course Objectives
After completing this course, students will be able to:
Install and deploy Exchange Server 2010.
Configure Mailbox servers and mailbox server components.
Manage recipient objects.
Configure the Client Access server role.
Manage message transport.
Configure the secure flow of messages between the Exchange Server organization and the Internet.
Implement a high-availability solution for Mailbox servers and other server roles.
Plan and implement backup and restore functionality for the server roles.
Plan and configure messaging policy and compliance.
Configure Exchange Server permissions and security for internal and external access.
Monitor and maintain the messaging system.
Transition an Exchange Server 2003 or Exchange Server 2007 organization to Exchange Server 2010.
Configure Exchange Server 2010 integration with Microsoft Exchange Online.
Configure the Unified Messaging Server role and Unified Messaging components.
Course Outline
This section provides an outline of the course:
Module 1, Deploying Microsoft Exchange Server 2010 describes how to prepare for, and perform, an
installation of Exchange Server 2010. This module also provides details on the Exchange Server 2010
deployment.
Module 2, Configuring Mailbox Servers describes the Exchange Management Console and Exchange
Management Shell management tools. This module also describes the Mailbox server role, some of the
new Exchange Server 2010 features, and the most common post-installation tasks for Mailbox server roles.
The module concludes with a discussion about public-folder configuration and usage.
Module 3, Managing Recipient Objects describes how you can manage recipient objects, address
policies, and address lists in Exchange Server 2010, and the procedures for performing bulk-management
tasks in Exchange Management Shell.
Module 4, Managing Client Access describes how to implement the Client Access server role in
Exchange Server 2010.
Module 5, Managing Message Transport describes how to manage message transport in Exchange
Server 2010, which includes topics such as components of message transport, how Exchange Server 2010
routes messages, and how you can troubleshoot message-transport issues. Additionally, this module
provides details on deploying the Exchange Server 2010 Hub Transport server.
Module 6, Implementing Messaging Security describes how to plan for and deploy an Exchange Server
2010 Edge Transport server role, and the security issues that relate to the deployment. Additionally, it
describes how to configure secure Simple Mail Transfer Protocol (SMTP) messaging and domain security.
About This Course xvii
Module 7, Implementing High Availability describes the high-availability technology built into Exchange
Server 2010 and some of the outside factors that affect highly available solutions. This module provides
details about how to deploy highly available mailbox databases and other Exchange Server 2010 server
roles.
Module 8, Implementing Backup and Recovery describes the Exchange Server 2010 backup and restore
features, and what you should consider when creating a backup plan.
Module 9, Configuring Messaging Policy and Compliance describes how to configure the Exchange
Server 2010 messaging policy and compliance features.
Module 10, Securing Microsoft Exchange Server 2010 describes how to secure your Exchange Server
deployment by configuring administrative permissions, and auditing and configuring secure access to the
Exchange Server environment from the Internet.
Module 11, Maintaining Microsoft Exchange Server 2010 describes how to monitor and maintain your
Exchange Server environment. Additionally, it also describes troubleshooting techniques for fixing
problems that may arise.
Module 12, Upgrading from Exchange Server 2003 or Exchange Server 2007 to Exchange Server 2010
describes the options that organizations have when they implement Exchange Server 2010. Additionally, it
describes how to transition an existing Exchange Server 2003 or Exchange Server 2007 organization to
Module 13, Implementing Microsoft Exchange Online with Office 365 describes the Exchange Online
features and how to integrate an on-premises Exchange Server 2010 deployment with Exchange Online.
Appendix A, Implementing Unified Messaging describes how Unified Messaging works with your
telephony system and Exchange Server environment, and how to configure Unified Messaging.
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 that you
learn in the modules.
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. The latter 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, and 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 email to

support@mscourseware.com. To inquire about the Microsoft Certification Program, send email
to mcphelp@microsoft.com.
About This Course xix
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 Microsoft Virtual Server 2005 R2 with Service Pack 1 (SP1) to perform the labs.
Important: At the end of each lab, you must revert the virtual machine to the state that the virtual
machine was in before the lab started. To revert a virtual machine, perform the following steps:
1. In Microsoft 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

10135B-NYC-DC1 Domain controller in the Contoso.com domain
10135B-NYC-SVR1 Member server in the Contoso.com domain
10135B-VAN-DC1 Domain controller in the Adatum.com domain
10135B-VAN-EX1 Exchange 2010 server in the Adatum.com domain
10135B-VAN-EDG Exchange 2010 Edge Transport server
10135B-VAN-CL1 Client computer in the Adatum.com domain
10135B-VAN-TMG Microsoft Forefront Threat Management Gateway server in the

Adatum.com domain
10135B-VAN-SVR1 Standalone server
Software Configuration
The following software is installed on each virtual machine:
Windows Server 2008 R2, SP1
Windows 7, SP1
Exchange Server 2010, SP2
Microsoft Office 2010 SP1
Microsoft Forefront Threat Management Gateway SP1

xx About This Course
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.
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, including:
Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) processor

Dual 120 gigabyte (GB) hard disks 7200 RM Serial ATA (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
Deploying Microsoft Exchange Server 2010
Contents:
Lesson 1: Overview of Exchange Server 2010 Requirements 1-3
Lesson 2: Installing Exchange Server 2010 Server Roles 1-18
Lab A: Installing Exchange Server 2010 1-38

Lesson 3: Completing an Exchange Server 2010 Installation 1-42
Lab B: Verifying an Exchange Server 2010 Installation 1-51

1-2 Deploying Microsoft Exchange Server 2010
Module Overview
This module describes how to prepare for, and perform, an installation of Microsoft Exchange Server
2010. The most important task in preparing for an Exchange Server 2010 installation is to ensure that the
Active Directory Domain Services (AD DS) environment is ready. Exchange Server 2010 requires an
Active Directory deployment because AD DS stores all configuration and recipient information that
Exchange Server uses.
This module also provides details on the Exchange Server 2010 deployment. To install Exchange
Server 2010 properly for your environment, you must be aware of the server roles that Exchange Server
can install. Additionally, you should be aware of the infrastructure, hardware, and software requirements
for introducing Exchange Server 2010 into a messaging environment. Finally, you should know how to
verify, troubleshoot, and secure the installation.
After completing this module, you will be able to:
Describe the infrastructure requirements to install Exchange Server 2010.
Install Exchange Server 2010 server roles.
Complete an Exchange Server 2010 installation.

10135B: Configuring, Managing, and Troubleshooting Microsoft Exchange Server 2010 Service Pack 2 1-3
Lesson 1
Overview of Exchange Server 2010 Requirements
In this lesson, you will review the requirements for installing Exchange Server 2010. The most important
requirement is the Active Directory deployment, but you also must ensure that you implement the
appropriate Domain Name System (DNS) infrastructure. You also should be aware of the Exchange Server
2010 infrastructure requirements when you perform an installation, and when you need to troubleshoot
deployment issues.
After completing this lesson, you will be able to:
Describe the Active Directory components.
Describe the Active Directory partitions.

Describe how Exchange Server 2010 uses AD DS.
Describe the DNS requirements for Exchange Server 2010.
Prepare AD DS for Exchange Server 2010.
Describe the integration of AD DS and Exchange Server 2010.

Reviewing Active Directory Components
AD DS consists of several components. Since Exchange Server deeply integrates with AD DS, it is
important to understand the purpose of each of the following AD DS components:
Domains. An Active Directory domain is a collection of computers that a Microsoft Windows

network administrator defines. These computers share a common directory database, security
policies, and security relationships with other domains. An Active Directory domain provides access to
the centralized user and group accounts that the domain administrator maintains. You can organize
computer and user accounts within AD DS into a hierarchy based on organizational units (OUs).
Forests. A forest is a set of one or more domains that share common configuration and schema
information. A tree is set of domains that share the same Domain Name System (DNS) namespace.
When multiple domains exist in a forest, there is an automatic trust relationship between the
domains, which enables users in one domain to access resources in another domain. There can be
only one Exchange Server organization per forest. An Active Directory forest is a security boundary.
By default, no security accounts outside of a forest have any access in the forest.
Trusts. Trusts enable users from a trusted domain to authenticate in another trusting domain. In a
forest, all domains have trusts (either direct trusts or transitive trusts) with all other domains in the
forest.
Domain controllers and global catalog servers. A domain controller holds a copy of the local domain
database, which includes user accounts and computer accounts. It also is responsible for
authenticating users and computers. Additionally, domain controllers respond to queries for
information in AD DS. A domain controller has directory information only for the domain of which it
is a member; it does not have information about users in other domains. A global catalog server is a
domain controller that also holds a subset of information from other domains in the forest. For
example, a global catalog server has limited information about all users in a forest.
Active Directory sites. Active Directory sites are defined as one or more IP subnets. Typically, all of the
IP subnets in a given physical location are part of the same site. Sites do not typically encompass
more than one physical location. All of the computers within a single site must have a fast network
connection, which is usually 10 megabits per second (Mbps) or more, between them.
Active Directory replication. AD DS replicates information between domain controllers. It replicates

domain information between domain controllers in the same domain and to global catalog servers in
the forest. AD DS also replicates configuration data and the schema between all domain controllers in
the same forest. Within an Active Directory site, replication of changes starts within a few seconds of
the change being made on one domain controller. Between Active Directory sites, replication can be
scheduled, and happens every three hours by default. Also, all replication traffic between sites is sent
through a bridgehead server in each site.
Discussion: Reviewing Active Directory Implementations
AD DS is the integrated, distributed directory service that is included with the Windows Server 2008 R2,
Windows Server 2008, Windows Server 2003, and Windows 2000 Server operating systems. Many
applications, such as Exchange Server 2010, integrate with AD DS. This creates a link between user
accounts and applications, which enables single sign-on for applications. Additionally, the Active Directory
replication capabilities enable distributed applications to replicate application-configuration data.
Discussion Questions
Based on your experience, consider the following questions:
Question: Under what circumstances would an organization deploy multiple domains in the
same forest?
Question: Under what circumstances might an organization deploy multiple forests?
Question: What type of information do domains in a forest share?

Reviewing Active Directory Partitions
Active Directory information falls into four types of partitions: domain, configuration, schema, and
application. These directory partitions are the replication units in AD DS.
Domain Partition
A domain partition contains all objects in the domains directory. Domain objects replicate to every
domain controller in that domain, and include user and computer accounts, and groups.
A subset of the domain partition replicates to all domain controllers in the forest that are global catalog
servers. If you configure a domain controller as a global catalog server, it holds a complete copy of its own
domains objects and a subset of attributes for every domains objects in the forest.
Configuration Partition
The configuration partition contains configuration information for AD DS and applications, including
Active Directory site and site link information. Additionally, some distributed applications and services
store information in the configuration partition. This information replicates through the entire forest so
each domain controller has a replica of the configuration partition.
When application developers choose to store application information in the configuration partition, the
developers do not need to create their own mechanism to replicate the information. The configuration
partition stores each type of configuration information in separate containers. A container is an Active
Directory object similar to an OU that you use to organize other objects.
Schema Partition
The schema partition contains definition information for all object types and their attributes that you can
create in AD DS. This data is common to all domains in the forest, and AD DS replicates it to all domain
controllers in the forest. However, only one domain controller maintains a writable copy of the schema. By
default, this domain controller, known as the Schema Master, is the first domain controller installed in an
Active Directory forest.
Application Partitions
An administrator or an application during installation creates application partitions manually. Application
partitions hold specific application data that the application requires. The main benefit of application
partitions is replication flexibility. You can specify the domain controllers that hold a replica of an
application partition, and these domain controllers can include a subset of domain controllers throughout
the forest. Exchange Server 2010 does not use application partitions to store information.
How Exchange Server 2010 Uses AD DS
To ensure proper placement of Active Directory components in relation to computers that are running
Exchange Server, you must understand how Exchange Server 2010 communicates with AD DS and uses
Active Directory information to function.
AD DS stores most Exchange Server 2010 configuration information.
Note The Exchange Server 2010 Edge Transport server role is the only Exchange Server
role that does not use AD DS to store configuration information. Instead, the Edge
Transport server role uses Active Directory Lightweight Directory Services (AD LDS) for this
purpose. For more details, see Module 6, Implementing Messaging Security.
Forests
An Exchange Server organization and an Active Directory forest have a one-to-one relationship. You
cannot have an Exchange Server organization that spans multiple Active Directory forests. You also cannot
have multiple Exchange Server organizations within a single Active Directory forest.
Note In Exchange Server 2010, you can add multiple Exchange Server organizations in
different forests to the Exchange Management Console. This enables you to manage
multiple organizations from a single management console, but does not enable the
integration of the two Exchange Server organizations.
Schema Partition
The Exchange Server 2010 installation process modifies the schema partition to enable the creation of
Exchange Server-specific objects. The installation process also adds Exchange Server-specific attributes to
existing objects.
For example, the installation process updates user objects with additional attributes to describe storage
quotas and mailbox features.
Configuration Partition
The configuration partition stores configuration information for the Exchange Server 2010 organization.
Because AD DS replicates the configuration partition among all domain controllers in the forest,
configuration of the Exchange Server 2010 organization replicates throughout the forest.
The configuration partition includes Exchange Server configuration objects, such as global settings, email
address policies, transport rules, and address lists.
Domain Partition
The domain partition holds information about recipient objects. This includes mailbox-enabled users, and
mail-enabled users, groups, and contacts. Objects that are mailbox-enabled or mail-enabled have
preconfigured attributes, such as email addresses.
Global Catalog
When you install Exchange Server 2010, the email attributes for mail-enabled and mailbox-enabled
objects replicate to the global catalog. The following is true:
The global address list is generated from the recipients list in an Active Directory forests global
catalog.
Exchange Hub Transport servers access the global catalog to find the location of a recipient mailbox
when delivering messages.
Exchange Client Access servers access the global catalog server to locate the user Mailbox server and
to display the global address list to Microsoft Office Outlook, Microsoft Outlook Web App, or
Exchange ActiveSync clients.
Note Because of the importance of the global catalog in an Exchange Server organization,
you must deploy at least one global catalog serverin each Active Directory site that contains
an Exchange 2010 server. You must deploy enough global catalog servers to ensure
adequate performance.
Note Windows Server 2008 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 global catalog servers (ROGC). This means that you should not deploy an
Exchange 2010 server in any site that contains only RODCs or ROGCs.
Reviewing DNS Requirements for Exchange Server 2010
Each computer that is running Exchange Server must use DNS to locate AD DS and global catalog servers.
As a site-aware application, Exchange Server 2010 prefers to communicate with directory servers that are
located in the same site as the computer that is running Exchange Server.
Role of DNS
Exchange Server services use DNS to locate a valid domain controller or global catalog. By default, each
time a domain controller starts the Netlogon service, it updates DNS with service (SRV) records that
describe it as a domain controller and global catalog server, if applicable.
To ensure that the domain controller updates DNS records properly, it is essential that all domain
controllers use an internal DNS server that supports dynamic updates. After DNS records are registered,
computers that are running Exchange Server can use DNS to find domain controllers and global catalog
servers.
SRV Resource Records

SRV resource records are DNS records. These records identify servers that provide specific services on the
network. For example, an SRV resource record can contain information to help clients locate a domain
controller in a specific domain or site.
All SRV resource records use a standard format, which consists of several fields. These fields contain
information that AD DS uses to map a service back to the computer that provides the service.
SRV resource records use the following format:
_Service_.Protocol.Name Ttl Class SRV Priority Weight Port Target

The following table describes each field in an SRV resource record.
Field Description
_Service Specifies the name of the service, such as Lightweight DirectoryAccess Protocol
(LDAP) or Kerberos, provided by the server that registers this SRV resource
record.
_Protocol Specifies the transport protocol type, such as transmission control protocol(TCP)
or User Datagram Protocol (UDP).
Name Specifies the domain name that the resource record references.
Ttl Specifies the Time to Live (TTL) value in seconds, which is a standard field in
DNS resource records that specifies the length of time that a record is valid.
Class Specifies the standard class value for the DNS resource record, which usually
is.IN, for the Internet system. This is the only class that Windows Server 2008
DNS supports.
Priority Specifies the servers priority. Clients attempt to contact the host that has the
lowest priority.
Weight Denotes a load-balancing mechanism that clients use when selecting a target
host. When the priority field is the same for two or more records in the same
domain, clients randomly choose SRV resource records that have higher weights.
Port Specifies the port where the server is listening for this service.
Target Specifies the fully qualified domain name (FQDN) (also called the full computer
name), of the computer that provides the service.
The SRV records for domain controllers and global catalog servers are registered with several different
variations to allow locating domain controllers and global catalog servers in several different ways. One
option is to register DNS records by site name, which enables computers that are running Exchange
Server to find domain controllers and global catalog servers in the local Active Directory site. Exchange
Server always performs DNS resource queries for the local Active Directory site first.
When a computer that is running Exchange Server is a member server, Exchange Server configures it
dynamically with its site each time it authenticates to AD DS. As part of the authentication process, the
registry stores the site name. When the Exchange server queries DNS for domain controller or global
catalog server records, the Exchange server always attempts to connect to domain controllers with the
same site attribute as the Exchange server.
Host Records
Host records provide a host name to IP address mapping. Host records are required for each domain
controller and other hosts that need to be accessible to Exchange Servers or client computers. Host
records can use IPv4 (A records) or IPv6 (AAAA records).
MX Records
A Mail Exchanger (MX) record is a resource record that allows servers to locate other servers to deliver
Internet email by using the Simple Mail Transfer Protocol (SMTP). An MX record identifies the SMTP server
that will accept inbound messages for a specific DNS domain. Each MX record contains a host name and a
preference value. When you deploy multiple SMTP servers that are accessible from the Internet, you can
assign equal preference values to each MX record to enable load balancing between the SMTP servers.
You also can specify a lower preference value for one of the MX records. All messages are routed through
the SMTP server that has the lower preference-value MX record, unless that server is not available.
Note In addition to SRV, Host, and MX records, you also may need to configure Sender
Policy Framework (SPF) records to support Sender ID spam filtering. Module 6 provides
more information on SPF records. Additionally, some organizations use reverse lookups as
an option for spam filtering, so you should consider adding reverse lookup records for all
SMTP servers that send your organizations email.
Preparing AD DS for Exchange Server 2010
To install Exchange Server 2010, you need to run the Exchange Server 2010 setup command for preparing
the Active Directory forest for the installation. You can use the setup command with the following
switches.
Setup switch Explanation
/PrepareAD Prepares the global Exchange Server objects in Active Directory, creates
/OrganizationName: the Exchange Universal Security Groups in the root domain, and
organizationname prepares the current domain
Must be run by a member of the Enterprise Admins group
/PrepareLegacy Necessary if the organization contains Exchange Server 2003 servers
ExchangePermissions 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
/PrepareDomain Prepares the domain for Exchange Server 2010 by creating a new
/PrepareDomain global group in the Microsoft Exchange System Objects container
domainname called Exchange Install Domain Servers
/PrepareAllDomains Not required in the domain where /PrepareAD is run
Can prepare specific domains by adding the domains fully qualified
domain name (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 Active Directory forest in the same domain and the same site
as the domain controller that hosts the Schema Master role.
Options for Preparing Active Directory

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 Active Directory 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 Active
Directory schema changes are implemented during the install.
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 right permissions, the
/PrepareAD process also configures the legacy permissions and makes the required schema changes.
Functions Performed by /PrepareAD

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 Active Directory, and
populates the container with all the child containers required to install Exchange Server 2010
computers.
Creates a new OU in the Active Directory 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. Module 9, Securing Exchange Server 2010
details these groups and RBAC.
Demonstration: Integration of AD DS and Exchange Server 2010
In this demonstration, you will review the integration of AD DS and Exchange Server 2010.
Demonstration Steps
1. On a domain controller, open Active Directory Users and Computers.
2. In the Active Directory domain, expand the Microsoft Exchange Security Groups organizational
unit.
3. Review the description and membership of the following Active Directory groups:
Organization Management
Recipient Management
View-Only Organization Management
Discovery Management
4. Open ADSI Edit, and connect to the domain partition. Review the information in the domain
partition.
5. Connect to the configuration partition. Review the information in the configuration partition, and in
the CN=Services, CN=Microsoft Exchange, CN=Exchangeorganizationname container.
6. Connect to the schema partition. Review the information in the schema partition, and point out the
attributes and class objects that begin with ms-Exch.
Question: How do you assign permissions in your Exchange organization? How will you
assign permissions by using the Exchange security groups?
Question: Which Active Directory partition would you expect to contain the following
information?
Users email address
Exchange connector for sending email to the Internet
Exchange Server configuration

Lesson 2
Installing Exchange Server 2010 Server Roles
Before you install Exchange Server 2010, you need to understand the concept of Exchange Server 2010
server roles. Each server role provides a specific set of functionality that an Exchange Server organization
requires.
When you install Exchange Server 2010, you can install all server roles on the same computer, except for
the Edge Transport server role. Alternately, you can distribute the roles across multiple computers. After
you decide which server role to deploy in each Exchange server, you must ensure that the network
infrastructure and servers are ready for the Exchange Server 2010 installation.

Describe the server roles included in Exchange Server 2010.
Describe the options for deploying Exchange Server 2010.
Describe the hardware recommendations for combining server roles in Exchange Server 2010.
Describe the options for integrating Exchange Server 2010 and Exchange Online Services in Microsoft
Office 365.
Describe the infrastructure requirements for installing Exchange Server 2010.

Describe the server requirements for installing Exchange Server 2010.
Describe the considerations for deploying Exchange Server 2010 servers as virtual machines.
Describe the process for installing Exchange Server 2010.
Describe the options for performing an unattended installation.

Overview of Server Roles in Exchange Server 2010
Exchange Server 2010 provides functionality that falls into five separate server roles. When you install
Exchange Server 2010, you can select one or more of these roles for installation on the server. Large
organizations might deploy several servers with each role, whereas a small organization might combine all
server roles except the Edge Transport server role on one computer, because of different configuration
storage it uses, which will be discussed later.
Note Exchange Server 2010 server roles are a logical grouping of features and
components that perform a specific function in the messaging environment. You can install
all server roles, except the Edge Transport server role, on the same physical computer.
Exchange Server 2010 Server Roles

The following server roles are included in Exchange Server 2010:
Hub Transport server role. The Hub Transport server role is responsible for message routing. The Hub
Transport server performs message categorization and routing, and handles all messages that pass
through an organization. You must configure at least one Hub Transport server in each Active
Directory site that contains a Mailbox server or a Unified Messaging server, and the server running the
Hub Transport server role must be a member of an Active Directory domain.
Mailbox server role. The Mailbox server role is responsible for managing mailbox and public folder
databases. Mailboxes and public folders reside on the Mailbox servers. Mailbox servers contain
mailbox and public folder databases. You can enable high availability by adding mailbox servers to a
Database Availability Group (DAG). Because Mailbox servers require Active Directory access, you must
install this role on a member server in an Active Directory domain.
Client Access server role. The Client Access server role enables connections from all available client
protocols to the Exchange Server mailboxes. You must assign at least one Client Access server in each
Active Directory site that contains a Mailbox server. Client protocols that connect through a Client
Access server include:
Messaging Application Programming Interface (MAPI) clients
Outlook Web App clients
Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) clients
Outlook Anywhere, which is known as remote procedure call (RPC) over HTTP in Exchange
Server 2003
Exchange ActiveSync clients
Note In previous Exchange Server versions, MAPI clients connect directly to the Mailbox
servers. In Exchange Server 2010, all clients, including MAPI clients, connect to the Client
Access servers. MAPI clients still connect directly to Mailbox servers when accessing public
folders.
Edge Transport server role. The Edge Transport server role is the Simple Mail Transport Protocol
(SMTP) gateway server between your organization and the Internet. To ensure security, you should
deploy the computer that runs the Edge Transport server role in a perimeter network, and it should
not be a member of your internal Active Directory forest. Because the Edge Transport server is not
part of an Active Directory domain, it cannot use AD DS to store configuration information. Instead, it
uses AD LDS on Windows Server 2008 computers to access recipient and configuration information.
On the Edge Transport server, you create connectors to define message-flow paths into, and out of,
your organization. You can define multiple Edge Transport servers to provide load balancing and high
availability.
Note You cannot combine the Edge Transport server role with any other role on the same
computer. The Hub Transport and Edge Transport servers both provide message routing
and delivery capabilities to, and from, the Internet. However, some advanced transport
features are available only on Edge Transport servers.
Unified Messaging server role. The Unified Messaging server role provides the foundation of services
that integrate voice and fax messages into your organizations messaging infrastructure. This role
requires the presence of three server roles: Hub Transport, Client Access, and Mailbox. The Unified
Messaging server provides access to voice messages and faxes.
Deployment Options for Exchange Server 2010
You can deploy the server roles in Exchange Server 2010 in several different scenarios, depending on an
organizations size and requirements. If you are an administrator, it is important to understand the
deployment scenarios when you plan an Exchange Server system.
Exchange Server 2010 Editions

Exchange Server 2010 is available as Standard Edition and Enterprise Edition. The Standard Edition should
meet the messaging needs of small and medium corporations, but also may be suitable for specific server
roles or branch offices. The Enterprise Edition is for large enterprise corporations, and enables you to
create additional databases apart from including other advanced features.
Feature Standard Edition Enterprise Edition
Database Support Five databases 100 databases
Database Storage No software storage limit; storage No software storage limit; storage limit is
Limit limit is hardware dependent hardware dependent
DAG membership Supported Supported
Note If you want to use databases larger than 1TB on Exchange Server 2010 Standard
Edition, you have to enable it in the registry. To learn how to modify the registry for this
purpose, go to http://go.microsoft.com/fwlink/?LinkId=248378.
Exchange Server 2010 Client Access Licenses

Exchange Server 2010 has two client-access license (CAL) options:
Exchange Server Standard CAL. Provides access to email, shared calendaring, Outlook Web App, and
ActiveSync.
Exchange Server Enterprise CAL. Requires a standard CAL, and provides access to additional features
such as unified messaging, per-user and per-distribution-list journaling, managed custom email
folders, and Microsoft Forefront Endpoint Protection for Exchange Server.
Deployment Scenarios for a Simple Organization

In a small organization, you can install all the server rolesexcept the Edge Transport server roleon a
single computer. Small organizations might also consider using Exchange Online services.
Deployment Scenarios for a Standard Organization

Medium-sized organizations should consider installing the required services and Exchange server roles on
multiple computers. A typical deployment scenario for a medium-sized organization may include:
Two domain controllers for each domain.
Two Exchange servers configured with the Mailbox server role and other server roles, except the Edge
Transport server role.
Note In Exchange Server 2007, Mailbox servers that were part of a failover cluster could
not run additional Exchange server roles. With Exchange Server 2010, Exchange servers that
are part of a DAG also can host other Exchange server roles, except the Edge Transport
server role.
One Exchange server configured with the Edge Transport server role.
Note You can add only Exchange Server 2010 running on Windows Server 2008 Enterprise
Edition or Datacenter Edition or Windows Server 2008 R2 Enterprise Edition or Datacenter
Edition to a DAG. If a standard organization uses the Windows Server 2008 or Windows
Server 2008 R2 Standard Edition servers, the organization can deploy multiple Mailbox
servers, but cannot configure high availability for the Mailbox server role.
As your organization expands, you should consider adding dedicated servers for roles like the Hub
Transport server, the Client Access server, or the Unified Messaging server. This provides scalability and
redundancy.
Deployment Scenarios for a Large or Complex Organization

A large or complex organization needs to deploy dedicated servers for each server role, and may have to
deploy multiple servers for each role. A typical deployment scenario for a large organization can include:
Two domain controllers and global catalog servers for each organizational domain. If the
organization includes multiple Active Directory sites, and you are deploying Exchange servers in a site,
you should deploy global catalog servers in the site.
One or more Exchange servers configured with the Mailbox server role. You can deploy multiple
Mailbox servers in each Active Directory site.
One or more Exchange servers dedicated to each of the other server roles. You must deploy at least
one Hub Transport server and Client Access server in each Active Directory site that includes a
Mailbox server.
If the organization has a smaller branch office, you can deploy multiple Exchange servers hosting all
the server roles except for the Edge Transport server role, and configure the Mailbox servers to be
part of a DAG.
One or more Exchange servers configured with the Edge Transport server role. Multiple servers
provide redundancy and scalability.
Hybrid Deployment with Office 365

In Exchange Server 2010 Service Pack 2 (SP2), it is possible to create a hybrid deployment between
on-premises Exchange Server and Exchange Online from Office 365. A hybrid deployment offers
organizations the ability to extend the user experience and administrative control they have with their
existing on-premises Microsoft Exchange organization to the Office 365 cloud. A hybrid deployment
provides you with a view of a single Exchange organization between an on-premises organization and a
cloud-based organization. In addition, a hybrid deployment can serve as an intermediate step to moving
completely to a cloud-based Exchange organization.
A hybrid deployment of Exchange Server and Office 365 provides the following features:
Mail routing with a shared domain namespace. For example, both on-premises and cloud-based
organizations use the @contoso.com SMTP domain.
A unified global address list, also called a shared address book. With this address list, users can view
all contacts from both on-premises Exchange and Office 365.
Free/busy and calendar sharing between on-premises and cloud-based organizations.
Centralized control of mail flow. The on-premises organization can control mail flow for the on-
premises and cloud-based organizations.
A single Outlook Web App URL for both the on-premises and cloud-based organizations.
The ability to move existing on-premises mailboxes to the cloud-based organization.
Centralized mailbox management using the on-premises Exchange Management Console.

Message tracking, MailTips, and multi-mailbox search between on-premises and cloud-based
organizations.
In Exchange Server 2010 SP2, there is a Hybrid Configuration Wizard that allows you to perform hybrid
deployment and integrate your local Exchange server with Office 365. Before you start deploying
Exchange in a hybrid scenario, you should make sure that you have a proper Office 365 license. Office 365
is examined in greater detail in Module 13.
Hardware Recommendations for Combining Server Roles
Small and medium-sized companies, and large organizations that have a small number of users in a single
location, may choose to combine multiple Exchange Server 2010 server roles on a single computer.
Combining Server Roles

You can install all roles, except the Edge Transport server role, on a single computer. When you design the
hardware configuration for servers on which you install multiple server roles, consider the following
recommendations:
You should plan for at least two processor cores, at a minimum, for a server with multiple server roles.
The recommended number of processor cores is eight, while 24 is the maximum recommended
number.
You should design a server with multiple roles to use half of the available processor cores for the
Mailbox role and the other half for the Client Access and Hub Transport roles.
You should plan for the following memory configuration for a server with multiple server roles: 8
gigabytes (GB) and between 2 megabytes (MB) and 10 MB per mailbox. This can vary based on the
user profile and the number of storage groups. We recommend 64 GB as the maximum amount of
memory you need.
To accommodate the Client Access and Hub Transport server roles on the same server as the Mailbox
server role, you should reduce the number of mailboxes per core calculation, based on the average
client profile by 20 percent.
You can deploy multiple Exchange server roles on a mailbox server that is a DAG member. This means
that you can provide full redundancy for the Mailbox, Hub Transport, and Client Access server roles
on just two Exchange servers. Be aware, however, that you cannot use DAG together with NLB on the
same servers; therefore, if you want to achieve full redundancy with just two servers, you will need a
hardware load balancer.
Options for Integrating Exchange Server 2010 and Exchange Online

Services in Office 365
One deployment option available in Exchange Server 2010 is to integrate your messaging system with
Exchange Online Services. Exchange Online Services is part of the Office 365 services that Microsoft offers.
Office 365
Office 365 is a set of Microsoft-hosted messaging and collaboration solutions, including Microsoft
Exchange Online, Microsoft SharePoint Online, Microsoft Office Web Apps, and Microsoft Lync Online.
These services are available on a subscription basis.
Exchange Online Services

When you subscribe to Exchange Online Services in Office 365, you can take advantage of the following
features:
Email and calendar functions. Exchange Online delivers email services, including spam filtering,
antivirus protection, and mobile-device synchronization. Through Microsoft Office Outlook and
Outlook Web App, you can use the advanced email, calendar, contact, and task management features
of Exchange Online.
Email coexistence and migration tools. The Office 365 Suite includes email coexistence and migration
tools. If you have AD DS and Microsoft Exchange Server, the Microsoft Online Services Directory
Synchronization tool synchronizes your user accounts, contacts, and groups from your local
environment to Microsoft Online Services. This tool also makes your Microsoft Exchange Global
Address List (GAL) available in Exchange Online.
Exchange Online Services and Exchange Server 2010

Exchange Server 2010 provides additional functionality with Exchange Online Services. With Exchange
Server 2010, you can host some of the mailboxes in an internal Exchange organization, which displays as
the On-Premise Exchange organization in the Exchange Management Console. Additionally, you can host
some of your organizations mailboxes on Exchange Online. You can use the Exchange Management
Console to move mailboxes to the Exchange Online Services and manage those mailboxes.
Infrastructure Requirements for Exchange Server 2010
Before you deploy Exchange Server 2010 in your organization, you need to ensure that your organization
meets AD DS and DNS requirements.
Active Directory Requirements

You must meet the following Active Directory requirements before you can install Exchange Server 2010:
The domain controller that is the schema master must have Windows Server 2003 Service Pack 1
(SP1) or newer, Windows Server 2008, or Windows Server 2008 R2 installed. By default, the schema
master runs on the first Windows domain controller installed in a forest.
In each of the sites where you deploy Exchange Server 2010, at least one global catalog server must
be installed and run Windows Server 2003 SP1 or newer, Windows Server 2008, or Windows Server
2008 R2.
The Active Directory domain and forest functional levels must run Windows Server 2003, at the
minimum.
If you have a resource forest configuration, or multiple forests, and users from different forests need
to access mailboxes in an Exchange 2010 organization, you must configure a trust between the
forests. In this case, the minimum forest functional level must be Windows Server 2003.
DNS Requirements
Before you install Exchange Server 2010, you must configure DNS correctly in your Active Directory forest.
All servers that run Exchange Server 2010 must be able to locate Active Directory domain controllers,
global catalog servers, and other Exchange servers.
Server Requirements for Exchange Server 2010
Exchange Server 2010 requires a minimum level of hardware, and specific software, before you can
install it.
Hardware Requirements
You can deploy Exchange Server 2010 only on 64-bit versions of Windows Server 2008 or Windows
Server 2008 R2 that are running on 64-bit hardware.
Resource Requirement
Processor x64 architecture-based computer with Intel processor that supports Intel 64
architecture (formerly known as Intel EM64T).
AMD processor that supports the AMD64 platform.
Intel Itanium IA64 processors not supported.
Memory A minimum of 2 GB of system memory, plus 2 to 6 MB per mailbox. This
recommendation is based on the number of mailbox databases and the user-usage
profile.
Disk 1.2 GB disk space for Exchange Server files and 200 MB of free disk space on the
system drive.
File system Drives formatted with NTFS file systemfor all Exchange Serverrelated volumes.
Note Exchange Server 2010 is available only in 64-bit versions, which means that you can
install all components, including the Exchange Management tools, only on 64-bit operating
systems.
Exchange Server 2010 Prerequisite Software

All Exchange Server 2010 servers must have the following software installed:
Active Directory Domain Services (AD DS) management tools, which is required on all Exchange
Server 2010 servers, except for Edge Transport servers
Microsoft .NET Framework 3.5 (SP1) or newer
Windows Remote Management (WinRM)
Windows PowerShell Version 2
Note The Net.Tcp Port Sharing Service must be configured to start automatically before
starting the Exchange server installation. This will be configured as a part of the setup
process in Exchange Server 2010 SP1 or later.
On Windows Server 2008 R2 all these software components can be installed from Server Manager.
However, on Windows Server 2008, you should manually download and install them. Exchange Server
2010 SP2 setup provides the appropriate download links for missing software, and also enables automatic
installation of missing software components during Exchange installation.
Server Role Installation Requirements

Each server role in Exchange Server 2010 has slightly different installation requirements. All server roles,
except for the Edge Transport server role, require some Web Server components, such as Internet
Information Services (IIS).
The following table summarizes the requirements for each server role.
Server Role Software Requirements
Mailbox server role 2010 Office System Converter: Microsoft Filter Pack
Install the default Web Server (IIS) server role along with the following
role services:
IIS 6 Metabase Compatibility
IIS 6 Management Console
Basic Authentication
Windows Authentication
.NET Extensibility
Client Access server Install the default Web Server (IIS) server role and the following role
role services:
ISAPI Extensions
Digest Authentication
Dynamic Content Compression
.NET Extensibility
Install the Windows Communication Foundation (WCF) HTTP
Activation feature
Install the RPC over HTTP Proxy feature
(continued)
Server Role Software Requirements
Hub Transport server Install the default Web Server (IIS) server role and the following role
role services:
.NET Extensibility
Edge Transport server Must have a DNS suffix configured

role Install the AD LDS server role
Unified Messaging Install the Desktop Experience feature. This installs the required
server role Microsoft Windows Media Player audio/video codecs.
Install the default Web Server (IIS) server role and the following role
services:
.NET Extensibility
Note Installing Exchange Server 2010 on a Windows Server 2008 computer might add
additional roles or role services to the server. For example, when you perform a typical
installation, the File Server server role is added along with additional Web Server (IIS) role
services.
Installation Requirements for Installing Management Tools on Windows Vista or

Windows 7
You can install the Exchange Server 2010 management tools on computers that are running 64-bit
versions of Windows Vista or Windows 7. Before installing the management tools, you will need to
ensure that the following components are installed:
Microsoft .NET Framework 3.5 Service Pack 1or later
Windows Remote Management (WinRM)
Windows PowerShell Version 2

Considerations for Deploying Exchange Server 2010 As a Virtual Machine
One option with Exchange Server 2010 is to deploy the servers as virtual machines.
Benefits of Using Virtual Machines

Deploying Exchange Server 2010 servers as virtual machines provides the same advantages as deploying
other servers as virtual machines. You can deploy all Exchange Server 2010 SP2 server roles as virtual
machines.
The benefits of deploying Exchange Servers as virtual machines include:
Increases hardware utilization and decreases the number of physical servers. In many organizations,
the servers deployed in data centers have very low hardware utilization. Frequently, servers use less
than 10 percent of the available hardware resources. By deploying multiple virtual machines on a
single physical server, you can increase the hardware utilization, while decreasing the number of
physical servers deployed. This can result in significant cost savings.
Deploying Exchange Servers as virtual machines provides server-management options that are not
available for physical servers. Because virtual machines are just a set of files, you may have additional
management options with virtual machines. For example, to increase a virtual machines hardware
level, you can assign more of the host resources to the virtual machine, or move the virtual machine
files to a more powerful host server.
Note Microsoft supports Exchange Server 2010 running as virtual machines for all
virtualization vendors that are validated through the Windows Server Virtualization
Validation Program. See http://go.microsoft.com/fwlink/?LinkId=248379 for details.
Microsoft supports Exchange Server 2010 in production on hardware virtualization software only when all
the following conditions are true:
The hardware virtualization software is running one of the following:
Windows Server 2008 with Hyper-V technology
Windows Server 2008 R2 with Hyper-V technology

Microsoft Hyper-V Server 2008
Microsoft Hyper-V Server 2008 R2
Any third-party hypervisor that has been validated under the Windows Server Virtualization
Validation Program.
The Exchange Server guest virtual machine is running Microsoft Exchange 2010. This includes
Exchange 2010 Hosting Mode, available in Exchange 2010 SP1 or later.
The Exchange Server guest virtual machine is deployed on Windows Server 2008 with SP2 (or later) or
Windows Server 2008 R2 RTM or later.
Considerations for Deploying Exchange Server 2010 Servers as Virtual Machines

While running Exchange Server 2010 as a virtual machine provides some benefits, you also should
consider the following issues:
Exchange servers can be designed to ensure that that the servers fully utilize the available hardware.
For example, in a large organization, you can deploy several thousand mailboxes to a Mailbox server
or deploy a Client Access server with sufficient client connections so that your organization fully
utilizes all hardware resources.
One of the benefits of running virtual machines is that you can configure high availability within the
virtual machine environment. For example, you can deploy Quick Migration in Windows Server 2008
Hyper-V or Live Migration in Windows Server 2008 R2 Hyper-V. However, Microsoft does not support
running both DAGs and a virtual machine-based high availability solution. If you require high
availability, you should use the Exchange Server 2010 solution. DAGs provide failover features that are
not available in virtual machine-based, high-availability solutions. Some of the DAG features include
multiple copies of the database, backing up the database on the passive node, and application-aware
clustering.
The storage used by the Exchange Server guest machine can be virtual storage of a fixed size, SCSI
pass-through storage, or Internet SCSI (iSCSI) storage. Pass-through storage is storage that is
configured at the host level and dedicated to one guest machine. To provide the best performance
for Exchange server storage, use either pass-through disks or fixed-size virtual disks.
You must allocate sufficient storage space for each Exchange Server guest machine on the host
machine for the fixed disk that contains the guest's operating system, any temporary memory storage
files in use, and related virtual machine files that are hosted on the host machine. Additionally, for
each Exchange Server guest machine, you must also allocate sufficient storage for the message
queues on Hub Transport and Edge Transport servers and sufficient storage for the databases and log
files on Mailbox servers. You should host the storage used by Exchange Server in disk spindles that
are separate from the storage that is hosting the guest virtual machine's operating system.
You can deploy only management software such as antivirus software, backup software, virtual
machine management software, and so on, on the physical root machine. You should not install any
other server-based applications such as Exchange Server, Microsoft SQL Server, AD DS, and so on,
on the root machine. The root machine should be dedicated to running guest virtual machines.
Running Exchange servers as virtual machines can complicate performance monitoring. The
performance data between the host and virtual machine is not consistent because the virtual machine
uses only some part of the hosts resources.
One of the most common performance bottlenecks for Mailbox servers is network input/output (I/O).
When you run Mailbox servers in a virtual environment, the virtual machines have to share this I/O
bandwidth with the host machine and other virtual machine servers deployed on the same host. If a
single virtual machine is running on the physical server, the network I/O that is available to the virtual
machine is almost equivalent to the I/O available to a physical server. A heavily utilized Mailbox server
can consume all of the available I/O bandwidth, which makes it impractical to host additional virtual
machines on the physical server.
If you are planning to deploy Exchange Server 2010 as a virtual machine, ensure that you plan the
virtual hardware requirements carefully. Running Exchange Server 2010 as a virtual machine does not
change the Exchange Server hardware requirements. You must assign the same hardware resources to
the Exchange Server virtual machine as you would assign to a physical server that is running the same
workload.
Process for Installing Exchange Server 2010
The Exchange Server 2010 graphical setup program guides you through the installation process. The
following steps provide a high-level installation overview:
1. Install the prerequisite software. For all server roles, you must install Microsoft .NET Framework 3.5, or
later, Windows Remote Management (WinRM) 2.0, and Windows PowerShell version 2. If you install
Exchange Server on Windows Server 2008 R2, the correct versions of Windows PowerShell and
Windows Remote Management are installed already.
2. To start the installation, run setup.exe from the installation source. The setup program checks to
ensure that the correct software is installed on the computer. If prerequisite software is not installed,
you can use the links provided on the Start page to download and install the software.
3. The setup program provides the option to install additional language packs that will enable the
Exchange Server 2010 management tools to display in languages other than English.
4. The setup program provides the option to perform a Typical Exchange Server Installation or a
Custom Exchange Server Installation. The typical installation option installs the Hub Transport
server role, the Client Access server role, the Mailbox server role, and the Exchange Management
tools. The custom installation option allows you to choose the roles you want to install.
Choose this option if you want to install an Edge Transport server or a Unified Messaging server,
or install just the Exchange Management Tools.
5. If this is the first Exchange Server 2010 server in the deployment, and you do not run setup
/PrepareAD, you are prompted for the Exchange organization name.
6. If you chose the Mailbox server role, the Exchange setup program prompts you if you have any Office
Outlook 2003 or Entourage clients in the organization. If you choose Yes, Exchange setup creates the
public folders required by these clients for the offline address book and for sharing calendar
information.
7. If you choose to install the Client Access server role, you also can configure the external domain name
for the Client Access server. Clients use this external domain name to connect to the server from the
Internet.
Note Exchange Server 2010 supports Office Outlook 2003 SP1 or later clients. The only
Entourage version supported by Exchange Server 2010 is Entourage 2008, Web Services
Edition. This version of Entourage requires public folders.
Exchange Server setup program then checks that the organizational prerequisites and server
prerequisites are met for each server role that you select. If all the prerequisites are met, Exchange
Server 2010 is installed on the computer. If this is the first Exchange server in the organization, and
you have not run /PrepareAD, Exchange Server setup modifies AD DS, and then installs each selected
server role.
You can use the Exchange Server 2010 Service Pack Setup wizard to upgrade your current version of
Exchange Server 2010. If you have the RTM version of Exchange Server 2010 installed, you can upgrade to
either Exchange Server 2010 Service Pack 2 (SP2) or Exchange Server 2010 Service Pack 1 (SP1). If you
have Exchange Server 2010 SP1 installed, you can upgrade to Exchange Server 2010 SP2. We strongly
recommended that you upgrade to Exchange 2010 SP2.
Unattended Installation Options
You can use the command line to perform an unattended Exchange Server 2010 installation. When you
use the command line, you can use parameters to install specified roles or configure other setup options.
The table below lists the most commonly used command-line setup parameters.
Parameter Options Explanation
/mode, /m Install Use this parameter to control what the

Upgrade setup program does.
Uninstall You can use the Upgrade mode only to
upgrade from a previous prerelease
RecoverServer
version of Exchange Server 2010.
Default: Install
/roles, /r The following is the list of valid Use this parameter to specify which
role names: roles you want to install. If you specify
HubTransport, HT, H multiple roles, separate them with
commas. Note that you cannot
ClientAccess, CA, C
combine the Edge Transport role with
EdgeTransport, ET, E any other.
Mailbox, MB, M
UnifiedMessaging, UM, U
ManagementTool, MT, T
/OrganizationName Use the parameter to specify the name

organizationname to give the new Exchange organization.
This parameter is required if you are
installing the first server in an
organization and you have not run
/PrepareAD.
(continued)
Parameter Options Explanation
/targetdir, /t A valid path Use this parameter to specify in which

folder to install Exchange Server.
Default: %%programfiles%%
\Microsoft\Exchange Server.
/PrepareAD, /p None Use this parameter to prepare AD DS

for installation.
/DomainController, /dc The name of a suitable domain Use this parameter to specify which
controller domain controller setup will be read
and written from during installation.
/NewProvisionedServer, Server name Use this parameter to create a

/nprs placeholder server object in AD DS so
that you can delegate setup of a
server.
/ServerAdmin User or group Use this parameter to specify an

account that will have permissions to a
provisioned Exchange server.
/Hosting Use this parameter to install and

enable hosting functionality and
features. For example, to specify the
Hosting mode, specify the following:
Setup.com /roles: Mailbox /Hosting.
This parameter is available for multi-
tenant deployments. It is not available
for on-premises deployments.
Note To run an unattended installation with setup parameters, you must run setup.com or
setup rather than setup.exe. To see all the parameters available for use with setup.com, run
the command with the /? parameter.
The following is the syntax for this command.
Setup.com [/roles:<roles to install>] [/mode:<setup mode>] [/console]

[/?][/targetdir:<destination folder>] [/prepareAD] [/domaincontroller]
For example, if you want to install Exchange Server 2010 into the default path, and specify the roles of
Hub Transport, Client Access, and Mailbox, you would enter the following command.
Setup.com /r:H,M,C
Additionally, you should consider using the /InstallWindowsComponents switch with Setup.com, which
will automatically add required roles and features for Exchange Server. You can use this switch in
Exchange Server 2010 SP1 or later.
Lab A: Installing 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. In Hyper-V Manager, click 10135B--NYC-DC1, and in the Actions pane, click Start.
10135B- NYC-DC1: Domain controller in the Contoso.com domain.
3. In the Actions pane, click Connect. Click the CTRL+ALT+DELETE button in the top-left corner of the
Virtual Machine Connection window.
4. Log on using the following credentials:
User name: Administrator
Password: Pa$$w0rd
Domain: Contoso
5. Repeat these steps to start, and log on to the 10135B-NYC-SVR1 virtual machine.
10135B- NYC-SVR1: Member server in the Contoso.com domain.
Lab Scenario
You are working as a messaging administrator in Contoso Ltd. Your organization is preparing to install its
first Exchange Server 2010 server. Contoso Ltd. is a large multinational organization that includes offices
in Seattle, Washington, in the United States, and in Tokyo, Japan.
Contoso Ltd. does not have a previous version of Exchange Server deployed so you do not have to
upgrade a previous messaging system. Before installing Exchange Server 2010, you must verify that the
Active Directory environment is ready for the installation. You also must verify that all computers that will
run Exchange Server 2010 meet the prerequisites for installing Exchange.
Exercise 1: Evaluating Requirements for an Exchange Server Installation

Scenario
The Active Directory administrators at Contoso Ltd. are testing the Exchange Server 2010 deployment by
deploying a domain controller in a test environment. The server administration team has deployed a
Windows Server 2008 R2 server that you can use to deploy the first Exchange Server 2010 server in the
test organization.
You need to verify that the Active Directory 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?
Active Directory domain controllers: Windows Server 2003 Yes or No

SP2 or later
Active Directory domain and forest functional level: Yes or No

Windows Server 2003 or higher
DNS requirements Yes or No
Exchange Server 2010 schema changes Yes or No
Active Directory Domain Services (AD DS) management Yes or No

tools
Microsoft .NET Framework 3.5 or later Yes or No
Windows Remote Management (WinRM) Yes or No
Windows PowerShell Version 2 Yes or No
2010 Office System Converter: Microsoft Filter Pack Yes or No
Web Server (IIS) server role along with the following role Yes or No
services:
ISAPI Extensions
Digest Authentication
Dynamic Content Compression
.NET Extensibility
Windows Server 2008 features Yes or No
WCF HTTP Activation
RPC over HTTP Proxy
The main tasks for this exercise are:
1. Evaluate the Active Directory requirements.
2. Evaluate the DNS requirements.

3. Evaluate the server requirements.
X Task 1: Evaluate the Active Directory 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.
X Task 2: Evaluate the DNS requirements

On NYC-SVR1, use Ipconfig, Ping, and NSLookup to evaluate DNS name resolution functionality.
X Task 3: Evaluate the server requirements

1. On NYC-SVR1, evaluate whether the required Windows Server 2008 features, including the required
AD DS administration tools, are installed.
2. Evaluate whether the Microsoft Internet Information Services (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.
Exercise 2: Preparing for an Exchange Server 2010 Installation

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.
1. Install the Windows Server 2008 server roles and features.
2. Prepare AD DS for the Exchange Server 2010 installation.
X Task 1: Install the Windows Server 2008 server roles and features
1. On NYC-SVR1, in Server Manager, install the prerequisite server roles and features for Exchange
Server 2010.
2. Configure the Net.Tcp Port Sharing Service to start Automatically.

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

1. In Hyper-V Manager, connect C:\Program Files\Microsoft Learning
\10135\Drives\Exchange2010SP2.iso as the DVD drive for NYC-SVR1.
2. From a command prompt, run the Exchange Server setup program with the /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.
Exercise 3: Installing Exchange Server 2010

Scenario
After you prepare the environment, continue with the Exchange Server 2010 server installation.
The main task for this exercise is:

Install Microsoft Exchange Server 2010.
X Task 1: Install Microsoft Exchange Server 2010

1. Start the Exchange Server 2010 installation.
2. Perform a Typical Exchange Server Installation.
3. Choose to automatically install required roles and features.
4. Choose to enable access for Outlook 2003 or Entourage clients.
Results: After this exercise, you should have prepared the AD DS and server configuration for the
Exchange Server 2010 installation.
Lesson 3
Completing an Exchange Server 2010 Installation
After you install the necessary server roles in Exchange Server 2010, you should verify the installation
and perform post-installation tasks, including securing Exchange Server 2010 and installing additional
third-party software, if necessary. This lesson describes the post-installation tasks that you should perform.
Verify an Exchange Server 2010 installation.

Verify an Exchange Server 2010 deployment.
Describe how to troubleshoot an Exchange Server 2010 installation.
Describe how to finalize an Exchange Server 2010 installation.

Demonstration: Verifying an Exchange Server 2010 Installation
If all prerequisites are met, the Exchange Server installation should complete successfully. However, you
should verify that the installation was successful.
Demonstration Steps
1. On VAN-EX1, open the Services management console, and review the Microsoft Exchange services
that were added during the installation.
2. Open Windows Explorer, and browse to C:\ExchangeSetupLogs.

3. Review the contents of the ExchangeSetup.log file.
4. Describe some of the other files in this folder.
5. Browse to C:\Program Files\Microsoft\Exchange Server\V14. Describe the contents of the folders

in this location.
6. Open the Exchange Management Console.
7. Under Server Configuration, verify that the server that you installed is listed.
8. Click Toolbox and review the installed tools.
9. In the left pane, click Recipient Configuration. Create a new mailbox.
10. Open Windows Internet Explorer, and connect to the Outlook Web App site on a Client Access
server. Log on using the credentials for the new mailbox that you created.
11. Send an email to the mailbox that you created. Verify that the messages delivery.
Additional Tests to Verify Installation

After the Exchange Server 2010 installation finishes, you also can take the following steps to verify that the
installation was successful:
Check the Exchange setup log files. The installation process creates several log files that the
C:\ExchangeSetupLogs directory stores. Review the setup logs for errors that occur during installation.
Ensure that the Exchange Management Console opens and displays the installed Exchange server.
Create a user account with a mailbox and connect to that mailbox by using an Office Outlook client
or Outlook Web App.
Note For detailed information about each of the log files created during the installation,
see Exchange Server Help.
Demonstration: Running the Exchange Best Practices Analyzer
The Microsoft Exchange Server Best Practices Analyzer Tool automatically examines an Exchange Server
deployment and determines whether the configuration meets with Microsoft best practices. Microsoft
performs periodic updates on the definitions that the Exchange Server Best Practices Analyzer uses, so
they typically reflect the latest version of the Microsoft best practices recommendations. We recommend
running the Exchange Server Best Practices Analyzer after you install a new Exchange server, upgrade an
existing Exchange server, or make configuration changes. You can find the Exchange Server Best Practices
Analyzer in the Toolbox node of the Exchange Management Console.
In this demonstration, your instructor will run the Exchange Server Best Practices Analyzer and review the
generated reports.
Note For more information about the Exchange Server Best Practices Analyzer, view the
Exchange Server Best Practices Analyzer Help that is available with the Exchange Server Best
Practices Analyzer Tool.
Demonstration Steps
1. On VAN-EX1, open Exchange Management Console, and then click Toolbox.
2. Start the Best Practices Analyzer, and clear the options to check for updates and to join the
customer improvement program. Go to the Welcome page.
3. Start a new scan. Choose to perform a Health Check scan to scan the server that you just installed.
4. When the scan finishes, view the following tabs and reports:
Critical Issues
All Issues
Recent Changes
Informational Items
Tree reports
Other reports
Troubleshooting an Exchange Server 2010 Installation
The Exchange Server installation should complete successfully if you meet all prerequisites. However, if the
installation does not complete properly, it is important for you to follow a consistent troubleshooting
process as this ensures that you do not miss steps and problems are resolved quickly.
Your troubleshooting process should include the following best practices:
1. Identify the problem. Before you begin to apply any fixes to your Exchange Server installation, be sure
that you identify exactly what is the problem. Applying inappropriate fixes could create additional
problems. To identify an installation problem you should check the setup and event logs for errors.
2. Identify potential fixes for the problem. You cannot always fix problems by using the most obvious
solution. Your search for potential fixes should be methodical and include multiple sources, such as
Microsoft TechNet, the Microsoft Knowledge Base, and suggestions in event logs.
After you identify a list of potential fixes, prioritize them based on how likely they are to fix the
problem and how long implementation will take. In most cases, try quick fixes before long and
involved fixes, even if the longer fix is more likely to resolve the problem.
3. Test only one fix at a time. It is essential that you test only one fix at a time. Do not implement three
fixes, and then see if the problem is fixed. Implementing one fix at a time ensures that you
understand what solution fixed the problem. When you implement multiple fixes, the first fix may
resolve the problem, but another one may introduce additional problems.
When you implement a fix, be sure to document the changes you make. Then, if the fix does not
resolve the problem, you can undo the changes before trying another solution.
4. Document the problem resolution. Documentation is an essential part of problem resolution. If the
same problem occurs later, documentation of the previous solution makes it easier to address the
current issue. Disseminating that knowledge to others in the organization may prevent the problem
from occurring again.
Potential Problems and Resolutions

Some common installation problems and solutions are:
Net.TCP Port Sharing Service is not set to start automatically. You must set this service to start
automatically.
Insufficient disk space. Your server might not have the necessary disk space to install Exchange Server
2010. To resolve this, either increase your servers disk space or remove unnecessary files to create
more free space.
Missing software components. Your server might not have all of the required software components for
the server roles you want to implement. To resolve this, determine the required software components,
download them if necessary, and install them.
Incorrect DNS configuration. Exchange Server 2010 relies on global catalog servers to perform many
operations, and uses DNS to find global catalog servers. If the DNS configuration is incorrect, your
server might not be able to find a global catalog server. To verify the problem, use the dcdiag tool. To
resolve the problem, ensure that the Exchange server and domain controllers are all using the
appropriate internal DNS servers.
Incorrect domain functional level. All domains with Exchange Server 2010 recipients or servers must be
at Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003 functional level. To
resolve this problem, raise the domain functional level to the appropriate functional level.
Insufficient Active Directory permissions. When you install Exchange Server 2010, you need sufficient
permissions to extend 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. You also must run Setup.exe with the
/PrepareLegacyExchangePermissions switch. Wait for replication throughout the Exchange Server
organization before you continue.
Finalizing the Exchange Server Installation
After finishing the Exchange Server installation, you might need to perform additional steps to finalize the
server deployment.
Configuring Exchange Server Security

Security is important for all the servers in your environment. However, security is even more important for
computers that are running Exchange Server. For most organizations, messaging is a critical part of the
network. People rely on messaging to perform their jobs. Sensitive and private information often is sent
through, and stored in, the messaging system. Unlike many other servers, computers that are running
Exchange Server all communicate with the Internet in some way. Even Mailbox servers with no direct
Internet communication are exposed to messages that originally came from the Internet.
Use the following steps to secure computers that are running Exchange Server 2010:
Restrict physical access. Like all servers, physical access to a computer that is running Exchange Server
should be restricted. Any server that you can access physically also can be compromised easily.
Restrict communication. You can use firewalls to restrict the communication between servers, and
between servers and clients. Limiting communication to only specific IP addresses, or ranges of IP
addresses, reduces the risk that a hacker will access or modify the system. An Edge Transport server
must be available to anonymous Internet connections, but firewalls can restrict access to specific
ports.
Reduce the attack surface. To limit software flaws that hackers can use, eliminate unnecessary software
and services from your Exchange servers. In particular, Edge Transport servers should have only the
necessary services and software running because they are exposed to the Internet.
Restrict permissions. Evaluate who has permissions to manage Active Directory in your organization.
Users who are domain administrators can add themselves to any group, and so they could manage all
Exchange Server recipients and computers that are running Exchange Server in that domain. Reduce
delegated Active Directory management permissions in a more granular way if you do not want all of
the domain administrators to be capable of managing Exchange Server as well.
Configure Additional Software

Before you install any additional software, ensure that Microsoft certifies it for use with Exchange
Server 2010. Failure to verify certification for Exchange Server 2010 could result in data or availability loss.
Products specifically designed for use with Exchange Server 2010 take advantage of new features.
Some of the additional software you might want to install or configure includes:
Antivirus software. Antivirus software can be used with the Edge Transport server and internal servers.
You can install Forefront Protection for Exchange Server on Exchange Server 2010, or deploy and
configure non-Microsoft antivirus solutions.
Anti-spam software. Anti-spam software can significantly reduce unsolicited commercial email
messages that your users receive, and have to manage. Exchange Server 2010 provides anti-spam
features on the Edge Transport server role and the Hub Transport server role. Most organizations that
deploy anti-spam software on Exchange Server 2010 will deploy it on the Edge Transport server, but
you also can enable and configure anti-spam features on Hub Transport servers. Many organizations
choose to deploy third-party anti-spam solutions.
Backup software. To back up Exchange Server 2010 servers, you must deploy backup software that
uses Volume Shadow Copy Service (VSS) to perform the backup.
Monitoring tools and agents. One example of a monitoring tool is Microsoft System Center
Operations Manager. Operations Manager allows you to proactively monitor and manage your
Exchange servers by installing monitoring agents on them.
Note There are additional tasks that you must perform for each server role. Later modules
cover these tasks.
Lab B: Verifying an Exchange Server 2010 Installation
Lab Setup
2. Ensure that the 10135B-NYC-DC1 and the 10135B-NYC-SVR1 virtual machines are running.
10135B- NYC-DC1: Domain controller in the Contoso.com domain.
10135B- NYC-SVR1: Member server in the Contoso.com domain.
3. If required, connect to the virtual machines.
Lab Scenario
You have completed the installation of the first Exchange Server at Contoso Ltd. You now need to verify
that the installation completed successfully. You also should ensure that the installation meets the best
practices that Microsoft suggests.
Exercise 1: Verifying an Exchange Server 2010 Installation

1. View the Exchange Server services.

2. View the Exchange Server folders.
3. Create a new user, and send a test message.
4. Run the Exchange Server Best Practices Analyzer Tool.

X Task 1: View the Exchange Server services

1. Open the Services console.
2. Review the status for each Exchange Server service.
X Task 2: View the Exchange Server folders.

Using Windows Explorer, browse to C:\Program Files\Microsoft\Exchange Server\v14. This list of
folders includes ClientAccess, Mailbox, and TransportRoles. The three roles were installed as part of
the typical setup.
X Task 3: Create a new user, and send a test message

2. Under Recipient Configuration, create a new mailbox with a new user account named TestUser and
a password of Pa$$w0rd.
3. Using Internet Explorer, open https://NYC-SVR1/owa.
4. Log on as TestUser, and send a message to Administrator.
5. Log on to Outlook Web App as Administrator, and verify that the message was delivered.
X Task 4: Run the Exchange Server Best Practices Analyzer tool

1. Start the Exchange Server Best Practices Analyzer.
2. Run a Health Check scan with a name of Post-Installation Test. Scan only
NYC-SVR1.
3. Review the information in the Exchange Server Best Practices Analyzer report.
Results: After this exercise, you should have verified that the Exchange Server 2010 server installation
completed successfully.
X 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 the virtual machine name in the Virtual Machines list, and then click Revert.
3. In the Revert Virtual Machine dialog box, click Revert.
4. In the Virtual Machines pane, click 10135B-VAN-DC1, and then in the Actions pane, click Start.
5. To connect to the virtual machine for the next modules lab, click 10135B-VAN-DC1, and then in the
Actions pane, click Connect.
Important Start the VAN-DC1 virtual machine first, and ensure that it is fully started
before starting the other virtual machines.
6. Wait for 10135B-VAN-DC1 to start, and then start 10135B-VAN-EX1. Connect to the virtual machine.
7. Wait for 10135B-VAN-EX1 to start, and then start 10135B-VAN-EX3. Connect to the virtual machine.
Module Review and Takeaways
Review Questions
1. The installation of Exchange Server 2010 fails. What information sources can you use to troubleshoot
the issue?
2. What factors should you consider while purchasing new servers for your Exchange Server 2010
deployment?
3. How would the deployment of additional Exchange Server 2010 servers vary from the deployment of
the first server?
Common Issues Related to Installing Exchange Server 2010

Identify the causes for the following common issues related to installing Exchange Server 2010 and
explain the troubleshooting tips. For answers, refer to relevant lessons in the module.
Issue Troubleshooting tip
You start the Exchange installation and

get an error message stating that you
do not have sufficient permissions.
You start the Exchange installation and

the prerequisite check fails.
You run setup with /PrepareAD

parameter and receive an error
message.
Real-World Issues and Scenarios

1. An organization has a main office and multiple smaller branch offices. What criteria would you use to
decide whether to install an Exchange server in a branch office? What additional factors should you
consider if you decide to deploy an Exchange server in the branch office?
2. An organization has deployed AD DS within two different forests. What issues will this organization
experience when they deploy Exchange Server 2010?
3. An organization is planning to deploy Exchange Server 2010 servers as virtual machines running on
Hyper-V in Windows Server 2008 R2. What factors should the organization consider in their planning?
Best Practices for Deploying Exchange Server 2010

Supplement or modify the following best practices for your own work situations:
Plan the hardware specifications for your Exchange Server 2010 servers to allow for growth. In most
organizations, the amount of email traffic and the size of the user mailboxes are growing rapidly.
Consider deploying at least two Exchange Server 2010 servers. With two servers, you can provide
complete redundancy for the core Exchange server roles.
When deploying multiple Exchange servers with dedicated server roles for each server, deploy the
server roles in the following order:
a. Client Access server
b. Hub Transport server

c. Mailbox server
d. Unified Messaging server
You can deploy the Edge Transport server at any time, but it does not integrate automatically with
your organization until you deploy a Hub Transport server.
2-1
Module 2
Configuring Mailbox Servers
Contents:
Lesson 1: Overview of Exchange Server 2010 Administrative Tools 2-3
Lesson 2: Configuring Mailbox Server Roles 2-16
Lesson 3: Configuring Public Folders 2-33

Lab: Configuring Mailbox Servers 2-41
2-2 Configuring Mailbox Servers
Module Overview
The Microsoft Exchange Server management tools provide a flexible environment that enables
administrators to manage all sizes of Microsoft Exchange Server 2010 messaging deployments. Successful
Exchange Server messaging professionals need to understand where configuration elements reside within
the Exchange Management Console and the basics of the Exchange Management Shell. This module
describes these management tools.
This module also describes the Mailbox server role, some of the new Exchange Server 2010 features, and
the most common Mailbox server role post-installation tasks. The module concludes with a discussion
about public folder configuration and usage.
Describe the Exchange Server 2010 administrative tools.
Configure mailbox server roles.
Configure public folders.

Lesson 1
Overview of Exchange Server 2010 Administrative Tools
This lesson introduces you to the Exchange Management Console, Exchange Management Shell, and the
Exchange Control Panel (ECP). These tools are the main interfaces that Exchange Server administrators use
daily, so a detailed understanding of when and how to use each interface is vital.
Describe the Exchange Management Console.

Describe Windows PowerShell.
Describe the Exchange Management Shell.
Describe remote Windows PowerShell.
Use Exchange Management Shell cmdlets.
Work with the Exchange Management Shell.
Apply Exchange Manage Shell cmdlet examples.
Describe the Exchange Control Panel.

Demonstration: What Is the Exchange Management Console?
In this demonstration, you will review how to navigate the Exchange Management Console, and use it to
manage Exchange Server.
Demonstration Steps
2. Note the consoles layout: the Console Tree is on the left; the Content pane is in the middle; and the
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.
The Exchange Management Console uses the Microsoft Management Console (MMC) 3.0 paradigm of a
four-pane environment. These four components are:
Console Tree. This area provides a hierarchical view of the Exchange Server organization and servers,
which you use to locate the objects that you want to manage. As you navigate the Exchange Server
hierarchy, and select objects in the Console Tree, the three other work panes provide details and
configuration options based on your selection.
Results pane. This area displays the objects available under that which you have select in the Console
Tree. The Results pane updates as you navigate the Console Tree, to reflect your location within the
hierarchy, and you can filter and sort objects there.
Work pane. This area presents child objects of the Results pane. For example, when you select a
Mailbox server in the Results pane, the Work pane displays the databases on that server. You can use
the links in the Actions pane to manage the objects in the Work pane.
Actions pane. This area exposes different administrative tasks in response to your selections within the
Results and Work panes. For example, if you select a recipient object in the Results pane, the Actions
pane contains administrative tasks that enable you to move the mailbox, change its properties, or
disable the selected mailbox. The tasks that the Actions pane list are also available when you right-
click the object in the Results or Work pane.
The Console Tree is a unique feature of the Exchange Management Console, and it has four main nodes:
Organization Configuration, Server Configuration, Recipient Configuration, and Toolbox. These four nodes
have four distinct functions.
Organization Configuration
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, Microsoft Exchange ActiveSync policies, journal and transport rules, message-formatting
options, and email domain management.
Server Configuration
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, product-key
management, and the per-server configuration of the Microsoft Outlook Web App. You also can
configure server certificates from this node.
Recipient 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.
Toolbox
The Toolbox node contains 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, link to the Remote Connectivity Analyzer, Messaging Tracking, and Queue Viewer.
You also can use the Exchange Management Console to manage both onsite and hosted Exchange Server
2010 environments, including the Exchange Online deployed as part of an Office 365 implementation.
The Console Trees root node also includes two tabs in the Content pane: Organizational Health and
Customer Feedback. The Organizational Health tab displays a report on the overall status of the Exchange
Server organization that includes information about the number of deployed databases, servers, and
Client Access Licenses. Use the Customer Feedback tab to enable the Customer Experience Improvement
Program and to access Exchange Server documentation.
Question: Does the Exchange Management Console organization seem logical to you? Why?
Question: Does the Exchange Management Console have the same functionality as it did in
previous Exchange Server versions? What is different about this version?
What Is Windows PowerShell?
In recent years, Microsoft has prompted Windows PowerShell as a single command line and scripting tool
that can be used to manage almost all Microsoft products. Windows PowerShell is an extensible scripting
and command-line technology that developers and administrators use to automate tasks in a Windows
operating system environment. Windows PowerShell uses a set of small commands called cmdlets that
each performs a specific task. You also can combine multiple cmdlets to perform complex administrative
tasks.
Windows PowerShell is an important underlying tool for Exchange Server 2010. Exchange Server 2010-
specific cmdlets are enabled in the Exchange Management Shell, and Exchange Management Console
provides GUI access to the Windows PowerShell cmdlets. When you perform an action in Exchange
Management Console, a Windows PowerShell command runs in the background to implement the
changes in the Exchange environment.
Windows PowerShell is accessible directly through a new command shell, called PowerShell.exe. When
you run Windows PowerShell from this command shell, you can perform many of the tasks you could
perform by using the traditional command shell (cmd.exe), plus many more.
Some of the most important features of Windows PowerShell are:

Simple cmdlets. Cmdlets are small executable files, written in Microsoft Visual C# or any other
Microsoft .NET Framework-compliant language, that provide a standard procedure for performing
certain actions. All cmdlets are in format verb-noun, for example: get-user, set-mailbox, and so on.
The syntax is very similar to the English language, so it can be easily adopted.
Aliases. You also can alias cmdlets. If you commonly run a specific cmdlet, you can assign an alias to
the cmdlet to make it easier to remember. These aliases are stored in the default user profile on a
computer or in the user-specific profile. For example, if you want to replace the Get-ChildItem cmdlet
with the show alias, you would run New-Alias show Get-ChildItem.
Variables. As with most programming languages, Windows PowerShell supports the concept of a
variable to which you can assign a value. Variables in Windows PowerShell are named starting with a
dollar sign ($) character; for example, $date and $servername. Variables can have a data type formally
defined. To display the value of a variable, just type the variable name (including the $). You can also
perform normal variable manipulation.
Pipelining. Pipelining enables you to string cmdlets together and make the output of one cmdlet the
input of the next cmdlet. Windows PowerShell provides a pipeline, but instead of passing raw text to
the next cmdlet, it passes managed objects. For example, in one cmdlet, you can use a filter to locate
a set of Exchange Server recipients based on one or more parameters, and then apply an action to
that set of recipients.
Exchange Management Shell also provides a robust and flexible scripting platform that can reduce the
complexity of current Microsoft Visual Basic scripts. Tasks that previously required many lines in Visual
Basic scripts can now be performed by using as little as one line of code.
What Is the 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.
When you run cmdlets in the Exchange Management Shell, role-based access control (RBAC) is used to
determine whether you have the required permissions to run the cmdlets. RBAC enables you to assign
granular permissions to administrators, and more closely align the roles that you assign users and
administrators to the actual roles they hold within your organization. Since all Exchange Server 2010
administration tools run Exchange Management Shell cmdlets to make changes to the Exchange
environment, RBAC permissions are consistently applied all administration tools.
What Is Remote Windows PowerShell?
In Exchange Server 2010, if your user account is enabled for remote PowerShell, you can connect to a
session on a remote Exchange Server 2010 computer to perform commands on it. Whether you use
Exchange Management Shell to administer a server you are physically connected to, or to administer a
server across the country, the Windows PowerShell Remoting feature performs the operation in Exchange
Server 2010.
Remote Windows PowerShell Features

Remote Windows PowerShell provides the following new features in Exchange Server 2010:
Client/server management model. With remote PowerShell, all cmdlets run remotely on an Exchange
server rather than from the management client. This allows the server to process the client requests,
thereby reducing their impact on the client. This also allows you to manage multiple servers at the
same time from a single client, and also to run scripts that will configure multiple servers at one time.
Simplified client computer configurations. Since the cmdlets run on the remote server, and not the
client, you only need to install Windows PowerShell 2.0 on the management machine if you do not
need the graphical user interface (GUI) tools. Since Windows PowerShell 2.0 includes both a 32-bit
and 64-bit version, you can use a 32-bit client to manage the Exchange environment. If users only
need to perform a limited set of tasks, you can also write custom graphical user interfaces that run
Windows PowerShell commands when the user applies changes in the GUI.
Standard protocols that allow easier management through firewalls. Remote Windows PowerShell
leverages Windows Remote Management (WinRM) for connectivity through standard HTTPS
connections. Since corporate firewalls often allow HTTPS by default, using Windows PowerShell
requires no additional firewall configuration. Because SSL is required for all WinRM connections by
default, all authentication and shell commands are also encrypted when sent across the network.
These new features enable scenarios such as simplified cross-domain management, management from
workstations that do not have installed management tools, management through firewalls, and the ability
to throttle resources that management tasks consume. For example, if you deploy Exchange Online in an
Office 365, you can use Remote PowerShell to manage both the on-premises and online Exchange
environments.
Learning How to Use the Exchange Management Shell
Working with Exchange Management Shell cmdlets and commands can be confusing initially. Here are
some suggestions for optimizing the learning process:
All shell cmdlets start with a verb-noun pairs. A hyphen (-) without spaces separate the verb-noun
pair, and the cmdlet nouns are always singular. Verbs refer to the action that the cmdlet takes. Nouns
refer to the object on which the cmdlet takes action. For example, in the Get-Mailbox cmdlet, the
verb is Get, and the noun is Mailbox. All cmdlets that manage a particular feature share the same
noun.
To get help on any cmdlet, use the Get-Help command followed by the cmdlet name. For example,
Get-Help New-Mailbox will display the information on how you can use the cmdlet New-Mailbox,
and all the parameters that you can modify with the cmdlet. Get-Help cmdletname Examples
displays examples of the cmdlet syntax.
Use Format-List (FL) to list full details about any object. For example, running get-mailbox id Anna
| FL will list full details about Annas mailbox. Running Get-ClientAccessServer | FL will list full details
of all the Client Access servers in the organization.
You can use wild cards with many get cmdlets. For example, you can use the get-excommand get*
to list all of the Exchange cmdlets that start with Get. You can use the Get-Mailbox id Anna | FL
*quota* command to list all parameters in Adams mailbox that have size in the parameter name.
Most cmdlets accept positional parameters in addition to named parameters. You can use positional
parameters to supply values to the cmdlet based on the values location rather than on a parameter
name. For example, Get-Mailbox -Identity Anna returns information about Annas mailbox. The
named parameter in this example is Identity. However, Identity is also a positional parameter for the
Get-Mailbox cmdlet. If you do not specify a name value with Identity, Windows PowerShell uses the
Identity parameter. As an example, Get-Mailbox Anna returns the same information as the previous
example.
You can use the Tab key to auto-complete cmdlets and parameters. For example, if you type Set-
Web and press the Tab key, the cmdlet will autocomplete to Set-WebServicesVirtualDirectory. If
the cmdlet is ambiguous when you press the Tab key, the autocomplete will display the first
command alphabetically that matches the typed letters. You can press the Tab key repeatedly until
the desired command is displayed. You can also use autocomplete to complete attribute names, but
not values.
Use pipelining to combine cmdlets. Pipelining allows you to chain one cmdlet to another so that the
previous cmdlets results act as input to the next cmdlet. To pipeline information from one cmdlet to
another, specify the pipe character (|) between the cmdlets. You can pipeline more than two cmdlets.
In fact, you can use as many as necessary to achieve the results you desire.
The following example uses two pipelined cmdlets with a filter between them. The first cmdlet,
Get-user, retrieves all users from Active Directory Domain Service (AD DS), and then pipes the
results to the filter. The filter, which is based on the distinguished name, selects among these users,
and leaves only those located in the Sales organizational unit (OU) and its child OUs. These results are
piped to the Enable-Mailbox cmdlet, which will create a mailbox for these users, and then place
them in Mailbox Database 1.
Get-User | Where-Object {$_.distinguishedname ilike "*ou=sales,dc=adatum,dc=com"} |

Enable-Mailbox database Mailbox Database 1"
For More Information Module 3 provides additional information and examples about
how to use pipelining to combine cmdlets to manage multiple recipients simultaneously.
Demonstration: Working with the Exchange Management Shell
In this demonstration, you will see the Exchange Management Shell syntax and examples that are used to
view or modify objects in an Exchange Server 2010 environment.
Demonstration Steps
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-Mailbox | FT Name,*quota
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 chris@adatum.com -Alias Chris -Database Mailbox
Database 1 -Name ChrisAshton -OrganizationalUnit Users -Password $password -FirstName
Chris -LastName Ashton -DisplayName Chris Ashton -ResetPasswordOnNextLogon $true
Note Assign a password to a new user by specifying the Read-Host cmdlet with the
-AsSecureString switch, because passwords cannot be stored as simple strings. If you are
providing the password in the .csv file, you also can use the ConvertTo-SecureString
cmdlet to convert the files text into a secure string..
Introducing the Exchange Control Panel
The Exchange Control Panel (ECP) is a new feature in Exchange Server 2010. The ECP can be used by
Exchange administrators to manage many of the Exchange organizational and recipient settings. The ECP
can also be used by end users to configure most of their personal mailbox settings.
The ECP runs on the Client Access servers, and is accessible through the URL
https://ClientAccessServerName/ECP. When you connect to the site, the Outlook Web App authentication
page appears. After authenticating, you can either manage your personal mailbox settings, or if you have
permissions in the Exchange organization, you can manage many of the Exchange settings.
Note Like all of the other Exchange management tools, the ECP uses Exchange
Management Shell cmdlets to implement changes to the Exchange environment. This
means that RBAC permissions are applied when you try to view information in the ECP, and
when you try to make changes to the Exchange environment.
The Exchange Control Panel allows all mailbox users to configure most of their mailbox settings, including:
Outlook Web App settings such as email signatures and out of office messages.
Perform message tracking of messages sent or received from their mailbox.
View and manage mobile devices that have connected to their mailboxes.
View group memberships and request to join public groups.
Recover deleted messages.

Exchange administrators can use the Exchange Control Panel to configure many Exchange organization or
recipient settings, including:
Manage existing mailboxes. Administrators can manage most mailbox settings, but cannot create new
mailboxes by using the ECP.
Manage distribution groups. Administrators can create and manage universal distribution groups but
not security groups.
Multi-Mailbox Search. Members of the Discovery Management group can search all user mailboxes
by using the ECP.
Message tracking. Administrators can track all messages sent to and from mailboxes in the Exchange
organization.
Configure RBAC. Administrators can create new management role groups, assign users to
management role groups, and configure other RBAC settings.
Manage Exchange ActiveSync policies and mobile device quarantine. Administrators can manage the
mobile devices that have connected to user mailboxes and configure quarantine policies for new
devices.
Lesson 2
Configuring Mailbox Server Roles
This module describes how to configure the Mailbox server after you install it. Since the Mailbox server
stores all of the mailbox and public folder data, it is a critical component in an Exchange Server messaging
system. You also will learn about databases, database storage considerations, and managing the number
and size of databases.
Describe your initial mailbox configuration tasks.
Describe mailbox and public folder databases.
Describe database file types.
Describe the process for updating mailbox databases.
Configure database options.
Identify Exchange Server 2010 storage improvements.

Describe your database storage options.
Describe direct attached storage.
Describe storage area networks.
Manage mailbox size limits.
Identify the criteria to consider when implementing databases.

Initial Mailbox Configuration Tasks
Complete the following steps after deploying the Mailbox server role:
Secure the server. Before deploying mailboxes on the Mailbox server role, you should secure the
server, which includes configuring permissions at the organizational and server levels. This reduces
the Exchange Servers attack surface.
Create and configure databases. Exchange Server 2010 uses mailbox databases or public folder
databases to store messages. As a result, before creating mailboxes on the server, you need to create
the required databases.
Configure high availability. Exchange Server 2010 uses database availability groups (DAGs) to provide
high availability for mailbox databases. It is recommended that the DAGs be configured before
deploying mailboxes on the mailbox databases.
Configure public folders. Although recent Exchange Server versions de-emphasize the role of public
folders, Microsoft continues to support public folders fully, and you must configure them if you have
Outlook 2003 or earlier clients. However, if you are using Office Outlook 2007 or newer clients, public
folders are not required to support offline address-book distribution or calendar information. During
the installation of the first Exchange Server 2010 into a new AD DS forest, you have the option to
support older Office Outlook clients. Exchange Server creates a public folder database if you choose
this option. You also can create public folders after installation if you do not configure them during
setup.
Configure recipients, including resource mailboxes. The Mailbox server role manages all user
mailboxes, so deploying the Mailbox server role includes configuring recipients.
Configure the offline address book. Outlook 2007 (and higher) clients support retrieving offline
address books with HTTP, rather than only with public folders, as in previous Office Outlook versions.
What Are Mailbox and Public Folder Databases?
To manage Mailbox servers properly, you need to know how they store mailbox and public folder
contents. Exchange Server 2010 stores mailbox and public folder contents in databases, which enhances
performance and reduces storage utilization.
Mailbox servers can maintain mailbox databases and public folder databases, and each database consists
of a single rich-text database (.edb) file. Exchange Server 2010 mailbox servers store all messages in this
database regardless of which type of client sends or reads the messages.
Mailbox databases store the messages for mailbox-enabled users. Users cannot have a mailbox without a
mailbox database. Public folder databases store the contents of public folders. Unlike previous Exchange
Server versions that required unique database names only within a storage group, Exchange Server 2010
requires unique database names across the entire Exchange Server organization.
In Exchange Server 2010, each database has a single set of transaction logs, which store database changes.
Database changes include all messages sent to or from the database. Transaction logs are an essential part
of disaster recovery if you need to restore a mailbox or public folder database.
By default, all databases and transaction logs are stored in one folder within the Exchange Server
directory (C:\Program Files\Microsoft\Exchange Server\v14\Mailbox). Each database has its own folder.
Although Exchange Server 2010 does not require separating databases and transaction logs, given the
appropriate redundancy, performing this separation increases recoverability. You should consider it if your
organization does not employ other availability options. If the disk storing a database fails, you will need
the transaction logs to recover activity since your last backup. If your transaction logs also are lost, along
with the database, you can recover only to the point of your last back up.
The Exchange Server 2010 database schema was changed significantly to improve its performance
over previous Exchange Server versions. The new database schema now performs larger and more-
sequential input/output (I/O) transactions, optimizes performance on lower end disk systems, and reduces
the database maintenance that you must perform. These improvements were accomplished by removing
single-instance storage and increasing the page size from 8 kilobytes (KB) to 32 KB.
In Microsoft Exchange Server 2000 and Exchange Server 2003, there was an option to create multiple
databases and have them share a set of transaction logs. This was called a storage group. In Exchange
Server 2007, having multiple databases in a storage group was available only for databases that did not
have high availability features enabled. In Exchange Server 2010, there is no option to have multiple
databases to share a single set of transaction logs.
What Are the Database File Types?
A database consists of a collection of file types, each of which performs different functions.
<Log Prefix>.chk. This checkpoint file determines which transactions require processing to move the
checkpoint file from the transaction log file to the database. Each databases log prefix determines its
checkpoint file name. For example, the checkpoint file name for a database with prefix E00 would be
E00.chk. This checkpoint file is several kilobytes in size, and does not grow.
<Log Prefix>.log. This is the databases current transaction log file. An example is E00.log. The
maximum amount of data storage for this file is 1 megabyte (MB). When this file reaches its
maximum storage of 1 MB, Exchange Server renames it and creates a new current transaction log.
<Log Prefix>xxxxxxxx.log. Exchange Server renames and files this transaction log file. Log files use
sequential hexadecimal names. For example, the first log file for the first database on a server would
be E0000000001.log. Each transaction log file is always 1 MB.
<Log Prefix>res00001.jrs to <Log Prefix>res0000A.jrs. These are the reserved transaction logs for the
database. Exchange Server 2010 uses these only as emergency storage when the disk becomes full
and it can write no new transactions to disk. When Exchange Server 2010 runs out of disk space, it
writes the current transaction to disk, using up the space reserved by the 10 reserve transaction logs
and then dismounts the database. The reserved transaction logs ensure minimal loss of data that is in
transit to the database. The reserved transaction logs always are 1 MB each.
Tmp.edb. This temporary workspace is for processing transactions. Exchange Server 2010 deletes the
contents of this file when it dismounts the database or when the Microsoft Exchange Information
Store service stops. This file typically is a few megabytes in size.
<Log Prefix>tmp.log. This is the transaction log file for the temporary workspace. An example is
E00tmp.log. This file does not exceed 1 MB.
<File Name>.edb. This is the rich-text database file that stores content for mailbox and public folder
databases. An example is Database.edb. Each mailbox or public folder database is contained in a
single file. Database files can grow very large, depending on the content that the database stores.
The Update Process for Mailbox Databases
The following process takes place when a Mailbox server receives a message:
1. The Mailbox server receives the message.
2. The Mailbox server writes the message to the current transaction log and memory cache
simultaneously.
Note If the current transaction log reaches 1 MB of storage, Exchange Server 2010
renames it and creates a new current transaction log.
3. The Mailbox server writes the transaction from memory cache to the appropriate database.
4. The Mailbox server updates the checkpoint file to indicate that the transaction was committed
successfully to the database.
5. Clients can access and read the message in the database.

Demonstration: Configuring Database Options
Several configuration options are set at the database level. Three key management tabs contain these
options: Maintenance, Limits, and Client Settings. This demonstration examines how these tabs can be
used to configure your database options.
The Maintenance Tab

Use the Maintenance tab to specify a journal recipient when you are using database journaling. However,
we recommend using journaling rules for journaling in Exchange Server 2010.
The maintenance schedule is the period of time in which Exchange Server performs database
maintenance. In Exchange Server 2010, online defragmentation occurs continually, so you use the
maintenance window primarily to remove deleted items and mailboxes.
The Maintenance tab has a checkbox that you can select to keep the database from mounting at startup.
You typically use this checkbox, and another that allows the database to be overwritten by a restore,
during recovery or database-maintenance tasks. The checkbox for enabling circular logging sets the
transaction-logging mode so that Exchange Server 2010 overwrites the transaction logs after they are
committed to the database. Circular logging does not allow you to recover a database to a point in time
other than when the last full backup was completed. We recommend circular logging only in test
environments or in high availability configurations in which adequate redundancy negates the need for
this type of recovery.
The Limits Tab

Use the Limits tab to set the maximum size for mailboxes that the database stores, and to specify the
notification schedule for sending messages to users who are approaching these limits.
The deletion settings specify how long the database stores deleted items and mailboxes after the user
deletes them. You can recover items that users have deleted and purged from their Deleted Items folder,
without having to perform a restore from a backup.
The Client Settings Tab

Use the Client Settings tab to configure the default public folder, if necessary, and the default offline
address book for all mailboxes in the database.
Demonstration Steps
2. In the Console Tree, expand Microsoft Exchange On-Premises, expand Organization

Configuration, and then click Mailbox.
3. Select the Database Management tab, and then view the properties of a mailbox database.
4. View the properties on the General, Maintenance, Limits, and Client Settings tabs.
5. Run the Move Database Path Wizard to move the database files.
Question: When would you need to move the path of the transaction logs or databases?
Question: When might you use circular logging?

Exchange Server 2010 Storage Improvements
Exchange Server 2010 introduces several significant changes that reduce storage costs and improve
performance, including changes to the database schema, the use of compression, and the change to
32 KB database pages. Additionally, further improvements minimize database fragmentation by writing
data sequentially on disk, which also improves disk performance. Lastly, when you combine the reduced
storage input/output (I/O) requirements with the new database high availability features, you may be able
to leverage inexpensive direct-attached storage for larger Exchange Server deployments.
Since the storage I/O requirements are lower in Exchange Server 2010, more storage options are available.
Still, you should ensure that your storage method meets the business and technical requirements for the
Exchange Server deployment. Tools such as LoadGen and JetStress are available to approximate usage
patterns, and you can use these tools to test various hardware configurations in your environment.
Options for Database Storage
Exchange Server 2010 now supports several disk storage options, including Serial Advanced Technology
Attachment (SATA), Solid-state drive (SSD), and Serial Attached small computer system interface (SCSI), or
SAS. When selecting which storage solution to use, the goal is to ensure that the storage will provide the
performance that your environment requires.
JBOD
Just a bunch of disks (JBOD) is a collection of disks that have no redundancy or fault tolerance. Usually,
JBOD solutions are lower cost than solutions that use redundant array of independent disks (RAID). JBOD
adds fault tolerance by using multiple copies of the databases on separate disks.
RAID
RAID increases disk-access performance and fault tolerance. The most common RAID options are:
RAID 0 (striping). Increases read and write performance by spreading data across multiple disks.
However, it offers no fault tolerance. Performance increases as you add more disks. You add fault
tolerance by using multiple copies of the databases on separate RAID sets.
RAID 1 (mirroring). Increases fault tolerance by placing redundant copies of data on two disks. Read
performance is faster than a single disk, but write performance is slower than RAID 0. Half of the disks
are used for data redundancy.
RAID 5 (striping with parity). Increases fault tolerance by spreading data and parity information across
three or more disks. If one disk fails, the missing data is calculated based on the remaining disks. Read
and write performance for RAID 5 is slower than RAID 0. At most, only one third of the disks are used
to store parity information.
RAID 0+1 (mirrored striped sets). Increases fault tolerance by mirroring two RAID 0 sets. This provides
very fast read and write performance, and excellent fault tolerance.
RAID 6 (striping with double parity). Increases fault tolerance by spreading data and parity information
across four or more disks. If up to two disks fail, RAID 6 calculates the missing data based on data and
parity information stored on the remaining disks. Read and write performance for RAID 6 typically is
slower than RAID 0, and RAID 6 does not have a read penalty. The main benefit of RAID 6 is the
ability to rebuild missing data if you have two failures per RAID group, and to reduce the impact of
rebuilding the RAID set when a disk fails.
RAID 1+0 or RAID 10 (mirrored sets in a striped set). Provides fault tolerance and improved
performance, but increases complexity. The difference between RAID 0+1 and RAID 1+0 is that RAID
1+0 creates a striped set from a series of mirrored drives. In a failed disk situation, RAID 1+0 performs
better and is more fault tolerant than RAID 0+1.
Data Storage Options: Direct Attached Storage
Direct attached storage is any disk system that connects physically to your server. This includes hard disks
inside the server or those that connect by using an external enclosure. Some external enclosures include
hardware-based RAID. For example, external disk enclosures can combine multiple disks in a RAID 5 set
that appears to the server as a single large disk.
In general, direct attached storage provides good performance, but it provides limited scalability because
of the units physical size. You must manage direct attached storage on a per-server basis. Exchange
Server 2010 performs well with the scalability and performance characteristics of direct attached storage.
Direct attached storage provides the following benefits:
Lower cost Exchange Server solution. Direct attached storage usually provides a substantially lower
purchase cost than other technologies.
Easy implementation. Direct attached storage typically is easy to manage, and requires very little
training.
Distributed failure points. Each Exchange server has separate disk systems, so the failure of a single
system does not affect the entire Exchange messaging system negatively, assuming that you
configure your Exchange servers for high availability.
Data Storage Options: Storage Area Networks
A storage area network (SAN) is a network dedicated to providing servers with access to storage devices.
A SAN provides advanced storage and management capabilities, such as data snapshots, and high
performance. SANs use either Fibre Channel switching or Internet SCSI (iSCSI) to provide fast and reliable
connectivity between storage and applications. Fibre Channel switching or iSCSI allows many servers to
connect to a single SAN.
Fibre Channel is a standard SAN architecture that runs on fiber optic cabling. Most SANs use it because
Fibre Channel is specifically for SANs, and it is the fastest architecture available.
SANs are complex and require specialized knowledge to design, operate, and maintain. Most SANs also
are more expensive than direct attached storage.
SANs provide the following benefits:
A large RAM cache that keeps disk access from becoming a bottleneck. The reduced I/O requirements
of Exchange Server 2010 make it more likely that an iSCSI-based SAN will meet your requirements in
small and medium-sized deployments. However, you should test all hardware configurations
thoroughly before deployment to ensure that they meet your organizations required performance
characteristics.
Highly scalable storage solutions. Messaging systems are growing continually, and require larger
storage over time. As your needs expand, a SAN allows you to add disks to your storage. Most SANs
incorporate storage virtualization, which allows you to add disks and allocate the new disks to your
Exchange server.
Multiple servers attached to a single SAN. If you use a SAN, you can connect multiple computers that
are running Exchange Server, and then divide the storage among them.
Enhanced backup, recovery, and availability. SANs use volume mirroring and snapshot backups.
Because SANs allow multiple connections, you can connect high performance back-up devices to the
SAN. SANs also allow you to designate different RAID levels to different storage partitions.
For cost-conscious SAN implementations, iSCSI may be a viable option. An iSCSI network encapsulates
SCSI commands in TCP/IP packets over standard Ethernet cabling and switches. You should implement
this technology only on dedicated storage networks that are 1 gigabit per second (Gbps) or faster.
Demonstration: How to Manage Mailbox Size Limits
In this demonstration, you will review how to use the Exchange Management Console to configure
storage quotas, and how to use the Exchange Management Shell to configure storage quotas in bulk or
simultaneously.
You can enforce size limits either on a specific mailbox or on a database, which applies the settings on all
mailboxes in the database, by default. The three options available to set a limit on mailboxes and on the
database are:
Issue warning at (KB). When a mailbox reaches the size you specify, at a predetermined schedule
(daily by default), mailbox-enabled users receive a message indicating that their mailboxes have
become too large.
Prohibit send at (KB). When a mailbox reaches the size you specify, the user no longer can send
messages and receives a warning message that the mailbox is too large. The mailbox can still receive
messages.
Prohibit send and receive at (KB). When a mailbox reaches the size you specify, the user can no longer
send or receive messages, and receives a warning message that the mailbox is too large. If the
organization uses a Unified Messaging server, prohibiting email reception can result in lost email
messages, voicemail messages, and faxes. Most organizations elect not to use this option.
You also can use mailbox database defaults to set limits on the database. Exchange Server 2010 enables
this by default, and if you use it, the mailbox inherits any settings that you assign to the database that
stores the mailbox.
Deleted item retention settings work similarly to size limits in that you can assign them either on the
mailbox or database. By default, all mailboxes also inherit deleted time retention from the database.
Database Sizes
As a best practice, set limits on all mailboxes by using the Mailbox database settings. Setting limits ensures
that mailboxes do not grow larger than the hardware can support. This reduces the possibility that a
mailbox grows and fills an entire disk on the Exchange server due to a virus, user intent, or an incorrect
configuration.
Demonstration Steps
2. In the Console Tree, expand Microsoft Exchange On-Premises, expand Recipient Configuration,
and click Mailbox.
3. Right-click a user mailbox, and click Properties.
4. Click the Mailbox Settings tab, and double-click Storage Quotas.

5. Unselect Use mailbox database defaults, and modify the value for Prohibit send and receive at
(MB).
6. Open Exchange Management Shell.

7. Configure the database limits with the Set-MailboxDatabase cmdlet.
8. Configure just the user mailboxes that are contained in the Marketing department with the Get-
Mailbox and Set-Mailbox cmdlets.
Discussion: Considerations for Implementing Databases
It is important to plan properly for any changes you want to make in the Exchange Server environment.
When considering which sort of storage to use for new databases, note the following:
Give each set of transaction logs its own hard disk. You likely will achieve the best performance when
transaction logs do not share disks with any other data. However, if you do not require high
performance, and there are enough copies of the data, you may not require this.
Use RAID 5 or RAID 6 to enhance performance and fault tolerance for databases. RAID 5 increases
read and write performance for random disk access and fault tolerance.
Use RAID 1 to provide fault tolerance for transaction logs. RAID 1 keeps two complete copies of
transaction logs for fault tolerance, and it provides good write performance for data that is written
serially.
Use a SAN, which provides excellent scalability and manageability for storage in large Exchange
Server organizations. A Fibre Channel SAN provides the best performance, but this high level of
performance may be more than you need to support your organizations requirements. SANs also
add considerable cost and complexity.
Use the prohibit send at storage limit to manage storage growth. This storage limit forces users to
address the size of their mailbox before sending additional messages. Halting message reception is
risky, because important business data might get lost. However, a warning may not be enough
encouragement for users to lower their mailbox size.
Question: What should you consider when naming databases?
Question: When would you want or need to create multiple databases?
Question: Why would you want to reduce the number of databases?
Question: What should you consider when planning to build additional Mailbox servers?
Lesson 3
Configuring Public Folders
This lesson covers public folders, and details how you can configure them. If you have deployed only
Outlook 2007 and later clients, you do not need to implement public folders in Exchange Server 2010.
However, many organizations have implemented public folders for business use in previous Exchange
Server versions, and have migrated these public folders to Exchange Server 2010. It is essential to
understand when to use public folders and how to configure them properly.
Describe public folders.
Configure public folder replication.

Describe how clients access public folders.
Configure public folders.
Identify when to use Microsoft SharePoint 2010 instead of public folders.

What Are Public Folders?
A public folder is a repository for different information types, such as email messages, text documents,
and multimedia files. A public folder database stores public folder contents, which you can share with
Exchange Server organization users.
Organizations typically use public folders as:
A location to store contacts for the entire organization.
Centralized calendars for tracking events.
Discussion groups.
A location in which to receive and store messages for a workgroup, such as the Help desk.
A storage location for custom applications.
Additionally, system public folders support legacy Office Outlook versions for free/busy information,
custom forms, and offline address books.
Configuring Public Folder Replication
Public folder content replication is an email-based process for copying public folder content between
computers that are running Exchange Server. When you modify a public folder or its contents, the public
folder database that contains the replica of the public folder that you change sends a descriptive email
message to the other public folder databases that host a replica of the public folder. To reduce network
traffic, Exchange Server includes information about multiple changes in one email message. If any
message exceeds the specified size limit, that message is sent as a separate replication message. Exchange
Server routes these replication messages the same way that it routes other email messages. By default,
public folder content replicates every 15 minutes, and you cannot set replication to less than every
minute.
Because AD DS and Active Directory store the public folder configuration objects, AD DS and Active
Directory replication must be working correctly to ensure that the configuration is available to all
Exchange servers.
When you create a public folder, only one replica of that public folder exists within the Exchange Server
organization.
Using multiple replicas allows you to place public folder content in the physical server locations where
users are located. This results in faster access to public folder content and reduced communication across
wide area network (WAN) links between physical locations. Public folder replication also provides fault
tolerance for public folders.
How Clients Access Public Folders
The public folder connection process for Messaging Application Programming Interface (MAPI)-based
clients is:
1. If the public folder is located on the user accounts default public folder database, Exchange Server
directs the client to this database for the public folder contents.
2. If the public folder contents are not stored in the user accounts default public folder database,
Exchange Server redirects the client to a public folder database on a computer that is running
Exchange Server 2010 in the local Active Directory site.
3. If no computer that is running Exchange Server 2010 or Exchange Server 2007 on the local Active
Directory site has a copy of the public folder contents, Exchange Server redirects the client to the
Active Directory site with the lowest cost site link that does have a copy of the public folder contents.
4. If there is no computer that is running Exchange Server 2010 or Exchange Server 2007 that has a copy
of the public folder contents, Exchange Server redirects the client to a computer that is running
Microsoft Exchange Server 2003 and that does have a copy of the public folder contents. It does this
by using the cost assigned to the routing group connector(s). Exchange Server 2010 does not enable
this by default. Rather, you must enable it with the Set-RoutingGroupConnector cmdlet.
5. If no public folder replica exists on the local Active Directory site, a remote Active Directory site, or on
a computer that is running Exchange Server 2003, the client cannot access the contents of the
requested public folder.
Note For Outlook Web App clients to view public folders, a replica of the public folder
must be available on an Exchange Server 2010 mailbox server.
Demonstration: How to Configure Public Folders
In this demonstration, you will review how to use the Public Folder Management Console and Office
Outlook to configure public folders. You will see how to:
Use the Public Folder Management Console to add replicas and set permissions on a public folder.
Use the Public Folder Management Console to add permissions to a public folder.
Open Outlook, and then view the permissions for the public folder.
Demonstration Steps
Use the Public Folder Management Console to add replicas and set permissions on a public folder
2. Open the Public Folder Management Console, and then connect to a Mailbox server.
3. Create a new public folder named Sales.
4. View the properties of the Sales public folder, and then view the options on the General, Statistics,
Limits, and Replication tabs.
5. Add a replica to the Sales public folder.
Use the Public Folder Management Console to add permissions to a public folder
1. Open the Public Folder Management Console.
2. On the Sales folder properties, click the Permissions tab.
3. Add Luca Dellamore with Edit All permissions to the folder properties.
Use Outlook to view and edit public folder permissions
1. Logon to VAN-CL1 as Adatum\Administrator.
2. Open Outlook.
3. View the permissions for the Sales public folder.
Question: How is public folder management different in Exchange Server 2010 than in
previous Exchange Server versions?
Best Practices for Public Folder Deployment
When planning public folder deployment in Exchange Server 2010, you should consider the following
best practices:
Some organizations make little use of public folders, while others use them extensively, and may have
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.
If your organization uses public folders extensively, you might need 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 both the number of users that
are 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.
Schedule public folder replication during nonpeak 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 nonbusiness hours.
If the network bandwidth and latency between company locations is not a significant issue, then the
primary considerations for using replication or referrals are server capacity, client performance, and
enabling high availability for public folders. 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 as compared to accessing public folders across a WAN
connection. If you do not have a Mailbox server with the capacity to host public folder replicas in the
remote site, then use public folder referrals. If public folder availability is an important consideration
in your organization, then the only way you can provide high availability is through configuring
multiple replicas.
If you have Office Outlook 2003, you should enable replication for the system public folders that
these clients require. These folders include the Schedule+ free/busy folders, and the OAB folders. The
OAB folder includes up to three different versions of the OAB. Only replicate the OAB versions that
the Office Outlook clients in your organization require. In a migration scenario, you should enable
replication of these folders from previous versions of Exchange server to Exchange 2010. If you only
have Exchange Server 2010 deployed, you should consider deploying multiple replicas of these
system folders to ensure the folders are high available to clients.
Note For Outlook Web App clients to view public folders, a replica of the public folder
must be available on an Exchange 2010 Mailbox server.
Lab: Configuring Mailbox Servers
Lab Setup
Important If required, start the 10135B-VAN-DC1 virtual machine first, and ensure that it
is fully started before starting the other virtual machines.
1. On the host computer, click Start, point to Administrative Tools, and click Hyper-V Manager.
2. Ensure that the 10135B-VAN-DC1, 10135B-VAN-EX1, and the 10135B-VAN-EX3 virtual machines are
running.
10135B-VAN-DC1: Domain controller in the Adatum.com domain
10135B-VAN-EX1: Exchange 2010 server in the Adatum.com domain
3. If required, connect to the virtual machines. Log on to the computers as Adatum\Administrator,

using the password Pa$$w0rd.
Lab Scenario
You are a new messaging administrator at A. Datum Corporation, and your manager has left instructions
indicating that you need to create and configure a database for the executive group, and then move the
existing database for the accounting group to a new location. Additionally, you need to add an additional
public folder database, and then replicate data to it.
Exercise 1: Configuring Mailbox Databases

Scenario
You must configure the executives database so that the mailbox does not send or receive messages after
the mailbox size reaches 1,024 MB. Additionally, you should ensure that a warning is sent to users if their
mailbox reaches 850 MB.
1. Create a new database for the Executive mailboxes.
2. Configure the Executive mailbox database with appropriate limits.
3. Move the existing Accounting database to a new location.
X Task 1: Create a new database for the Executive mailboxes

1. On VAN-EX1, open the Exchange Management Console.
2. Create a new database named Executive on VAN-EX1.

3. Store database files in C:\Mailbox\Executive.
4. Store log files in C:\Mailbox\Executive.
X Task 2: Configure the Executive mailbox database with appropriate limits

Configure the limits on the Executive database:
Prohibit send and receive: 1024 MB

Issue warning: 850 MB
X Task 3: Move the existing Accounting database to a new location

1. Move the Accounting database files.
2. Store database files in C:\Mailbox\Accounting.
3. Store log files in C:\Mailbox\Accounting.
Results: After this exercise, you should have created a new database, set the specified limits, and moved
the existing Accounting database to a new folder.
Exercise 2: Configuring Public Folders

Scenario
Before creating a new public folder database and replicating it, you must check the numbers of items and
size in the Executive public folder so that you can later verify that the replication was successful.
1. Check Executives public folder statistics.
2. Create a public folder database on VAN-EX3.

3. Add a replica of the Executives public folder on VAN-EX3.
4. Verify replication between VAN-EX1 and VAN-EX3.
X Task 1: Check Executives public folder statistics

1. On VAN-EX3, open the Exchange Management Console, and in the Toolbox node, open the Public
Folder Management Console.
2. In the Public Folder Management Console, connect to VAN-EX1, and view the number of items and
size in the Executives public folder on VAN-EX1.
Write down Total Items ______________________
Write down Size (KB) ________________________
X Task 2: Create a public folder database on VAN-EX3

Create a new public folder database on VAN-EX3 named PF-VAN-EX3.
Store database files in C:\Mailbox\PF-VAN-EX3\PF-VAN-EX3.edb.
Store log files in C:\Mailbox\PF-VAN-EX3.
X Task 3: Add a replica of the Executives public folder on VAN-EX3

Add PF-VAN-EX3 as a replica for the Executives public folders, and then wait for replication to
complete.
Note It can take up to 15 minutes for replication to complete.
X Task 4: Verify replication between VAN-EX1 and VAN-EX3

Verify the number and size of items in the Executives public folder on
VAN-EX3.
Results: After this exercise, you should have created a new public folder database on VAN-EX3 and added
replicas for each public folder.

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

4. Repeat this step for every virtual machine that is running.
7. Wait for VAN-DC1 to start, and then start VAN-EX1. Connect to the virtual machine.
8. Wait for VAN-EX1 to start, and then start VAN-CL1. Connect to the virtual machine.
Review Questions
1. Which tools can you use to manage Exchange Server 2010?
2. What customizations can you make on mailbox databases?

3. When can you use public folders?
Common Issues Related to Designing Mailbox Databases

Identify the causes for the following common issues related to designing and implementing Exchange
Server mailbox databases, and then complete the troubleshooting tips. For answers, refer to relevant
lessons in the module.
You are planning to deploy a new Mailbox

server on a different server and storage
platform.
After applying limits on each of the

mailbox databases, some of the users are
exceeding these limits.
You are migrating from Exchange Server

2003, and none of the users with Exchange
Server 2010 mailboxes can access legacy
public folders via Outlook Web App.
Real-Word Issues and Scenarios

1. Your organization needs to determine which storage solution to deploy for the new Exchange Server
2010 messaging environment. What information should you consider when selecting the hardware?
2. Your organization would like to automate creation of user mailboxes for employees based on their
status in your organizations human-resources system. What can you use to perform this automation?
3. Your organization wants to reduce administrative costs. One suggestion is to give department heads
and administrative assistants the necessary access to manage departmental and project-based
groups. What can you use to accomplish this task?
Best Practices Related to Public Folder Deployment Planning

Determine the public folder features that your organization needs, such as multiple master
replications.
Determine whether other solutions, such as SharePoint or Microsoft InfoPath, meet user needs
better.
Define specific age and size limits, so that public folder data does not grow uncontrolled and
outdated.
Tools
Tool Use for Where to find it
Exchange Management Configuring the Exchange Server Start menu

Console organization, its servers, and its recipients
Exchange Management Configuring the Exchange Server Start menu

Shell organization, its servers, and its recipients
Completing bulk-management tasks
Exchange Control Panel Managing recipients Outlook Web App
3-1
Module 3
Managing Recipient Objects
Contents:
Lesson 1: Managing Mailboxes 3-3
Lesson 2: Managing Other Recipients 3-21

Lesson 3: Configuring Email Address Policies 3-28
Lesson 4: Configuring Address Lists and Address Book Policies 3-33
Lesson 5: Performing Bulk Recipient Management Tasks 3-40

Lab: Managing Exchange Recipients 3-46
3-2 Managing Recipient Objects
Module Overview
In any messaging system, you need to create recipients and configure them to send and receive email. As
a Microsoft Exchange Server messaging administrator, you often must create, modify, or delete recipient
objects. Therefore, it is important to have a good understanding of recipient management. In Exchange
Server 2010, you can easily perform bulk management of Exchange Server recipient objects by using the
Exchange Management Shell.
This module describes how you can manage recipient objects, address policies, and address lists in
Exchange Server 2010, and the procedures for performing bulk management tasks in Exchange
Management Shell.
Manage mailboxes in Exchange Server 2010.
Manage other recipients in Exchange Server 2010.
Configure email address policies.
Configure address lists and address books policies.

Perform bulk recipient management tasks.
Lesson 1
Managing Mailboxes
Apart from creating mailboxes, you may need to modify mailbox options to meet the needs of users and
ensure optimal performance of the messaging environment. Based on your organizations requirements,
and its users, you also may have to move mailboxes to different servers or databases, and configure
resources.
This lesson provides an overview of Exchange Server recipient objects and the available configuration
options. Additionally, this lesson covers the reasons and procedures for moving mailboxes, and explains
how to configure resource mailboxes.

Identify the different recipient object types in Exchange Server 2010.
Manage mailbox user accounts.
Describe how to configure mailbox settings.
Configure mailbox permissions.
Move mailboxes by using the Exchange Management Console.
Describe the purpose and functionality of resource mailboxes.
Describe how to design resource booking policies.
Manage resource mailboxes.

Types of Exchange Server Recipients
In Microsoft Exchange Server 2003, you can use the Active Directory Users and Computers functionality
to perform all individual recipient management tasks. However, in Microsoft Exchange Server 2007, and
subsequently in Exchange Server 2010, you cannot use Active Directory Users and Computers to manage
Exchange Server recipients. You must configure all Exchange Server-specific recipient settings in the
Exchange Management Console or the Exchange Management Shell.
Exchange Server recipients are mail-enabled when they have associated email addresses, but do not
have Exchange mailboxes. For example, a contact that has been mail-enabled becomes a mail contact.
Exchange Server 2010 supports the following recipient types:
User mailboxes. A mailbox that you can assign to an individual user in your Exchange Server
organization. It typically contains messages, calendar items, contacts, tasks, documents, and other
important business data.
Mail users or mail-enabled Active Directory users. These are users outside the Exchange Server
organization that have an external email address. All messages sent to the mail user are routed to this
external email address. A mail user is similar to a mail contact, except that a mail user has Active
Directory logon credentials and can access resources.
Resource mailboxes (Room mailboxes and Equipment mailboxes). A resource mailbox that you can
assign to a meeting location, or to a resource such as a projector. You can include resource mailboxes
as resources in meeting requests, which provides a simple and efficient way of scheduling resource
usage.
Mail contact or mail-enabled contacts. These contacts contain information about people or
organizations that exist outside an Exchange Server organization and that have an external email
address. Exchange Server routes all messages sent to the mail contact to this external email address.
Mail-enabled security and distribution groups. You can use a mail-enabled Active Directory security
group object to grant access permissions to Active Directory resources, and you also can use it to
distribute messages. You can use a mail-enabled Active Directory distribution group object to
distribute messages to a group of recipients.
Dynamic distribution groups. A distribution group that uses recipient filters and conditions to derive
its membership at the time messages are sent.
Linked mailboxes. You can assign a linked mailbox to an individual user in a separate, trusted forest.
Remote mailboxes. Remote mailboxes are mailboxes that are located in the Exchange Online
environment. In a hybrid Exchange Server 2010 deployment, you can create and manage remote
mailboxes in the Exchange Online environment by using the Exchange Management Console.
You can use a mail-enabled user when Exchange Server 2010 is not responsible for sending and receiving
mail for an Active Directory user, but you want that user to appear in the global address list (GAL). You
might do this for remote sales people that prefer to use email based on their own Internet service
providers (ISP).
You can only mail-enable universal security groups and universal distribution groups in Exchange Server
2010, similar to Exchange Server 2007.
Question: How is a mail-enabled contact different from a mail-enabled user?

Demonstration: How to Manage Mailboxes
In this demonstration, you will see how to manage mailboxes by performing common operations such as
creating, deleting, and removing mailbox user accounts.
Demonstration Steps
Use the Exchange Management shell to mail-enable an existing user
1. Open Active Directory Users and Computers, and ensure that Daniel Brunner exists in the Users
container.
2. In the Exchange Management Console, create a new mailbox for Daniel Brunner.
3. Create the mailbox in Mailbox Database 1.
Create a new mail-enabled user with the Exchange Management Console
In the Exchange Management Console, run the New Mailbox Wizard, and create a new user account
and mailbox for Kim Akers. Create the mailbox in the Accounting mailbox database.
Disable a user mailbox
1. In the Exchange Management Console, disable Daniel Brunners mailbox.
2. In Active Directory Users and Computers, verify that Daniel Brunners user account still exists.
Remove a user mailbox
1. In the Exchange Management Console, remove Kim Akerss mailbox.
2. In Active Directory Users and Computers, verify that Kim Akers user account also has been deleted.
Note Remove-mailbox deletes the specified user account and mailbox, and disable-
mailbox removes the mailbox, but leaves the user account enabled.
Question: What tools do you prefer to use for managing mailbox users?
Question: How does your organization delegate Exchange and Active Directory
management tasks?
Configuring Mailbox Settings
Exchange Server 2010 provides several options for configuring a single mailbox. Many of these options
are similar to those available for managing an Active Directory Domain Services (AD DS) environment.
Mailbox configuration options include:
General
User Information
Address and Phone
Organization
Account
Member Of
However, some configuration options are unique to Exchange Server such as:
Mail Flow Settings. There are three mail-flow settings: delivery options, message-size restrictions, and
message-delivery restrictions:
Use the delivery options to set:
Who can send an email message from that mailbox.
A recipient to whom all messages are forwarded.
The maximum number of recipients to which the mailbox can send a single message.
Use the message-size restrictions options to specify the maximum size for the messages that the
mailbox sends or receives.
Use the message delivery restrictions options to control the recipients that can send messages to
the mailbox.
Mailbox Features. Use these options to configure the mailboxs specific features, such as Microsoft
Outlook Web App, Microsoft Exchange ActiveSync, Unified Messaging, Post Office Protocol
version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4), and the Archive mailbox.
Calendar Settings. Use this option to configure how a mailbox processes meeting requests.
Mailbox Settings. There are four mailbox settings: messaging records management, federated sharing,
storage quotas, and archive quota.
E-Mail Addresses. Use this option to configure the e-mail addresses assigned to the mailbox.
Question: Why would you configure mailbox size limits on individual mailboxes?
Demonstration: How to Configure Mailbox Permissions
In Exchange Server 2010, you use the Exchange Management Console and Exchange Management Shell
to configure the Full Access and Send As mailbox permissions. When you grant a user the Full Access
permission to another users mailbox, the delegated user can log on to the mailbox, and view and manage
all messages in the mailbox. Granting Full Access permissions does not grant the delegated user the right
to send mail as the selected mailbox. To allow a user to send mail from a delegated mailbox, you must
configure Send As permissions. When a user with Send As permissions sends a message from the
delegated mailbox, any message sent from the mailbox will appear as if it were sent by the mailbox
owner.
In this demonstration, you will see how to assign Full Access and Send As permissions to a mailbox.
Note In Exchange 2010 Service Pack 1 (SP1), Outlook 2007 and Outlook 2010 clients
automatically download all mailboxes to which the user has full access. If the user has full
access to a large number of mailboxes, this could cause performance issues. In Exchange
2010 SP1, users cannot control this behavior and cannot turn it off. In Exchange 2010 SP2,
administrators can turn off the automapping feature.
Demonstration Steps
Assign Wei Yu send as permissions on Andreas Herbingers mailbox
1. Open Exchange Management Console.

and then select Mailbox.
3. In the Results pane, select the Andreas Herbinger mailbox, and then in the Actions pane, click
Manage Send As Permission.
4. In the Manage Send As Permission Wizard, click Add.

5. In the Select User or Group dialog box, choose Wei Yu, and then click OK.
6. Click Manage.
7. Click Finish.
Assign Wei Yu full access to Conor Cunninghams mailbox
1. Select the Conor Cunningham mailbox, and then in the Actions pane, click Manage Full Access
Permission.
2. In the Manage Full Access Permission Wizard, click Add.
3. In the Select User or Group dialog box, choose Wei Yu, and then click OK.
4. Click Manage, and then click Finish.
Question: When would more than one user need to access the same mailbox?
Question: What is the difference between Send on behalf of permissions and Send As
permissions?
Demonstration: How to Move Mailboxes
In this demonstration, you will see how to move mailboxes by using the Exchange Management Console.
Exchange Server 2010 uses move requests to move mailboxes. You can initiate a move request by running
the New-MoveRequest cmdlet or by using the New Local Move Request wizard in the Exchange
Management Console. Move requests have the following characteristics:
The Mailbox Replication Service running on a Client Access server carries out the move. The Mailbox
move is asynchronous, which means that the request can run immediately after initiating the move
request, or the request can be queued if other mailboxes are already being moved.
Mailboxes are kept online during the asynchronous moves. While the mailbox is being moved, the
Client Access server that the client is connected to maintains the connection to the source Mailbox
database. When the move is complete, the Client Access server switches the connection to the
destination database.
The mailboxs dumpster moves with the mailbox when you move it between Exchange Server 2010
mailbox servers.
Fast search is available upon completion. As soon as the mailbox begins to move, content indexing
starts to scan the mailbox so that fast searching is available upon the moves completion.
You can configure throttling for each MRS instance, each mailbox database, or each mailbox server.
While the mailbox is being moved, it is listed in the Move Request folder in the Exchange
Management Console. When the mailbox move is complete, the move request continues to be listed
in the Move Request folder until you clear the move request. The mailbox cannot be moved again
until the move request is cleared.
While a move request is in progress, the mailbox stays online, allowing the user to continue sending and
receiving email. You can view the move request status in the Exchange Management Console and
Exchange Management Shell. The request can have one of the following statuses:
Queued for move
Move in progress
Ready to complete
Completing
Note In Exchange Server 2010 SP1 or newer versions, you can configure MRS throttling
policies to control the server resources used by MRS. MRS throttling is controlled by the
configuration file MSExchangeMailboxReplication.exe.config.
Demonstration Steps
Move Conor Cunninghams mailbox to the Accounting database
1. On VAN-EX1, in the Exchange Management Console, create a new Local Move Request to move
Conor Cunninghams mailbox to the Accounting Mailbox database.
2. View the move request status in the Move Request node.
Question: What is the benefit of scheduling mailbox moves?

What Are Resource Mailboxes?
Resource mailboxes are specific types of mailboxes that you can use to represent meeting rooms or
shared equipment, and you can include them as resources in meeting requests. The Active Directory user
that is associated with a resource mailbox is a disabled account.
Room mailboxes. These are resource mailboxes that you can assign to meeting locations, such as
conference rooms, auditoriums, and training rooms.
Equipment mailboxes. These are resource mailboxes that you can assign to resources that are not
location-specific, such as portable computer projectors, microphones, or company cars.
You can include both types of resource mailboxes as resources in meeting requests, and thus provide a
simple and efficient way to utilize resources for your users. You can configure resource mailboxes to
automatically process incoming meeting requests based on the resource booking policies that are defined
by the resource owners. For example, you can configure a conference room to automatically accept
incoming meeting requests except recurring meetings, which can be subject to approval by the resource
owner.
You can create a resource mailbox as a room or as equipment. After creating the resource mail box, you
must configure properties such as location and size. Then, you must define the resource booking policy
and enable the resource booking attendant.
Room List Distribution Groups

The process of picking a room mailbox that is available during a selected meeting time can be
complicated. One way for users to see this information is to invite multiple meeting rooms to the meeting,
and then view availability information for each room. In Exchange Server 2010, you can create room-list
distribution groups based on company locations or other attributes. Users then can select the room list to
generate a list of meeting rooms and get information about room availability, without having to add all
rooms manually to the meeting request.
You can create room-list distribution groups only by using Exchange Management Shell commands. For
example, the following command populates the variable $members with all room mailboxes with the
Office attribute equal to NYC Main Office:
$Members=Get-Mailbox -Filter {(RecipientTypeDetails -eq "RoomMailbox") -and (Office -eq

"NYC Main Office")}
The following command creates a new room list distribution group that includes all the room mailboxes in
$members variable:
New-DistributionGroup -Name "NYC-Main Office Conference Rooms" -RoomList -Members

$Members
After you create the room-list distribution groups, Office Outlook 2010 users can use the distribution
groups to easily view available meeting rooms. When users create a new meeting request in Outlook, they
can select the appropriate room-list distribution group, and easily view the availability for all meeting
rooms in the list.
Designing Resource Booking Policies
Exchange Server 2010 provides several optionsor booking policiesthat you can use for configuring
resource mailbox settings and for customizing the resource mailbox to meet your organizations needs.
Booking polices define the automatic scheduling of resources.
A resource booking policy specifies:
Who can schedule a resource.
When the resource can be scheduled.
What meeting information will be visible on the resources calendar.
The response message that meeting organizers will receive.
Options for Configuring Automate Processing Settings

Exchange Server 2010 provides several options that you can use for configuring resource mailbox settings
and to customize it to meet most business needs. There are three values for Automate Processing: None,
Booking Attendant (AutoAccept), and Calendar Attendant (AutoUpdate). By default, the Calendar
Attendant is enabled on each resource mailbox. For the resource mailbox to process and accept meeting
requests, you must enable the Booking Attendant. In Exchange Server 2010, you can use both the
Exchange Management Console and Exchange Management Shell to configure resource mailboxes.
Three common scheduling scenarios used are automatic booking, manual approval by delegates, and
manual approval from the resources.
To enable automatic booking, the booking attendant should be enabled and the policy should be
configured.
To enable manual approval by delegates, the booking attendant should be enabled, and then All
Book In Policy should be disabled. Next the All Request In Policy should be enabled, and the
delegates should be specified.
To enable manual approval from the mailbox, the booking attendant should be left disabled.
You can use the Exchange Management Console, or the Exchange Management Shell to configure
resource booking policies. The following table lists the Set-CalendarProcessing parameters that you can
configure. These options also are available when you access the resource mailbox properties in the
Exchange Management Console.
Setting Description
AllowConflicts Specifies whether to allow conflicting meeting requests. The default

configuration is false, which prevents overlapping appointments for
a resource.
AllowRecurringMeetings Specifies whether to allow meetings that happen regularly. The

default is true, which allows you to books rooms and equipment for
recurring meetings such as weekly status meetings.
AllRequestInPolicy Specifies whether to allow all users to submit in-policy requests. The
default is true, which allows all users to request appointments with
the resource, if the request meets all specified requirements, such as
no conflicts. A resource mail delegate still must approve all requests,
unless AllBookInPolicy is true.
AllBookInPolicy Specifies whether to approve in-policy requests automatically

from all users. The default is true, which allows all users to book
appointments with the resource, if the request meets all specified
requirements, such as no conflicts.
AllRequestOutOfPolicy Specifies whether to allow all users to submit out-of-policy requests.

The default is false, which prevents all users from requesting
appointments that do not meet specified requirements, such as
no conflicts.
BookInPolicy Specifies a list of users for whom requests that meet the specified
requirements are booked automatically without approval from a
resource mailbox delegate.
ConflictPercentageAllowed Specifies the maximum percentage of meeting conflicts for new

recurring meeting requests.
DeleteAttachments Specifies whether to remove attachments from all incoming

messages.
EnableResponseDetails Specifies the reasons for accepting or declining a meeting request

in the response email message.
ForwardRequestsToDelegates Specifies whether to forward incoming meeting requests to the

resource delegates.
MaximumConflictInstances Specifies the maximum number of conflicts for new recurring

meeting requests.
RemoveOldMeetingMessages Specifies whether to remove old and redundant updates and

responses.
RemovePrivateProperty Specifies whether to remove the private flag on incoming meeting

requests.
RequestInPolicy Specifies a list of users who are allowed to submit in-policy meeting
requests.
(continued)
Setting Description
RequestOutOfPolicy Specifies a list of users who are allowed to submit appointment

requests that do not meet specified requirements, such as no
conflicts. A resource mailbox delegate still must approve all
requests.
ResourceDelegates Specifies a list of users who are resource delegates.
ScheduleOnlyDuringWorkHours Specifies whether to allow meetings to be scheduled outside of

work hours.
TentativePendingApproval Specifies whether to mark pending requests as tentative on the

calendar. The default is true, which marks appointment requests as
tentative until they are approved. When this value is false, pending
appointments are not displayed on the calendar.
MaximumDurationInMinutes Specifies the maximum length of the appointment that the resource
will accept.
Considerations for Developing a Resource Booking Policy

When designing the resource booking policy, you must consider:
Who can schedule a resource. You might accept the default settings for most resources in the
organization, but consider restricting who can book heavily used or important resources. For example,
if you use a resource room mailbox to manage the schedule for a large conference room, you may
want to restrict who can book meetings in the conference room.
When users can schedule the resource. You may want to set restrictions on the time of day when
meetings can be booked with a resource, or restrict the meeting length or meeting recurrence.
The automatic acceptance policy for the meeting resource. By default, all resource mailboxes are
configured to accept all new appointment requests as tentative, until a user approves the request.
Because the meeting is set to tentative, this also enables other users to book the meeting resource for
the same time. By changing the Automate Processing attribute for the resource mailbox, you can
modify the default behavior. The default value is configured as Auto Update. If you set the value to
Auto Accept, the resource mailbox accepts all meetings from authorized users automatically, and
prevents other users from booking the resource at the same time.
Question: How will you use resource mailboxes in your environment?

Demonstration: How to Manage Resource Mailboxes
In this demonstration, you will use Exchange Management Console to:
Create and configure a resource mailbox.
Configure a delegate for a resource mailbox.
Configure a room list distribution group.
Demonstration Steps
Create a resource mailbox
1. On VAN-EX1, in the Exchange Management Console, create a new room mailbox with the following
information:
Name: Conference Room 1
User logon name (User Principal Name): ConferenceRoom1
Alias: ConferenceRoom1
2. After creating the room mailbox, modify the properties, and enable the resource booking attendant.
3. Open Windows Internet Explorer, and log on to Outlook Web App as Adatum\Administrator with
the password Pa$$w0rd.
4. In Outlook Web App, create a new Meeting Request. Invite the Conference Room 1 resource mailbox
to the meeting.
5. Send the meeting request and verify that the resource accepted the invitation.
Configure a delegate for a resource mailbox
1. On VAN-EX1, in the Exchange Management Console, access the Conference Room 1 properties.
2. Add Luca Dellamore as a delegate on the mailbox, and configure the mailbox properties so that all
meeting requests must be approved by the delegate.
3. Configure Luca Dellamore to have Full Access Permissions for Conference Room 1.
4. Configure the company name for the mailbox as Fourth Coffee.
5. Verify that the delegate has to accept the meeting request for the room mailbox.
Configure a room list distribution group
1. On VAN-EX1, in the Exchange Management Shell , run the following commands to create a room list
distribution group that includes all mailboxes with a company attribute of Fourth Coffee:
$Members=Get-User -Filter {(RecipientTypeDetails -eq "RoomMailbox") -and (Company -eq

"Fourth Coffee")}
New-DistributionGroup -Name "Fourth Coffee Conference Rooms" -RoomList -Members $Members
2. On NYC-CL1, verify that the room list is available.
Question: How does your organization use resource mailboxes?
Question: Which attributes are useful for your resource mailboxes?

Lesson 2
Managing Other Recipients
Exchange Server also includes other recipient types that provide additional functionality, such as sending
email to an entire company department or sharing email addresses between users, for recipients outside
your company.
In this lesson, you will be introduced to the other recipient types in Exchange Server 2010 such as contacts
and distribution groups.
Describe the functionality of mail contacts and mail users.
Describe the purpose of a distribution group.
Explain the options for configuring distribution groups.
Manage distribution groups by using the Exchange Control Panel.

What Are Mail Contacts and Mail Users?
Mail contacts are mail-enabled Active Directory contacts. These contacts contain information about
people or organizations that exist outside your Exchange Server organization. You can view mail contacts
in the GAL and other address lists, and you can add them as members to distribution groups. Each contact
has an external email address, and all email messages that are sent to a contact are automatically
forwarded to that address.
If multiple people within your organization contact a trusted external person, you can create a mail
contact with the persons email address. This allows Exchange Server users to select that person from the
GAL for sending email.
Mail users are similar to mail contacts. Both have external email addresses, they contain information about
people outside your Exchange Server organization, and you can display them in the GAL and other
address lists. However, unlike a mail contact, mail users have Active Directory logon credentials and can
access resources to which they are granted permission.
If a person external to your organization requires access to resources on your network, you should create
a mail user instead of a mail contact. For example, you may want to create mail users for short-term
consultants who require access to your server infrastructure, but who will use their own external email
addresses.
In another scenario, you can create mail users for whom you do not want to maintain an Exchange Server
mailbox. For example, after an acquisition, the acquired company may maintain its own messaging
infrastructure, but it may also need access to your networks resources. For those users, you might want to
create mail users instead of mailbox users.
Question: When would you use mail-enabled contacts?

Question: Why would you use a mail-enabled contact rather than a mail-enabled user?
What Are Distribution Groups?
You can use mail-enabled groups to allow end users to send email to multiple recipients. Mail-enabled
groups also allow you to assign permissions simultaneously to multiple users for Exchange Server objects,
such as private mailboxes and public folders. In Exchange Server 2010, mail-enabled groups belong to
one of the following four categories:
Universal Security groups. Can be mail-enabled and can be assigned permissions outside of Exchange
Server.
Distribution groups. Are mail-enabled and can only be assigned Exchange Server permissions for
things such as Public folders. The two types of distribution groups are:
Static
Dynamic
Public groups. End users can manage these distribution groups through the Exchange Control Panel.
Within Exchange Control Panel, the end user can add or remove group members, moderate the
group, or even request access to other public groups.
Moderated groups. These are distribution groups that allow the group manager to approve or reject
either all messages sent to the group or from specific users. You can use moderated groups to restrict
the conversations that occur between group members.
Question: When would your organization use distribution groups?
Question: When would your organization use public and moderated groups?
Options for Configuring Distribution Groups
Similar to the options available for configuring mailboxes, there are a number of options available for
configuring mail-enabled groups.
You can configure several options for Exchange Server distribution groups, including:
Group membership. These are the objects that are in the distribution group.
Maximum message size. Use this option to set the maximum size for messages that can be sent to the
distribution group.
Message delivery options. Use these options to configure which users can send messages to the
group.
Address list visibility. Use this option to hide the group from the address list. You can use this option
when the distribution group is used mainly for receiving email from the Internet, and internal users
do not need it.
Delivery of out-of-office messages. Enable this option to send out-of-office messages back to the
message sender, if one of the distribution group recipients has enabled out-of-office notifications.
Non-delivery reports. Use this option to configure non-delivery reports (NDR). You can choose to
send an NDR or specify whether they are sent to the distribution lists manager or to the message
originator.
E-mail addresses for the group. Use this option to configure the distribution groups email address.
Message moderation. Use these options to assign moderators permissions to review all messages that
are sent to the distribution list. You also can configure a list of users that do not require moderation.
Additionally, you can configure notifications to alert the message originators if their message is
approved or not.
Creating and managing distribution groups in the Exchange Control Panel. Users, who have the
permission to create distribution groups that are not security groups, can create and manage these
groups by using the Exchange Control Panel. By default, members of the Recipient Management
or Organization Management group have the required permissions. You can also assign these
permissions to other users by adding the MyDistributionGroups role to each users role assignment.
Note Module 10 covers user role assignments in more detail.
Membership approval. With Exchange Server 2010, users can request to join or leave distribution
groups that are not security groups by using the Exchange Control Panel. When you create a
distribution group, you can use the following options to control if and how users can join or leave the
group:
Choose whether owner approval is required to join the group. If you choose Open, users can
join this distribution group without the approval of the distribution group owners. If you choose
Closed, only distribution group owners can add members to the group. Requests to join this
distribution group will be rejected automatically. If you choose owner approval, users can request
membership on this distribution group. The distribution group owner must approve requests to
join the group before the user can join.
Choose whether the group is open to leave. If you choose Open, users can leave this distribution
group without the approval of the distribution group owners. If you choose Closed, only
distribution group owners can remove members from this distribution group. Requests to leave
this distribution group will be rejected automatically.
Question: What is the advantage of enforcing a naming convention for distribution groups?
Demonstration: How to Manage Groups by Using the Exchange

Control Panel
In Exchange Server 2010, you can create and manage distribution groups in the Exchange Control Panel.
When you create a distribution group by using the Exchange Control Panel, it will always be configured as
a distribution group rather than a security group. You cannot modify security groups by using the
Exchange Control Panel.
Demonstration Steps
Add MyDistributionGroups to the default user role assignment
1. On VAN-EX1, connect to the Exchange Control Panel, and log in as Adatum\Administrator using
the password Pa$$w0rd.
2. Edit the Default Role Assignment Policy by adding the MyDistributionGroups role.
Create and configure a new distribution group
1. On VAN-EX1, connect to the Exchange Control Panel, and log in as Adatum\Conor using the
password Pa$$w0rd.
2. Create a new distribution group with the following configuration:

Display name: Sales
Alias: Sales
Description: Sales Department
3. Add the following members:

Manoj Syamala
Rohinton Wadia
Paul West
4. Configure the Membership Approval as Owner Approval.
Manage distribution group membership
1. Log on to Exchange Control Panel as Adatum\Wei with the password Pa$$w0rd.
2. Request to join the Sales group.
3. Log on to Outlook Web App as Adatum\Conor with the password Pa$$w0rd.
4. Approve the Request to Join Distribution Group
Question: When would you use public groups?

Lesson 3
Configuring Email Address Policies
In many messaging systems, you might host multiple Single Mail Transfer Protocol (SMTP) domains, and
thus you would need to manage the email addresses assigned to the Exchange recipients. To ensure that
recipients have appropriate email addresses, you can create and apply email address policies.
In this lesson, you will learn about email address policies and how to configure them.

Describe the purpose and functionality of email address policies.
Configure email address policies.

What Are Email Address Policies?
For a recipient to send or receive email messages, the recipient must have an email address. Email address
policies generate the primary and secondary email addresses for your recipients so they can receive and
send email. You must create an accepted domain so that a domain in an email address policy functions
properly. An accepted domain is an SMTP namespace that you can configure Exchange servers to send
messages to, or from which they can receive messages.
By default, Exchange Server contains an email address policy for every mail-enabled user. This default
policy specifies the recipients alias as the local part of the email address and uses the default accepted
domain. The local part of an email address is the name that appears before the @ symbol. However, you
can configure how your recipients email addresses display. To specify additional email addresses for all
recipients or just a subset, you can modify the default policy or create additional email address policies.
Creating an Email Address Policy

Exchange Server applies an email address policy to recipient group based upon an OPATH filter. OPATH is
a querying language designed to query object-data sources. The filter defines the search scope in the
Active Directory forest and the attributes to match.
The New E-mail Address Policy Wizard provides a standard list of recipient scope filters. These include:
All recipient types. Select this check box if you do not want to filter recipient type.
Users with Exchange mailboxes. Select this check box if you want your email address policy to
apply to users who have Exchange Server 2010, Exchange Server 2007, and Exchange Server 2003
mailboxes. Users with Exchange mailboxes are those that have a user domain account and a mailbox
in the Exchange organization.
Users with external e-mail addresses. Select this check box if you want your email address policy
to apply to users who have external email addresses. Users with external email accounts have user
domain accounts in the Active Directory Domain Services (AD DS), but use email accounts that are
external to the organization. This enables them to be included in the GAL and added to distribution
lists.
Resource mailboxes. Select this check box if you want your email address policy to apply to
Exchange Server resource mailboxes. Resource mailboxes let you administer company resources, such
as a conference room or company vehicle, through a mailbox.
Contacts with external e-mail addresses. Select this check box if you want your email address
policy to apply to contacts with external email addresses. Mail-enabled groups resemble distribution
groups, as messages sent to a mail-enabled group account will go to several recipients.
Mail-enabled groups. Select this check box if you want your email address policy to apply to security
groups or distribution groups that have been mail-enabled.
The second part of the E-mail Address Policy filter has conditions in one of the following categories:
Recipient is in a State or Province. Select this check box if you want the email address policy to
include only recipients from specific states or provinces. The Address and Phone tabs in the recipients
properties contains this information.
Recipient is in a Department. Select this check box if you want the email address policy to include
only recipients in specific departments. The Organization tab in the recipients properties contains this
information.
Recipient is in a Company. Select this check box if you want the email address policy to include only
recipients in specific companies. The Organization tab in the recipients properties contains this
information.
Custom Attribute equals Value. There are 15 custom attributes for each recipient. There is a
separate condition for each custom attribute. If you want the email address policy to include only
recipients that have a specific value set for a specific custom attribute, select the check box that
corresponds to that custom attribute.
When creating an email address policy, you can use the following email address types:
Default SMTP e-mail address. Default SMTP email addresses are commonly used email address types
that Exchange Server provides for you.
Custom SMTP e-mail address. If you do not want to use one of the default SMTP e-mail addresses,
you can specify a custom SMTP email address. When creating a custom SMTP email address, you can
use the variables in the following table to specify alternate values for the local part of the email
address.
Variable Value
%g Given name (first name)
%i Middle initial
%s Surname (last name)
%d Display name
(continued)
Variable Value
%m Exchange alias
%xs Uses the x number of letters of the surname. For example if

x=2, the first two letters of the surname are used
%xg Uses the x number of letters of the given name. For example,
if x=2, the first two letters of the given name are used
NonSMTP email address. Exchange Server 2010 supports a number of nonSMTP address types.
When you upgrade from Exchange Server 2003, you need to complete an upgrade process to allow
Exchange Server 2010 administrative tools to manage the legacy Recipient policies as E-mail Address
policies.
Demonstration: How to Configure Email Address Policies
In this demonstration, you will see how to modify existing email address policies, create new policies, and
configure an alias.
Demonstration Steps
Create a new email address policy for Fourth Coffee recipients

Configuration, and then select Hub Transport.
3. Create a new email address policy named with these attributes:
Name: Fourth Coffee
Display Name: Fourth Coffee
Recipient container to apply filter: Adatum.com
Included recipient types: All Recipient types
4. Use the user Alias as the local part of the email address.
5. Select fourthcoffee.com as the accepted domain.
6. Apply the email address policy immediately.
Verify that the email address policy has been applied
and then select Mailbox.
2. Verify that the updated email address was applied to Paul West and Luca Dellamore.
Lesson 4
Configuring Address Lists and Address Books Policies
Address lists are similar to a telephone book in that they provide a clearing house in which users can
locate, send email to, and find information about, other users. In larger or specialized organizations, you
may need to modify the lists organization.
In this lesson, you will learn about address lists and how to manage them.

Explain the functionality of address lists.
Configure address lists.
Describe how to configure offline address books.
Describe the options for deploying offline address books.
Describe address books policies.
Configure address books policies.

What Are Address Lists?
Address lists are recipient objects that are grouped together based on a Lightweight Directory Access
Protocol (LDAP) query for specific Active Directory attributes. You can use address lists to sort the GAL
into multiple views, which makes it easier to locate recipients. This is especially helpful for very large or
highly segmented organizations.
Similar to configuring email address policies, you can configure address lists with recipient filters that
determine which objects belong in each address list. Address lists are evaluated every time a mail-enabled
account is modified to determine on which address lists it should appear.
Example 1
Consider a company that has two large divisions and one Exchange organization. One division, named
Fourth Coffee, imports and sells coffee beans. The other division, Contoso, Ltd., underwrites insurance
policies and therefore the employees rarely communicate with each other. To make it easier for
employees to find recipients who exist only in their division, you can create two new custom address
lists: one for Fourth Coffee and one for Contoso, Ltd. When searching for recipients in their division,
these custom address lists allow employees to select only the address list that is specific to their division.
However, if an employee is unsure about the division in which the recipient exists, the employee can
search within the GAL, which contains all recipients in both divisions.
Example 2
You can use subcategories of address lists called hierarchical address lists. For example, you can create an
address list that contains all recipients in Vancouver and another that contains all Redmond recipients.
You also can create another list called Research and Development within the Vancouver address-list
container, which contains all employees who work in Vancouvers Research and Development department.
This allows employees to more easily find the information they need.
Demonstration: Configuring Address Lists
In this demonstration, you will see how to create and configure address lists.
Demonstration Steps
Create a new Email Address list for Fourth Coffee recipients
1. Open Exchange Management Console.

Configuration, and then select Mailbox.
3. Create a new address list with the following attributes.
Name: Fourth Coffee
Display Name: Fourth Coffee
Container: \
Recipient container to apply filter: Adatum.com
Included recipient types: All Recipient types
4. Use the Recipient is in a Company condition to apply this policy to only recipients that list Fourth
Coffee for their company attribute.
5. Preview the address list.

6. Apply the email address list immediately.
Verify the new address list is working
1. Log on to Outlook Web App as Adatum\George with the password Pa$$w0rd.
2. Open the Address book, and view the members of the Fourth Coffee address list.
3. Close Outlook Web App.
Configuring Offline Address Books
Exchange Server 2010 provides several configuration options for deploying offline address books. Office
Outlook uses the offline address book when you configure it to use a cached mode Outlook profile, or
when it is in offline mode. The default offline address book contains the entire global address list (GAL),
which includes all recipients in the Exchange organization. You can create additional GALs, which contain
a subset of recipients. By default, these additional GALs are not included in the default offline address
book.
By default, the offline address book generates only once each day. This means that any additions,
deletions, or changes made to mail-enabled recipients are only committed to the offline address book
once each day, unless you modify the schedule to generate the offline address book more often. In many
environments, you would need to modify the offline address book generation schedule to accommodate
the rate of change in a particular Exchange Server organization.
The process of generating and distributing the offline address book consists of the following components:
Offline address book generation process. To create and update the offline address book, the
OABGen service runs on the offline address book generation server, which must be a Mailbox server.
Microsoft Exchange File Distribution service. The Microsoft Exchange File Distribution service runs
on Client Access servers. This service gathers the offline address book and keeps the content
synchronized with the content on the offline address book generation server.
OAB virtual directory. The OAB virtual directory is the distribution point needed by the web-based
distribution used by Microsoft Office Outlook 2007 and newer clients. By default, when you install
Exchange Server, a new virtual directory named OAB is created in the default internal Web site in
Internet Information Services (IIS). For users that work outside your company, you can add an external
website.
Autodiscover service. Autodiscover service was introduced in Exchange Server 2007 as a feature
where Office Outlook 2007 or newer clients, as well as some mobile devices, automatically configure
their profile to access Exchange Server. This service runs on a Client Access server and returns the
correct OAB URL for a specific client connection.
As a best practice, whether you use a single offline address book or multiple offline address books,
consider the following factors as you plan and implement your offline address book strategy:
Size of each offline address book in your organization.
Number of offline address book downloads. How many clients will need to download the offline
address book?
Overall number of changes made to the directory. If a large number of changes are made, the size of
the differential offline address book downloads will be large.
Offline Address Book Size Considerations

In some large organizations that have large directories, or for organizations that have deployed Office
Outlook in cached mode, the size of the offline address book may be a concern. Offline address book
sizes can vary from a few megabytes (MBs) to a few hundred MBs. The following factors can affect the size
of the offline address book:
Usage of certificates in a company. The higher the number of public key infrastructure (PKI)
certificates, the larger the size of the offline address book. PKI certificates range from 1 kilobyte (KB)
to 3 KB. They are the single largest contributor to the offline address book size.
Number of Active Directory mail recipients.
Number of Active Directory distribution groups.
Information that a company adds to AD DS for each mailbox-enabled or mail-enabled object. For
example, some organizations populate the address properties for each user; others do not. The offline
address book size increases as the number of attributes used increases.
Options for Deploying Offline Address Books

Public folder distribution is the distribution method by which Microsoft Office Outlook 2003 accesses the
offline address book. With public folder distribution, the generation process for the offline address book
places the files directly in one of the system public folders, and then, if multiple replicas of the public
folder are configured, Exchange Server store replication copies the data to other public folder distribution
points.
Microsoft Office Outlook 2007 and newer clients that are working in cached mode can also use the public
folder as the source for the OAB. In addition, these clients can use web-based distribution to access the
offline address book. Web-based distribution does not require the use of public folders. Instead, after the
offline address book generates the files, the Client Access server replicates them. Web-based distribution
uses Secure Hypertext Transfer Protocol (HTTPS) and Background Intelligent Transfer Service (BITS). If you
require redundancy, you can use multiple Client Access servers as publishing points.
What Are Address Book Policies?
Some organizations require that certain users be prohibited from seeing all of the other users in the
global address list (GAL). For example, a large investment company may have several divisions that are
competitors in selected markets, and allowing communication between investors in each division may
violate trading laws. Other organizations have extremely large GALs and may want to limit the size of the
offline address book for users. Limiting what users can see in the GAL is called GAL segmentation.
In Exchange 2010 SP2, you can use address book policies to configure GAL segmentation. When
configuring an address book policy, you assign a GAL, an offline address book, a room list, and one or
more address lists to the policy. You can then assign the address book policy to mailbox users, which
means that the users can only see the objects in the GAL that are part of their policy.
Note Address book policies provide a virtual segmentation of the GAL, not a legal
separation. This means that users may sometimes be aware of other recipients in the
organization that are not part of their address book policy. For example, a distribution
group that is included in the address book policy may include recipients from other address
book policies. If one of those recipients has an out of office message configured, the out of
office message will be sent to anyone who sends to the distribution group.
Address book policies are only applied when the users email client connects to the Microsoft Exchange
Address Book service on an Exchange Server 2010 SP2 Client Access server. If you update the address
book policy, the client must reconnect to the Address Book service before the new policy is applied. If a
client accesses the global address list through another means, such as a direct LDAP query to a global
catalog server, the address book policy does not apply.
Demonstration: Configuring Address Books Policies
Address book policies contain the following lists:
One GAL
One offline address book
One room list (for booking purposes)
One or more address lists
In this demonstration, you will perform the following tasks to configure an address book policy for the
Fourth Coffee organization:
Create a global address list for Fourth Coffee users
Create a new offline address book for Fourth Coffee users
Create the address book policy
Question: Does your organization have a requirement for address book policies? If so, how
will you use them?
Lesson 5
Performing Bulk-Recipient Management Tasks
Managing a large number of recipients can be time consuming. Manual changes are also prone to error.
You can use the Exchange Management Shell to create scripts that automate these management tasks.
In this lesson, you will be introduced to bulk management of recipients and using Exchange Management
Shell to manage multiple recipients.

Describe the benefits of managing recipients in bulk.
Describe examples of Exchange Management Shell cmdlets that manage multiple objects.
Manage multiple recipients.

Discussion: Benefits of Managing Recipients in Bulk
Exchange Management Shell cmdlets are powerful tools that you can use for managing multiple
recipients simultaneously. The cmdlets use features such as pipelining and filtering to sort the results of
one cmdlet and apply the result to another cmdlet. Exchange Management Shell also is a very powerful
scripting tool for managing multiple recipients in bulk. In small organizations, you might not need to
manage multiple recipients at the same time. However, in medium or large organizations, you may often
need to manage multiple users at the same time, and it is useful to know how to use Exchange
Management Shell to do that.
Question: Describe situations where you need to create multiple recipients.
Question: Describe situations where multiple recipients need to be modified.

Exchange Management Shell Examples
You can use Exchange Management Shell commands to manage multiple recipients or other objects at
one time. The primary means to do this are piping and filtering.
Piping Output Between Cmdlets

For relatively simple tasks, pipe output from one cmdlet to another to perform bulk management tasks.
The most common structure is to use one cmdlet to gather a list of recipients or Active Directory objects,
and then pipe that list to a second cmdlet that performs the necessary action.
In the following example, the first cmdlet gathers the list of Marketing organizational unit (OU) users, and
then you pipe that list of users to a second cmdlet that moves those users to a new mailbox database.
Get-User OrganizationalUnit Marketing | Enable-Mailbox VAN-EX1

\Mailbox Database 1
All cmdlets that gather lists of objects for manipulation begin with Get. Some cmdlets that gather a list of
recipients or Active Directory objects are:
Get-User. Gathers a list of user objects from AD DS.

Get-Recipient. Gathers a list of recipients.
Get-Mailbox. Gathers a list of mailboxes.
Get-MailUser. Gathers a list of mail-enabled users.
Get-Contact. Gathers a list of contacts.
Get-Group. Gathers a list of groups from AD DS.

The following example returns all members in the Sales distribution group, configures the mailboxes
to not inherit the default mailbox size limits from the mailbox database, and then assigns a prohibit
send quota of 4 GB:
Get-DistributionGroup Sales | Get-DistributionGroupMember | Set-Mailbox

UseDatabaseQuotaDefaults $false ProhibitSendQuota 4GB
The following example retrieves a list of all mailboxes on VAN-EX1, and then moves these mailboxes
to Mailbox Database 2:
Get-Mailbox -server VAN-EX1 | New-MoveRequest -Local -TargetDatabase "Mailbox

Database 2"
Custom Filters
You must specify a filter string when you run various Exchange Management Shell cmdlets, such as
Get-User, and you want to create a custom filter by using the Filter or RecipientFilter parameter.
Microsoft Windows PowerShell uses OPATH for the filtering syntax. OPATH is a querying language
that queries object data sources. With the Exchange Management Shell, which is built on PowerShell,
you no longer need to use the complicated syntax of Lightweight Directory Access Protocol (LDAP),
which Exchange Server 2003 used, to create filters. Instead, you can create filters by using the more
simple OPath syntax, which the following example shows:
Syntax: -Filter {(attribute operation value) operation (attribute operation value)}
The following cmdlet selects users with the Company attribute defined as Adventure Works, and who are
not working in the IT department.
Get-User -Filter {(Company eq Adventure Works) -and (Department ne IT)}
Common operations are:

-and
-or
-not
-eq (equals)
-ne (does not equal)
-lt (less than)
-gt (greater than)
-like (string comparison)
-notlike (string comparison)
The following example removes all messages with the word Sale in the subject from all message queues:
Get-Message -Filter {Subject -like *Sale*"} | Remove-Message

Demonstration: How to Manage Multiple Recipients
Exchange Management Shell provides several features that you can use to perform bulk recipient
management. For relatively simple tasks, you can pipe output between cmdlets to retrieve a list of
appropriate objects, and then you can modify them. You can use scripting for complex tasks, such as
creating users from a .csv file.
Scripts
Create scripts to perform advanced bulk-management tasks that are not possible with piping. Scripts can
create more complex structures, and consequently enable you to perform more complex tasks.
Using scripts, you can:
Define variables.
Use loops.
Read data files to obtain user names and passwords.
Demonstration Steps
1. The instructor will run the following cmdlets:
Get-User filter {Company eq "Fourth Coffee"}
Disable-mailbox Scott
Get-User OrganizationalUnit Accounting | Set-Mailbox UseDatabaseQuotaDefaults $false
ProhibitSendQuota 4GB
Get-Mailbox Parna | FL Name,Prohibit*
2. The instructor will run the following script. The script will create mailboxes based on information
provided in a .csv file.
## Section 1
## Define Database for new mailboxes
$db="Mailbox Database 1"
## Define User Principal name

$upndom="Adatum.com"
## Section 2
## Import csv file into variable $users
$users = import-csv $args[0]
## Section 3
## Function to convert password string to secure string
function SecurePassword([string]$plainPassword)
{
$secPassword = new-object System.Security.SecureString
Foreach($char in $plainPassword.ToCharArray())
{
$secPassword.AppendChar($char)
}
$secPassword
}
## Section 4
## Create new mailboxes and users
foreach ($i in $users)
{
$sp = SecurePassword $i.password
$upn = $i.FirstName + "@" + $upndom
$display = $i.FirstName + " " + $i.LastName
New-Mailbox -Password $sp -Database $db DisplayName $display -UserPrincipalName
$upn -Name $i.FirstName -FirstName $i.FirstName -LastName $i.LastName -
OrganizationalUnit $i.OU
}
3. In Exchange Management Console, verify that the users listed in the .csv file have been created.
Question: Which tasks will you automate with PowerShell scripts?

Lab: Managing Exchange Recipients
Lab Setup
2. Ensure that the 10135B-VAN-DC1, 10135B-VAN-EX1, and 10135B-VAN-CL1 virtual machines are
running.
10135B-VAN-DC1: Domain controller in the Adatum.com domain.
10135B-VAN-EX1: Exchange 2010 server in the Adatum.com domain.
10135B-VAN-CL1: Windows 7 client computer in the Adatum.com domain.
3. If required, connect to the virtual machines. Log on to the computers as Adatum\Administrator,

using the password Pa$$w0rd.
Lab Scenario
You are the messaging administrator for A. Datum Corporation. Your company is purchasing a new
company called Adventure Works. Adventure Works recipients will need to maintain a separate email
domain and address list. You also must create new mailboxes for the new departments employees.
Exercise 1: Managing Recipients

Scenario
Your manager wants you to complete several tasks in preparation for the Adventure Works acquisition
project.
1. Create and configure a mailbox for called Adventure Works Questions.
2. Create a resource mailbox and configure auto-accept settings for the Adventure Works Project Room.
3. Move George Schallers mailbox to VAN-EX1\Mailbox Database 1.
4. Create and configure a mail-enabled contact for Ian Palangio at Woodgrove Bank.
5. Create a moderated distribution list for Adventure Works Project, and delegate an administrator.
6. Create a room list distribution group for the Adventure Works meeting rooms.
7. Verify that changes were completed successfully.
X Task 1: Create and configure a mailbox called Adventure Works Questions

2. Create a new mailbox named Adventure Works Questions in the Mailbox Database 1 database.
Configure a user logon name of AdventureWksQ and a password of Pa$$w0rd.
3. Configure the mailbox with a Company name of Adventure Works.
4. Assign George Schaller full access to the Adventure Works Questions mailbox.
X Task 2: Create a resource mailbox, and configure auto-accept settings for the
ProjectRoom
1. In Exchange Management Console, create a new room mailbox named ProjectRoom in the Mailbox
Database 1 database. Configure a user logon name of ProjectRoom.
2. Enable the Booking Attendant on ProjectRoom.
3. Configure the ProjectRoom with the Company name of Adventure Works.
X Task 3: Move George Schallers mailbox to VAN-EX1\Mailbox Database 1

In Exchange Management Console, create a new local move request to move George Schallers
mailbox to VAN-EX1\Mailbox Database 1.
X Task 4: Create and configure a mail-enabled contact for Ian Palangio at Woodgrove
Bank
In Exchange Management Console, create a new mail-enabled contact for Ian Palangio, using an
alias of IanPalangioWB and an email address of ian.palangio@woodgrovebank.com.
X Task 5: Create a moderated distribution list for the Adventure Works Project, and
delegate an administrator
1. In Exchange Management Console, create a new Distribution group called Adventure Works Project
with an alias of AdventureWorksProject.
2. Add the following recipients to the Adventure Works Project group:
George Schaller
Ian Palangio
Wei Yu
Paul West
3. Specify George Schaller as the group moderator, and enable moderation of all messages.
X Task 6: Create a room list distribution group for the Adventure Works meeting
rooms
1. On VAN-EX1, if required, open the Exchange Management Shell.
2. At the command prompt, type $Members=Get-User -Filter {(RecipientTypeDetails -eq
"RoomMailbox") -and (Company -eq "Adventure Works")} and press Enter.
3. At the command prompt, type New-DistributionGroup -Name "Adventure Works Conference

Rooms" -RoomList -Members $Members and press Enter.
X Task 7: Verify that changes were completed successfully

1. Log on to VAN-CL1 as Adatum\Administrator, and open Outlook.
2. Create and send a new meeting request. Invite the Adventure Works Project group, and select the
Adventure Works Conference Rooms room list. Specify ProjectRoom as the room.
3. On VAN-EX1, open Outlook Web App, log on as Adatum\George, using the password Pa$$w0rd,
and accept the meeting request message. Send the response now.
Results: After this exercise, you should have completed all of the assigned tasks, which include creating a
mailbox, creating a resource mailbox, moving a mailbox, creating a contact, and creating a moderated
distribution group.
Exercise 2: Configuring Email Address Policies

Scenario
Adventure Works maintains a distinct identity for customers, but some functions, such as accounting, are
integrated with A. Datum Corporation. To ensure that users receive all email properly, they must be able
to receive email at all domains, but use their own domain as the reply-to address.
1. Create an email address policy for Adventure Works users.
2. Verify that addresses were applied to A. Datum users.

X Task 1: Create an email address policy for Adventure Works users

2. Create a new email address policy with the following configuration:
a. Apply to all recipients with a company attribute of Adventure Works the Adatum.com domain.
b. SMTP address: first name.last name@adventure-works.com.
c. Accepted domain: Adventure-works.com.
X Task 2: Verify that addresses are applied correctly

1. In the Exchange Management Console, view the properties for George Schaller, and modify his
company description to Adventure Works.
2. Confirm that George Schaller has an email address that uses the adventure-works.com domain.
Results: After this exercise, you should have created an email address policy for Adventure Works users.
Exercise 3: Configuring Address Lists

Scenario
New address lists and offline address books are necessary to organize the address books for users in the
combined A. Datum and Adventure Works organization. However, each organization requires a separate
address to make it easier to find users. You also must create a new offline address book that includes
those address lists to support sales people with portable computers.

1. Create an empty container address list named Companies.
2. Create a new address list for Adventure Works recipients.
3. Create a new address list for A. Datum recipients.

4. Verify the new address list is available in Microsoft Office Outlook.
5. Create a new offline address book for the Adventure Works address list.
6. Create a GAL for Adventure Works users.
7. Create the address book policy for the Adventure Works users.
X Task 1: Create an empty container address list named Companies

2. In the Mailbox node of the Organization Configuration work center, create a new address list named
Companies with no recipients.
X Task 2: Create a new address list for Adventure Works recipients

Create a new address list Adventure Works in Companies for all recipients with the Company
Adventure Works.
X Task 3: Create a new address list for A. Datum Corporation recipients

Create a new address list A Datum in Companies for all recipients with the Company A. Datum.
X Task 4: Verify the new address list is available in Microsoft Office Outlook
1. Log on to VAN-CL1 as Administrator, and open Outlook.
2. Verify that the address book contains the address lists for A. Datum and Adventure Works.
3. Close Outlook.
X Task 5: Create a new offline address book for the Adventure Works address list
1. On VAN-EX1, open Exchange Management Console.
2. Create a new offline address book named Adventure Works with the Adventure Works address list,
and enable distributions through Web-based distribution and public folders. Use the OAB folder on
VAN-EX1 for Web-based distribution.
3. Close the Exchange Management Console.
X Task 6: Create a global address list for Adventure Works users

At the command prompt, type New-GlobalAddressList Name Adventure Works GAL
IncludedRecipients AllRecipients ConditionalCompany Adventure Works and press Enter.
X Task 7: Create the address book policy for the Adventure Works users
In the Exchange Management Console, create a new address book policy with the following
configuration:
Name: Adventure Works ABP
Global address list: Adventure Works GAL

Offline address book: Adventure Works OAB
Room list: Adventure Works
Address Lists: Adventure Works
Results: After this exercise, you should have created an address list for the A. Datum and Adventure
Works users, and an offline address book for each organization.
Exercise 4: Performing Bulk Recipient Management Tasks

Scenario
Your manager left you a number of recipient management tasks to complete for the new Adventure
Works users:
Add a header line to the .csv file exported from the Human Resources (HR) system.
Modify the CreateUsersLab.ps1 script, and import Adventure Works users from a .csv file.
Define mailbox limits for all users in the Adventure Works company.
1. Add a header line to the .csv file exported from the Human Resources (HR) system.
2. Modify the CreateUsersLab.ps1 script to Adventure Works users from a .csv file.
3. Create the AdventureWorks Organizational Unit in the Adatum.com domain
4. Run CreateUsersLab.ps1 to Adventure Works users from a .csv file.
5. Define mailbox limits for all Adventure Works company users.
X Task 1: Add a header to the .csv file exported from the Human Resources (HR) system
1. On VAN-EX1, open D:\Labfiles\Users.csv in Notepad.
2. Add a header line that defines each column:
FirstName
LastName
Password
3. Save the changes to Users.csv, and close Notepad.
X Task 2: Modify the CreateUsersLab.ps1 script to import Adventure Works users

from a .csv file
1. Open D:\Labfiles\CreateUsersLab.ps1 in Notepad.
2. Modify CreateUsersLab.ps1 as required to:

Configure the database to create users as Mailbox Database 1.
Configure the user principal name to be adatum.com.
Place users in the AdventureWorks OU.
Configure the .csv import file to be D:\Labfiles\Users.csv.
Configure the $pwd to be based on the password field in the Users.csv.
Configure the first and last name.
Configure the user principal name (UPN) as first name@adatum.com.
Configure the alias to be the first name and last name, with no space between the names.
Configure the display name to be the first name and last name, with a space between the names.
3. Save the changes to CreateUsersLab.ps1, and close Notepad.
X Task 3: Create the AdventureWorks Organizational Unit

1. Open Active Directory Users and Computers.
2. Create an OU named AdventureWorks.
X Task 4: Run CreateUsersLab.ps1 to import the Adventure Works Users

1. Open the Exchange Management Shell.
2. Run D:\Labfiles\CreateUsersLab.ps1.
X Task 5: Configure the Settings for the Adventure Works users

1. Use the Get-User cmdlet to retrieve all users in the AdventureWorks OU, and then pipe the results to
the Set-User cmdlet to set the Company attribute to Adventure Works.
2. Run Get-Mailbox cmdlet to retrieve a list of all Adventure Works users:
OrganizationalUnit: AdventureWorks
3. Set mailbox limits by piping the list of mailboxes to the Set-Mailbox cmdlet:
IssueWarningQuota 4GB
ProhibitSendQuota 5GB
4. Configure the Adventure Works mailboxes to use the Adventure Works ABP address book policy
Results: After this exercise, you should have created all of the additional Adventure Works users with an
Exchange Management Shell script, and then have set the storage quota.

following steps:
Note Start the VAN-DC1 virtual machine first, and ensure that it is fully started before
starting the other virtual machines.
Review Questions
1. How would you ensure that meeting requests to room mailboxes are validated manually before being
approved?
2. How would you give access to allow a user to send messages from another mailbox, without giving
them access to the mailbox contents?
3. What should you consider when configuring offline address book distribution?
Common Issues Related to Configuring Offline Address Books

Identify the causes for the following common issues related to configuring offline address books, and
complete the troubleshooting tips. For answers, refer to relevant lessons in the module.
The offline address book is not up-to-

date with changes made during the day.
Outlook 2003 clients are not able to

download the offline address book.

1. A company that has two large divisions and one Exchange Server organization. Employees in each
division rarely communicate with each other. What can you do to reduce the number of recipients
the employees of each division see when they open the Exchange address list?
2. An organization has a large number of projects that leverage distribution groups. Managing group
members takes considerable time. You need to reduce the time the help desk spends managing
groups so that they can work on other issues.
3. You employ contractors that need an email address from your company. The company needs to
enable the contracts to receive these messages in their current third-party mailboxes.
Best Practices Related to Managing Recipient Objects

Define clear naming conventions and adhere to them. Naming conventions help identify location and
purpose of recipient objects, and helps both end users and administrators locate recipients easily.
Test global changes prior to making them in production. Changes to global settings, like email
address policies, should be tested in a lab environment before you make changes in production. This
avoids configuration errors.
4-1
Module 4
Managing Client Access
Contents:
Lesson 1: Configuring the Client Access Server Role 4-3
Lesson 2: Configuring Client Access Services for Outlook Clients 4-24
Lab A: Configuring Client Access Servers for Outlook Anywhere Access 4-44
Lesson 3: Configuring Outlook Web App 4-48
Lesson 4: Configuring Mobile Messaging 4-57
Lab B: Configuring Client Access Servers for Outlook Web App

and Exchange ActiveSync 4-67
4-2 Managing Client Access
Module Overview
Microsoft Exchange Server 2010 provides access to user mailboxes for many different clients. All
messaging clients access Exchange Server mailboxes through a Client Access server. Because of the
importance of this server role, you must understand how to configure it to support all different client
types. This module provides details on how to implement the Client Access server role in Exchange
Server 2010.

Configure the Client Access server role.
Configure Client Access services for Microsoft Office Outlook Clients.
Configure Outlook Web App.
Configure mobile messaging.
Lesson 1
Configuring the Client Access Server Role
You can implement the Client Access server role on an Exchange server that has other roles except the
Edge Transport server role. Alternately, you can deploy the Client Access server role on one or more
dedicated servers. In many organizations, the Client Access server is accessible from the Internet, thus
securing the Client Access servers is an important part of deployment. This lesson describes the process
for deploying and securing a Client Access server.

Describe how client access works in Exchange Server 2010.
Describe how client access works with multiple sites.
Describe the Client Access server deployment options.
Configure a Client Access server.
Secure a Client Access server.
Explain Client Access server deployment considerations.
Configure Client Access server certificates.
Describe the configuration options for Post Office Protocol 3 (POP3) and Internet Message Access
Protocol 4 (IMAP4) client access.
Describe how to configure the Client Access server for secure Internet access.
How Client Access Works
In Exchange Server 2010, all messaging clients connect to a Client Access server when accessing an
Exchange Server mailbox. For users to access their mailbox, you must deploy a Client Access server in the
same site as the Mailbox server.
Important In Microsoft Exchange Server 2007 or earlier Exchange server versions, MAPI
clients such as Microsoft 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.
How Client Access Servers Work

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 protocol ports for client connections 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 a Microsoft Active Directory Domain Services (AD DS) domain
controller by using the Kerberos protocol 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 uses a Lightweight Directory Access Protocol (LDAP) request to a global catalog server
to locate the Mailbox server that manages the users mailbox.
The Client Access server also provides a directory lookup service for all clients. When the client
requests the global address list (GAL), or searches the GAL for a specific recipient, the Client Access
server performs the Active Directory 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.
Note In Microsoft Exchange Server 2003 and earlier versions, the front-end server
accesses the back-end server on behalf of the client using the same protocol as the client
connection. In Exchange Server 2010, the Client Access server role uses a MAPI RPC
connection.
How Client Access Works with Multiple 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.
In a single-site scenario, the Client Access server communicates directly with Mailbox servers. In a
multiple-site scenario, Exchange Server directs clients 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.
How Client Access Works with Multiple Internet Access Points

If you have multiple Active Directory sites, you can provide Internet access to each sites Client Access
servers. 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 the Domain Name System (DNS) and can connect to
the Client Access server using the appropriate protocol.
When an Internet client connects to the Client Access server from the Internet in this scenario, 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:
1. 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.
2. 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 you configure the Client Access server with 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.
Exchange Server presents the user with a page that provides the correct URL for the Client Access
server, so that the user can connect to the appropriate Client Access server in their home site. If you
do not configure an external URL for the Client Access server in the site that contains the user
mailbox, 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 clients to another Client
Access server in a different site. It proxies all other Client Access server client requests 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. Exchange Server 2010 Service Pack 2 (SP2) provides a
new technology for silent redirection of Outlook Web App clients, which will be discussed
later in this module.
Important Both redirection and using a proxy will not work for POP3 or IMAP4 clients.
POP3 or IMAP4 messaging clients must connect to a Client Access server in the same
Active Directory site as the user's Mailbox server.
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 configured. In this scenario, 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. By default, the Outlook
Web App virtual directory is configured to use forms-based authentication. You should ensure that you
enable forms-based authentication on the Client Access server that is accessible from the Internet. You
also must configure the other Client Access servers to use Windows-integrated authentication.
Exchange Server supports using a proxy for clients that use Outlook Web App, Microsoft
Exchange ActiveSync, and Exchange Web Services. Exchange Server supports using a proxy from one
Client Access server to another, when the destination Client Access server is running the same Exchange
Server version or an earlier version as the source Client Access server.
Best Practice To optimize user mailbox access, you should enable Internet access to the
Client Access servers in each site. This access is particularly important if you have slow
network connections between Active Directory site locations.
Deployment Options for a Client Access Server
When planning your Client Access server deployment, you must meet certain requirements to ensure a
successful deployment. Additionally, there are options for deploying Client Access servers in scenarios
where servers require higher availability, or you have multiple sites.
Requirements for Client Access Server Deployment

When you deploy Client Access servers, you must meet the following requirements:
You must have at least one Client Access server in each Active Directory site where you have Mailbox
servers deployed.
If your Active Directory forest includes multiple domains, each site must have a Client Access server
for each domain that includes Mailbox servers in that site.Client Access servers should have a fast
network connection to Mailbox servers, to support remote procedure call (RPC) connectivity.
Client Access servers should have a fast network connection to domain controllers and global catalog
servers.
If users need to access their mailboxes from the Internet through the Client Access server, then the
server must be accessible from the Internet using HTTP or HTTPS, IMAP4, or POP3.
Best Practice Because the server running the Client Access server role must be a member
server in an Active Directory 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.
Options for Client Access Server Deployment

The Client Access server role performs a critical function in your Exchange Server organization. You have
the following options when deploying the Client Access server role:
You can deploy the Client Access server role on the same computer as all other Exchange Server 2010
server rolesexcept for the Edge Transport server role. Installing all server roles on a single server
does not provide additional availability, and does offer limited scalability.
You can deploy the Client Access server role on a dedicated server. This deployment provides
additional scalability and performance benefits.
You also can deploy multiple servers running the Client Access server role. To provide high availability
for Client Access servers, you can deploy Network Load Balancing, or deploy a hardware network load
balancer to manage connections to the Client Access servers. In Exchange Server 2010, you also can
configure Client Access arrays to provide failover and redundancy. A Client Access array is a container
object used by Exchange Server 2010 Client Access servers. When you deploy database availability
groups (DAGs) Exchange Server 2010 uses Client Access arrays to track which mailbox databases are
located in each Active Directory site, and to manage the client connection failovers to the local
mailbox databases.
Note You can install Client Access servers on Mailbox servers that are DAG members.
However, just adding the Client Access server to a DAG member does not provide high
availability for the Client Access server, because DAG uses Failover Clustering which does
not support Client Access server. To provide high availability for Client Access servers, you
need to implement a Client Access array, and deploy a network load balancing solution. For
more information on Client Access arrays, see Module 7, Implementing High Availability.
Demonstration: How to Configure a Client Access Server
In this demonstration, you will see how to configure the global Client Access server settings, as well as the
settings for each Client Access server in the organization.
Demonstration Steps
2. In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand

Organization Configuration, and then click Client Access. You apply settings to all Client Access
servers and mailboxes while in the Organization Configuration node.
3. Review the default polices on the Outlook Web App Mailbox Policies and Exchange ActiveSync
Mailbox Policies tabs.
4. In the left pane, expand Server Configuration, and then click Client Access.
5. Examine the properties of one of the listed Client Access servers. These properties display information
only, and cannot be used to configure the server settings.
6. In the results pane, review the settings available on each of the tabs. These settings configure the
Client Access server settings for the Client Access server virtual directories.
Question: Why would you create multiple Outlook Web App Mailbox policies or Exchange
ActiveSync polices, rather than just use the default policies?
Question: Why would you modify the server settings on one Client Access server to be
different from those on another Client Access server?
Securing a Client Access Server
In many organizations, the Client Access server is accessible from the Internet for Outlook Anywhere,
Outlook Web App, or Exchange ActiveSync clients. Therefore, it is critical that you ensure that the Client
Access server that faces the Internet is as secure as possible.
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 Secure Sockets Layer (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
exactly matches the server name that users will use to access the Client Access server. Also ensure that
the certificate that the Certification Authority (CA) issues is trusted by all of the client computers and
mobile devices that will be accessing the server. By default, Exchange Server 2010 has a self-signed
certificate installed. However, because of trust issues, it is not recommended to use this certificate for
external connections in production. If you do not have internal public key infrastructure (PKI), you
might consider buying a commercial certificate from a globally trusted provider. In either way, make
sure the server certificate supports Subject Alternative Names (SAN).
2. Make sure that Client Access server virtual directories in IIS are configured to require SSL.
3. Secure the following virtual directories:
Autodiscover
ecp
EWS
Microsoft-Server-ActiveSync
OAB
owa
RPC
RPCWithCert
By default, all these virtual folders are configured to require SSL, after Exchange Server Client Access
Server role is installed. It is not recommended to change this.
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, it negotiates with the client to
determine the most secure authentication method that both 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 you use Integrated Windows authentication and users log on with a
domain account, users 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. For Integrated Windows authentication to work from a web browser, the Client Access
server URL must be in the clients Intranet zone.
Important When using a single Internet-accessible Client Access server for all sites, you
must enable Windows Integrated 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.
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 that is stored in
the AD DS.
Basic authentication. Basic authentication transmits passwords in clear text over the network.
Therefore, you should always secure Basic authentication by using 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
(ECP). 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. When you use 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. Automatic time-out of inactive sessions is valuable because it protects user accounts from
unauthorized access if users leave their session logged on while away from their computers.
The 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.
Note You can configure the time-out values for public and private computers by
modifying the Client Access server registry. You can do this by using 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.
Instead of a pop-up screen, forms-based authentication creates a logon Web page for Outlook Web App.
You can modify the logon page by configuring the logon prompt (user name, domain\user name, or user
principal name), language, graphics, and text. User credentials entered into the Outlook Web App logon
page are transmitted in clear text similar to Basic authentication. However, forms-based authentication
requires the use of SSL. SSL encrypts the user credentials as they are transmitted over the network.
Forms-based authentication is enabled by default for Outlook Web App, and for ECP.However, you might
consider changing this to Windows Integrated authentication for Client Access servers that are not
internet facing, because Forms-Based Authentication does not support single-sign on.
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 proxy, such as Forefront Threat Management Gateway,
between 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 the Client Access server
resources are not used to perform single socket layer (SSL) decryption and encryption.
If you use Forefront Threat Management 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 will be 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 TMG Server computer.
Considerations for Implementing 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.
Choosing a Certification Authority

One of the most important considerations when planning the use of certificates is identifying the source
of the certificates. Exchange Server 2010 can use self-signed certificates, certificates issued by a public CA,
or certificates issued by a private CA. Each type of certificate has advantages and disadvantages.
CA type Explanation
Public CA Advantages:
Client computers already trust the root CA, so certificates can be
chained to the root without further configuration.
The public CA provides full certificate and certificate-revocation
management services.
Disadvantages:
The certificates issues by public CAs are more expensive than self-signed
certificates or certificates issued by internal CAs.
(continued)
CA type Explanation
Internal CA Advantages:
Revocation is managed internally, so certificates can be centrally
revoked 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
can introduce 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 costlier than
buying certificates from a public CA.
Client computers that are not members of an internal Active Directory
domain do not automatically trust the root CA. Therefore, you must add
certificates for the trusted root to client machines, where necessary.
Self-signed certificates Advantages:

Self-signed certificates can be deployed without any Public Key
Infrastructure (PKI) infrastructure. When you install Exchange Server
2010, a self-signed certificate is automatically created for each
computer.
Disadvantages:
No centralized revocation lists. If the private key of the certificate is
compromised, each relying party must be notified manually to change
to a new certificate and stop relying on the existing one.
Client computers will not automatically trust the self-signed certificate,
so you must add certificates for the trusted root to client machines
where necessary.
In an Exchange Server 2010 environment, you can use the self-signed certificates for internal
communication, such as for securing Simple Mail Transfer Protocol (SMTP) connections between Hub
Transport servers. You also can use these certificates to secure client connections to Client Access servers.
However, because none of the client computers trusts this certificate, 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. If users access the Client Access server from the Internet, it is important that the clients
trust this 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, you could
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.
Note If you are planning to enable Federated Sharing, you must obtain a certificate for
your Internet-accessible Client Access servers from a public, trusted CA.
Identifying the Required Client Protocols

As you plan the certificate deployment, you need to 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.
The following client connections can be protected using SSL or TLS:

POP3 and IMAP4 client access to Exchange
Outlook Web App
Outlook Anywhere
ECP
Exchange ActiveSync
Autodiscover
Planning the Certificate Names

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. Autodiscover is
used to configure Outlook and mobile device profile settings automatically. It will be discussed in more
detail in Lesson 2.
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 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 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 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. Deploying wildcard certificates is also considered a
security risk in many organizations because the certificate can be used for any server name
in the domain. If this certificate is compromised, all hosts names for the organization are
also compromised.
Demonstration: How to Configure Certificates for Client Access Servers
In this demonstration, you will see how to configure a Windows Server 2008 Certification Authority to
support certificate requests with multiple subject alternative names. You will then see how to use the New
Exchange Certificate Wizard to request a certificate for a Client Access server, and how to install that
certificate.
Demonstration Steps
1. In the Exchange Server, open the Exchange Management Console, select Server Configuration, and
then click Client Access.
2. Click Configure External Client Access Domain, and configure the external domain name for Client
Access servers in the organization.
3. In the Actions pane, click New Exchange Certificate to open the New Exchange Certificate Wizard.
This wizard helps you determine what type of certificates you need for your Exchange organization.
4. On the Introduction page, enter a user-friendly name for your certificate.
5. On the Domain Scope page, do not select the Enable wildcard certificate check box.
6. On the Exchange Configuration page, configure the certificate request to include Outlook Web App
on the Internet and Intranet, Exchange ActiveSync and Autodiscover.
7. On the Certificate Domains page, accept the names that will be added to the certificate request.
8. On the Organization and Location page, enter information about your Exchange organization. Click
the Browse button to select a location for the certificate request file, and enter the desired file name.
9. On the Certificate Completion page, verify that all the information you have entered is correct. If it
is, click the New button.
10. On the Completion page, click Finish.

11. Provide the certificate request file to your CA. After the certificate has been issued, complete the
certificate installation process.
12. In the Exchange Management Console, select Server Configuration.
13. In the Actions pane, click Complete Pending Request.
14. Import the certnew.cer file.

15. In the Actions pane, click Assign Services to Certificate.
16. Assign the certificate to Internet Information Services on VAN-EX1.
Question: What would you need to change in this procedure if you were also enabling
secure access to IMAP4 using a server name of IMAP4?
Question: How would this process change if you were requesting a certificate from an
external, public CA?
Options for Configuring POP3 and IMAP4 Client Access
By default, Exchange Server 2010 supports POP3 and IMAP4 client connections, but the services are set to
start manually. If you want to enable user access for these protocols, you must start the services and
configure them to start automatically.
Configuration Options
If you choose to enable POP3 or IMAP4 access, you can configure the following settings.
Option Description
Bindings Enables the configuration of the local server addresses that will be used for
unencrypted or Transport Layer Security (TLS) connections or for SSL
connections.
Authentication Enables the configuration of supported authentication options. Support options

include basic authentication, Integrated Windows authentication, and secure
logon requiring TLS. The default setting is secure logon.
Connection settings Enables the configuration of 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 Enables the configuration of the message formats used for these protocols, and
for configuring how clients will retrieve calendar requests.
User access On each user account, you can enable or disable access for the POP3 and IMAP4
protocols. By default, all users are enabled for access.
Configuring Throttling Policies
Microsoft Exchange Server 2010 uses client throttling policies to manage the performance of your
Exchange organization. These policies are used to limit the number of RPC requests from clients which
could cause performance problems. To achieve this, Exchange tracks the resources that each user
consumes and enforces connection bandwidth limits, as necessary.
You can apply restrictions on concurrent connections to Exchange Web Service, POP3/SMTP, OWA,
ActiveSync, and Windows Remote PowerShell. In Exchange Server 2010 RTM, only the policies limiting
concurrent connections were enabled by default. However, in Exchange 2010 Service Pack 1 (SP1), all
clients throttling policies are enabled by default.
When you first create an Exchange organization, a default throttling policy is automatically created that
implicitly governs all users within that organization. In most cases, this policy is sufficient to manage the
load placed on your Exchange system, but you can customize the default policy or add additional policies
based on the needs of your organization.
In an Exchange organization, you can define an acceptable load on a user-by-user basis. Through policies,
Exchange evaluates how each user employs the system and ensures that the resulting per-user load falls
within acceptable boundaries as defined by the user's policy. The client throttling system tracks system
usage on a per-user basis and uses the throttling policy associated with that user to determine if throttling
should occur.
Exchange Server 2010 SP1 also adds a new feature called Delivery Class Throttling. This enables you to
classify messages based on their characteristics and accordingly assign it a delivery class. Cost can be
assigned to each message based on message size, number of recipients, and frequency. This cost is then
used to assign a delivery class to the messages. Message priority is measured according to their class,
which means the higher the delivery class, the higher the message priority in the connector queue. For
example, delivery class throttling will give high priority to small messages with few recipients over bulk
messages with many recipients in the message queue.
You must use Exchange Management Shell and the following cmdlets to manage throttling policies.
Cmdlet Description
New-ThrottlingPolicy This cmdlet creates a new throttling policy.
Remove-ThrottlingPolicy This cmdlet removes a throttling policy.
Get-ThrottlingPolicy This cmdlet lets you view the settings of a throttling policy.
Set-ThrottlingPolicy This cmdlet modifies all available settings for a throttling policy.
Configuring the Client Access Server for Internet Access
To enable access to the Client Access server from the Internet, you need to complete the following steps:
1. 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. This URL is used to access the website
from external locations. By default, the external URL is blank. For Internet-facing Client Access servers,
the external URL should be configured to use the name published in DNS for that Active Directory
site. The external URL should also use the same name as the one used for the server certificate. For
Client Access servers that will not have an Internet presence, the setting should remain blank.
2. Configure external DNS name resolution. For each Client Access server that you are exposing to the
Internet, you need to verify that the 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 you will need to configure a host record for each host.
3. Configure access to the Client Access server virtual directories. Each of the client access methods uses
a different virtual directory. If you are using a standard firewall or application layer firewall that filters
client requests based on the virtual directory, you need to ensure that all virtual directories are
accessible through the firewall.
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. Plan for Client Access server access with multiple sites. If your organization has multiple locations and
Active Directory sites, and you are deploying Exchange servers in each site, your first decision is
whether you will make the Client Access servers in each site accessible from the Internet. If you
choose not to make the Client Access server accessible, you should not configure an external URL for
it. All client requests to that server can be used as a proxy from an Internet-accessible Client Access
server. If you do decide to make a sites Client Access server accessible from the Internet, you need to
complete the steps listed below for each site.
For each site, you will need to configure a unique external URL for the Client Access servers that
are accessible from the Internet.
You need to ensure that the host records for each site are added to the appropriate DNS zone.
You need to configure the firewalls and SSL certificates for each site.
Lesson 2
Configuring Client Access Services for Outlook Clients
The Client Access servers in Exchange Server 2010 provide several services for Office Outlook clients. For
the most part, these services are enabled by default for Outlook clients on the internal network, but you
may need to modify some of the settings. Additionally, you can make some of these services available to
Outlook clients connecting the Exchange servers from outside the environment. In this case, you need to
enable these features, and ensure that they are configured correctly.
Describe the services provided by a Client Access server for Outlook clients.
Describe the RPC client access services feature.

Describe Autodiscover functionality.
Configure Autodiscover.
Describe the Availability Service, and its purpose.
Explain the MailTips purpose and functionality.
Configure MailTips.
Describe the Outlook Anywhere functionality.
Configure Outlook Anywhere.
Explain how to troubleshoot Outlook client connectivity.

Services Provided by a Client Access Server for Outlook Clients
In Exchange Server 2010, the Client Access server role provides critical services for all messaging clients,
including Office Outlook clients. The following table lists the services provided for Outlook clients.
Service Description
RPC Client Access Enables MAPI clients such as Outlook to connect to user mailboxes. The client
services connects to the Client Access server using a MAPI connection.
Autodiscover The Autodiscover service configures client computers that are running Outlook
2007 or newer, or supported mobile devices. The Autodiscover process
configures the Outlook client profile, including the mailbox server, Availability
service, and offline address book download locations.
Availability The Availability service is used to make free/busy information available for
Outlook 2007 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.
MailTips The MailTips feature provides notifications for users regarding potential issues
with sending a message, before they send the message.
Offline Address The Client Access server makes offline address book available through a Web
Book download service. Only Microsoft Office Outlook 2007 or later clients are capable of
retrieving OABs from a Web service.
ECP The ECP is a Webbased management interface that can be used to enable self
service for mailbox users, and enables users to perform specific management
tasks without having access to the entire Exchange management interface.
(continued)
Service Description
Exchange Web Exchange Web Services enables client applications to communicate with the
Services Exchange server. You also can access Exchange Web Services programmatically. It
provides access to much of the same data made available through Office
Outlook. Exchange Web Services clients can integrate Outlook data into line-of-
business (LOB) applications.
Outlook Anywhere Outlook Anywhere enables Outlook 2003 or later clients to access the user
mailbox by using RPCs encapsulated in an HTTP or HTTPS packet. This enables
secure access to user mailboxes from clients located on the Internet.
What Is RPC Client Access Services?
One the most significant architectural changes in Exchange Server 2010 is that the Client Access server
supports all client connections, including MAPI client connections from Outlook clients. In previous
Exchange Server versions, Outlook configured as a MAPI client always connects 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. The only case when clients
are still connecting to Mailbox server is when they access public folders.
How RPC Client Access Services Works

Because of the change in the messaging architecture, the client communication with the mailbox server
has changed in the following way:
In Exchange Server 2010, when a MAPI client starts, it connects to a Client Access server. The client
protocol has not changed, and it remains compatible with older Outlook versions, to Outlook 2003
SP2.
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 the client such as an Outlook Web App client requests the Global Address List (GAL), the Client
Access server role now 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.
Benefits of RPC Client Access Services

RPC Client Access services provide a number of benefits:
All clients now use the same mailbox access architecture.
For organizations that deploy highly available Mailbox servers, client outages have been reduced in
situations where a mailbox database fails over to another server. When a mailbox fails over to another
server, the Client Access server is notified, and the client connections are redirected to the new server
within seconds. In a failover scenario, clients in Exchange Server 2007 would be disconnected for one
to 15 minutes. In Exchange Server 2010, if one Client Access server in a Client Access server array fails,
the client will immediately reconnect to another Client Access server in the array. If a mailbox server
fails, the client is disconnected for 30 seconds.
Mailboxes can now be moved 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 can handle 64,000 connections. That number increases to 250,000
RPC context handle limit in Exchange 2010.
What Is Autodiscover?
The Autodiscover service in Exchange Server 2010 simplifies Office Outlook 2007, 2010 or later client
configuration. Autodiscover provides configuration information that Outlook requires to create a profile
for the client. Outlook clients can also use the Autodiscover service to repair Exchange Server connection
settings if a profile is corrupted, or if the user mailbox is moved to a different server. The Autodiscover
service uses a users email address and password to provide profile settings to Outlook 2007, 2010 or later
clients, and supported mobile devices.
As part of the profile creation, Autodiscover provides information for the client to locate various Web
services, such as the Availability service, Unified Messaging settings, and offline address books.
How Autodiscover Works

Outlook 2010 connects to Exchange Server 2010 in the following manner:
1. When you install the Client Access server role, a service connection point (SCP) is configured
automatically in Active Directory for the Client Access server. This SCP includes the Client Access
server URL. Service Connection Point (SCP) is used only by internal clients.
2. When Outlook 2010 starts for the first time, Outlook uses the user name or the users email address
and password to configure the MAPI profile automatically. Exchange Server uses configuration
information to build an Outlook configuration template. The configuration template includes
information about Active Directory and the Exchange Server 2010 organization and topology.
3. If Outlook is running on a domain-joined computer, then Outlook also uses the SCP to locate the
Autodiscover service on an Exchange Server 2010 computer with the Client Access server role
installed. The information includes the download location for the Availability Web service and the
Offline Address Book. If you are accessing Exchange Client Access server from outside, or from a
computer that is not joined to your domain, then the client looks for the Autodiscover host in DNS.
After that Outlook is redirected to the Autodiscover virtual folder on CAS.
4. Outlook downloads the required configuration information from the Autodiscover service.
5. Outlook then uses the appropriate configuration settings to connect to Exchange Server 2010.
Autodiscover Response Format

The Autodiscover.xml file that downloads to the client during Autodiscover can contain many different
types of information. The following shows one example of the information that might be included in the
file:
<Autodiscover
xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response
xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>First Last</DisplayName>
<LegacyDN>/o=AdatumOrg/ou=First Administrative
Group/cn=Recipients/cn=Gregory</LegacyDN>
<DeploymentId>644560b8-a1ce-429c-8ace-23395843f701</DeploymentId>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol>
<Type>EXCH</Type>
<Server>LON-EX1.adatum.com</Server>
<ServerDN>/o=ADatumOrg/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=LON-EX1</ServerDN>
<ServerVersion>72008287</ServerVersion>
<MdbDN>/o=ADatumOrg/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=LON-EX1/cn=MailDB</MdbDN>
<ASUrl>https://mail.adatum.com/ews/exchange.asmx</ASUrl>
<OOFUrl>https://mail.adatum.com/ews/exchange.asmx</OOFUrl>
<UMUrl>https://mail.adatum.com/unifiedmessaging/service.asmx</UMUrl>
<OABUrl>https://mail.adatum.com/OAB/d29844a9-724e-468c-8820-
0f7b345b767b/</OABUrl>
</Protocol>
</Account>
</Response>
</Autodiscover>
Supported Clients and Protocols

Autodiscover supports the following clients and protocols.
Client application Protocol
Office Outlook 2010 RPC over TCP/IP
Outlook Anywhere RPC over HTTP
Exchange ActiveSync Exchange ActiveSync over HTTP
Entourage 2008, Exchange Web Services Edition Exchange Web Services (HTTPS)
Note Exchange Server 2010 supports Autodiscover for Exchange ActiveSync Service
clients. However, the Exchange ActiveSync Service client must be running Windows
Mobile 6 to support this feature.
Configuring Autodiscover
By default, the Autodiscover settings for internal clients are automatically configured, and Outlook 2007
or later clients are automatically configured to use the appropriate services. In some cases, you may want
to modify the default settings. For external clients, you need to configure the appropriate DNS settings to
ensure that external clients can locate the Client Access server that is accessible from the Internet.
Configuring the Autodiscover Settings

To enable Autodiscover, you must have at least one Client Access server that is running the Autodiscover
service. When you install the Client Access server role, the Autodiscover virtual directory is created
automatically in IIS.
To manage Autodiscover settings, you must use the following Exchange Management Shell cmdlets:
Task Exchange Management Shell cmdlet
Configure the Autodiscover SCP Set-ClientAccessServer
Create a new Autodiscover virtual directory New-AutodiscoverVirtualDirectory
Remove an Autodiscover virtual directory Remove-AutodiscoverVirtualDirectory
Configure an Office Outlook provider Set-OutlookProvider
Locate an Office Outlook provider or providers on the Get-OutlookProvider

virtual directory
Configuring Autodiscover for Multiple Sites

If your organization has deployed Exchange servers in multiple Active Directory sites, you should consider
configuring site affinity for the Autodiscover service. To use site affinity, you specify which Active Directory
sites are preferred for clients to connect to a particular Autodiscover service instance. Usually
Autodiscover site affinity is used in scenarios when you do not have good connectivity between all of your
sites and you would like Outlook clients to utilize Autodiscover services on a Client Access Server (CAS) to
which the clients have good connectivity. In another scenario, if you have acceptable connectivity
between your sites, you may still prefer that your Outlook clients utilize Autodiscover services on a Client
Access Server in a site that is local to the clients.
To configure site affinity, use a cmdlet as shown in the following example:
Set-ClientAccessServer -Identity "ServerName"

-AutodiscoverServiceInternalURI "https://VAN-EX1/autodiscover/autodiscover.xml"
AutodiscoverSiteScope "HeadOffice"
This cmdlet configures the URI for the Autodiscover service in the HeadOffice site to use the VAN-EX1
server.
Configuring DNS to Support Autodiscover

For external clients to be able to locate the appropriate Client Access servers, you must configure DNS
with the correct information. When the Outlook client attempts to locate the Client Access server, it first
tries to locate the SCP information in the Active Directory directory service. If the client is outside the
network, Active Directory is not available. Therefore, 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.e-maildomain/autodiscover/autodiscover.xml
https://<e-maildomain/autodiscover/autodiscover.xml
To enable Autodiscover, 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, or to reverse proxy server (such as TMG) that is used to publish Client Access
Server
Using the Test E-mail AutoConfiguration Feature in Outlook 2010

You can use the Test E-mail AutoConfiguration feature in Outlook 2010 to test whether Autodiscover is
working correctly. You do it by clicking on the Outlook icon in the notification area, while holding Ctrl
button, and then you click Test E-mail AutoConfiguration.
Note You also can use the Exchange Management Shell cmdlet
Test-OutlookWebServices to test the Autodiscover settings on a Client Access server.
A very useful tool for testing Autodiscover functionality from outside can be found at
https://www.testexchangeconnectivity.com/. This is an official Microsoft testing tool that you can use to
test Autodiscover for ActiveSync and Outlook connectivity. Besides using it for on-premises Exchange
Server, you can also use it to test service availability in Microsoft Office 365.
What Is the Availability Service?
Exchange Server 2010 makes free/busy information available to both Outlook 2007 or later, and Outlook
Web App clients, by using the Availability service. The Availability service replaces the public folder used
to store free/busy information in previous Exchange Server versions.
The Scheduling Assistant uses the Availability service to:
Retrieve live free/busy information for Exchange Server 2007 or Exchange Server 2010 mailboxes.
Retrieve live free/busy information from other Exchange Server 2007 or Exchange Server 2010
organizations.
Retrieve published free/busy information from public folders for mailboxes hosted on Exchange
Server 2003 servers.
View the working hours of attendees.
Show meeting time suggestions.
Note Only Outlook 2007 or later and Outlook Web App use the Availability service.
Outlook 2003 clients continue to use the Schedule+ Free Busy Information public folder.
This folder must be available on an Exchange server for these clients to function.
How the Availability Service Works

The Availability service provides free/busy information by using the following process:
1. When you start the Scheduling Assistant in Outlook 2007 or Outlook Web App, the client sends a
request to the URL provided to the client during Autodiscover. The request includes all invited users,
including resource mailboxes.
2. The Client Access server Availability service queries Active Directory to determine the user mailbox
location. For any mailbox in the same site as the Client Access server, the request is sent directly to
the Mailbox server to retrieve the users current free/busy information.
3. If the mailbox is in a different site than the Client Access server, the request is sent by proxy to a
Client Access server in the site where the user mailbox is located. The Client Access server in the
destination site extracts the availability information from the Mailbox server, and replies to the
requesting Client Access server.
4. If the mailbox for one of the invited users is on a computer running Exchange Server 2003, Availability
service queries the public folder that contains the free/busy information for the user.
5. The Availability service combines the free/busy information for all invited users, and presents it to the
Outlook 2007 or Outlook Web App client.
How Free/Busy Information Is Retrieved

When a user creating a meeting request has an Exchange Server 2003 or Exchange 2000 Server mailbox,
free/busy information is always retrieved using public folders. The following table summarizes how
free/busy information is retrieved when the user that creates the meeting request has an Exchange Server
2010 mailbox.
Client Invitee mailbox Free/Busy retrieval method
Outlook 2007 or Exchange 2007 or 2010 The Availability service reads from invitee mailbox.
later
Outlook 2007 or Exchange 2003 The Availability service uses HTTP/HTTPS to read from
later /public virtual directory on Exchange 2003 server.
Outlook 2003 Exchange 2007, 2010 or Outlook reads free/busy information from public
Exchange 2003 folders.
Outlook Web App Exchange 2007 or 2010 Calls the Availability service application programming
(Exchange 2007 or interface (API) This API reads from the invitees
2010) mailbox.
Outlook Web App Exchange 2003 Calls the Availability service API that uses HTTP/HTTPS
(Exchange 2007 or to read from /public virtual directory on Exchange
2010) 2003 server.
You also can configure the Client Access server to query the Availability service in a different Exchange
Server 2010 organization. This allows you to share scheduling information between Exchange Server
organizations.
Deploying the Availability Service

The Availability service is deployed by default on all Client Access servers and does not need configuration
except in scenarios where you are integrating the free/busy information from multiple forests.
Autodiscover delivers the service location for the Availability service to Outlook 2007 clients. Availability
service is located at the URL http://servername/EWS.
What Are MailTips?
MailTips are informative messages displayed to users before they send a message. MailTips inform a user
about issues or limitations with the message the user intends to send. Exchange Server 2010 analyzes
the message, including the list of recipients to which it is addressed. If it detects a potential problem, it
notifies the user with MailTips prior to sending the message. With the help of the information provided by
MailTips, senders can adjust the message they compose to avoid undesirable situations or non-delivery
reports (NDRs).
Types of MailTips
Exchange Server 2010 provides several default MailTips, including the following examples:
Mailbox Full. This MailTip displays if the sender adds a recipient whose mailbox is full, and if your
organization has implemented a Prohibit Receive restriction for mailboxes over a specified size.
Recipient Out of Office. This MailTip displays the first 250 characters of the out-of-office reply
configured by the recipient, if a recipient has configured an out-of-office rule.
Restricted Recipient. This MailTip displays if the sender adds a recipient for which delivery restrictions
are configured, and prohibits this sender from sending the message.
External Recipients. This MailTip displays if the sender adds a recipient that is external, or adds a
distribution group that contains external recipients.
Large Audience. This MailTip displays if the sender adds a distribution group that has more than the
large audience size configured in your organization. By default, Exchange Server displays this MailTip
for messages to distribution groups that have more than 25 members.
You can also configure custom MailTips in the Exchange Management Shell. A custom MailTip can be
assigned to any recipient. For example, you could configure a custom MailTip for a recipient who is on an
extended leave or for a distribution group where all members of the group will be out of the office.
Alternately, you can create a custom MailTip for a distribution group that explains the purpose of the
group and thus reduces its misuse. When you configure a custom MailTip, it displays when a user
composes a message for a specified recipient. In Exchange Server 2010 SP2, you can also use Exchange
Control Panel to configure custom mail tips.
Note MailTips are available only in Exchange Server 2010 Outlook Web App, or when
using Microsoft Office Outlook 2010 or later. MailTips are not available in Outlook 2007.
How MailTips Work

MailTips are implemented as a Web service in Exchange Server 2010. When a sender composes a
message, the client software makes an Exchange Web service call to Exchange Server 2010 server with the
Client Access server role installed, to get the list of MailTips. 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 following actions by the sender trigger MailTips to be evaluated or updated:

Adding a recipient
Adding an attachment
Replying to the sender, or replying to All
Opening a message from the Drafts folder, which is already addressed to recipients
When the Client Access server is queried, it compiles the list of applicable MailTips, and returns all of them
at one time. This way, all MailTips are displayed to the user 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 MailTip data:
The Client Access server queries the 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.
3. The Client Access server returns MailTips data back to the client.
Note Several MailTips are available when the Outlook client is offline. To enable this
functionality, the redesign of the structure of the offline address book now includes some of
the information that MailTips requires. MailTips that require current information from Active
Directory or the user mailbox are the only MailTips that will not work while the Outlook
client is offline. MailTips that will not work offline are the Invalid Internal Recipient, the
Mailbox Full, and the Recipient Out-of-Office MailTips.
Limitations on MailTips
MailTips are subject to the following restrictions:
When a message is addressed to a distribution group, the MailTips for individual recipients that are
members of that distribution group are not evaluated. However, if any of the members is an external
recipient, the External Recipients MailTip is displayed, which shows the sender the number of external
recipients in the distribution group.
If the message is addressed to more than 200 recipients, MailTips for individual mailboxes are not
evaluated due to performance reasons.
Custom MailTips are limited to 250 characters.

Demonstration: How to Configure MailTips
In this demonstration, you will see how to review and configure default MailTips for an Exchange
Server 2010 organization, and how to configure custom MailTips. You will also confirm that the MailTips
functions as expected.
Demonstration Steps
1. In Exchange Management Shell, use the Get-OrganizationConfig cmdlet to review the default
configuration for MailTips.
2. Use the Get-OrganizationConfig MailTipsLargeAudienceThreshold 10 cmdlet to modify the

large distribution group threshold setting.
3. Use the Set-DistributionGroup Marketing MailTip The marketing team will be at a conference
till next week. cmdlet to configure a custom MailTip.
4. Log on to Outlook Web App. Prepare test messages to verify that the default and custom MailTips
work as expected.
Question: Will you leave MailTips enabled in your organization? How will you modify the
default configuration?
What Is Outlook Anywhere?
When you enable Outlook Anywhere, an Outlook 2003 or later client can connect to a server running
Exchange Server 2010 or Exchange Server 2007 using RPCs encapsulated in an HTTP or HTTPS packet. This
feature is a secure option for connecting to the Exchange server from the Internet while using a MAPI
client.
How Does Outlook Anywhere Work?

To deploy Outlook Anywhere, you need to deploy the Outlook 2007 or Outlook 2003 client and the RPC
proxy service running on Windows Server 2008. The following is a description of the communication
process between all components in an RPC-over-HTTP configuration:
1. All communication between the Outlook client and the Client Access server is sent using HTTPS. The
client establishes a connection to the Client Access server for each RPC request that it sends, and then
establishes a second connection for responses from the Client Access server.
2. When the client connects, the Client Access server authenticates the user by forwarding the
authentication request to a domain controller.
3. After the user is authenticated, the Client Access server uses an RPC connection to communicate with
the Mailbox server hosting the user mailbox.
4. If the client requests a Global Address List lookup, the NSPI component on the Client Access server
will send a Lightweight Directory Access Protocol (LDAP) query to a global catalog server.
Demonstration: How to Configure Outlook Anywhere
When configuring Outlook Anywhere, you must configure the Exchange Client Access server, and then
configure the Outlook clients.
Implementing Outlook Anywhere

To configure Outlook Anywhere on Exchange Server 2010, you must perform the following high-level
steps:
1. Configure a computer running Windows Server 2008 as the RPC proxy server by installing the RPC
over HTTP Proxy feature in Server Manager. When you select this feature, the required Web Server
(IIS) role services are installed on the server. You should install the RPC over HTTP Proxy feature on
the Client Access server.
2. Install a server certificate on the RPC proxy server. By default, Outlook Anywhere requires SSL
encryption. Configure the RPC virtual directory to require SSL.
3. Enable Outlook Anywhere in the Exchange Management Console. When you enable RPC over HTTP,
you must configure both an external host name and authentication method.
4. Configure the Outlook 2010, Outlook 2007 or Outlook 2003 profile on the client to use RPC over
HTTP to connect to the Client Access server.
Demonstration Steps
1. On the Client Access server, use the following cmdlet to review the Autodiscover configuration:
Get-ClientAccessServer id VAN-EX1 | FL
2. On the Client Access server, verify that the RPC over HTTP Proxy feature is installed.
3. On the Client Access server, in Exchange Management Console, click Enable Outlook Anywhere,
using a host name that is resolvable from the Internet.
4. On the Client Access server, in Internet Information Services (IIS) Manager, verify that the RPC virtual
directory is configured to use SSL and that it is configured to accept Basic and Windows
Authentication.
5. On the client computer, configure the Outlook account properties to Connect to Microsoft
Exchange using HTTP, and then click Exchange Proxy Settings.
6. In the Microsoft Exchange Proxy Settings dialog box, complete the following information:
Use the URL (https://): external host name for the Client Access server
Connect using SSL only: enable (default)

On fast networks, connect using HTTP first, then connect using TCP/IP: enable
On slow networks, connect using HTTP first, then connect using TCP/IP: enable (default)
Proxy authentication setting: NTLM Authentication (default)
7. From the client, open Outlook and connect to the server.
8. Press and hold the Ctrl key, and then right-click the Office Outlook icon in the Windows 7
operating system notification area. Click Connection Status. Confirm that the Conn column lists
HTTPS as the connection method.
9. Press and hold Ctrl, and then click the Outlook icon in the notification area of the Windows task bar.
Click Test E-mail AutoConfiguration.
10. Click Test. View the information displayed on both the Results and Log tabs.
Troubleshooting Outlook Client Connectivity
To troubleshoot Outlook with MAPI connectivity to an Exchange server, use the following steps:
1. Identify network connectivity issues. If the Outlook client or the Exchange server experiences
problems connecting to the network, Outlook shows a status of Disconnected, and no new messages
can be transferred between the client and the server.
2. Identify name resolution issues. Outlook clients must be able to resolve the name of the Exchange
server to which they are connecting. By default, Outlook 2007 clients use DNS host-name resolution
to resolve the name of the Exchange server to its IP address. If DNS servers are not available on the
network, or if the records in DNS are incorrect, Outlook clients are unable to connect to the Exchange
server.
3. Identify client configuration issues. A client configuration issue can occur in Outlook or Windows
configurations. An improperly configured client can prevent the computer from connecting to the
Exchange server, or create intermittent connectivity problems. You may need to troubleshoot the
client computer to rule out any configuration errors before investigating a server-based issue.
4. Identify server configuration or service-availability issues. A configuration error can prevent some or
all users from connecting to the Exchange server. Based on the symptom that the user is
experiencing, you can verify configuration by using the Exchange Server Best Practices Analyzer Tool,
or examine server properties by using the Exchange Management Console.
5. If the client computer is using Outlook Anywhere to connect to the Client Access server, it may be a
Client Access server certificate issue. Outlook Anywhere relies on valid server certificates to provide
secure communication with the server. Invalid names on certificates, expired certificates, or non-
trusted certificates can cause connectivity issues between these clients and a Client Access server.
Tip To ensure that a valid server certificate is trusted and can be used for connecting with
Outlook Anywhere, you should connect from a Web browser to the RPC virtual directory on
the Exchange server. If the user receives a prompt with a warning message about the
certificate authenticity, then there is an issue with the certificate configuration. This will lead
to problems with Outlook Anywhere, Autodiscover, and Exchange ActiveSync.
6. You can use the Test E-Mail AutoConfiguration Wizard in Outlook 2007 to test whether Autodiscover
is configured correctly. When you run the wizard, it will provide information whether the client could
connect to the Autodiscover service on a Client Access server, and it will display the information that
it received through the Autoconfiguration process.
Lab A: Configuring Client Access Servers for Outlook

Anywhere Access
Lab Setup
2. Ensure that the 10135B-VAN-DC1, 10135B-VAN-EX1, 10135B-VAN-EX2, and the 10135B-VAN-CL1

virtual machines are running.
10135B-VAN-CL1: Client computer in the Adatum.com domain
3. If required, connect to the virtual machines. Log on to VAN-DC1, VAN-EX1, and VAN-EX2 as
Adatum\Administrator, using the password Pa$$w0rd. Do not log on to VAN-CL1 at this point.
Lab Scenario
You are working as a messaging administrator in A. Datum Corporation. Your organization has decided to
deploy Client Access servers so that the servers are accessible from the Internet for a variety of messaging
clients. To ensure that the deployment is as secure as possible, you must secure the Client Access server,
and configure a certificate on the server that will support the messaging client connections. You also need
to configure the server to support Outlook Anywhere connections.
Exercise 1: Configuring Client Access Servers

Scenario
As a messaging administrator in A. Datum Corporation, you have deployed the Exchange Server
environment, and you are now working on configuring the Client Access servers. The organization has
decided to use a certificate from the internal CA to secure all client connections to the server. You need to
enable this configuration, and then you need to ensure that Outlook clients can still connect to the server.
1. Configure an External Client Access Domain for VAN-EX2.
2. Prepare a Server Certificate request for VAN-EX2.
3. Request the certificate from the CA.

4. Import and assign the IIS Exchange service to the new certificate.
5. Verify Outlook connectivity to the Exchange Server.
X Task 1: Configure an External Client Access Domain for VAN-EX2

1. On VAN-EX2, open the Exchange Management Console and configure an External Client Access
Domain named mail.Adatum.com.
2. Apply the external domain name just to VAN-EX2.
3. Verify that the External Client Access Domain was applied to the owa (Default Web Site) virtual
directory.
X Task 2: Prepare a Server Certificate request for VAN-EX2

1. On VAN-EX2, run the New Exchange Certificate Wizard using the following configuration options:
Friendly name: ADatum Mail Certificate
Outlook Web App is on the intranet
mail.adatum.com as the server name for all services

Outlook Web App is on the Internet
Exchange ActiveSync is enabled
Autodiscover is used on the Internet
Long URL is used for AutoDiscover
Organization: A Datum
Organization Unit: Messaging

Country/region: Canada
City/locality: Vancouver
State/province: BC
2. Save the file using the name CertRequest.req.
X Task 3: Request the certificate from the CA

1. Copy the text of the certificate request file to the clipboard.
2. Connect to https://van-dc1.adatum.com/certsrv and create a new certificate request using the

contents of the certificate request file. Use an advanced certificate request using a base-64-encoded
CMC or PKCS#10 file. Copy and paste the contents of the CertRequest.req file into the Saved
Request field. Request a Web server certificate.
3. Download the certificate and save it.
4. View the certificate. Verify that the certificate includes several subject alternative names, and then
click OK.
X Task 4: Assign the IIS Exchange Service to the new certificate

1. In the Exchange Management console, use the Complete Pending Request Wizard to import the
Adatum Mail certificate.
2. In the Exchange Management console, use the Assign Services to Certificate Wizard to assign the
Adatum Mail certificate to the Internet Information Services service.
X Task 5: Verify Outlook connectivity to the Exchange Server

1. On VAN-CL1, log on as Molly using the password Pa$$w0rd.
2. Open Microsoft Outlook 2010, and verify that a profile is automatically created for Molly.
3. In Microsoft Outlook, click File, and then click Account Settings. Verify that the Outlook profile is
configured to use VAN-EX2 as the mailbox server.
Results: After this exercise, you should have configured the security settings for VAN-EX2 by using the
Security Configuration Wizard, and installed a server certificate from the internal CA on the server. You
should have also verified Outlook client connectivity to the Exchange server.
Exercise 2: Configuring Outlook Anywhere

Scenario
A. Datum Corporation has several users who are frequently out of the office. These users all have laptop
computers, and they want to use Office Outlook to connect to their Exchange Server mailboxes while in
the office or out of the office. You need to configure the Client Access server to enable Outlook
Anywhere, and then configure a client to connect to the server using RPC over HTTPS. Finally, you need to
verify that the connection works.
1. Configure a DNS record for Mail.Adatum.com.
2. Configure Outlook Anywhere on VAN-EX2.
3. Configure the Outlook profile to use Outlook Anywhere.
4. Verify Outlook Anywhere connectivity.

X Task 1: Configure a DNS record for Mail.Adatum.com

On VAN-DC1, create a new host record for Mail.adatum.com using an IP address of 10.10.0.21.
X Task 2: Configure Outlook Anywhere on VAN-EX2

1. On VAN-EX2, verify that the RPC over HTTP Proxy feature is installed.
2. In the Exchange Management Console, enable Outlook Anywhere for VAN-EX2.
3. Configure an external host name of Mail.adatum.com, and choose NTLM authentication.
4. Restart VAN-EX2 and log back on as Administrator with the password Pa$$w0rd.
X Task 3: Configure the Outlook profile to use Outlook Anywhere

1. On VAN-CL1, ensure that you are logged on as Adatum\Molly.
2. Modify the profile for Molly to connect to Microsoft Exchange using HTTP.
3. Configure the Exchange Proxy server settings as follows:
Use this URL (https://): mail.adatum.com


4. Close Outlook.
X Task 4: Verify Outlook Anywhere connectivity

1. On VAN-CL1, open Outlook and verify that you are connected to the Exchange server.
2. Press and hold Ctrl, and then right-click the Office Outlook icon in the Windows 7 notification area.
Confirm that the Conn column lists HTTPS as the connection method. You may need to click the up
arrow in the Windows 7 notification area to view the Office Outlook icon.
3. Use the E-mail AutoConfiguration tool to review the settings Autodiscover provided to the client.
4. Log off VAN-CL1.
Results: After this exercise, you should have enabled Outlook Anywhere on VAN-EX2, and configured a
client profile to use Outlook Anywhere. You also verified the Outlook Anywhere functionality.
X To prepare for the next lab

Do not shut down the virtual machines and revert them to their initial state when you finish this lab.
This modules last lab requires the virtual machines for completion.
Lesson 3
Configuring Outlook Web App
Exchange Server 2010 uses Outlook Web App to provide access to user mailboxes through a Web
browser. Many organizations provide users with access to Outlook Web App from the Internet. Some
organizations also use Outlook Web App internally. In both scenarios, deploying Outlook Web App is
quite easy because only a Web browser is required as a client. This lesson describes how to configure
Outlook Web App for Exchange Server 2010.
Describe Outlook Web App features.
Identify Outlook Web App configuration options.

Describe the file and data access options in Outlook Web App.
Configure Outlook Web App.
Configure Outlook Web App policies.
Configure user options using the ECP.

What Is Outlook Web App?
Outlook Web App allows users to access their mailboxes through a Web browser. The feature set in
Outlook Web App closely mimics features available in Outlook 2010, and may provide features that are
not available in previous Outlook versions. In some cases, it may be possible to use Outlook Web App in
place of Outlook 2010.
Features of Outlook Web App

Outlook Web App provides most features that are available when using the full Outlook 2010 client. Some
of these features enable users to:
Read and respond to messages.
Book meetings and view the Calendar.
Create and edit Contacts and Tasks.
Read attachments that have been rendered into HTML content on the server.
Configure personal settings such as signatures, out of office messages and junk email settings.
Change passwords.
Configure mobile device settings.
Create and edit server-side rules.
Access public folders.
Use Secure/Multipurpose Internet Mail Extensions (S/MIME) to sign and encrypt email and to read
signed and encrypted email.
Recover deleted items.
Create and edit personal distribution lists.

Outlook Web App has been redesigned in Exchange Server 2010 to include features such as chat, text
messaging, mobile phone integration, and enhanced conversation view. In Exchange Server 2010, these
features are accessible from an expanded set of Web browsers, including Microsoft Internet Explorer 6.0
or later, Firefox, Safari, and Google's Chrome.
Benefits of Outlook Web App

Outlook Web App provides many important benefits for an organization. These include:
All communication between the Outlook Web App client and the Client Access server is sent using
HTTP. You can easily secure this information using SSL. This also means that it is easy to configure
firewalls or reverse proxies to enable Internet access to Outlook Web App, as only a single port is
required.
Outlook Web App does not require that you deploy or configure a messaging client; all client
computers, including computers that run Linux or Macintosh, have a Web browser available. This
means that users can access their mailbox from any client that can access the Client Access servers
URL.
Outlook Web App in Exchange Server 2010 also provides access to some features that are only
available through Outlook Web App or Outlook 2010. For example, features such as the archive
mailbox or conversation view can be accessed through Outlook Web App without deploying Outlook
2010.
Limitations of Outlook Web App

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 2007 using Outlook Anywhere,
POP3, and IMAP clients can cache messages to provide offline access.
Question: What is Outlook Web App for Exchange Server 2010?

Question: What are the benefits of Outlook Web App?
Question: When would you use Outlook Web App instead of Outlook or Windows Mail?
Configuration Options for Outlook Web App
Although Outlook Web App is available automatically on Client Access servers, you must configure
Outlook Web App to support your users specific requirements.
Configuration Tasks for Outlook Web App

When configuring Outlook Web App, you need to complete the following tasks:
Install and configure a server certificate to enable SSL for all client connections.
Configure the Outlook Web App virtual directory. When you install the Client Access server role, an
Outlook Web App virtual directory is configured in the default IIS website on the Client Access server.
In most cases, you might not need to modify the Outlook Web App virtual directory settings, other
than configuring the default website to use a CA certificate for SSL, and to set the authentication
options.
Configure segmentation settings. You can enable or disable specific Outlook Web App features for
Exchange Server 2010 Outlook Web App users. Access the Outlook Web App virtual directory
properties in the Exchange Management Console to configure the segmentation settings.
Modify the attachment handling settings. You can configure the attachment settings by configuring
the WebReady Document Viewing settings on the Outlook Web App virtual directory.
You can also use the Exchange Management Shell set-OWAVirtualDirectory cmdlet with the
parameters AllowedFileTypes, AllowedMimeTypes, BlockedFileTypes, BlockedMIMETypes,
ForceSaveFileTypes, and ForceSaveMIMETypes.
Configure GNU zip (GZIP) compression settings. Gzip enables data compression, which is optimal for
slow network connections. You can use the Exchange Management Shell to configure Gzip
compression. Use the set-OWAVirtualDirectory cmdlet with the parameter GzipLevel.
Configure Web beacon settings. A Web beacon is a file objectsuch as a transparent graphic
or an imagethat is put on a website or in an email message. Web beacons are typically used
together with HTML cookies to monitor user behavior on a website, or to validate a recipient's email
address when an email message containing a Web beacon is opened. Web beacons and HTML forms
also can contain harmful code, and can be used to circumvent email filters. By default, Web beacons
and HTML forms are set to UserFilterChoice. This blocks all Web beacons and HTML forms, but lets
the user unblock them on individual messages. You can use the Exchange Management Shell to
change the type of filtering that is used for Web beacon and HTML form content in Outlook Web
App. If you change the setting to ForceFilter, this blocks all Web beacons and HTML forms. If you
change the setting to DisableFilter, this allows all Web beacons and HTML forms.
Configure Cross-site silent redirection. This feature is specific to Exchange 2010 SP2. When this
feature is enabled, a user with a mailbox in one Active Directory site who accesses the Outlook Web
App URL in another Active Directory site will be silently redirected to the Outlook Web App URL
for his or her Active Directory. Cross-site silent redirection prevents users from having to learn a
secondary Outlook Web App URL. If the authentication method for the Outlook Web App virtual
directory on both the source and target Client Access servers is set to forms-based authentication,
the user will only have to enter his or her credentials once. If the authentication methods differ on
the source and target Client Access servers, the user may have to enter his or her credentials a second
time. When using forms-based authentication, you must require SSL on both the source and target
Outlook Web App virtual directories. To configure cross-site silent redirection, the administrator must
use the new CrossSiteRedirectType parameter that has been added to the Set-OWAVirtualDirectory
cmdlet. You can configure totally silent redirection, or you can let users know that they are being
redirected.
What Is File and Data Access for Outlook Web App?
File and data access provide Outlook Web App users different levels of access to files that are attached to
messages. This feature lets users open files that are attached to email messages and files that are stored in
Windows file shares. You can manage direct file access for Microsoft Office Outlook Web App in Microsoft
Exchange Server 2010 for both public and private computers.
Configuring File and Data Access

You can configure the following settings when configuring file and data access for Outlook Web App
users:
Enable WebReady Document Viewing or force WebReady Document Viewing. When you enable
WebReady Document Viewing, and a user attempts to open a file in the message window, the file is
converted to HTML, and then displayed in the Web browser. This enables users to view the files on
the local computer even if the native application for the file is not installed on the computer. If only
WebReady Document Viewing is enabled, users cannot save the document to the local hard disk or
view the document in its native application. By default, only a limited number of file types can be
viewed through WebReady Document Viewing.
Direct file access. Direct file access lets users open files that are attached to email messages and files
that are stored in Windows SharePoint Services document libraries and in Windows file shares.
Configure different settings for public or private computers. When users connect to Outlook Web
App, they can choose whether they are connecting from public or private computers. You can
configure different direct file access and WebReady Document Viewing settings for each option. The
customization settings available for public and private computer access are shared between the two
tabs. For example, if a file extension is blocked for public computer access it is also blocked for private
computer access.
Restrict or enable access. You can configure how users interact with files by using the Allow, Block, or
Force Save options for direct file access and by configuring the file extensions for WebReady
Document Viewing.
Demonstration: How to Configure Outlook Web App
In this demonstration, you will see how to configure several different Outlook Web App aspects. As you
will see in this demonstration, you may need to use several different tools to configure Outlook Web App.
Demonstration Steps
1. On the Client Access server, ensure that the Outlook Web App virtual directory is configured to use
SSL, and is using the correct server certificate.
2. In the Exchange Management Console, on the owa (Default Web Site) Properties, configure the
external URL with the required authentication and segmentation settings.
3. In the Exchange Management Shell, use the set-owavirtualdirectory owa (Default Web Site)
ForceSaveFileTypes .xls, cmdlet to force attachments with an .xls extension to be saved to disk
before they can be opened.
4. Use the set-owavirtualdirectory owa (Default Web Site) GzipLevel Off, cmdlet to disable Gzip
compression for Outlook Web App.
5. Use the Set-OwaVirtualDirectory -identity Owa (Default Web Site) -
FilterWebBeaconsAndHtmlForms ForceFilter cmdlet to block all Web beacons.
Demonstration: How to Configure Outlook Web App Policies
One of the new features in Exchange Server 2010 is the option to configure multiple Outlook Web App
policies for users. In previous Exchange Server versions, all users receive the same settings when they
connect to Outlook Web App. With Exchange Server 2010 Outlook Web App policies, you can configure
unique policies and assign them to users.
Demonstration Steps
1. In Exchange Management Console, in the Organization Configuration node, click Client Access.
2. Click New Outlook Web App Mailbox Policy. Provide a name for the policy, and configure the
policy settings.
3. After creating the policy, you can configure additional settings by accessing the policy properties.
4. Assign the policy to a user account by accessing the Outlook Web App properties on the Mailbox
Features tab.
5. Log on to Outlook Web App as the user, and test the policy application.
Demonstration: How to Configure User Options Using the ECP
Another new feature in Exchange Server 2010 is the ECP. You can use the ECP to perform several different
administrative functions, but users also can use the ECP to modify their mailbox settings. In this
demonstration, you will see how you can configure the ECP virtual directory and view some of the
available ECP configuration options.
Demonstration Steps
1. On the Client Access server, in IIS Manager, review the settings for the ecp virtual directory.
2. In the Exchange Management Console, review the settings for the ecp (Default Web Site) virtual
directory on each Client Access server.
3. As a user, access the ECP by opening Internet Explorer, and accessing https://servername/ecp.
4. Log on to the ECP, and review the settings that can be modified by the user.
Lesson 4
Configuring Mobile Messaging
Exchange Server 2010 supports mobile devices as a messaging client. With Exchange Server 2010, you
can synchronize mailbox content and perform most of the same tasks with mobile devices as you can with
other messaging clients. Exchange Server 2010 also provides administrative options for managing mobile
devices. This lesson describes how to implement and manage mobile access for Exchange Server 2010.
Describe the purpose and functionality of Exchange ActiveSync.
Configure Exchange ActiveSync.
Identify security options for Exchange ActiveSync.
Configure Exchange ActiveSync policies.
Manage mobile devices.

What Is Exchange ActiveSync?
Exchange ActiveSync (EAS) is an XML-based protocol that enables mobile devices to communicate
over HTTP (or HTTPS) with Exchange Server. EAS is designed for the synchronization of email, contacts,
calendar, tasks, and notes from an Exchange server to a mobile device with a supported operating
system. ActiveSync protocol also provides mobile device management and policy controls. The Exchange
ActiveSync communication process is optimized to function over high-latency and low-bandwidth
networks. By default, Exchange ActiveSync is available for all users after you install a Client Access server.
ActiveSync has gone through many versions in last 10 years. The first version of Exchange ActiveSync
protocol (it was called AirSync at the time) was a part of Mobile Information Server (MIS) 2002 and it
provided connection between mobile devices and Exchange Server 2000. However, the first version of
ActiveSync protocol that supported management policies was introduced in Exchange Server 2003.
Exchange ActiveSync Features in Exchange Server 2010

Some features of Exchange ActiveSync in Exchange Server 2010 are:
Access to mail messages, calendars, contacts, and tasks.
Offline access to mail messages, calendars, contacts, and tasks.
Server-side searching to include messages not on the device.
Out-of-Office configuration.
Selfservice devicewipe and device password reset. Administrators and users can remotely wipe a
device of all data if it is lost or stolen. Users can perform this task, as well as recover their mobile
device password, through Outlook Web App.
Administrative reporting, including:
The number of messages sent and received.
The number of attachments downloaded.
The bandwidth consumed by a particular user or server.
The latest version of ActiveSync protocol that is included in Exchange Server 2010 SP2 is 14.1. Besides
having all features from previous versions, this version of the protocol added several new features such as:
GAL photos. Images stored in an Active Directory server of the user who has sent the email.
Message Diffs. A means of sending only the new portion of an email and avoiding redundant
information.
Information Rights Management (IRM) over EAS. A method to apply digital rights management
control and encryption to email messages that are sent and received.
Exchange ActiveSync has been licensed to many different mobile operating system manufacturers. You
can use ActiveSync to connect your mobile device to Exchange Server, on Windows Phone 7 (or later), iOS
4 (or newer), and Android version 2 (and newer) based mobile devices. However, not all devices support
the same set of ActiveSync features. Exchange ActiveSync features are dependent on the operating system
version running on the mobile device. You will need to verify which features are supported on your
mobile device.
Note Because most tablet devices run a mobile operating system, they also use
ActiveSync protocol to connect to Exchange server.
How Exchange ActiveSync Works

When users connect to the Client Access server with a mobile device, the following process occurs:
1. The Exchange ActiveSync client connects using HTTPS, to the Microsoft Server ActiveSync virtual
directory on the Client Access server. The Client Access server authenticates the client.
2. If the users mailbox is on a Mailbox server in the same site as the Client Access server, then the Client
Access server connects to the users Mailbox server using an RPC connection. If the Mailbox server is
in a different site, then the Client Access server proxies the client request to a Client Access server in
the appropriate site.
3. If Exchange Active Sync is supported from the operating system on the mobile device, it can use
Direct Push technology to ensure that messages are delivered to the mobile client when they connect
to the Exchange server. With Direct Push technology, the mobile device maintains a constant HTTPS
connection to the Client Access server, resulting in instant message retrieval and real-time access to
email. All current mobile device operating systems that support ActiveSync also support Direct Push
technology.
Direct Push
Direct Push allows the Client Access server to notify mobile clients when new items have arrived. The
client then initiates synchronization to download the new items. Direct Push uses the following steps:
1. The mobile device issues a long-standing HTTPS request to the server. This request is known as a
PING. The PING leaves an HTTPS connection open with the server.
2. If new items arrive, or items are changed, the server sends a response to the device that includes the
folders containing the new or changed items. If there are no new or changed items in the specified
folders during the PING requests lifetime, the server sends an empty response to the device.
3. If the response is not empty, the mobile device issues a synchronization request, synchronizes with
the server, and then sends a new PING request. If the response is empty, the mobile device sends a
new PING request.
4. When the user makes a change on the mobile device, the device uses the existing HTTPS connection
to send the updates to the Client Access server.
Demonstration: How to Configure Exchange ActiveSync
In this demonstration, you will see how to configure the Exchange ActiveSync settings on a Client Access
server and how to configure a Windows Mobile device to use ActiveSync to synchronize with the
Exchange server.
Demonstration Steps
1. On the Client Access server, in IIS Manager, verify that SSL for the Exchange ActiveSync virtual
directory is required.
2. In Exchange Management Console, configure authentication and remote file server settings on the
Microsoft-Server-ActiveSync virtual directory.
Options for Securing Exchange ActiveSync
Mobile clients such as Exchange ActiveSync clients are difficult to secure. Because the devices are
small and portable, they are susceptible to being lost or stolen. At the same time, they may contain
highly confidential information. The storage cards that fit into mobile device expansion slots can store
increasingly large amounts of data. While this data-storage capacity is important to the mobile-device
user, it also heightens the concern about data falling into the wrong hands.
Mobile clients also are difficult to manage using centralized policies because the devices might rarely, or
never, connect to the internal network. The devices also do not require Active Directory accounts, so you
cannot use Group Policy Objects (GPOs) to manage the client settings.
Implementing 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.
Exchange ActiveSync lets you force password requirements to a mobile device, configure the amount of
data that will synchronize from Inbox and calendar, and allow or prohibit synchronization while roaming.
In addition, with these policies you can control some basic application usage on the device (for example,
browser and email clients), as well as some hardware capabilities such as Bluetooth, wireless, camera, and
storage card access. In general, these settings provide the most important features for managing mobile
devices. All these settings are mandatory, which means that if they are applied, users cannot change them
from the client side.
Active Sync polices are applied on a per-user basis, which means you can create different policies for
different users. However, the policies can be applied only to the level that the mobile device supports.
Policy settings that the mobile platform does not support on the client side are ignored.
To ensure that mobile devices are as secure as possible, you should configure Exchange ActiveSync
policies that require device passwords, and encrypt the data stored on the mobile device.
Note Encryption of data stored on the mobile device is currently supported only on the
Windows Mobile 6.5 operating system. The next release of Windows Phone 7 will support
encryption policies.
Managing Mobile Devices

You can manage mobile devices using either the Exchange Management Console or the Exchange
Management Shell. With these tools, you can perform the following tasks:
View a list of all mobile devices that any enterprise user is using.
Send or cancel remote wipe commands to mobile devices. Performing a remote wipe is useful when
an end user loses his or her mobile device, or if the device is stolen and there is a risk that personal or
confidential information could be accessed.
View the status of pending remote-wipe requests for each mobile device.
View a transaction log that indicates which administrators have issued remote-wipe commands, and
the mobile devices to which those commands pertain.
Delete an old or unused partnership between devices and users.
Note The option to manage a mobile device for a user mailbox in the Exchange
Management Console is available only after the user has synchronized with the Exchange
Server from a mobile device. You also can manage mobile devices in the Exchange
Management Shell by using the Remove-ActiveSyncDevice and the
Clear-ActiveSyncDevice cmdlets.
Configuring Self-Service Mobile Device Management

Users also can manage their own mobile devices by accessing the ECP. One of the options available is the
Phone tab. From this tab, users can wipe a device that they have configured, and can delete partnerships
for devices that they no longer use.
Self-service management is enabled by default for all users who are assigned to a
Microsoft Exchange ActiveSync mailbox policy.
Note In Exchange Server 2010, the request originator receives a confirmation message
when the device acknowledges the remote wipe request. If the user originates the request
through Outlook Web App, they will receive a confirmation email. If the administrator
originates the request, both the administrator and the user will receive a confirmation email.
Enabling SSL for the Mobile Device Connections

To ensure that the communication between the mobile device and the Client Access server is secure, you
should ensure that the Microsoft Server ActiveSync virtual directory is configured to require SSL.
Installing CA Root Certificates on Mobile Devices

Just like desktop computers, mobile devices are configured to trust the root certificates for most public
CAs. 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. All mobile operating systems that support ActiveSync also support installation of root CA
certificates. Usually, it will be easiest to send a .cer file to a mobile device by email or transfer it using
desktop synchronization software.
Mobile Device Quarantine in Exchange Server 2010
Microsoft Exchange Server 2010 SP1 and later, with the latest version of ActiveSync protocol, offer some
new features in the field of mobile device management for both users and administrators.
As an administrator, you can create allow lists, block lists, and quarantine lists that specify which mobile
devices are allowed to access your Exchange mailboxes. This allows you to identify the devices that users
can connect to the Exchange Sever. For example, you can specify that only devices that are running
Windows Phone 7 operating system can connect to the Exchange Server.
This is achieved by defining the device access state for each mobile device that connects to Exchange
Server. A device access state is the status of a particular device. You can control device access states in
several ways and a mobile device will behave differently in each access state. The access state of a device
can be one of the following:
Allowed. In the allow access state, a mobile device can synchronize through Exchange ActiveSync and
connect to the Exchange server to retrieve email and manipulate calendar information, contacts,
tasks, and notes. This will continue as long as the device complies with the Exchange ActiveSync
configured mailbox policies. This is the default state for all devices, because Exchange Server does not
have any quarantine policies defined.
Blocked. If defining ActiveSync Access rules are blocking a mobile device, it cannot connect to the
Exchange server, and receives an HTTP 403 Forbidden error. You can block a device based on device
family or you can block some specific model of device. The user will receive an email message from
the Exchange server telling them that the mobile device was blocked from accessing their mailbox. A
mobile device may also be blocked because it fails to apply the Exchange ActiveSync mailbox policies.
If this is the case, the user cannot receive an email message that tells them that the mobile device was
blocked from accessing their mailbox. However, the mobile device information displayed in Outlook
Web App show that it is blocked due to the failure by the device to apply the Exchange ActiveSync
mailbox policies.
Quarantined. When a mobile device is in a quarantined state, it is allowed to connect to the Exchange
server, but with limited access to data. The user can add content to their own Calendar, Contacts,
Tasks, and Notes folders but the server will not allow the device to retrieve any content from the
user's mailbox. The user will receive a single email message that tells him or her that the mobile
device is quarantined. This message will be received by the device and will also be available in the
user's mailbox. You can add customized text to this message to provide instructions for users whose
devices are quarantined. A device will remain in quarantined state until the administrator decides
whether it will be blocked or allowed to connect.
You can create and manage device access rules by using Exchange Control Panel or Exchange
Management Shell. You can manage both ActiveSync device policy and ActiveSync Access policy from
these interfaces.
Demonstration: How to Configure Exchange ActiveSync Policies
One of the features in Exchange Server 2010 is that you can manage mobile users and devices with
Exchange ActiveSync mailbox policies. When you create a policy, you can configure the following options:
Allow or block nonprovisionable devices. This option permits you to specify whether devices that do
not fully support the device security settings can synchronize with the Exchange Server computer.
Enable, disable, or limit attachment downloads. This option allows you to enable or disable
attachment downloads, and configure a maximum attachment download size.
Configure devices to require passwords. If you choose to require passwords, you also can configure
the following attributes:
Minimum password length.
A requirement for alphanumeric passwords.
Inactivity time before the password is required.
The option to enable password recovery.
A requirement for device encryption.
Number of failed attempts allowed. This option specifies whether you want the device memory
wiped after a specific number of failed logon attempts.
Options for disabling removable storage, cameras, Wi-Fi, or Bluetooth.
Options for configuring synchronization settings such as message size limits.
Options for enabling additional mobile device applications such as Web browsers, unsigned
applications, or for defining allowed and blocked applications.
Note Some of these features were implemented with Windows Mobile 5.0 devices. Some
features, such as encryption on the local device, and Windows SharePoint Services and
Windows File Shares integration, are available only with Windows Mobile 6 or later. Some
settings also require an Enterprise Client Access License for each mailbox.
In this demonstration, you will see how to configure Exchange ActiveSync policies.
Demonstration Steps
1. In the Exchange Management Console, access the Organization Configuration node, and then click
Client Access.
2. Create New Exchange ActiveSync Mailbox Policy, and then configure the available settings.
3. After creating the policy, access the policy properties and configure the additional settings.
4. Access a user mailboxs properties. On the Mailbox Features tab, click Exchange ActiveSync, and
then click Properties. Assign the appropriate Exchange ActiveSync policy.
Lab B: Configuring Client Access Servers for Outlook Web

App and Exchange ActiveSync
Lab Setup

virtual machines are running:
10135B-VAN-CL1: Client computer in the Adatum.com domain.
Lab Scenario
To enable client access to the server, your organization has decided to enable both Outlook Web App and
Exchange ActiveSync for its users. However, the security officer at A. Datum Corporation has defined
security requirements for the Outlook Web App and Exchange ActiveSync deployment. Therefore, you
need to enable the security features for both Outlook Web App and Exchange ActiveSync.
Exercise 1: Configuring Outlook Web App

Scenario
A. Datum Corporation has several users who work regularly from outside the office. These users should be
able to check their email from any client computer, including client computers located in public areas. To
provide this functionality, you must configure the server settings for Outlook Web App, and configure
Outlook Web App policies. You also need to verify that the settings have been successfully applied.
1. Configure IIS to use the Internal CA certificate.
2. Configure Outlook Web App settings for all users.
3. Configure an Outlook Web App Mailbox Policy for the Branch Managers.
4. Verify the Outlook Web App configuration.
X Task 1: Configure IIS to use the Internal CA certificate

1. On VAN-EX2, in Internet Information Services (IIS) Manager, verify that the owa virtual directory
under the Default Web Site is configured to require SSL.
2. Verify that the Default Web Site is configured to use the Adatum Mail Certificate.
X Task 2: Configure Outlook Web App settings for all users

1. On VAN-EX2, in Exchange Management Console, verify that the owa virtual directory is configured to
use forms-based authentication. Modify the forms-based authentication to use the user name only
and to use the Adatum.com domain automatically.
2. Disable the Tasks and Rules display for all users.
3. Use the set-owavirtualdirectory owa (Default Web Site) ForceSaveFileTypes .doc cmdlet to
force all users to save Word documents before opening them.
4. Use the set-owavirtualdirectory owa (Default Web Site) GzipLevel Off cmdlet to disable GZip
compression.
5. Use the Set-OwaVirtualDirectory -identity Owa (Default Web Site) -

FilterWebBeaconsAndHtmlForms ForceFilter cmdlet to block all Web beacons and HTML forms.
6. Use the IISReset /noforce command to restart IIS.
X Task 3: Configure an Outlook Web App Mailbox Policy for the branch managers
1. Create a new Outlook Web App Mailbox policy, and configure the policy with the name Branch
Managers Policy.
2. Configure the policy to prevent branch managers from changing their password.
3. Apply the policy to all users in the Branch Managers organization unit (OU).
X Task 4: Verify the Outlook Web App configuration

1. On VAN-EX1, connect to https://mail.Adatum.com/owa.
2. Log on to Outlook Web App as Adatum\Sharon using the password Pa$$w0rd. Sharon is not in the
Branch Managers OU.
3. Verify that the Tasks folder is not displayed in the user mailbox, and that Sharon cannot configure a
new Inbox rule in the ECP.
4. Connect to OWA again, and log on as Adatum\Johnson using the password Pa$$w0rd. Johnson is
in the Branch Managers OU.
5. Verify that the Tasks folder is listed in the user mailbox, but that Johnson is not able to change his
password.
Results: After this exercise, you should have configured Outlook Web App on VAN-EX2. This
configuration includes assigning the internal CA certificate to the Default Web Site, and configuring
Outlook Web App settings for all users, as well as for specific users. You also should have verified the
Outlook Web App settings.
Exercise 2: Configuring Exchange ActiveSync

Scenario
A. Datum Corporation has several users who use Windows Mobile devices to access their mail. You need
ensure that these users can access their mailboxes using Exchange ActiveSync. To ensure that the client
connection is secure, you must configure an Exchange ActiveSync policy, and apply it to a user account.
You will also install a root certificate on the mobile device, and configure SSL security. Lastly, you need to
manage the mobile device as both an administrator and a user using ECP.

1. Verify the Exchange ActiveSync virtual directory configuration.
2. Create a new Exchange ActiveSync mailbox policy.
X Task 1: Verify the Exchange ActiveSync virtual directory configuration

On VAN-EX2, in Exchange Management Console, review the configuration for the Microsoft Server
ActiveSync virtual directory on VAN-EX2.
X Task 2: Create a new Exchange ActiveSync mailbox policy

1. On VAN-EX2, in Exchange Management Console, create a new Exchange ActiveSync Mailbox policy
with the following configuration:
Name: EAS Policy 1
Enable unprovisionable devices
Enable attachments to be downloaded to the device

Require passwords
Enable password recovery
2. Review the other Exchange ActiveSync Mailbox policy settings.
3. Apply the Exchange ActiveSync Mailbox policy to Scott MacDonald.
Results: After this exercise, you should have configured the Exchange server environment to support
Exchange ActiveSync. You first verified that Exchange ActiveSync worked, and then enhanced the security
configuration by creating a more secure Exchange ActiveSync Mailbox policy, and by enabling SSL for all
Exchange ActiveSync connections.

following steps:
1. On the host computer, start Microsoft Hyper-V Manager.

7. Wait for VAN-EX1 to start, and then start VAN-EX2. Connect to the virtual machine.
Review Questions
1. You need to ensure that users from the Internet can connect to a Client Access server by using
Outlook Anywhere. How will you configure the firewall between the Internet and the Client Access
server?
2. You need to ensure that the same Exchange ActiveSync policies are assigned to all users, with the
exception of the Executives group. This group requires higher security settings. What should you do?
3. You have deployed an Exchange Server 2010 server in an organization that includes several Exchange
Server 2003 servers. How will Exchange Server 2010 obtain free\busy information for user mailboxes
on the Exchange Server 2003 servers?
Common Issues Related to Client Connectivity to the Client Access Server

Identify the causes for the following common issues related to client connectivity to the Client Access
server, and complete the troubleshooting tips. For answers, refer to relevant lessons in the module.
Users using Web browsers

other than Internet Explorer
may have trouble
authenticating.
Clients receive certificate-

related errors when they
connect to the Client Access
server.
Users from the Internet are

not able to connect to the

1. Your organization has two locations with an Internet connection in each location. You need to ensure
that when users access their email using Outlook Web App from the Internet, they will always connect
to the Client Access server in their home office.
2. You are planning on enabling Outlook Web App, Outlook Anywhere, and Exchange ActiveSync access
to your Client Access server. You want to ensure that all client connections are secure by using SSL,
and that none of the clients receives errors when they connect to the Client Access server. You plan
on requesting a certificate from a Public CA. What should you include in the certificate request?
3. You have deployed two Client Access servers in the same Active Directory site. When one of the Client
Access servers shuts down, users can no longer access their email. What should you do?
Best Practices Related to Planning the Client Access Server Deployment

Supplement or modify the following best practices for your own work situations.
When designing the Client Access server configuration, consider the following recommendations:
The recommended processor configuration for Client Access servers is eight processor cores, and the
maximum recommended number of processor cores is 12. You should deploy at least two processor
cores for Client Access serverseven in small organizationsbecause of the addition of the RPC
Client Access service on the Client Access server.
As a general guideline, you should deploy three Client Access server processor cores in an Active
Directory site for every four Mailbox server processor cores.
The recommended memory configuration for Client Access server is 2 gigabytes (GB) per processor
core, with a maximum of 8 GB.
Deploying Client Access servers on a perimeter network is not a supported scenario. The Client Access
server must be deployed on the internal network. The Client Access server role must be installed on a
member server, and it must have access to a domain controller and global catalog server, as well as
the Mailbox servers inside the organization.
Use Device Access Rules and quarantine options to control mobile devices.
Tools
Microsoft Exchange Server Troubleshooting Internet http://go.microsoft.com/fwlink

Remote Connectivity connectivity for messaging /?LinkId=179969
Anaylzer clients.
Test E-Mail Troubleshooting Outlook Open Outlook, press and hold Ctrl,
AutoConfiguration Connectivity to the Client right-click the Outlook connection
Access server. object, and then click Test E-Mail
AutoConfiguration.
Internet Information Server Configuring SSL settings for Administrative Tools

(IIS) Manager Client Access server virtual
directories.
5-1
Module 5
Managing Message Transport
Contents:
Lesson 1: Overview of Message Transport 5-3
Lesson 2: Configuring Message Transport 5-18
Lab: Managing Message Transport 5-33

5-2 Managing Message Transport
Module Overview
This module describes how to manage message transport in Microsoft Exchange Server 2010. To
implement message transport in Exchange Server 2010, it is important to understand the components of
message transport, how Exchange Server 2010 routes messages, and how you can troubleshoot message-
transport issues.
This module also provides details on deploying the Exchange Server 2010 Hub Transport server, and the
options that you can configure.
Describe message transport in Exchange Server 2010.
Configure message transport.

Lesson 1
Overview of Message Transport
In this lesson, you will review message flow and the components that message transport requires,
especially when you implement multiple Exchange Server 2010 Hub Transport servers. To understand
message flow, you should know how message routing works within an Exchange Server organization, and
how Exchange Server routes messages between Active Directory Domain Services (AD DS) sites or
outside the Exchange Server organization. Exchange Server 2010 provides several tools for
troubleshooting Simple Mail Transfer Protocol (SMTP) message delivery, and this lesson describes how
you can use these troubleshooting tools.
Describe the components of message transport.
Describe how an Exchange Server organization routes messages.
Describe message routing between Active Directory sites.

Describe options for modifying the default message flow.
Describe the tools for troubleshooting SMTP message delivery.
Troubleshoot SMTP message delivery.

Components of Message Transport
Message transport in Exchange Server 2010 consists of several components that work together to route
messages. These components include the SMTP Receive connector through which messages from inside
or outside the organization enter the transport pipeline, and Agent delivery, which is a non-Microsoft
agent that directly submits messages. Other message transport components include:
Submission queue
Categorizer
Store driver
Microsoft Exchange Mail Submission service
Pickup and Replay directories
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 delivery. The categorizer cannot process a message until the
transport server promotes it to the submission queue. During the time that the categorizer processes a
message, a copy of the message remains in the submission queue. After successful processing, the
message is removed from both the categorizer and the submission queue.
Messages can enter the submission queue in several ways:
Messages received by an SMTP Receive connector. This is used for inbound messages from the
Internet or from a client using Post Office Protocol version 3 (POP3) or Internet Message Access
Protocol version 4 (IMAP4).
Messages placed in the Pickup directory. This method is used for troubleshooting and legacy
applications.
Messages submitted by a transport agentsuch as a non-Microsoft connectorto a foreign

messaging system.
Messages submitted by the store driver. This method is used to retrieve messages from the senders
Outbox. This queue exists only on Hub Transport servers and not on Edge Transport servers, because
Edge Transport servers do not communicate with Mailbox servers.
Messages resubmitted after failed delivery. The categorizer resubmits messages that are not delivered
on the first attempt. You also can manually resubmit messages.
Delivery Queue
Delivery queues contain messages that the Exchange Server has yet to deliver. Messages are placed in one
of two delivery queuesmailbox delivery queue or remote delivery queuedepending on their intended
delivery route.
Mailbox delivery queues hold messages that are being delivered to Mailbox servers located in the
same site. Messages are delivered by using encrypted Remote Procedure Calls (RPCs). Mailbox
delivery queuesone queue for each databaseexist only on Hub Transport servers.
Remote delivery queues contain messages that are being delivered to a remote server by using SMTP.
Remote delivery queues can exist on both Hub Transport servers and Edge Transport servers, and
more than one remote delivery queue can exist on each server. On Edge Transport servers, these
destinations are external SMTP domains or SMTP connectors. On Hub Transport servers, these
destinations may refer to Hub Transport servers in remote Active Directory sites, Edge Transport
servers, or non-Exchange Server SMTP connections.
Note Exchange Server 2010 has additional queues. These include the Poison message
queue, which is a queue that is used to isolate messages that could be potentially harmful
to the Exchange Server 2010 system after a server failure. This queue is typically empty, and
if no poison messages exist, the queue does not appear in the queue-viewing interfaces.
The Unreachable queue contains messages that cannot be routed to their destinations.
Typically, an unreachable destination is caused by configuration changes that have modified
the routing path for delivery.
Categorizer
The categorizer retrieves one message at a time from the submission queue, and it 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 or an Internet SMTP
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. Expanding the distribution lists enables
identification of individual recipients who belong to the distribution lists. 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 sender of the
original message.
Determines routing paths. As part of determining the routing path, the categorizer identifies the
destination. The possible destinations could be a users mailbox, a public folder, or an expansion
server for distribution groups. If the categorizer cannot determine a valid destination, it generates a
non-delivery report (NDR).
Converts content format. The categorizer converts messages to an appropriate format for recipients
who require varying formats. Within 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 message size,
permissions for sending messages to specific users, the number of message recipients, and other
message characteristics.
Store Driver
The store driver is a software component that is present on each Hub Transport server. The store driver
retrieves messages from the senders Outbox and then submits them to the submission queue. The
responding store driver mechanism places a copy of the message into the Hub Transport servers
submission queue so that the categorizer can later process the message. After the store driver adds the
messages 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 Messaging Application Programming Interface (MAPI) format. The
store driver must convert them to Summary Transport Neutral Encapsulation Format (STNEF) before
placing them in the submission queue. The store driver performs this conversion to ensure successful
delivery of messages despite the format that was used to create the messages. A TNEF-encoded message
contains a plain text version of the message, and a binary attachment that contains various other parts of
the original message. Some Microsoft Outlook 2010 features require TNEF encoding to be understood
correctly by an Internet email recipient who also uses Outlook. For example, when you send a message
with voting buttons to a recipient over the Internet, if TNEF is not enabled for that recipient, the voting
buttons will not be received. If the store driver cannot convert the content, it generates an NDR.
Microsoft Exchange Mail Submission Service

The Microsoft Exchange Mail Submission service is a notification service that runs on Mailbox servers. It
notifies a Hub Transport server role in the local Active Directory site when a message is available for
retrieval from a senders Outbox. The store driver on the notified Hub Transport server role picks up the
message from the senders Outbox. If there are multiple Hub Transport servers in the Active Directory site,
the Microsoft Exchange Mail Submission service attempts to distribute notifications evenly between the
Hub Transport servers, and will use the first Hub Transport server that responds.
Pickup and Replay Directories

Most messages enter the message transport pipeline through SMTP Receive connectors, or by submission
through the store driver. However, messages can also enter the message transport pipeline by being
placed in the Pickup or Replay directory on a Hub Transport server or an Edge Transport server.
After a message is placed in the Pickup directory, the store driver adds the message to the submission
queue. The store driver then deletes the message from the Pickup directory. Messages from the Pickup
directory must be text files that comply with the basic SMTP message format and have configured read
and write permissions.
The Pickup directory allows the Hub Transport server to process and deliver a properly formatted text file.
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 directly into the Pickup directory for delivery, rather than communicate directly with Exchange
Server SMTP Receive connectors.
How Are Messages Routed in an Exchange Server Organization?
In an Exchange Server messaging environment, you must deploy a Hub Transport server role in each
Active Directory site where a Mailbox server role or a Unified Messaging server is installed. Hub Transport
servers deliver all messages in an Exchange Server 2010 organization, including messages sent between
two recipients with mailboxes located in the same Mailbox database, on the same site, and between
Active Directory sites.
The following process describes how a Hub Transport server delivers mail within a single Active Directory
site:
1. The message flow begins when a message is submitted to the message store on an Exchange Server
2010 Mailbox server role.
If the client is a Microsoft Office Outlook client, the message is submitted using MAPI, and the
message is written directly to the Outbox in the users mailbox.
2. When the Microsoft Exchange Mail Submission service detects that a message is available and waiting
in an Outbox, it picks an available Hub Transport server and submits a new message notification to
the store driver.
3. The store driver retrieves the message from the Mailbox server role. The store driver uses MAPI to
connect to the users Outbox and collect any messages that are awaiting delivery. The store driver
submits the messages to the categorizer submission queue, for processing, and also moves a copy of
the message from the users Outbox to the users Sent Items folder.
Note While the message is passing through the Hub Transport server role, the server can
use transport agents to modify the message or the message flow. For example, transport
agents can apply custom routing or journaling rules, or perform antivirus filtering.
4. For messages destined to arrive at a Mailbox server on the same Active Directory site, the store driver
places the message in a local delivery queue and delivers the message through MAPI to the Mailbox
server role.
5. For messages destined to arrive at a Mailbox server on another Active Directory site, the Hub
Transport server uses the Active Directory site-link information to determine the route to the
destination site. After determining the path, the Hub Transport server connects directly to the server
on the remote site. If no Hub Transport server on the destination site is available, the store driver
routes the message to a Hub Transport server that is closer to the destination site.
6. For messages destined for the Internet, the Hub Transport server delivers the message to an Edge
Transport server, which delivers the message to the appropriate Internet email server. If the
organization does not use an Edge Transport server, a Hub Transport server delivers the message
directly to the appropriate Internet email server using SMTP.
Message-Flow Characteristics
In an organization with multiple sites, message flow has the following characteristics:
Direct relay routing. The Hub Transport server delivers messages directly to a Hub Transport server on
the remote site, unless there is a communication problem or hub sites are enabled.
Queue at point of failure. The Hub Transport server uses the site-link cost assignment to determine
a routing topology only when direct communication with a Hub Transport server role on the
destination site fails. If no Hub Transport server on the destination site responds, the Hub Transport
server uses IP site-link costs to determine the closest site at which to queue the message.
Using hub sites to control message routing. If you configure a hub site along the least cost path for
message delivery, the message is delivered to a Hub Transport server on the hub site rather than
using direct relay routing. The Hub Transport server on the hub site delivers the message to a Hub
Transport server on the next hub site or the destination Active Directory site.
Delayed fan-out. As the Hub Transport server delivers messages throughout the Exchange Server
organization, the Hub Transport server delays expansion of distribution lists and message bifurcation
until messages reach a fork in the routing topology. Delayed fan-out applies when you use hub sites
to control message routing, and it overrides direct relay routing when appropriate to minimize wide
area network (WAN) utilization.
Shadow redundancy. This feature provides redundancy for messages for the entire time they are in
transit. The solution involves a technique similar to the Transport Dumpster. The Transport Dumpster
stores recent messages that are redelivered in the case of a Mailbox server failure. With shadow
redundancy, a messages deletion from the transport databases is delayed until the transport server
verifies that all of the messages next hops have completed delivery. If any of the next hops fail before
reporting that a successful delivery has occurred, it resubmits the message for delivery to that next
hop.
How Are Messages Routed Between Active Directory Sites?
For remote mail-flow scenarios, the initial steps, in which the message passes from the Mailbox server to
the Hub Transport server, are identical to those of the local mail-flow scenario.
Understanding Remote Mail Flow

When a message is addressed to a recipient in the same Exchange Server organization, but in a different
Active Directory site, the following process takes place:
1. The local Mailbox server uses Active Directory site-membership information to determine which Hub
Transport servers are located in the same Active Directory site as the Mailbox server. The Mailbox
server submits the message to the local Hub Transport server. If more than one Hub Transport server
exists in the site, the Mailbox server will load-balance message delivery to all available Hub Transport
servers.
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 Active Directory site of
the users Mailbox server.
3. In a default configuration, the local Hub Transport server opens an SMTP connection to the remote
Hub Transport server in the destination site, and then delivers the message. After a Hub Transport
server in the destination Active Directory site receives the message, it forwards the message to the
appropriate Mailbox server in the destination Active Directory site.
4. If the message has multiple recipients whose mailboxes are in different Active Directory sites,
Exchange Server uses delayed fan-out to optimize message delivery. If the recipients share a portion
of the path, or the entire path, Exchange Server sends a single copy of the message with these
recipients until the bifurcation point. Exchange Server then bifurcates and sends a separate copy to
each recipient.
For example, if the least-cost routes from Site1 to Site3 and Site4 both pass through Site2, Exchange
Server sends a single copy of a message intended for recipients in Site3 and Site4 to a Hub Transport
server in Site2. Then, the Hub Transport server in Site2 sends two copies of the message: one each to
a Hub Transport server in Site3 and Site4.
How Exchange Server 2010 Deals with Message-Delivery Failure

If a Hub Transport server cannot deliver a message to a Hub Transport server in the destination site, the
Hub Transport server uses the least-cost routing path to deliver the message 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 to trace the path backward until it makes a connection to a Hub Transport server. The
Hub Transport server queues the messages in that Active Directory site, and the queue is in a retry state.
If Hub Transport servers are not available in any site along the least-cost route, the message is queued on
the local Hub Transport server. This behavior is called queue at point of failure.
Options for Modifying the Default Message Flow
In some cases, you may want to modify the default message routing configuration. You can do this by
configuring specific Active Directory sites as Hub sites, and by assigning Exchange Server-specific routing
costs to Active Directory site links. Hub sites are central sites that you define to route messages.
By default, Hub Transport servers in one site will try to deliver messages to a recipient in another site by
establishing a direct connection to a Hub Transport server in the remote Active Directory site. However,
you can modify the default message-routing topology in three ways.
Configuring Hub Sites

You can configure one or more Active Directory sites in your organization as hub sites. When a hub site
exists along the least-cost routing path between two Hub Transport servers, the messages are routed to a
Hub Transport server in the hub site for processing before they are relayed to the destination server.
Note 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
lowest cost 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. Use the Set-ADSite Identity sitename HubSiteEnabled $true cmdlet to
configure a site as hub site.
Configuring Exchange-Specific Routing Costs

You also can modify the default message-routing topology by configuring an Exchange-specific cost to an
Active Directory IP site link. If you assign an Exchange-specific cost to the site link, the Hub Transport
server determines the least-cost routing path by using this attribute rather than the Active Directory-
assigned cost.
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 Active Directory sites.
Configuring 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 in the
list. 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 then expands the list and distributes the messages.
For example, you can use expansion servers for location-based distribution groups to ensure that the local
Hub Transport server resolves them.
Note You might need to review the Active Directory site design when you deploy
Exchange Server 2010 to adjust the IP site links and site-link costs so that you optimize
delayed fan-out and instead queue at the point of failure.
Tools for Troubleshooting SMTP Message Delivery
Similar to Exchange Server 2007, Exchange Server 2010 also provides several tools for troubleshooting
SMTP message delivery.
Note Exchange Server 2010 relies on the Active Directory site configuration for message
routing. Therefore, to troubleshoot a message-routing issue, you might need to use Active
Directory tools to validate or modify site, site link, or IP subnet information, and to verify
Active Directory replication. You can use the Active Directory Sites and Services tool to view
IP subnets and site links.
Using 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 the 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 Mail Flow Troubleshooter

The 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.
The Mail Flow Troubleshooter is available in the Exchange Management Console Toolbox.
Using the Queue Viewer

Like previous Exchange Server versions, messages waiting to be processed or delivered reside in message
queues on the Exchange Server 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. To
manage queues, you can use either the Exchange Queue Viewer or the Exchange Management Shell.
Exchange Server 2010 features simplified queues. Hub Transport servers maintain five queues:
Submission queue. Contains messages that the Categorizer is processing.

Remote delivery queue. There is one queue for each outbound SMTP domain to which the Hub
Transport server routes mail.
Poison message queue. Contains messages that could cause the server to crash.
Mailbox delivery queue. There is one queue for each Mailbox server to which the Hub Transport server
can deliver messages.
Unreachable queue. Contains messages that Hub Transport servers cannot route to their destinations.
You can view the queues on a Hub Transport server by accessing the Exchange Queue Viewer in the
Toolbox node in the Exchange Management Console.
To manage message queues from the Exchange Management Shell, use the following cmdlets:
Get-Queue
Get-Message
Additionally, you can perform the following tasks on queues and messages in queues from the Exchange
Management Shell:
Suspend-Queue and Resume-Queue

Retry-Queue
Suspend-Message and Resume-Message
Remove-Message
Note For more information on the queues that Exchange Server 2010 uses, and the
process for troubleshooting message flow, see the Managing Queues page on the Microsoft
Technet Web site.
Using Message Tracking and Tracking Log Explorer

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\TransportRoles\Logs\MessageTracking folder. The message-
tracking logs are retained for 30 days, with a maximum size for all log files of 250 megabytes (MB). You
can use the set-TransportServer cmdlet in the Exchange Management Shell to modify the default
settings.
Note To view the message-tracking logs, use the Message Tracking and Tracking Log
Explorer tools available in the Exchange Management Console Toolbox. In Exchange Server
2010, users also can track their messages using the Exchange Control Panel. The Message
Tracking tool does not provide the level of detail that the Tracking Log Explorer provides.
For example, sending a message between two Exchange servers that are in the same Active
Directory site does not show the Exchange server names in Message Tracking whereas
Tracking Log Explorer provides you with this information.
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 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 it 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 C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs
\ProtocolLog folder.
Using Telnet
You can use Telnet to check if the SMTP port responds, or to directly send a 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 #. For example, you can use
either TELNET VAN-EX1 SMTP or TELNET VAN-EX1 25, both being basically the same.
TestExchangeConnectivity Website
This website, available at http://go.microsoft.com/fwlink/?LinkId=248382, enables you to test connectivity
to various Exchange services from the Internet, and also test the functionality of these services. In context
of SMTP, you can test inbound and outbound email traffic that is using the SMTP protocol. You can use
this TestExchangeConnectivity web site to test both an on-premises Exchange Server as well as Exchange
Online in Office 365. To use this tool, you must enter the credentials of a working account from the
Exchange domain you want to test. To avoid the risk of your working credentials being exploited and
compromising the security of your Exchange Server environment, we strongly recommend that you create
a test account for the purpose of using this tool, and delete this account immediately after you have
completed the connectivity testing.
Demonstration: How to Troubleshoot SMTP Message Delivery
In this demonstration, you will see how to use Telnet and Queue Viewer to troubleshoot SMTP message
delivery.
Demonstration Steps
1. Open the Command Prompt window.
2. To start the Telnet tool, at the command prompt, type Telnet VAN-EX1 SMTP, and try to send a mail
using Telnet.
3. In Exchange Management Console, from the Toolbox pane in Exchange Management Console, start
the Queue Viewer tool.
4. Suspend and resume the Submission queue.

5. Close Queue Viewer.
Lesson 2
Configuring Message Transport
To configure message transport in an Exchange Server organization, you must first configure the Hub
Transport servers. It is important to understand the various message-transport concepts and components,
such as accepted and remote domains and SMTP connectors. This lesson also describes the various tasks
of configuring a Hub Transport server and message routing.
Describe the process for configuring Hub Transport Servers.
Configure Hub Transport Servers.
Describe the options for configuring message transport.
Describe accepted domains.
Describe remote domains.
Configure accepted and remote domains.

Describe an SMTP connector.
Configure SMTP Send and Receive connectors.
Describe the purpose and functionality of back pressure.

Process for Configuring Hub Transport Servers
By default, when you install a Hub Transport server in an Exchange Server 2010 organization, this enables
message routing within the organization. However, you might need to configure additional options on
the Hub Transport server role.
To configure a Hub Transport server, use the following process:
1. Configure server-specific settings. These settings include internal Domain Name System (DNS)
configuration and connection limits.
2. Configure authoritative domains and email address policies. An authoritative domain is one for which
the Exchange Server organization accepts messages and has mailboxes. You first must configure an
authoritative domain before you can configure email address policies to apply email addresses to
recipients and accept inbound SMTP messages for those recipients.
3. Configure a postmaster mailbox. For each accepted domain, you should configure a postmaster
mailbox. The postmaster mailbox must meet the requirements of RFC 2822, and to receive NDRs and
DSNs. You can create a new mailbox, or you can add the postmaster alias to an existing mailbox user.
4. Configure Internet message flow. 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. 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.
5. 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.
Note 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.
6. Configure messaging policies. By default, messaging policies are not applied to messages passing
through the Hub Transport server role. As part of the Hub Transport server role deployment, you
must configure your organizations transport and journaling rules.
7. Configure administrative permissions. As part of the Hub Transport server role deployment, you can
choose to delegate permissions to configure and monitor the server.
Demonstration: How to Configure Hub Transport Servers
In this demonstration, you will review the options for configuring Hub Transport servers.
Demonstration Steps
1. On VAN-EX1, if required, click Start, point to All Programs, point to Microsoft Exchange Server
2010, and then click Exchange Management Console.
2. In Exchange Management Console, expand Microsoft Exchange On-Premises, expand

Organization Configuration, and then click Hub Transport.
3. On the Global Settings tab, double-click Transport Settings and review the options on the
Message Delivery tab.
4. In Exchange Management Console, expand Server Configuration, and then click Hub Transport.
Open Hub Transport server properties and review the options on the Log Settings tab and the
Limits tab.
5. At the Exchange Management Shell command prompt, type

Get-TransportServer -I van-ex1 |fl, and then press Enter.
What Are Accepted 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.
Configuring Accepted Domains

The accepted domain property specifies one or more SMTP domain names for which the Exchange server
receives mail. If an SMTP Receive connector on the Exchange Server 2010 Hub Transport server receives a
message that is addressed to a domain that is not on the accepted domain list, it rejects the message and
sends an NDR.
To configure an accepted domain, access the Organization Configuration node, and then click Hub
Transport. You can view the current accepted domains in the Accepted Domains tab, and you can
create additional domains by clicking New Accepted Domain in the Actions pane.
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 Active Directory forest. The
recipients in an 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.
Note To configure accepted domains using the Exchange Management Shell, use the
New-AcceptedDomain or Set-AcceptedDomain cmdlet.
What Are Remote Domains?
Remote domains define SMTP domains that are external to your Exchange 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 organizations global configuration
settings.
Note In Exchange Server 2010 Service Pack 2 (SP2), it is possible to define an Office 365
infrastructure as your remote domain. If the new remote domain you are creating
represents the part of your organization that is hosted on Office 365, you should use the
Office 365 Tenant Domain tab in the of Remote Domain Properties dialog box.
Creating Remote Domain Entries

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 Active Directory forest. When you
create a domain entry, you provide a name to help the administrator identify the entrys purpose when
they view configuration settings.
This 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.
Configuring Remote Domain Settings

The configuration for a remote domain determines the out-of-office message settings for email that is
sent to the remote domain and the message format settings for email that is sent to the remote domain.
Out-of-Office Message Settings

The out-of-office message settings control the messages that are sent to recipients in the remote domain.
The types of out-of-office messages that are available in your organization depend on both the Microsoft
Office Outlook client version and the Exchange Server version on which the users mailbox is located.
An out-of-office message is set on the Outlook client but is sent by the Exchange server. Exchange Server
2010 supports three out-of-office message classifications: external, internal, and legacy.
Message Format Options Including Acceptable Character Sets

You can configure multiple message format options to specify message delivery and formatting policies
for the messages that are sent to recipients in the remote domain.
The first set of options on the Message Format tab apply restrictions to the types of messages that can
be sent to the remote domain, how the senders name displays to the recipient, and the column width for
message text. These options include:
Allow automatic replies.A client email program may have a rule set to reply automatically to
messages that are sent to a particular distribution group. If you select this option, automatic replies
are sent to the remote domain. By default, this option is not selected, and automatic replies are not
sent to any recipient in any remote domain.
Allow automatic forward. A client email program may have a rule set to automatically forward
particular messages to another email address. If you select this option, automatic forwards are sent to
the remote domain. By default, this option is not selected, and automatic forwards are not sent to any
recipient in any remote domain.
Allow delivery reports. You can configure a client email program to notify the sender when the
message is delivered or is read by the recipient. By default, this option is selected, and delivery reports
are sent to all recipients in any remote domain. If you clear this option, delivery reports are not sent
to any recipient in the remote domain.
Allow nondelivery reports. When a message cannot be delivered to a recipient in the Exchange
organization, the Hub Transport server generates an NDR and sends it to the messages sender. By
default, this option is selected, and NDRs are sent to all email addresses in any remote domain. If you
clear this option, NDRs are not sent to any email address in the remote domain.
Display senders name on messages. A user who has a mailbox on a Mailbox server in the Exchange
organization has both an email address and a display name that is associated with their user account.
By default, this option is selected, and the users display name is visible to the messages recipient. If
you clear this option, the email alias is visible to the recipient. We recommend that you leave this
option selected.
Use message text line-wrap at column. To use line-wrap in message text for outgoing messages,
select this option. Then type the line-wrap size, between 0 and 132 characters, in the text box. To set
the value to unlimited, leave the field blank. The default value is unlimited (blank). If you select this
option, the text of all email messages that are sent from your organization to the remote domain are
displayed with the message text width that you specify.
If you do not set a value for this option, the client email application settings determines the message
text width. Some earlier versions of email clients require that a line break is positioned after the
seventy-sixth or seventy-seventh character. If you do not configure this setting, those email clients will
only view the first 76 characters of each line. Therefore, parts of the message may not appear.
Meeting forward notification enabled. This setting is available only when you use the Exchange
Management Shell. To configure this option, use the Set-RemoteDomain cmdlet with the
MeetingForwardNotificationEnabled parameter. By default, this setting is set to $true, and meeting
requests that are forwarded to recipients in the remote domain generate a meeting-forward
notification to the meeting organizer. When this parameter is set to $false, meeting requests that are
forwarded to recipients in the remote domain do not generate a meeting-forward notification.
Message Format Options

Use the Exchange Rich-Text Format (RTF) settings to determine whether email messages from your
organization to the remote domain are sent by using Exchange RTF.
Exchange RTF displays colors, fonts, and formatting in the email message. Exchange Server 2010 uses
RTF for messages that are delivered between Outlook clients. However, you can read Exchange RTF
only by using Outlook. The Exchange 2010 RTF format differs from the RTF format that word-processing
programs, such as Office Word, use. If recipients in a remote domain receive a file attachment named
Winmail.dat in their email, that remote domain is incompatible with Exchange RTF. To work around this
issue, you can configure the remote domain to never use Exchange RTF.
Character Sets
The Characters Sets options let you select a MIME character set and a non-MIME character set to use
when you send messages to a remote domain. The character sets used on the Internet are registered with
the Internet Assigned Names Authority (IANA). The most frequently used character sets are US ASCII and
Western European (ISO-8859-1). Other character sets are used to support language settings.
Demonstration: How to Configure Accepted and Remote Domains
In this demonstration, you will review the default accepted domain configuration, and then see how to
configure accepted and remote domains.
Demonstration Steps
2. Click the Accepted Domains tab, and then double-click Adatum.com. Click OK.
3. Click New Accepted Domain and create an accepted domain for adatum.local as Internal Relay
Domain.
4. Click the Remote Domains tab, and review the default remote domain settings. Click OK.
5. Click New Remote Domain, and create a remote domain for contoso.com.
What Is an SMTP Connector?
For a Hub Transport server to send or receive messages using SMTP, at least two SMTP connectors
must be available on the server. An SMTP connector is an Exchange Server component that supports
one-way SMTP connections that route mail between Hub Transport and Edge Transport servers or
between the transport servers and the Internet. You create and manage SMTP connectors from the
Exchange Management Console or the Exchange Management Shell. 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
intra-organization mail flow requires. These are implicit connectors that are not visible in
the Exchange management tools, and you cannot modify them.
What Are SMTP Receive Connectors?

An Exchange Server 2010 computer requires an SMTP Receive connector 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 Windows Mail and SMTP servers
on the Internet, Edge Transport servers, or other Exchange Server SMTP servers.
You create SMTP Receive connectors on each server running the Hub Transport server role. Use the
following naming protocol for the SMTP Receive connectors: Client SERVERNAME Receive connector,
which you configure to receive connections from SMTP clients such as Windows Mail; and Default
SERVERNAME Receive connector, which you configure to receive authenticated connections from other
SMTP servers. The default configuration for the two connectors is almost identical, but with one important
difference: you configure the Client SERVERNAME Receive connector to listen on port 587 rather than
port 25. As described in RFC 2476, port 587 has been proposed to be used only for message submission
from email clients that require message relay.
You can configure multiple SMTP Receive connectors with different parameters on a single Exchange
server. 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.
Note You must configure each SMTP Receive connector with a port on which the
connector will receive connections, local IP addresses that will 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.
What Are SMTP Send Connectors?

An Exchange Server 2010 computer requires an SMTP Send connector to send any SMTP email, and 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. These are created dynamically to
communicate with Hub Transport servers in other sites.
How to Manage SMTP Connectors

You can use the Exchange Management Console or the Exchange Management Shell to create, configure,
or view SMTP connectors. In the Exchange Management Console, you configure SMTP Receive connectors
for each Hub Transport server, while you configure Send connectors in the Organization Configuration
node. To manage connectors using the Exchange Management Shell, use the Set-ReceiveConnector and
Set-SendConnector cmdlets.
Note Incorrect configuration of SMTP Receive connectors can lead to opened relay on the
mail server. Therefore, you must carefully test the configuration.
Demonstration: How to Configure SMTP Send and Receive Connectors
In this demonstration, you will see how to configure SMTP Send and Receive connectors.
Demonstration Steps
2. Click the Send Connectors tab and create a New Send Connector.
3. In Exchange Management Console, expand Server Configuration, and then click Hub Transport.
4. Click New Receive Connector and create a Receive connector that allows the anonymous group to
send messages.
What Is Back Pressure?
Back pressure is a system-resource monitoring feature of the Microsoft Exchange Transport service that
exists on computers that have the Hub Transport server role or Edge Transport server role installed.
Back pressure monitors important system resources, such as available hard-disk drive space and available
memory. If utilization of a system resource exceeds the specified limit, the Exchange server stops
accepting new connections and messages. This prevents the system resources from being completely
overwhelmed, and enables the Exchange server to deliver the existing messages. When utilization of the
system resource returns to a normal level, the Exchange server accepts new connections and messages.
Back pressure can be used to:
Monitor system resources, such as available hard disk drive space and memory.
Restrict new connections and messages if a system resource exceeds a specified level.
Prevent the server from being completely overwhelmed.
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 overused. The server accepts new connections and messages.
Medium. The resource is slightly overused. Back pressure is applied to the server in a limited manner.
Mail from senders in the authoritative domain can flow. However, the server rejects new connections
and messages from other sources.
High. The resource is severely overused. Full back pressure is applied. All message flow stops, and the
server rejects all new connections and messages.
Options for Configuring Back Pressure

All configuration options for back pressure are available in the EdgeTransport.exe.config application
configuration file that is located in the C:\Program Files\Microsoft\Exchange Server\Bin directory.
The EdgeTransport.exe.config file is an XML application configuration file that is associated with the
EdgeTransport.exe file. The Microsoft Exchange Transport service uses the EdgeTransport.exe and
MSExchangeTransport.exe executable files. This service runs on every Hub Transport server or Edge
Transport server. Exchange Server applies the changes that are saved to the EdgeTransport.exe.config file
after the Microsoft Exchange Transport service is restarted.
Back pressure is turned on with the predefined default settings. There are various options you
can configure in back pressure, such as the PercentageDatabaseDiskSpaceUsedHighThreshold or
PercentagePrivateBytesUsedHighThreshold. However, Microsoft does not recommend modifying the
default back pressure configuration, so you should do it only when absolutely necessary. Incorrect
configuration of back pressure can affect system performance and functionality.
Lab: Managing Message Transport
Lab Setup
running:
3. If required, connect to the virtual machines. Log on to VAN-DC1, VAN-EX1 and VAN-EX2 as
Adatum\Administrator, using the password Pa$$w0rd.
Lab Scenario
You are a messaging administrator in A Datum Corporation., which is a large multinational organization
that has offices in London, Tokyo, and Vancouver, which is its headquarters. Your organization has
deployed Exchange Server 2010 in two of its sites. However, all Internet messages should flow through the
main site in Vancouver. As part of your job responsibilities, you need to set up the message transport to
and from the Internet and also ensure that the message flow works within and between the various sites.
Exercise 1: Configuring Internet Message Transport

Scenario
Your organization has deployed Exchange Server 2010 in two of its sites. However, all Internet messages
should flow through the main site. As part of your job responsibilities, you need to set up the message
transport to and from the Internet. You also want to configure the Hub Transport server for anti-spam.
1. Configure a Send connector to the Internet.
2. Configure a Receive connector to accept Internet messages.
3. Enable anti-spam functionality on the Hub Transport server.
4. Verify that Internet message delivery works.
X To prepare for this lab

1. On VAN-EX2, click Start, right-click Network, and then click Properties.
2. Click Change adapter settings.
3. Right-click Local Area Connection, and then click Properties.
4. Click Internet Protocol Version 4 (TCP/IPv4), and then click Properties.

5. Change the IP address to 10.10.11.21, and then click OK. Click Close.
6. Click the Start button, and then click Restart. In the Comment field, type Lab restart, and then
click OK.
7. After the system is restarted, log on to VAN-EX2 as Adatum\Administrator, using the password
Pa$$w0rd.
Note These preparation steps move VAN-EX2 to a second site defined in AD DS.
X Task 1: Configure a Send connector to the Internet

2. Create a new Send Connector with the following configuration:
Name: Internet Send Connector
Use: Internet
Address space: *
Route all messages through VAN-DC1.adatum.com
X Task 2: Configure a Receive connector to accept Internet messages

1. On VAN-EX1, create a new Receive Connector with the following configuration:
Name: Internet Receive Connector
Use: Custom
Local Network Settings: 10.10.0.10
2. Change the configuration on the Internet Receive Connector to enable anonymous users to send
email and to enable verbose logging.
X Task 3: Enable anti-spam functionality on the Hub Transport server

1. On VAN-EX1, open the Exchange Management Shell.
2. Switch to the c:\Program Files\Microsoft\Exchange Server\v14\scripts directory and use the

install-AntispamAgents.ps1 cmdlet to install the anti-spam agents on the Hub Transport server.
3. Restart the Microsoft Exchange Transport.
4. Verify that anti-spam configuration options are now available on VAN-EX1 and at the organization
level.
X Task 4: Verify that Internet message delivery works

1. On VAN-EX1, log on to Outlook Web App as Wei, and then send a message to Info@Internet.com.
2. From the Toolbox node in the Exchange Management Console, open the Queue Viewer. Check the
queues on VAN-EX1 to verify that the message was delivered.
3. On VAN-DC1, use Telnet to verify that VAN-EX1 accepts anonymous messages. Use Telnet to send a
message as Info@internet.com to WeiYu@adatum.com.
Results: After this exercise, you should have configured message transport to send and receive messages
to and from the Internet using a smart host. You also should have configured anti-spam functionality on a
Hub Transport server.
Exercise 2: Troubleshooting Message Transport

Scenario
You have successfully installed Exchange Server 2010 in two sites. You now need to make sure that mail
flow is working correctly.
1. Check the routing log, and verify that mail delivery works correctly.
2. Troubleshoot message transport.

X Task 1: Check the routing log, and verify that mail delivery works correctly
1. On VAN-EX1, use the Routing Log Viewer to verify that VAN-EX1 is located in the Default-First-Site-
Name site, and the VAN-EX2 is located in the Site2 site.
2. Log on to Outlook Web App as Wei, and send an email to Anna, whose mailbox is on VAN-EX2.
Verify that the mail is received and that Anna can respond to the email.
X Task 2: Troubleshoot message transport

1. On VAN-EX1, in Exchange Management Shell, run the d:\ labfiles\Lab05Prep1.ps1 script.
2. Send another email from Wei to Anna. Verify that the message is not delivered.
3. Use Queue Viewer to investigate mail flow problems.
4. Use Telnet to check connectivity from VAN-EX1 to VAN-EX2.
5. Re-create the receive connector to make mail flow work correctly.
6. Use Queue Viewer to force an immediate retry of message delivery.
7. Verify that Anna received the message.
Results: After this exercise, you should have used the Routing Log Viewer to get an overview of your
routing topology. For troubleshooting, you should have used the Queue Viewer and Telnet to investigate
the mail-flow problem.
Exercise 3: Troubleshooting Internet Message Delivery

Scenario
Your users complain that messages are not sent correctly to the internet. As part of your job
responsibilities, you need to track messages to find out why message flow to the Internet is not working
correctly.
1. Send a message to the Internet, and track it.
2. Implement user-based message tracking to verify mail delivery.
3. Troubleshoot Internet message delivery.
X Task 1: Send a message to the Internet, and track it

On VAN-EX2, log on to Outlook Web App as Anna and send a message to Info@Internet.com.
X Task 2: Implement user-based message tracking to verify mail delivery

Connect to the Exchange Control Panel as Anna, and use the Delivery Reports page to track the
message she sent. Search for messages sent to Info@Internet.com.
X Task 3: Troubleshoot Internet message delivery

1. On VAN-EX1, in Exchange Management Shell, verify that the shell is focused on
c:\Program Files\Microsoft\Exchange Server\v14\scripts, and run
d:\10135\labfiles\Lab05Prep2.ps1.
2. On VAN-EX2, send a second message from Anna to Info@Internet.com.
3. On VAN-EX1, in the Exchange Management Console, in the Toolbox node, access Message
Tracking.
4. Log on to Exchange Control Panel as Administrator, and track the message that Anna sent. Verify
that the message state is pending.
5. Use Mail Flow Troubleshooter to troubleshoot mail problems. When starting the Mail Flow
Troubleshooter, choose the option to troubleshoot the Messages are backing up in on one or more
queues on a server. Choose VAN-EX1 as the Exchange Server. Review the information on each wizard
page, and identify the proposed root cause for the issue.
6. On VAN-DC1, use nslookup to try to locate the MX records for internet.com.
7. Configure a smart host in your Send connector.
8. Verify that the messages are now delivered.
Results: After this exercise, you should have used tools like Mail Flow Troubleshooter, Queue Viewer,
Message Tracking, and nslookup to investigate why messages are not delivered to the Internet.

When you finish the lab, revert the virtual machines back to their initial state by completing the following
steps:
7. Wait for VAN-EX1 to start, and then start VAN-SVR1. Connect to the virtual machine.
Common Issues Related to Managing Message Transport

Identify the causes for the following common issues related to Managing Message Transport, and
You configure a Send Connector to the

Internet, but messages cannot be
transferred over it.
You want to understand over what hops

the message has been transferred.
Your Exchange Server does not accept

messages for the domain adatum-
info.com.
6-1
Module 6
Implementing Messaging Security
Contents:
Lesson 1: Deploying Edge Transport Servers 6-3
Lesson 2: Deploying an Antivirus Solution 6-18
Lab A: Configuring Edge Transport Servers and

Forefront Protection 2010 for Exchange Server 6-25
Lesson 3: Configuring an Anti-Spam Solution 6-29
Lesson 4: Configuring Secure SMTP Messaging 6-41

Lab B: Implementing Anti-Spam Solutions 6-52
6-2 Implementing Messaging Security
Module Overview
The Edge Transport server role is designed to be placed directly in a perimeter network, therefore directly
in the Internet. Placing a server directly in the Internet can be the cause of numerous security concerns.
This module describes how to plan for and deploy a Microsoft Exchange Server 2010 Edge Transport
server role, and the security issues related to the deployment.
This module describes how to configure secure Simple Mail Transfer Protocol (SMTP) messaging as well as
Domain Security, a feature available in Exchange Server 2007 and later versions. The Edge Transport role
provides powerful anti-spam functionalities, and some antivirus features. Because the Edge Transport role
does not include a virus scanner, you can integrate additional antivirus products such as Microsoft
Forefront Protection for Exchange Server.
Deploy Edge Transport servers.
Deploy an antivirus solution.
Configure an anti-spam solution.
Configure secure SMTP messaging.

Lesson 1
Deploying Edge Transport Servers
In any Exchange Server deployment, it is important that you do not expose too much information to the
Internet. You must ensure critical data such as email messages are protected from unauthorized access
from the Internet. The Edge Transport server role provides functionalities that secure this data from
unauthorized Internet access. If you are planning to place a server in your perimeter network, you should
plan to use an Edge Transport server.
This lesson describes features and functionalities of the Edge Transport server role, and explains how you
can configure data synchronization between Active Directory Domain Services (AD DS) and the Edge
Transport server.
Describe the Edge Transport server role.
Identify the infrastructure requirements for the Edge Transport server role.
Describe the functionality of Active Directory Lightweight Directory Services (AD LDS).
Configure Edge Transport servers.
Describe the purpose and functionality of Edge Synchronization.

Explain how Internet message flow works in Exchange Server 2010.
Describe the concept of cloned configuration.
Configure Edge synchronization.
Describe how to secure Edge Transport servers.

What Is the Edge Transport Server Role?
The Edge Transport server role in Exchange Server 2010 provides a secure SMTP gateway for all incoming
and outgoing email in an organization. As an SMTP gateway, the Edge Transport servers primary role is
to maintain message hygiene, which includes anti-spam and antivirus filtering. You also can use the Edge
Transport server to apply messaging policies to messages that are sent to the Internet.
Edge Transport Server Role Functionality

The Edge Transport server role provides the following functionalities.
Feature Description
Internet message delivery The Edge Transport server role accepts all email coming into the
Exchange Server 2010 organization from the Internet, and from servers
in external organizations. The Edge Transport server role routes all
accepted inbound messages to a Hub Transport server inside the
organization. It also routes all outbound messages to the Internet.
Antivirus and anti-spam The Exchange Server 2010 Edge Transport server role helps prevent
protection spam messages and viruses from reaching your organizations users by
using a collection of agents that provide different layers of spam
filtering and virus protection. It uses these agents to filter email
messages based on the source or destination recipients, source SMTP
server, attachments, and message contents.
Exchange Server 2010 does not include antivirus software. You must use
third-party software that integrates with Exchange Server 2010 to
provide antivirus protection.
(continued)
Feature Description
Edge transport rules Edge transport rules control the flow of messages that are sent to, or
received from the Internet. Edge transport rules apply actions to
messages that meet specified conditions. The Edge transport rule
conditions are based on data, such as specific words or text patterns in
the message subject, body, header, or From address, the spam
confidence level (SCL), or attachment type. Actions determine how the
message is processed when a specified condition is true. Possible actions
include quarantining a message, dropping or rejecting a message,
appending additional recipients, or logging an event.
Address rewriting Address rewriting enables SMTP address modification for any of your
organizations message senders or recipients. Address rewriting can be
useful in scenarios where an organization wants to hide internal
domains, to enable multiple organizations to appear as a single
organization, or to integrate services that a third-party provides to an
organization.
Edge Transport Servers Deployment Considerations

When planning to deploy Edge Transport servers, consider the following factors:
You cannot combine the Edge Transport server role with any other Exchange Server 2010 server role.
To provide increased security, you must install the Edge Transport server role on a separate computer,
which can be virtual or physical.
The computer should not be a member of an Active Directory domain.
If you allow Active Directory communications through the firewall that protects the internal network
from the perimeter network, it can cause security issues such as allowing an unauthorized user to
retrieve all your email addresses directly from the AD DS to use it for spam. Instead, the Edge
Transport server role uses AD LDS to store configuration and recipient information. The AD LDS does
not contain all the information from the AD DS, but synchronizes only the required information such
as email addresses.
Note You should not install the Edge Transport server role on a computer that is a
member of the internal Active Directory domain, but you can install it in a perimeter
network forest. Even if you install the Edge Transport server role on a member server, the
server still uses Active Directory Application Mode (ADAM) or AD LDS to store its
configuration and recipient information.
You should deploy the Edge Transport server role in a perimeter network to ensure network isolation
from both the internal network and the internal Exchange servers. You must configure the external
firewall on the perimeter network to allow inbound and outbound SMTP traffic to and from the Edge
Transport server role. The internal firewall must allow SMTP traffic between the Edge Transport server
role and one or more internal Hub Transport servers. The firewall also must allow outbound traffic
towards the perimeter network for Active Directory to AD LDS synchronization.
Infrastructure Requirements for the Edge Transport Server Role
The Edge Transport server role is different from any other Exchange Server 2010 server role, because you
can install it on servers running the Windows Server 2008 and the Windows Server 20008 R2 operating
systems that are not members of the internal Active Directory Domain Services (AD DS). This configuration
makes it much easier and more secure to deploy Edge Transport servers in a perimeter network. When
deploying Edge Transport servers, consider the following infrastructure requirements:
You can install Edge Transport servers either on standalone servers, or on servers that are members of
an extranet domain. The computer running the Edge Transport server role must have a fully qualified
domain name (FQDN) configured and must be able to resolve the FQDNs of the Hub Transport
servers as well as vice-versa.
You must deploy Edge Transport servers in a perimeter network. This configuration provides the
highest level of security.
The firewall configuration required for Edge Transport servers is greatly simplified, because the server
does not need to be an internal domain member. The following table describes the firewall
configuration requirements.
Firewall Firewall rule Explanation
External Allow port 25 from all external IP This rule enables SMTP hosts on the Internet
addresses to the Edge Transport to send email.
server.
External Allow port 25 to all external IP This rule enables the Edge Transport server
addresses from the Edge Transport to send email to SMTP hosts on the Internet.
server.
External Allow port 53 to all external IP This rule enables the Edge Transport server
addresses from the Edge Transport to resolve Domain Name System (DNS)
server. names on the Internet.
(continued)
Firewall Firewall rule Explanation
Internal Allow port 25 from the Edge This rule enables the Edge Transport server
Transport server to specified Hub to send inbound SMTP email to Hub
Transport servers. Transport servers.
Internal Allow port 25 from specified Hub This rule enables the Hub Transport servers
Transport servers to the Edge to send email to the Edge Transport server.
Transport server.
Internal Allow port 50636 for secure This rule enables the Hub Transport server
Lightweight Directory Access to replicate information to the Edge
Protocol (LDAP) from specified Hub Transport servers by using Edge
Transport servers to the Edge Synchronization. This port is not the default
Transport server. Secure LDAP port, but it is used specifically
for the Edge Synchronization process.
Internal Allow port 3389 for Remote This rule is used for optional remote
Desktop Protocol (RDP) from the desktop administration of the Edge
internal network to the Edge Transport server.
Transport server.
If the Edge Transport server directly routes email to the Internet, you must configure the server with
the IP addresses for Domain Name System (DNS) servers that can resolve DNS names on the Internet.
What Is AD LDS?
Edge Transport servers do not use the AD DS service to store their configuration information; instead, they
use AD LDS to store this data.
Note AD LDS runs only on Windows Server 2008 or Windows Server 2008 R2 computers,
while the ADAM service can run on Windows Server 2003 computers. AD LDS is an update
of ADAM.
What Is AD LDS?
AD LDS is a special mode of the AD DS that stores information for directory-enabled applications. AD LDS
is an LDAP-compatible directory service that runs on servers running the Windows Server 2008 or
Windows Server 2008 R2 operating system. AD LDS is designed to be a stand-alone directory service. It
does not require the deployment of DNS, domains, or domain controllers; instead, it stores and replicates
only application-related information.
How AD LDS Works with Exchange Server 2010 Edge Transport Servers
AD LDS stores configuration and recipient data for the Exchange Server 2010 Edge Transport server
role. Before you can install the Edge Transport server role, you must install the AD LDS server role on a
Windows Server 2008 or Windows Server 2008 R2 computer. AD LDS is then configured automatically
when you install the Edge Transport server role. The following types of information are stored in AD LDS:
Schema. AD LDS requires schema information that defines the types of objects and attributes that can
be created. The AD LDS version installed on an Edge Transport server contains a schema that defines
the Exchange Serverrelated information.
Configuration. The Configuration partition is similar to the Configuration partition in AD DS, and
provides a container to hold the Microsoft Exchange Services configuration information.
Recipient information. Recipient information can be synchronized from AD DS to AD LDS. Recipient

data that is synchronized from the Exchange Server organization is stored in the MSExchangeGateway
organizational unit (OU). Edge Transport servers use the recipient information when processing rules
such as recipient-filtering and transport rules.
Managing AD LDS
The AD LDS database is stored in the %programfiles%\Microsoft\Exchange Server\TransportRoles
\data\Adam directory. The primary database is adamntds.dit, which is similar to the databases that
Exchange Server uses for mailbox stores and mail queue databases.
In general, the AD LDS instance running on an Edge Transport server requires minimal administration. You
can make most changes to the AD LDS directory information by using Exchange Server 2010
management tools.
Note Before installing the Edge Transport server role, you must install AD LDS on the
computer. However, you do not need to perform any configuration steps in AD LDS before
installing the Edge Transport server role. In Exchange 2010 Service Pack 1 (SP1) or newer,
you can also use the SETUP.COM /InstallWindowsFeatures switch to add AD LDS
automatically to the computer.
Demonstration: How to Configure Edge Transport Servers
In this demonstration, you will review the Edge Transport server roles default configuration before
implementing Edge Synchronization.
Demonstration Steps
1. On VAN-EDG, open the Exchange Management Console.
2. Review the Edge Transport server roles default configuration settings including the default anti-spam
settings, Send and Receive Connectors and Accepted Domains.
What Is Edge Synchronization?
Edge synchronization is a process that replicates information from AD DS to AD LDS on Edge Transport
servers. Because Edge Transport servers are not joined to the internal Active Directory domain, they
cannot directly access the Exchange Server organization configuration or recipient information that is
stored in AD DS. EdgeSync enables the shared information to be replicated from AD DS to AD LDS.
You can deploy Edge Transport servers without using EdgeSync. However, it is strongly recommended
that you deploy EdgeSync along with Edge Transport servers, because EdgeSync can decrease the effort
needed to administer the Edge Transport servers. The Active Directory contains much of the configuration
information required by the Edge Transport server. For example, if you configure accepted domains on
the Hub Transport servers, these accepted domains can be replicated automatically to the Edge Transport
servers.
To enable any filtering or transport rules that are based on recipients, you must implement EdgeSync to
replicate the recipient information to AD LDS.
Information Replicated by Edge Synchronization

After you enable Edge Synchronization, the Edge Synchronization process establishes connections
between a Hub Transport server and the Edge Transport server, and synchronizes configuration and
recipient information between AD DS and AD LDS.
In Exchange Server 2007, EdgeSync replicates all of the configuration and recipient information in its
entirety. This takes a long time, particularly in organizations with a large number of recipients. Exchange
Server 2010 introduces incremental updates for EdgeSync. After the initial synchronization, only changes
to the objects in AD DS, such as the change in an email address, are synchronized to the Edge Transport
server.
Note The internal Hub Transport servers, and not the Edge Transport servers, always
initiate EdgeSync replication. EdgeSync replication traffic is always encrypted by using
Secure LDAP.
During synchronization, EdgeSync replicates the following data from AD DS to AD LDS:
Accepted domains
Recipients (hashed)
Safe senders (hashed)
Send connectors
Hub Transport server list (for dynamic connector generation)
Note The recipient and the safe senders are hashed by using a one-way hash, which
prevents an attacker from retrieving recipient information from the Edge Transport server.
Question: Can you deploy Edge Transport servers without using EdgeSync?
How Internet Message Flow Works
The primary function of the Edge Transport server is to secure both inbound and outbound Internet
email. After you configure an Edge subscription between your organizations Hub Transport servers and
the Edge Transport servers in the perimeter network, both inbound and outbound Internet email is
enabled.
Default SMTP Connectors

When you install the first Hub Transport server in an Exchange Server 2010 organization, two SMTP
Receive connectors are created. When you install an Edge Transport server, just an SMTP Receive
connector is created. When you enable Edge Subscription, two additional SMTP Send connectors are
created. The following table lists all of these connectors.
Connector name Connector type Description
Client SMTP Receive connector Created on each Hub Transport server

<SERVERNAME> Accepts connections from all remote IP addresses
on port 587 for message relay
Does not accept anonymous connections
Default SMTP Receive connector Created on each Hub Transport server

<SERVERNAME> Accepts connections from all remote IP addresses
on port 25
Does not accept anonymous connections
Default internal SMTP Receive connector Created on each Edge Transport server
receive connector Accepts connections from all remote IP addresses
<SERVERNAME> on port 25
Accepts anonymous connections
(continued)
Connector name Connector type Description
EdgeSync - SMTP Send connector Created on the Edge Transport server by Edge
Inbound to Subscription
<sitename> Created in AD DS, and then replicated to the Edge
Transport server by Edge Synchronization
Settings such as smart hosts and address space are
defined by the Edge Subscription
EdgeSync SMTP Send connector Created on the site that is defined by Edge Subscription
<sitename> to Created in AD DS, and then replicated to the Edge
Internet Transport server by Edge Synchronization
Source server is the Edge Transport server on which
Edge Subscription is enabled
Address space of *
Uses DNS to locate SMTP servers on the Internet
Default Message Transfer

After you enable EdgeSync, email flows through the Exchange server organization using the following
steps:
1. A user submits a message through a Client Access server to the Mailbox server. The Hub Transport
server retrieves the message from the Mailbox server, and categorizes it for delivery. In this scenario,
the message recipient is outside the organization.
2. The Hub Transport server determines that it must use the EdgeSync sitename to Internet Send
connector to send email to the Internet. It locates the Edge Transport server that is configured as the
bridgehead server for the connector.
3. The Hub Transport server forwards the message to the Edge Transport server, which sends the email
message to the Internet by using the EdgeSync sitename to Internet Send Connector.
4. For inbound messages, the sending SMTP connector connects to the Edge Transport server. The Edge
Transport server accepts this connection using the Default internal receive connector SERVERNAME,
which is configured to accept anonymous connections on port 25 from all IP addresses. The Edge
Transport server applies all virus and spam-filtering rules.
5. If the message is accepted, the Edge Transport server uses the EdgeSync Inbound to sitename
connector to forward the message to a Hub Transport server configured to accept Internet messages.
6. The Hub Transport server uses the Default SERVERNAME connector to receive the message, and then
forwards the message to the appropriate Mailbox server.
Note You can modify the default message flow by creating additional SMTP connectors.
For example, you may need to create a new SMTP send connector to send email to a
specific destination domain. You can do this by creating a new send connector, and then
configuring the destination domain name as the address space for the connector. Finally,
configure the connector to support the unique message-routing requirements for messages
sent to the domain.
Demonstration: How to Configure Edge Synchronization
In this demonstration, you will see how to enable Edge synchronization and test its functionality.
Demonstration Steps
1. On VAN-EDG, in the Exchange Management Shell, run the New-EdgeSubscription -FileName
c:\van-edge.xml command on the Edge Transport server.
2. Import the Edge subscription file by using the Exchange Management Console on the Hub Transport
server.
3. Use Start-EdgeSynchronization and Test-EdgeSynchronization -FullCompareMode to test Edge

synchronization.
4. Review the changes made to the Edge Transport server after Edge Synchronization.
What Is Cloned Configuration?
Cloned configuration is the process of configuring multiple Edge Transport servers with identical
configurations. To achieve high availability for messaging transport, you should ensure that multiple Edge
Transport servers are available at all times.
You can use cloned configuration to ensure that all Edge Transport servers have the same configuration.
You only configure one server, and export the configuration to an XML file that is then imported to the
target servers. Additionally, you can use the cloned configuration to restore the Edge Transport server
configuration quickly during a disaster recovery scenario.
The XML file includes the following configuration information:
Transport server file paths and all log files paths (such as the message tracking log path)
Transport agents, including status and priority
All Send and Receive connectorrelated settings (including Send connector passwords encrypted with
a default encryption key)
Accepted Domain information
Anti-spam features and configuration settings
Note Although AD LDS supports directory replication, Exchange Server 2010 does not
provide an option to use directory replication for configuring multiple Edge Transport
servers. You must use cloned configuration if you want to automate this process, and you
must repeat the edge-cloning steps each time you make a configuration change on one of
the servers.
Configuring Cloned Configuration

To configure cloned configuration, use the ExportEdgeConfig.ps1 and ImportEdgeConfig.ps1 scripts to
export configuration information from one Edge Transport server to an identically configured Edge
Transport server. You can also use the tool to test configuration changes and offer rollback assistance, or
to assist in disaster recovery when you deploy a new Edge Transport server, or replace a failed server.
To configure cloned configuration, you must perform the following three steps:
1. During the export configuration phase, export the configuration information from an existing Edge
Transport server into an XML file. Use the ExportEdgeConfig.ps1 script to export the information.
2. Validate the configuration on the target server. In this step, you run the ImportEdgeConfig.ps1
script. This script checks the existing information in the intermediate XML file to verify whether the
exported settings are valid for the target server, and then it creates an answer file. The answer file
specifies the server-specific information to be used during the next step when you import the
configuration on the target server. The answer file contains entries for each source server setting that
is not valid for the target server. You need to modify these settings so that they are valid for the
target server. If all settings are valid, the answer file contains no entries. Only then you can import it.
3. During the import-configuration phase, use the ImportEdgeConfig.ps1 script with the IsImport
$true parameter to import the information from both the intermediate XML file and the answer file,
into a new Edge Transport server.
The ExportEdgeConfig.ps1 and ImportEdgeConfig.ps1 files are Windows PowerShell command-line

interface scripts, and not individual cmdlets. The scripts are located in the %programfiles%\Microsoft
\Exchange\v14\Scripts folder on all servers running Exchange Server 2010.
Cloning Transport Rules

Cloned configuration does not clone any transport rule from an Edge Transport server. To ensure that all
transport rules are also cloned, use the following cmdlet to export all transport rules.
$file = Export-TransportRuleCollection
Set-Content Path c:\tmp\EdgeRuleCollection.xml Value $file.FileData Encoding Byte
On the target Edge Transport server, you then need to use the following command to import the
transport rules.
[Byte[]]$Data = Get-Content -Path "C:\tmp\EdgeRuleCollection.xml"

-Encoding Byte -ReadCount 0
Import-TransportRuleCollection -FileData $Data
Question: When using cloned configuration with your Edge Transport servers, what extra
fact should you consider?
Lesson 2
Deploying an Antivirus Solution
Although Exchange Server 2010 includes some basic antivirus features, it is important to implement a
separate antivirus product such as Microsoft Forefront Protection 2010 for Exchange Server. This lesson
describes the importance of protecting your Exchange Server organization from virus attacks, and also
describes the Forefront features Security.
Describe antivirus solution features.
Describe the Forefront Protection 2010 for Exchange Server features.
Explain the Forefront Protection 2010 deployment options.
Explain the best practices for deploying an antivirus solution.
Install and configure Forefront Protection 2010 for Exchange Server.

Antivirus Solution Features in Exchange Server 2010
Email is one of the most common ways to spread viruses from one organization to another. One of the
primary tasks in protecting your Exchange Server organization is to ensure that all messages containing
viruses are stopped at the messaging environments perimeter.
Exchange Server 2010 includes the following virus protection features:
Continuing support of the Virus Scanning application programming interface (VSAPI). In Exchange
Server 2010, Microsoft maintains support for the same VSAPI used in Exchange Server 2003 and
Transport agents that filter and scan messages. Exchange Server 2010 introduces the concept of
transport agentssuch as the attachment filtering agentto reduce spam and viruses. By enabling
attachment filtering on the Edge Transport or Hub Transport servers, you can reduce the spread of
malware attachments before they enter the organization. Additionally, third-party vendors can create
transport agents that specifically scan for viruses. Because all messages must pass through a Hub
Transport server, this is an efficient and effective means to scan all messages in transit.
Antivirus stamping. Antivirus stamping reduces how often a message is scanned as it proceeds
through an organization. It does this by stamping scanned messages with the version of the antivirus
software that performed the scan and the scan results. This antivirus stamp travels with the message
as it is routed through the organization, and determines whether additional virus scanning must be
performed on a message.
Integration with Forefront Protection 2010 for Exchange Server. Forefront Protection 2010 for
Exchange Server is an antivirus solution from Microsoft that integrates with Exchange Server 2010 to
provide advanced protection, optimized performance, and centralized management. This helps
customers deploy and maintain a secure messaging environment. Forefront Protection 2010 for
Exchange Server provides:
Advanced protection against viruses, worms, phishing, and other threats by using up to five
antivirus engines simultaneously at each layer of the messaging infrastructure.
Optimized performance through coordinated scanning across Edge Transport servers, Hub
Transport servers, and Mailbox servers and features, such as in-memory scanning, multithreaded
scanning processes, and performance bias settings.
Centralized management of remote installation, engine and signature updating, and reporting
and alerts through the Forefront Online Server Security Management Console.
What Is Forefront Protection 2010 for Exchange Server?
Forefront Protection 2010 for Exchange Server is a separate antivirus software package that you can
integrate with Exchange Server 2010 to provide antivirus protection for the Exchange environment.
The following table lists the benefits of implementing Forefront Protection 2010 for Exchange Server.
Service Description
Antivirus scan with multiple You can automatically scan messages using multiple virus pattern
engines engines, not just a single one.
Full support for VSAPI Forefront Protection 2010 for Exchange Server fully supports the
Exchange VSAPI.
Microsoft IP Reputation Service Provides sender reputation information about IP addresses that are
known to send spam. This is an IP-block list offered exclusively to
Exchange Server.
Spam Signature updates Identifies the most recent spam campaigns. The signature updates are
available on a need basis, up to several times a day.
Premium spam protection Includes automated updates for this filter, available on an as-needed
basis, up to several times a day.
Automated content filtering Automated content filtering updates for Microsoft SmartScreen
updates spam heuristics, phishing Web sites, and other Intelligent Message
Filter (IMF) updates.
Deployment Options for Forefront Protection 2010
When you implement Forefront Protection 2010 for Exchange Server, you must consider the various
deployment options.
Install Forefront Protection 2010

First, you need to determine the servers on which you plan to install Forefront Protection 2010. The
number of servers you install Forefront Protection 2010 on will also depend on financial considerations as
you will need to buy as many server licenses.
As a baseline, you should at least deploy Forefront Protection 2010 for Exchange Server on all Edge
and Hub Transport servers.
For full protection, you should deploy Forefront Protection 2010 for Exchange Server on all Edge
Transport, Hub Transport, and Mailbox servers.
You do not need to install Forefront Protection 2010 on the Client Access server role, because Forefront is
only needed on the Mailbox, Edge or Hub Transport server roles.
As previously mentioned, Forefront Protection 2010 for Exchange scans each email only once, and then
stamps it with a special antivirus stamp so that other servers do not scan that message again. This also
means that you do not need to scan the Mailbox servers, as any message that comes in or leaves the
system is eventually scanned by Forefront Protection 2010 when you install it on the Edge and Hub
Transport servers. However, it is up to your security team to decide on this matter.
Forefront Protection 2010 Scanning Considerations

After you decide the servers on which you want to deploy Forefront Protection 2010, you must consider
how many scan engines you should use to scan a message, and the types of scan engines that you should
use.
As a best practice, you should use five scanners as this provides an optimum combination with third-party
virus scanners. You can also change the selection of the virus scanners later.
Question: What is an antivirus stamp?

Best Practices for Deploying an Antivirus Solution
Although implementing an antivirus solution in Exchange Server is straightforward, there are some factors
that you should keep in mind when choosing and configuring an antivirus solution.
Implementing Multiple Antivirus Layers

To provide enhanced security against viruses, you should implement multiple layers of antivirus
protection. A virus can enter your organization from the Internet through an email, or from a non-
protected client within your company. Thus, it is a best practice to implement several layers of antivirus
protection such as a firewall, Edge Transport server, and at the client-computer level.
Maintaining Regular Antivirus Updates

Installing the antivirus product does not automatically mean that your organization is fully protected.
Regular antivirus pattern updates are critical to a well-implemented antivirus solution. You should also
monitor your antivirus patterns frequently to ensure they are up-to-date.
If you have a Microsoft System Center Operations Manager 2007 environment in your organization, you
can also use the Forefront Server Security Management Pack to monitor Forefront Protection 2010.
Demonstration: How to Install and Configure Forefront Protection 2010

for Exchange Server
In this demonstration, you will see how to install and configure Forefront Protection 2010 for Exchange
Server, and how to manage Forefront Protection 2010.
Demonstration Steps
1. Install Forefront Protection 2010 for Exchange Server.
2. Open the Forefront Protection 2010 Administration Console.
3. Configure the Antimalware - Edge Transport settings.
4. Configure the Antispam - Content Filter settings.

5. Configure global settings.
6. Review the monitoring options available in Forefront.

Lab A: Configuring Edge Transport Servers and Forefront

Protection 2010 for Exchange Server
Lab Setup
2. Ensure that the 10135B-VAN-DC1, 10135B-VAN-EX1, and the 10135B-VAN-SVR1 virtual machines are
running:
10135B-VAN-SVR1: Standalone server
3. If required, connect to the virtual machines. Log on to VAN-DC1 and VAN-EX1 as

4. Log on to VAN-SVR1 as Administrator, using the password Pa$$w0rd.
5. On the host computer, in Hyper-V Manager, click VANSVR1, and in the Actions pane, click Settings.
6. Click DVD Drive, click Image file, and then click Browse.
7. Browse to C:\Program Files\Microsoft Learning\10135\Drives, click EXCHANGE2010SP2.ISO, and

then click Open.
8. Click OK.
9. On VAN-SVR1, dismiss the Autoplay dialog box.

Lab Scenario
You are a messaging administrator in A. Datum Corporation, which is a large multinational organization.
Your organization has deployed Exchange Server 2010 internally, and now must extend it so that
everyone within the corporation can send and receive Internet email.
As part of your job responsibilities, you need to set up an Edge Transport server, and then install an
antivirus solution to scan all mail.
Exercise 1: Configuring Edge Transport Servers

Scenario
Your organization has internally deployed Exchange Server 2010, and now wants to use the Edge
Transport server role to replace an existing smart host. You need to deploy the Edge Transport server role,
and verify that Internet message flow is working.
1. Install the Edge Transport Server role.
2. Configure Edge Synchronization.
3. Verify that EdgeSync is working and that Active Directory Lightweight Directory Services contains
data.
4. Verify that Internet message delivery works.
X Task 1: Install the Edge Transport Server role

1. On VAN-SVR1, install the Edge Transport Server role by using the command d:\Setup /mode:install
/role:EdgeTransport in Command Prompt.
2. Restart VAN-SRV1, logon as Administrator, using the password Pa$$w0rd, and then open Exchange
Management Console.
X Task 2: Configure Edge Synchronization

1. Create a new Edge Subscription on the Edge Transport server by using the New-EdgeSubscription -
FileName c:\VAN-SVR1.xml cmdlet.
2. Copy the xml file to C:\ on VAN-EX1.

3. On VAN-EX1, in the Exchange Management Console, add the edge subscription to the Hub Transport
server by using the following configuration:
Active Directory Site: Default-First-Site-Name
Subscription file: c:\van-svr1.xml
Automatically create a Send connector for this Edge Subscription: checked

X Task 3: Verify that EdgeSync is working and that Active Directory Lightweight
Directory Services contains data
1. On VAN-EX1, use the Start-EdgeSynchronization cmdlet to force an immediate Edge
Synchronization.
2. Use the Test-EdgeSynchronization -FullCompareMode cmdlet to test Edge Synchronization.
3. Run the Get-User -Identity Wei | ft Name, GUID cmdlet to obtain the globally unique identifier
(GUID) for Wei Yu.
4. On VAN-SVR1, open LDP, and then connect to VAN-SVR1 using port 50389.
5. Open the CN=Recipients,OU=MSExchangeGateway container and verify that Wei Yus GUID is
listed.

1. On VAN-EX1, use Exchange Management Console to configure EdgeSync - Default-First-Site-
Name to Internet Send Connector to use 10.10. 0.10 as a smart host for email delivery.
2. Log on to Microsoft Outlook Web App as Adatum\Wei, and send a test message to the Internet to
verify it is working. If you do not receive a non-delivery report, the message has been sent outside the
organization.
Results: After this exercise, you should have installed an Edge Transport server role, and configured Edge
Synchronization between a Hub Transport and an Edge Transport server.
Exercise 2: Configuring Forefront Protection 2010 for Exchange Server

Scenario
Virus prevention is critical to your organizations security. As the messaging administrator, you are
required to install virus scanning software to scan every message and automatically remove viruses. To
implement this functionality, you must install antivirus software and configure it accordingly.
1. Install Forefront Protection 2010 for Exchange Server.
2. Configure Forefront Protection 2010 for Exchange Server.
3. Verify antivirus functionality.
X Task 1: Install Forefront Protection 2010 for Exchange Server

1. On host computer, attach the c:\Program Files\Microsoft Learning\10135\Drives
\ForeFrontInstall.iso file to the 10135B-VAN-SVR1 virtual machine. Close the Autoplay dialog box.
2. On VAN-SVR1, install Forefront Protection 2010 for Exchange Server. Accept all defaults, except
choose to enable anti-spam later.
X Task 2: Configure Forefront Protection 2010 for Exchange Server

1. Open the Microsoft Forefront Server Security Administration Console.
2. Configure the following antimalware settings:
Scan messages with all engines.
Delete messages with viruses.
3. On the Policy Management pane, expand Global Settings, and then click Advanced Options.
4. Configure the following global settings:
Increase the value of Maximum nested depth compressed files to 10 and Maximum nested
attachments to 50.
Configure the Intelligent Engine management as manual.
Change the update schedule for Norman Virus Control to update at 00:30 every day.
Results: After this exercise, you should have installed Forefront Protection 2010 for Exchange Server and
configured it.

Do not shut down the virtual machines and do not revert them to their initial state when you finish
this lab. The virtual machines are required to complete this modules last lab.
Lesson 3
Deploying an Anti-Spam Solution
Spam messages can adversely impact the messaging environment of an organization. Therefore,
implementing an anti-spam solution is a critical component of maintaining your organizations messaging
environment hygiene. Exchange Server 2010 includes several features that you can use to implement anti-
spam protection in your organization.
This lesson provides an overview of the options available for anti-spam filtering, and describes how you
can configure your Edge Transport servers to reduce spam in your organization.
Describe the spam-filtering features available in Exchange Server 2010.

Explain how Exchange Server 2010 applies spam filters.
Describe the concept of Sender ID filtering.
Describe the concept of Sender Reputation filtering.
Describe the concept of content filtering.
Configure anti-spam options.

Overview of Spam-Filtering Features
The spam-filtering functionality available on the Edge Transport server has a primary advantage when you
install it to route all email to and from the Internet. You can implement this anti-spam functionality by
using a series of Edge Transport server transport agents.
Note Forefront Protection 2010 for Exchange Server does provide more frequent updates
for the anti-spam patterns than Exchange Server 2010 built-in anti-spam features. Typically,
the built-in anti-spam pattern is updated daily, whereas in Forefront Protection 2010, you
can configure the updates to update multiple times a day.
Edge Transport Server Anti-Spam Agents

The following table lists the anti-spam agents implemented during the default installation of an Edge
Transport server.
Agent Default status Description
Connection Enabled Filters messages based on the IP address of the remote server
Filtering that is trying to send the message. Connection filtering uses IP
Block lists and IP Allow lists.
Content Enabled Filters messages based on the message contents. This agent
Filtering uses SmartScreen technology to assess the message contents. It
also supports safelist aggregation.
Sender ID Enabled Filters messages by verifying the IP address of the sending

SMTP server against the purported owner of the sending
domain.
Sender Enabled Filters messages based on the sender in the MAIL FROM: SMTP
Filtering header in the message.
(continued)
Agent Default status Description
Recipient Enabled Filters messages based on the recipients in the RCPT TO: SMTP
Filtering header in the message.
Sender Enabled Filters messages based on many characteristics of the sender

Reputation accumulated over a specific period.
Filtering
Attachment Enabled Filters messages based on attachment file name, file name
Filter extension, or file Multipurpose Internet Mail Extensions (MIME)
content type.
Note You can view all the agents installed on the Edge Transport server by using the Get-
TransportAgent cmdlet on the Edge Transport server. The default Edge Transport server
installation also includes other transport agents, such as the Address Rewriting Inbound
Agent, the Address Rewriting Outbound Agent, and the Edge Rule Agent. You cannot use
these agents for spam filtering.
Safelist Aggregation
In Exchange Server 2010, the Content Filter agent on the Edge Transport server uses the Microsoft Office
Outlook Safe Senders Lists, Safe Recipients Lists, and trusted contacts to optimize spam filtering. Safelist
aggregation is a set of anti-spam functionality that Outlook and Exchange Server 2010 share. This anti-
spam functionality collects data from the anti-spam safe lists that Outlook users configure, and makes this
data available to the anti-spam agents on the Edge Transport server. You must use the Update-Safelist
cmdlet to configure safelist aggregation.
How Exchange Server 2010 Applies Spam Filters
The Edge Transport server role in Exchange Server 2010 uses spam-filtering agents to examine each SMTP
connection and the messages sent through it. When an SMTP server on the Internet connects to the Edge
Transport server and initiates an SMTP session, the Edge Transport server examines each message by
using the following sequence:
1. When the SMTP session is initiated, the Edge Transport server applies connection filtering by using
the following criteria:
Connection filtering examines the administrator-defined IP Allow list. Administrators might
include the IP addresses for SMTP servers at partner organizations in the IP Allow list. If an IP
address is on the administrator-defined IP Allow list, the server does not apply any other filtering
and accepts the message.
Connection filtering examines the local IP Block list. Administrators might include the IP
addresses for the SMTP servers of known spam writers, or other servers from which the
organization does not want to receive email, in the IP Block list. If the connection filtering agent
finds the IP address of the sending server on the local IP Block list, the server rejects the message
automatically, and other filters are not applied.
Connection filtering examines the real-time block list (RBL) of any IP Block List Providers that you
have configured. If the agent finds the sending servers IP address on an RBL, the server rejects
the message, and other filters are not applied.
2. The Edge Transport server compares the senders email address with the list of senders configured in
sender filtering. If the SMTP address is a blocked recipient or domain, the server may reject the
connection, and no other filters are applied. Additionally, you can configure the server to accept the
message from the blocked sender, but stamp the message with the blocked sender information and
continue processing. The blocked sender information is included as one of the criteria when content
filtering processes the message.
3. The Edge Transport server examines the recipient against the Recipient Block list configured in
recipient filtering. If Edge Synchronization is enabled, the Edge Transport server can use the
information about recipient filtering from Active Directory. If the intended recipient matches a filtered
email address, the Edge Transport server rejects the message for that particular recipient. If multiple
recipients are listed on the message, and some are not on the Recipient Block list, further processing
is done on the message.
4. Exchange Server 2010 applies Sender ID filtering. Depending on how the Sender ID is configured, the
server might delete, reject, or accept the message. If the message is accepted, the server adds the
Sender ID validation failure to the message properties. The failed Sender ID status is included as one
of the criteria when content filtering processes the message.
5. The Edge Transport server applies content filtering and performs one of the following actions:
Content filtering compares the sender to the senders in the Safelist aggregation data from Office
Outlook users. If the sender is on the recipients Safe Senders List, the message is sent to the
users mailbox store. If the sender is not on the recipients Safe Senders List, the message is
assigned a spam confidence level (SCL) rating.
If the SCL rating is higher than one of the configured Edge Transport server thresholds, content
filtering takes the appropriate action of deleting, rejecting, or quarantining the message.
If the SCL rating is lower than one of the Edge Transport server thresholds, the message is passed
to a Hub Transport server for distribution to the Exchange Mailbox server containing the users
mailbox.
Note You can bypass spam filtering for a specific recipient by setting the
AntispamBypassEnabled property to True on the users mailbox. This causes the message
to bypass filtering and be delivered directly to the recipients mailbox.
What Is Sender ID Filtering?
The Sender ID Framework is an industry standard that verifies the Internet domain from which each
email message originates, based on the senders server IP address. The Sender ID Framework provides
protection against email domain spoofing and phishing schemes. By using the Sender ID Framework,
email senders can register all email servers that send email from their SMTP domain, and then email
recipients can filter email from that domain that does not come from the specified servers.
Sender Policy Framework (SPF) Records

To enable Sender ID filtering, each email sender must create a Sender Policy Framework (SPF) record and
add it to their domains DNS records. The SPF record is a single text (TXT) record in the DNS database that
identifies each domains email servers. SPF records can use several formats, including those in the
following examples:
Adatum.com. IN TXT v=spf1 mx -all. This record specifies that any server that has an MX record for
the Adatum.com domain can send email for the domain.
Mail IN TXT v=spf1 a -all. This record indicates that any host with an A record can send mail.
Adatum.com IN TXT v=spf1 ip4:10.10.0.20 all. This record indicates that a server with the IP
address 10.10.0.20 can send mail for the Adatum.com domain.
Note Microsoft provides the Sender ID Framework SPF Record Wizard to create your
organizations SPF records. You can access the wizard on the Sender ID Framework SPF
Record Wizard page on the Microsoft Web site.
Sender ID Configuration
After you configure the SPF records, any destination messaging servers that use the Sender ID features
can identify your server by using Sender ID.
After you enable Sender ID filtering, the following process shows how all email messages are filtered:
1. The sender transmits an email message to the recipient organization. The destination mail server
receives the email.
2. The destination server checks the domain that claims to have sent the message, and checks DNS for
that domains SPF record. The destination server determines if the IP address of the sending email
server matches any of the IP addresses that are in the SPF record. The IP address of the server
authorized to send email for that domain is called the purported responsible address (PRA).
3. If the IP addresses match, the destination server authenticates the message and delivers it to the
destination recipient. However, other anti-spam scanners such as content filtering are still applied.
4. If the addresses do not match, the mail fails authentication. Depending on the email server
configuration, the destination server might delete the message or forward it with additional
information added to its header indicating that it failed authentication.
What Is Sender Reputation Filtering?
The Exchange Server 2010 Sender Reputation feature makes message filtering decisions based on
information about recent email messages received from specific senders. The Sender Reputation agent
analyzes various statistics about the sender and the email message, to create a Sender Reputation Level
(SRL). This SRL is a number between 0 and 9, where a value of 0 indicates that there is less than a 1
percent chance that the sender is a spammer, and a value of 9 indicates that there is more than a 99
percent chance of it. If a sender appears to be the spam source, then the Sender Reputation agent
automatically adds the IP address for the SMTP server that is sending the message to the list of blocked
IP addresses.
How Sender Reputation Filtering Works

When the Edge Transport server receives the first message from a specific sender, the SMTP sender is
assigned an SRL of 0. As more messages arrive from the same source, the Sender Reputation agent
evaluates the messages and begins to adjust the senders rating. The Sender Reputation agent uses the
following criteria to evaluate each sender:
Sender open proxy test. An open proxy is a proxy server that accepts connection requests from any
SMTP server, and then forwards messages as if they originated from the local host. This also is known
as an open relay server. When the Sender Reputation agent calculates an SRL, it does so by
formatting an SMTP request in an attempt to connect back to the Edge Transport server from the
open proxy. If an SMTP request is received from the proxy, the Sender Reputation agent verifies that
the proxy is an open proxy and updates that senders open proxy test statistic.
HELO/EHLO analysis. The HELO and EHLO SMTP commands are intended to provide the receiving
server with the domain name, such as Contoso.com, or the IP address of the sending SMTP server.
Spammers frequently modify the HELO/EHLO statement to use an IP address that does not match the
IP address from which the connection originated, or to use a domain name that is different from the
actual originating domain name. If the same sender uses multiple domain names or IP addresses in
the HELO or EHLO commands, there is an increased chance that the sender is a spammer.
Reverse DNS lookup. The Sender Reputation agent also verifies that the originating IP address from
which the sender transmitted the message matches the registered domain name that the sender
submits in the HELO or EHLO SMTP command. The Sender Reputation agent performs a reverse DNS
query by submitting the originating IP address to DNS. If the domain names do not match, the sender
is more likely to be a spammer, and the overall SRL rating for the sender is adjusted upward.
SCL ratings analysis on a particular senders messages. When the Content Filter agent processes a
message, it assigns an SCL rating to the message. This rating is attached to the message as an SCL,
which is a numerical value between 0 and 9. The Sender Reputation agent analyzes data about each
senders SCL ratings, and uses it to calculate SRL ratings. More information on SCL ratings can be
found in the next topic, What is Content Filtering?.
The Sender Reputation agent calculates the SRL for each unique sender over a specific time. When the SRL
rating exceeds the configured limit, the IP address for the sending SMTP server is added to the IP Block
list for a specific time.
Sender Reputation Configuration

You can configure the Sender Reputation settings on the Edge Transport server. By using the Exchange
Management Console, you can configure the Sender Reputation block threshold, and configure the
timeout period for how long a sender will remain on the IP Block list. By default, the IP addresses are
blocked for 24 hours.
What Is Content Filtering?
The Content Filter agent uses SmartScreen technology to analyze the content of every email message, to
evaluate whether it is spam. The Content Filter agent is similar to the Exchange Server 2003 Intelligent
Message Filter feature.
When the Edge Transport server receives a message, the Content Filter agent evaluates the messages
content for recognizable patterns, and then assigns a rating based on the probability that the message is
spam. This rating is attached to the message as an SCL, which is a numerical value between 0 and 9. A
rating of 0 indicates that the message is highly unlikely to be spam, whereas a rating of 9 indicates that
the message is very likely to be spam. This rating persists with the message when it is sent to other servers
running Exchange Server.
Depending on how you configure the content filter, if a messages SCL score is greater than or equal to
the threshold you configure, then the Content Filter agent rejects, silently deletes, or quarantines the
message.
Content Filtering Configuration

Content filtering is enabled by default on Exchange Server 2010 Edge Transport servers, and is configured
to reject all messages with an SCL higher than 7. You can modify the default content filtering settings by
using the Exchange Management Console or the Exchange Management Shell. You can modify the
following settings in the Exchange Management Console:
Configure custom words. You can specify a list of key words or phrases to prevent blocking any
message containing those words. This feature is useful if your organization must receive email that
contains words that the Content Filter agent normally would block. You also can specify key words or
phrases that will cause the Content Filter agent to block a message containing those words.
Specify exceptions. You can configure exceptions to exclude any messages to recipients on the
exceptions list, from content filtering.
Specify actions. You can configure the SCL thresholds and threshold actions. You can configure the
Content Filter agent to delete, reject, or quarantine messages with an SCL higher than the value you
specify.
Note When the Content Filter agent rejects a message, it uses the default response of 550
5.7.1 Message rejected due to content restrictions. You can customize this message by
using the set-ContentFilterConfig cmdlet in the Exchange Management Shell.
Configuring the Quarantine Mailbox

When the SCL value for a specific message exceeds the SCL quarantine threshold, the Content Filter agent
sends the message to a quarantine mailbox. Before you can configure this option on the Edge Transport
server, you must configure a mailbox as the quarantine mailbox by configuring the quarantinemailbox
parameter of the set-contentfilterconfig cmdlet. As a messaging administrator, you should regularly
check the quarantine mailbox to ensure that the content filter is not filtering legitimate emails.
Note Messages are sent to the quarantine mailbox only when the SCL threshold
exceeds the value that you configured on the content filter. To see details on all actions that
transport agents perform on an Edge Server, use the scripts located in the %programfiles%
\Microsoft\Exchange Server\Scripts folder. The Get-AgentLog.ps1 script produces a raw
listing of all actions that transport agents perform. The folder contains several other scripts
that produce formatted reports listing information such as the top blocked sender domains,
the top blocked senders, and the top blocked recipients. By default, the transport agent
logs are located at %programfiles%\Microsoft\ExchangeServer\TransportRoles
\Logs\AgentLog.
The SCL Junk E-mail Folder Threshold

If the SCL value for a specific message exceeds the SCL Junk E-mail folder threshold, then the Mailbox
server places the message in the Outlook users Junk E-mail folder. If the SCL value for a message is lower
than the SCL delete, reject, quarantine, and Junk E-mail folder threshold values, then the Mailbox server
puts the message in the users Inbox.
Demonstration: How to Configure Anti-Spam Options
In this demonstration, you will see how to configure the various anti-spam options available in Exchange
Server 2010, such as Connection filters, Sender filters, and Recipient filters. You will also see how to
configure the Sender ID, Sender Reputation, and content filtering features.
Demonstration Steps
1. Open Exchange Management Console, and on the Edge Transport server, click the Anti-spam tab.
2. Configure the following Connection filters:

IP Allow List
IP Block List
IP Block List Providers
3. Add the zen.spamhaus.org domain to the IP Block List Providers list.
4. Configure the following filtering features:

Sender filtering
Recipient filtering
Sender ID
Sender Reputation
Content filtering
5. Configure the Edge Transport server to quarantine messages with a SCL rating greater than 7.
Lesson 4
Configuring Secure SMTP Messaging
To configure secure SMTP messaging, you can use Transport Layer Security (TLS) in Exchange server.
Additionally, you can configure Domain security, which is a new feature in Exchange Server 2007 and
Exchange Server 2010. This lesson describes how to secure SMTP messaging by using the available
options.
Describe the common SMTP security issues.
Describe the options for securing SMTP email.
Configure SMTP security.
Explain the concept of Domain Security.
Explain how Domain Security works.
Describe the Domain Security configuration process.

Configure Domain Security.
Explain how Secure MIME works.

Discussion: SMTP Security Issues
Although SMTP messaging is common in many organizations, there are a few security issues that you
must consider.
Question: What are the security issues with SMTP?

Question: How do you currently secure SMTP?
SMTP Email Security Options
Exchange Server 2010 offers several options to secure SMTP messaging traffic. All these options rely on
certificates to encrypt the traffic.
The following methods for securing SMTP require that you implement the option both on the source and
the target side. Since you most likely will not have access to the target side, the methods listed here have
limitations.
IPSec
IPSec provides a set of extensions to the basic IP protocol, and you can use it to encrypt server-to-
server communication. You can use IPSec to tunnel traffic, or peer- to-peer, to secure natively all IP
communications. Because IPSec operates on the transport layer and is network-based, applications
running on Exchange Server 2010 do not need to be aware of IPSec. You use IPSec normally to secure
server-to-server or client-to-server communication. You do not need another encryption method when
using IPSec.
VPN
Virtual private network (VPN) also operates on the transport layer, and very often uses IPSec as the
underlying protocol. VPN is used for site-to-site or client-to-site connections. Both operate on the
transport layer, which can be an advantage over application-layer protocols such as Secure MIME
(S/MIME) which does not require the application on both ends to know about the protocol.
TLS
The TLS protocol is the default protocol that is used in an Exchange Server 2010 organization to
encrypt server communication. It is a standard protocol that you can use to provide secure Web
communications on the Internet or intranet. TLS enables clients to authenticate servers, or optionally,
servers to authenticate clients. It also provides a secure channel by encrypting communications. TLS is
the latest version of the Secure Sockets Layer (SSL) protocol.
Exchange Server 2010s Domain Security feature uses TLS with mutual authenticationalso known as
mutual TLSto provide session-based authentication and encryption. Standard TLS is used to provide
confidentiality by encrypting but not authenticating the communication partners. This is typical of SSL,
which is the HTTP implementation of TLS.
S/MIME
S/MIME is a standard that you can use to implement public-key encryption, and email message
signatures. You can use encryption to protect message contents so that only the intended recipients can
read it. If a message is signed, the recipient can verify whether the message has been changed on the way
from the sender to the recipient.
S/MIME is a client-based encryption and signing protocol that provides end-to-end security, from the
sending mailbox to the receiving mailbox. Unlike other encryption protocols that are session-based on the
transport layer (such as TLS) the message also remains encrypted and signed within the mailbox. Even
administrators cannot decrypt it if their digital certificate does not allow them to do so. By implementing
S/MIME, you can perform the following tasks:
Use digital signatures as a way to prove to your communication partners that the content was not
altered.
Authenticate messages, especially for crucial functions, such as when your employer approves your
travel requests.
Encrypt messages to prevent accidental content disclosure.
By default, Exchange Server 2010 fully supports S/MIME for message encryption and signatures. Unlike in
previous versions, where you must configure every mailbox database, you do not need to configure any
server-side setting to support S/MIME.
Because S/MIME provides end-to-end security, it is important that the email application you use to read
and write S/MIME messages meets the following two requirements:
The application must support S/MIME encryption and signatures.
You must configure the digital signature in the email application.
Note When using S/MIME, you can send digitally signed messages to anyone, but you can
only encrypt messages to recipients whose certificates are available in the Global Address
List (GAL) or in contacts.
Alternate Options for Securing SMTP Traffic

Besides the mentioned options, you can also implement authentication and authorization on SMTP
connectors for security. This does not enforce traffic encryption, but can prevent unauthorized users
from sending SMTP messages to users in your organization, or relaying SMTP messages to the Internet.
Authentication and authorization can be configured based on user login, or on IP addresses or IP ranges.
Demonstration: How to Configure SMTP Security
In this demonstration, you will see how to configure an externally secured SMTP Connector and how to
configure an SMTP Connector that requires TLS and authentication.
Demonstration Steps
1. Use the Exchange Management Console to create a new Receive Connector.
2. Configure the Receive Connector to be externally secured.
3. Use Telnet to connect to Receive Connector.
4. Configure the Receive Connector to use TLS and authentication.
5. Use Telnet again to connect to Receive Connector.

What Is Domain Security?
Exchange Server 2010 can use TLS to provide security for SMTP email. In most cases, you cannot use
TLS when sending or receiving email because SMTP servers are not configured to use TLS. However, by
requiring TLS for all SMTP email sent between your organization and other specified organizations, you
can enable a high security level for SMTP email.
What Is Domain Security?

The Domain Security feature in Exchange Server 2010 provides a relatively low-cost alternative to
S/MIME or other message-encryption solutions. It uses mutual TLS, where each server verifies the identity
of the other server by validating the certificate that is provided by the other server. It is an easy way for
administrators to manage secured message paths between domains over the Internet. This means that all
connections between the partner organizations are authenticated, and all messages are encrypted while in
transit on the Internet.
TLS with mutual authentication differs from TLS in its usual implementation. Typically, when you
implement TLS, the client verifies a secure connection to the intended server by validating the servers
certificate, which it receives during TLS negotiation. With mutual TLS, each server verifies the connection
with the other server by validating a certificate that the other server provides.
How Domain Security Works
Domain Security works in a manner similar to establishing a TLS connection to an SMTP Receive
connector. However, as mutual TLS is used, both the sender and the receiver authenticate one another
before they send data. The message takes the following route from one organization to the other when
using Domain Security:
1. The Edge Transport server receives the email message from a source Hub Transport server.
2. The Edge Transport server initiates a mutual TLS session to the target Edge Transport server by
exchanging and verifying their certificates. This is only established when both the sending and
receiving SMTP connector can identify the sending domain. You must set the domain information on
the sending side by using the Set-TransportConfig -TLSSendDomainSecureList <domain name>
cmdlet. On the receiving side, use the: Set-TransportConfig -TLSReceiveDomainSecureList
<domain name> cmdlet to set the domain information.
3. The message is encrypted and transferred to the target Edge Transport server.
4. The Edge Transport server delivers the email to the target Hub Transport for local delivery. The
message is marked as Domain Secure, which will display in Outlook 2007 or newer, and in Outlook
Web App.
Process for Configuring Domain Security
To configure Domain Security, you need to perform the following process:

1. On the Edge Transport server, generate a certificate request for TLS certificates. You can request the
certificate from an internal, private certification authority (CA) or from a commercial CA. The SMTP
server in the partner organization must trust the certificate. When you request the certificate, ensure
that the certificate request includes the domain name for all internal SMTP domains in your
organization, as well as the FQDN of the Edge Server name as Subject Alternative Name (SAN).
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 then enable the certificate for use by
the SMTP connectors that are used to send and receive domain-secured email.
3. Configure outbound Domain Security. To configure outbound Domain Security, use Exchange
Management Shell cmdlets to specify the domains to which you will 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 cmdlets to specify the domains to which you will receive domain-secured email,
and then configure the SMTP Receive connector to use domain-secured email.
5. Notify partner to configure Domain Security. Domain Security must be configured on both sides (on
the sending and receiving side). Thus you also need to contact your partners administrator to
configure your domain for Domain Security.
6. Test message flow. Finally, send a message to the partner and vice-versa to verify that domain
security is working correctly. You can see an extra icon in Outlook and Outlook Web App.
Note When you install the Edge Transport server role, a self-signed certificate is issued to
the server. No others computers trust this certificate. When you require that the partner
organization trust the certificate, you should purchase a certificate from a commercial CA.
You also can make cross-forest trust, or import a CAs certificate in the Trusted Root CA
store on both sides, if you do not want to purchase a certificate from a commercial CA.
Demonstration: How to Configure Domain Security
In this demonstration, you will see how to configure Domain Security for the external domain
CONTOSO.COM. As Domain Security requires configuration on both sides, on the local and remote side,
this demonstration will only show your local configuration.
Demonstration Steps
1. Verify a computer certificate in the certificate store.
2. Enable Domain Security on the Receive connector.

3. Enable Domain Security on the Send connector.
4. Run Set-TransportConfig TLSSendDomainSecureList Contoso.com and Set-TransportConfig

TLSReceiveDomainSecureList Contoso.com to configure Domain Security partnership.
5. Run Start-EdgeSynchronization to synchronize the changes to the Edge Transport server.
How S/MIME Works
S/MIME is a messaging client-based solution for securing SMTP email. With S/MIME, each client computer
must have a certificate, and the user is responsible for signing or encrypting each email.
How S/MIME Secures Email

S/MIME provides email security by using the following options:
Digital signatures. When a user chooses to add a digital signature to a message, the senders private
key calculates and encrypts the messages hash value, and then appends the encrypted hash value to
the message as a digital signature. The users certificate and public key are sent to the recipient.
When the recipient receives the message, the senders public key decrypts the hash value and checks
it against the message. Digital signatures provide:
Authentication. If the public key can decrypt the hash value attached to the message, the
recipient knows that the person or organization who claims to have sent the message did indeed
send it.
Nonrepudiation. Only the private key associated with the public key could be used to encrypt the
hash value. Therefore, a message that is digitally signed helps to prevent its sender from
disowning the message.
Data integrity. If the hash value is still valid when the recipient receives it, any alteration of a
message that takes place will invalidate the digital signature.
Message encryption. When a user chooses to encrypt a message by using S/MIME, the messaging
client generates a one-time symmetric session key, and encrypts the entire message by using the
session key. The session key then is encrypted by using the recipients public key, and the encrypted
session key is combined with the encrypted message when the message is sent. When the message
arrives at the recipient, the recipients private key decrypts the message.
Message encryption enhances confidentiality. You can decrypt a message by using only the private
key associated with the public key that was used to encrypt it. Therefore, only the intended recipient
can view the contents.
When to Use S/MIME

S/MIME is a fairly complicated way to provide security for SMTP email because S/MIME:
Requires a client certificate on each computer that sends secure email. Distributing client certificates
for users that do not understand the technology takes significant administrative time.
Requires that a sender get access to the recipients public key before the sender can send an
encrypted email. Normally, this is accomplished by sending a digitally signed email.
Is a user-based security model. The user has to take the action to sign or encrypt the message. Users
may forget or not realize which email messages to secure.
Requires certificate backups. The certificates must be backed up, because if one is lost, the user will
not be able to decrypt messages that were encrypted with the public key associated with the
certificate.
Introduces another complication. Because the messages entering or leaving the organization are
encrypted, and the messages remain encrypted in the user mailbox, the messages cannot be scanned
for policy compliance, viruses, or spam.
Despite these issues, S/MIME remains the best option for securing individual email messages. To set up a
secure channel, all other solutions require some level of agreement between messaging administrators in
the two organizations. If users need to send secure email to recipients in many different organizations,
S/MIME is the most feasible option.
Lab B: Implementing Anti-Spam Solutions
Lab Setup
running.
Lab Scenario
You are a messaging administrator in A. Datum Corporation, which is a large multinational organization.
After configuring the Edge Transport server and installing an antivirus solution, you must implement an
anti-spam solution.
Exercise 1: Configuring an Anti-Spam Solution on Edge Transport Servers

Scenario
In your organization, users complain that they receive too many spam messages in their inbox, and they
want these spam messages automatically moved to the Junk email folder. To limit the number of spam
messages received by your organization, you need to increase the SCL junk threshold value for the
organization and ensure that junk email above a certain rating is rejected. You also want to configure a
Block List Provider.
1. Configure Domain Name System (DNS) for Internet message delivery.
2. Configure global SCL for junk mail delivery.
3. Configure content filtering to reject junk messages.
4. Configure an IP Allow List.
5. Configure a Block List Provider.
X Task 1: Configure Domain Name System (DNS) for Internet message delivery
1. On VAN-DC1, start DNS Manager.
2. In the Adatum.com zone, create an MX record for VAN-SVR1.adatum.com.
X Task 2: Configure global SCL for junk mail delivery

1. On VAN-SVR1, configure the content filtering settings to not reject any messages based on
SCL values.
2. On VAN-EX1, in Exchange Management Shell, use the Set-OrganizationConfig -SCLJunkThreshold 6

cmdlet to configure the global SCL levels.
3. On VAN-EX1, in the Exchange Management Shell, run d:\labfiles\Lab6Prep.ps1. This script will send
11 messages from VAN-SVR1 with the following SCL ratings.
Mail Sender SCL Level
Msg1@contoso.com 7
Msg2@contoso.com 8
Msg3@contoso.com 7
Msg4@contoso.com 7
Msg5@contoso.com 8
Msg6@contoso.com 6
Msg7@contoso.com 8
Msg8@contoso.com 7
Msg9@contoso.com 6
Msg10@contoso.com 6
Msg11@contoso.com 8
4. Log on to Outlook Web App as Wei and verify that three messages were sent to the user mailbox,
and that eight messages were sent to the Junk E-mail folder.
5. View the message details for one of the messages to verify the SCL value assigned to the message.
X Task 3: Configure content filtering to reject junk messages

1. On VAN-SVR1, configure content filtering to reject messages that have a SCL rating greater than or
equal to 7.
2. On VAN-EX1, run the D:\labfiles\Lab6Prep.ps1 script to send the test messages again.
3. Log on to Outlook Web App on VAN-EX1 as Wei. Verify that three messages are delivered to the
Inbox and no messages are delivered to the - folder in Weis mailbox. Delete the messages in the
Inbox.
X Task 4: Configure an IP Allow List

1. On VAN-SVR1, configure the IP Allow List to accept connections from 10.10.0.10.
2. Run the script to send the test messages again.
3. Verify that all messages are delivered to the Inbox in Weis mailbox. The SCL rating should be -1.
X Task 5: Configure a Block List Provider

Configure an IP Block List Provider named Spamhaus that uses zen.spamhaus.org as the lookup
domain.
Results: After this exercise, you should have configured different SCL levels, and verified the behavior of
junk mail in user mailboxes. You should also have configured a Block List Provider.

following steps:

Review Questions
1. Is Edge Synchronization a mandatory requirement?
2. Which Exchange Server versions support the Domain Security feature?

3. Does the Edge Transport server role in Exchange Server 2010 include virus-scanning capabilities?
Common Issues Related to Edge Synchronization and Domain Security

Identify the causes for the following common issues related to implementing messaging security. For
answers, refer to relevant lessons in the module.
You configured Domain Security with

a partner domain, but messages only
use TLS for message encryption, not
mutual TLS or Domain Security.
Edge Synchronization is not working

anymore.
Youre logged on to your Windows

Server 2008 machine using your own
account. When you run Test-
EdgeSynchronization, it shows that
the connection is broken.
7-1
Module 7
Implementing High Availability
Contents:
Lesson 1: Overview of High Availability Options 7-3
Lesson 2: Configuring Highly Available Mailbox Databases 7-6
Lesson 3: Deploying Highly Available Non-Mailbox Servers 7-26

Lesson 4: Deploying High Availability with Site Resilience 7-33
Lab: Implementing High Availability 7-43

7-2 Implementing High Availability
Module Overview
Many people rely on messaging environments so that they can perform critical business tasks, and it is
extremely important for your messaging solution to be available for an extended time. Thus, many
organizations place strict availability requirements on email and other critical applications.
For a messaging system to be a truly high availability solution, not only are technology and configuration
crucial, but also the processes and procedures that you use to maintain the messaging system. This
module describes the high availability technology built into Microsoft Exchange Server 2010 and some
of the outside factors that affect highly available solutions.

Describe high availability options.
Configure highly available mailbox databases.
Deploy highly available non-Mailbox servers.
Lesson 1
Overview of High Availability Options
High availability is a commonly used term that refers to a specific technology or configuration that
promotes service availability. Although many technologies and configurations can lead to highly available
configurations, they are not by themselves truly highly available. Much more effort is required to provide
a high availability solution.
In this lesson, you will review high availability, and some of the factors that go into designing and
deploying a highly available solution.
Describe high availability.

Identify the components of a high availability solution.
What Is High Availability?
High availability is a system design implementation that ensures a high level of operational continuity
over a specific time. Although many people attribute high availability to a specific technology, such as
failover clustering or load balancing, you can truly achieve high availability only with good design, testing,
training, and operational processes.
There are two types of downtime: planned and unplanned. Planned downtime is the result of events you
schedule, such as maintenance. By contrast, unplanned downtime is the result of events not within direct
control of information technology (IT) administrators. These events can be minor, such as a buggy
hardware driver or a processor that fails, or catastrophic, such as flood, fire, or earthquake.
Measuring Availability
Availability often is expressed as the percentage of time that a service is available for use. For example, a
requirement for 99.9 percent availability over a one-year period allows 8.75 hours of downtime. In
complex environments, organizations typically specify availability for a specific service, such as Exchange
messaging, which in turn may have availability goals tied to specific features such as Microsoft Outlook
Web App, Simple Mail Transfer Protocol (SMTP) message delivery, and Outlook Anywhere.
Achieving High Availability

Creating a high availability solution requires good design, planning, training, operational discipline, and
ongoing preventative maintenance. Applying a structured operations methodology, such as Microsoft
Operations Framework, results in a foundation for building and maintaining highly available solutions.
Using appropriate high quality and redundant hardware provides the proper infrastructure. Lastly,
deploying software with redundancy, such as Windows failover clustering or Network Load Balancing
(NLB), can help you protect and recover from a variety of hardware and software failures.
Discussion: Components of a High Availability Solution
Numerous components can comprise a messaging solution, and you should scrutinize them to ensure
that failures will not affect the entire solutions availability. Once you identify these components, you can
mitigate failures.
Question: Which components are important for running a high availability solution?
Question: What are some common single points of failure in a messaging solution?
Lesson 2
Configuring Highly Available Mailbox Databases
Historically, the Mailbox server role was the most complex and critical component in a highly available
Exchange Server deployment. Although this remains true, to a degree, Exchange Server 2010 reduces the
complexity of deploying a highly available Mailbox server. In doing so, it also reduces the likelihood that
administrators will configure a Mailbox server cluster improperly.
Describe database availability group (DAG).
Describe the Quorum selection process.
Describe Active Manager.
Describe continuous replication.
Describe how DAGs protect databases.
Configure a Database Availability Group.

Configure databases for high availability.
Create and configure a DAG.
Describe the transport dumpster.
Describe the failover process.
Describe how you can perform DAG monitoring and management.
Monitor replication health.

What Is a Database Availability Group?
A DAG is a collection of servers that provides the infrastructure for replicating and activating database
copies. The DAG uses continuous replication to each of the passive database copies within the DAG,
which:
Requires the Windows Server 2008 failover-clustering feature, although all installation and
configuration tasks occur with the Exchange Server 2010 management tools. Even though a DAG
requires the failover-clustering feature, Microsoft Exchange Server 2010 does not use Windows
failover clustering to handle database failover; instead, it uses Active Manager to control failover.
Additionally, you can use it for some failure-detection scenarios, such as a server failure. A later
section of this module describes the Active Manager in detail.
Uses an improved version of the continuous replication technology that Exchange Server 2007
introduced. The improvements support the new high availability features, such as database copies
and database mobility. A later section of this module describes continuous replication in detail.
Note DAGs can also use third-party replication instead of continuous replication.
Allows you to add and remove Mailbox servers at any time. You do not need to decide on the DAG
membership during installation.
Allows you to move a single database between servers in the DAG, without affecting other databases.
Allows up to 16 copies of a single database on separate servers. You can add up to 16 servers to a
DAG, which allows you to create up to 16 copies of a database. The database copies must be stored in
the same path on all servers. For example, if you store Mailbox Database 1 in D:\Mailbox\DB\Mailbox
Database 1\ on NYC-EX10, then you must also store it in D:\Mailbox\DB\Mailbox Database 1\ on all
other servers that host Mailbox Database 1 copies.
Defines the boundary for replication, because only servers within the DAG can host database copies.
You cannot replicate database information to Mailbox servers outside the DAG.
Because DAGs use the failover clustering feature, Exchange Server 2010 must be installed on Windows
Server 2008 or Windows Server 2008 R2 Enterprise Edition or Data Center Edition. You cannot add an
Exchange Server 2003 or Exchange Server 2007 databases to an Exchange Server 2010 DAG.
Question: During installation, do you need to decide if you want to join a server to a DAG?
What Is Quorum?
The failover cluster quorum configuration that the Exchange Server 2010 DAG uses determines the
number of failed nodes, or failed storage and network components, that the cluster can sustain while
continuing to function. Quorum prevents two sets of nodes from operating simultaneously as the failover
cluster. Simultaneous operation could happen when network problems prevent one set of nodes from
communicating with another set of nodes. Without a quorum mechanism, each set of nodes could
continue to operate as a failover cluster, resulting in a partition within the cluster.
To prevent problems that a split in the cluster may cause, failover clusters use a voting algorithm to
determine whether the cluster has enough votes to maintain quorum. Because a given cluster has a
specific set of nodes and a specific quorum configuration, the cluster determines how many votes are
required. If the number of votes drops below the majority, the cluster cannot start. Nodes continue to
listen for the presence of other nodes, in case another appears on the network, but the nodes will not
function as a cluster until a consensus is reached.
For example, if there are five votes in the cluster, the cluster continues to function as long as there are at
least three available votes. The source of the votes in Exchange Server 2010 can be a node or a witness file
share. When a majority of votes is not available, including when half the votes are available, the cluster
will not start.
Windows Server 2008 Quorum Options

The following table lists the quorum options in Windows Server 2008:
Exchange Server
Quorum mode Description Exchange Server 2007 2010
Node Majority Only nodes in the cluster Supported and recommended Not supported
have a vote. because the node and disk
Quorum is maintained majority, and node and file
when more than half the majority, provide an additional
nodes are online. vote to enable maintaining
quorum if half the nodes fail.
Node and File The nodes in the cluster Supported and recommended Supported
Share Majority and a witness file share for cluster continuous
have a vote. replication (CCR).
Quorum is maintained
when more than half the
votes are online.
Node and Disk The nodes in the cluster Supported and recommended Not supported
Majority and a witness disk have a for single copy clusters.
vote.
Quorum is maintained
when more than half the
votes are online.
No Majority: Only the quorum shared Supported but not Not supported
Disk Only disk has a vote. recommended for single copy
Quorum is maintained clusters because the quorum
when the shared disk is shared disk is a single point of
online. failure.
Question: Your DAG has two Mailbox servers (nodes) and one witness server. When will you
lose quorum and not be able to mount the databases automatically anymore?
What Is Active Manager?
To manage mailbox database replication and activation, Exchange Server 2010 includes a new
component called Active Manager, which runs as a function of the Microsoft Exchange Replication service
(MSExchangeRepl.exe). Active Manager replaces the resource model and failover management features
integrated into Windows failover clustering and used in Exchange Server 2003 and Exchange Server 2007.
To simplify the architecture, Active Manager runs on all Mailbox servers, even if the server is not part of a
DAG.
Active Manager runs as either the Primary Active Manager (PAM) or a Standby Active Manager
(SAM) on all of the DAG members. The PAM is the Active Manager in a DAG that controls which copies
will be active and which will be passive. It is responsible for processing topology change notifications
and reacting to server failures. The DAG member acting as the PAM is always the member that
currently owns the default cluster group. To identify the PAM, it is recommended to use the
Get-DatabaseAvailabilityGroup <DAG Name> -Status | Format-List Name, PrimaryActiveManager
cmdlet, rather than using the Windows Failover Clustering tools. If the server that owns the default cluster
group fails, the PAM function automatically moves to the server that takes ownership of the default
cluster group.
Far from having a passive role, the SAM function provides information about which server hosts the active
copy of a mailbox database. The SAM detects local database and Microsoft Exchange Information Store
failures, and reacts to them by requesting that the PAM initiate a failover when a copy is available. A SAM
does not determine a failover target, nor does it update a databases location state for the PAM. Each
SAM accesses the state of the active database copy so that it can redirect Hub Transport and Client Access
server requests. The PAM also performs the functions of the SAM role on the local system.
Question: On what Exchange servers does Active Manager run?

What Is Continuous Replication?
Continuous replication was introduced for Mailbox servers in Exchange Server 2007. Exchange Server 2010
continued to use continuous replication. Since Exchange Server 2010 Service Pack 1 (SP1), two options for
continuous replication are available: continuous replication file mode and continuous replication block
mode.
Continuous ReplicationFile Mode

Continuous replication creates a passive database copy on another Exchange Server computer in the DAG,
and then uses asynchronous log shipping to maintain the copies.
The continuous replication-file mode, or log shipping process, is as follows:
1. The Mailbox server role with the active database writes the active log, and then closes it.
2. The Replication Service replicates the closed log to servers hosting the passive databases.
3. The transaction logs are inspected, and then replayed or applied to the database copies, since each
copy of the database is identical. The databases remain synchronized.
In Exchange Server 2007, Microsoft Exchange Replication service performed this functionality, which
Microsoft Exchange Information Store service now performs. Replaying the log files to the passive
database occurs continuously, which results in a warm state, which is a database cache. In Exchange Server
2007, when the Mailbox server activates the passive copy, the database cache that was built by the
Microsoft Exchange Replication service as a result of replay activity is lost when the Microsoft Exchange
Information Store service mounts the database. This behavior places the database cache in a cold state.
The improvement in Exchange Server 2010 continuous replication reduces read input/output (I/O)
operations significantly during database activation.
Additionally, seeding no longer requires that you to use the active copy as the seeds source. In Exchange
Server 2010, you also can perform seeding from passive databases. If a healthy copy of the database is
available on any server, the Exchange Server can replay the transaction logs against a common, valid data
set. You can seed the data:
Automatically.
Manually, from the active or passive copies, by using the Update-MailboxDatabaseCopy cmdlet.
Manually, by copying the database files.
Continuous replication occurs over TCP sockets, as opposed to using the Exchange Server 2007 file-share
method. Continuous replication occurs when:
1. The target, or passive node, tells the active instance which transaction logs it expects to receive.
2. The source responds with the required transaction log files.
3. After Exchange Server 2010 copies the log files, and then places them in the target inspector directory
for processing.
4. The log-inspection process verifies that the data is correct and inspects the header. If the log passes
inspection, Exchange Server 2010 places it in the target log directory. If the log does not pass
inspection, Exchange Server 2010 requests it from the source up to three times before failing.
5. Once Exchange Server 2010 saves the transaction log to the target log directory, the information
store validates the logs to ensure that they are valid, that none are missing, and that the database
requires them.
Continuous ReplicationBlock Mode

Exchange Server 2010 SP1 included continuous replicationblock mode, and you could implement it to
reduce your exposure to data loss on failover. This is achieved by replicating Extensible Storage Engine
(ESE) log buffer writes to the passive database copies in parallel to writing them locally. Block mode
automatically becomes active when continuous replication file mode is up to date with the database
copies. The continuous replication block mode process is as follows:
1. Once in block mode, any block of data written to the ESE log buffer on the Exchange server that hosts
the active database is automatically copied to the replication log buffer all passive copies of the active
databases.
2. When the ESE log buffer is full, the final block is sent to the passive databases, and a transactional log
file is written to the Exchange server that hosts the active database. Then the ESE log buffer is
emptied.
3. When the Exchange servers hosting the passive databases receive the final block that fills up their
replication log buffer, they also save the buffer to a transaction log file with the same log generation
sequence number. After that, the buffer is emptied and the process starts again.
4. When the Exchange server with the active database fails, but the replication log buffer is not yet full,
then the buffer on the server hosting the passive copy of the database is saved to a new transactional
log file.
Replication transport is the same when file mode is enabled or disabled. The benefit of block mode is that
it can reduce the differences between the active copy and the passive copy, while also reducing the
possibility of data loss during a failover and the time it takes to perform a switchover.
How Are Databases Protected in a DAG?
The active database copy uses continuous replication to keep the passive copies synchronized based on
their replay lag-time setting. A DAG leverages the Windows Server operating system failover clustering
feature. However, it relies on the Active Manager server to maintain the status of all of the DAGs hosted
databases. Database characteristics are:
A single database can failover or switchover between DAG servers. However, it is only active on one
server at a time.
At any given time, a copy is either the replication source or the replication target, but not both.
A server may not host more than one copy of a given 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.
Database failovers occur when failures cause the active database to go offline. Either a single server failure
or something specific to a database may cause the failure. A switchover occurs when an administrator
intentionally coordinates moving the active database from one server to another.
Question: Can you have one database copied three times and another database copied only
one time?
Configuring a Database Availability Group
To configure a DAG you must understand the different settings that are available. Some of these settings
are required for every configuration, such as the DAG IP address; others can be considered to fine-tune
your DAG configuration, such as network compression settings.
In order to plan your DAGs correctly, you need to understand the purpose of each available configuration
setting in order to decide if you require it for your own Exchange organization.
In the EMC the following settings are available:

Witness Server. The server that you want to use as witness server. As a best practice it is
recommended to use a Hub Transport server outside the DAG as the witness server.
Witness Directory. The directory that will be used to store file share witness data.
Alternative Witness Server. The server that you can use in another data center to be enabled when the
first witness server is not available anymore.
Alternative Witness Directory. The directory that will be used to store file share witness data on the
alternative witness server.
Database availability group IP addresses. One or more IP addresses assigned to the DAG. You can
configure it by using a static IP addresses, or use a Dynamic Host Configuration Protocol (DHCP)
server to get an IP address automatically. Besides the DAG name, this is the only required setting;
therefore, you must either configure an IP address or have a DHCP server available to retrieve one. If
no IP address can be retrieved, the DAG cluster service will not start.
DAG Networks
A DAG network is a collection of one or more subnets that Exchange Server uses for either replication
traffic or Messaging Application Programming Interface (MAPI) traffic. Although Exchange Server
supports one network adapter and path, it is recommended a minimum of two DAG networks. In a two-
network configuration, you typically dedicate one network to replication traffic and the other network to
MAPI traffic.
You configure replication in the EMC. To enable the DAG network to replication traffic, you must enable
the Enable replication check box. Clear the check box to prevent replication from using the DAG network.
Note If you disable replication on a DAG network to preserve it for MAPI traffic,
replication traffic will still use that DAG network when no other network is available.
When implementing a DAG across multiple sites, you do need to configure the DAG networks. A DAG
supports having multiple subnets on the MAPI network as well as on the replication network. Therefore,
subnets do not need to span a wide area network (WAN) link.
When configuring the multisite DAG, you need to collapse the networks that Exchange Server enumerates
automatically when you add servers to the DAG into one MAPI network and one or more replication
networks. However, there can be no routing between the MAPI network and the replication network, nor
can there be routing between replication networks when you configure multiple networks.
DAG Network Compression

DAGs provide built-in compression for network traffic. This is based on the XPRESS algorithm, which is the
Microsoft implementation of the LZ77 algorithm. This is the same type of compression used for example
in MAPI RPC compression between Microsoft Outlook and Exchange. To configure DAG network
compression, you have the following options:
Disabled. Network traffic is not compressed.
Enabled. Compression is used for replication and seeding.
InterSubnetOnly. If the same subnet traffic is not compressed, this is the default setting where
compression is used when replicating across different subnets only.
SeedOnly. Compression is used only for seeding.
You can configure DAG network compression by using the following cmdlet:
Set-DatabaseAvailabilityGroup <DAG name> -NetworkCompression <Option>
DAG Network Encryption

You can configure DAG network communication encryption in the following ways:
Disabled. Network traffic is not encrypted.
Enabled. Network traffic for replication and seeding is always encrypted.

InterSubnetOnly. If the same subnet traffic is not encrypted, this is the default setting where network
traffic is encrypted when replicating across different subnets only.
SeedOnly. Network traffic is only encrypted for seeding.

You can configure DAG network encryption by using the following cmdlet:
Set-DatabaseAvailabilityGroup <DAG name> -NetworkEncryton <Option>
Third-Party Replication Mode

By default, a DAG uses the built-in continuous replication feature to replicate mailbox databases among
DAG servers. If your organization uses a third-party data replication solution that supports the Third Party
Replication API in Exchange 2010, you can also configure the DAG to use it rather than the built-in
replication feature. You can do this by using the New-DatabaseAvailabilityGroup cmdlet, and you can
disable it only by removing and recreating the DAG.
Configuring Databases for High Availability
Creating a DAG is only the first step to providing database availability. You must create and configure
additional database copies. Not only can you create a database copy initially, but an administrator also
can create one at any time. You can distribute database copies across Mailbox servers in a flexible and
granular way. You can replicate one, some, or all mailbox databases on a server in several ways.
To create a database copy, you must use the Add Mailbox Database Copy Wizard in the Exchange
Management Console, or the Add-MailboxDatabaseCopy cmdlet in the Exchange Management Shell.
Specify the following information when creating a mailbox database copy:
The name of the database that you are copying.
The name of the Mailbox server that will host the database copy.
The amount of time (in minutes) for log replay delay. This is the replay lag time, which sets how long
to wait before the logs are committed to the database copy. You can turn off log replay delay by
setting the value for it to 0.
The amount of time (in minutes) for log truncation delay. This is the truncation lag time, which sets
how long to wait before truncating committed transaction logs. You can turn off log truncation delay
by setting the value for it to 0.
An activation preference number. This is a preferred list sequence number, and it represents the order
of activation preference for a database copy after the active copy fails or experiences an outage.
Question: How do you plan to use the preferred list sequence number?
Demonstration: How to Create and Configure a DAG
In this demonstration, you will review how to create a new DAG, add member servers to it, and create a
copy of a mailbox database.
Demonstration Steps
1. Click Start, click All Programs, click Microsoft Exchange Server 2010, and then click Exchange
Management Console.
2. In the console tree, expand Microsoft Exchange On-Premises, expand Organization

3. Use the New Database Availability Group Wizard to create a DAG with the following settings:
Name: DAG1
Witness Server: VAN-DC1
Witness Directory: C:\FSWDAG1
4. Right-click DAG1, click Properties and configure 10.10.0.25 as the IP Address on the IP Address tab.
5. Use the Manage Database Availability Group Membership Wizard to add

VAN-EX1 and VAN-EX2 as members to DAG1.
6. In the Results pane, click the Database Management tab.
7. Use the Add Mailbox Database Copy Wizard to add a copy of Mailbox Database 1 to the second
Mailbox server.
Note Once you create a DAG, you then can create and configure DAG networks for
replication or for MAPI traffic. Add additional networks for redundancy or improved
throughput.
Question: What information do you need before you can configure a DAG?
What Is the Transport Dumpster?
If a failure occurs and some transaction logs are not replicated to the passive copy, you can use the
transport dumpster to redeliver any recently delivered email. The transport dumpster operates on the Hub
Transport servers within Active Directory Domain Services (AD DS) or Active Directory directory service.
When a database failover occurs, a request will be made to the Hub Transport servers to redeliver the lost
email messages. The next section details database failovers.
The transport dumpster only holds email that has been delivered. The local submission queue holds any
pending email. Once the transaction logs are replicated to each DAG server, the transport dumpster
purges the message.
The transport dumpster is configured by default. You can view the transport dumpster settings by running
the Get-TransportConfig cmdlet. You can control the transport dumpster with the following two
settings:
MaxDumpsterSizePerStorageGroup. This setting defines the maximum size of the transport
dumpster queue per database. This is a universal setting for all databases in the organization. The
recommended size is 1.5 times the maximum message size that can be sent. For example, if the
maximum size for messages is 10 megabytes (MB), you should configure this parameter with a value
of 15 MB.
MaxDumpsterTime. This setting defines the amount of time an email remains in the transport
dumpster queue. This is the time for which the transport dumpster retains a message if the dumpster
does not force it out because it reaches its maximum size. We recommend that you set the time to
seven days.
You also can modify the transport dumpster settings by accessing the Hub Transport server settings in the
Organization Configuration node, and then modifying the Transport Settings located on the Global
Settings tab.
If you implement a multisite DAG, you can mount the mailbox database in more than one Active
Directory site. If a database fails over to a second Active Directory site, Mailbox servers request redelivery
of messages from Hub Transport servers in both the databases original and new Active Directory sites.
Understanding the Failover Process
A failover occurs when service to the existing active database copy is compromised in some way. This
can occur when the server hosting the active database goes offline, when something causes the active
database to dismount, or when the server loses network connectivity. A switchover occurs when an
administrator manually moves the active database from one server to another. The main difference
between the failover process and the switchover process is that the failover process occurs automatically
when the service fails, while the switchover is a manual process. During a switchover, you can choose
which database will be mounted, or let Active Manager choose the best copy to mount. During a failover,
the Active Manager makes this decision.
When a failure affecting the active database occurs, Active Manager uses several sets of selection criteria
to determine which database copy to activate. When selecting the best copy to activate, Active Manager:
1. Creates a list of database copies that are potential candidates for activation.
2. Ignores and removes from the list any database copies that are unreachable or are blocked
administratively from activation.
3. Sorts the resulting list by using the copy-queue length as the primary key. In Exchange Server
2010 SP1 or later, if the servers are configured with an automatic database mount dial value of
Lossless, Active Manager sorts the resulting list in ascending order by using the value for
ActivationPreference as the primary key.
4. Attempts to locate a mailbox database copy on the list that has a status of Healthy,
DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource, and then evaluates
the activation potential of each of the copies on the list by using an ordered set of ten criteria. These
criteria include various combinations of settings such as content indexing status, copy queue length,
and replay queue length.
Database Failovers
When a highly available mailbox database failure occurs, the PAM attempts to perform a failover of the
database. Before attempting to select a suitable copy to activate, the Attempt Copy Last Logs (ACLLs)
process occurs. ACLL makes remote procedure calls (RPCs) to the server that hosted the active copy of the
mailbox database that is being activated. The RPCs request confirmation that the servers are available and
healthy, and they determine the LogInspectorGeneration value for the database copy. The last active
mailbox database copy is used to copy any missing log files to the copy selected by Active Manager for
activation.
After the ACLL process completes, the configured AutoDatabaseMountDial value is consulted. The
AutoDatabaseMountDial value has the following three potential settings:
BestAvailability. This value allows the database to be automatically mounted if the copy queue length
is less than or equal to 12. The copy queue length is the number of logs that have not been replicated
to the target Mailbox server. When Active Manager identifies the target server, Exchange Server 2010
attempts to replicate the remaining logs to the passive copies and mount the database. This is the
default value.
GoodAvailability. This value allows the database to be automatically mounted immediately after a
failover if the copy queue length is less than or equal to six. When Active Manager identifies the
target server, Exchange Server 2010 attempts to replicate the remaining logs to the passive copy and
mount the database.
Lossless. This value does not allow a database to mount automatically until all logs generated on the
active copy have been copied to the passive copy.
If the number of lost logs is within the configured AutoDatabaseMountDial value, Active Manager
issues a mount request to the store. If the number of lost logs falls outside the configured
AutoDatabaseMountDial value, Exchange Server 2010 evaluates the next mailbox database copy in
the sorted list and repeats the evaluation. If no databases meet the configured AutoDatabaseMountDial
setting, an administrator must manually mount the database and accept that the loss of data is larger
than the AutoDatabaseMountDial setting. You use the Set-MailboxServer cmdlet to configure the
AutoDatabaseMountDial setting for each DAG node.
It may seem counterintuitive to list the Best Availability as allowing for 12 missing transaction logs, and
Good Availability as only allowing 6. In this case, availability refers to the database being mounted and
available, not to the possibility of lost data. In most cases, data loss is less acceptable than the loss of
service. You must decide whether to keep the database available by allowing it to mount despite potential
data loss, or to leave it unavailable and wait for manual recovery of missing log files.
In Exchange Server 2010 SP1 or newer, the Active Manager behaves differently when you configure a
lossless setting. In this case, it sorts the resulting list in ascending order by using the ActivationPreference
value as the primary key. If you use any value other than lossless for the AutoDatabaseMountDial, the
Active Manager sorts by using the copy queue length, which is the default behavior in Exchange Server
2010.
Question: Suppose you want to ensure that databases are not mounted if any transaction
logs have not been replicated. What AutoDatabaseMountDial setting do you need to
configure?
Designing Monitoring and Management for a DAG
In larger organizations, DAG management is likely to be restricted to a relatively small group of

administrators. This group understands all of the design parameters that need to be considered when
creating and managing DAGs and database copies. You can delegate these permissions by using role-
based access control (RBAC).
To create and manage DAGs, you must be part of either the Organization Management role group, or the
Database Availability Groups management role. To create and manage database copies, you must be part
of either the Organization Management role group, or the Database Copies management role.
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 Microsoft System Center Operations Manager 2012. System Center Operations Manager 2012
proactively monitors servers, and can notify administrators when errors and events occur.
Exchange Server 2010 SP1 or newer provides the following options for monitoring DAG status:
CheckDatabaseRedundancy.ps1. This script checks the redundancy of replicated databases, and it

generates events if database resiliency is found to be in a compromised state.
Get-MailboxDatabaseCopyStatus. Use this cmdlet to view status information about a specific

mailbox database copy, all copies of a database, or all mailbox database copies on a server or in the
organization.
Test-ReplicationHealth. Use this cmdlet to perform a variety of tests, and to report back status for
various replication components.
CollectOverMetrics.ps1. This script collects statistics and information about switchovers and
failovers. The data reported is based on past events. This script was enhanced in Exchange Server
2010 SP1 to include metrics for continuous replication block mode, and more details from the
replication and replay pipeline. Additionally, it also features enhanced reporting.
CollectReplicationMetrics.ps1. This script collects statistics about replication in real time while the
script is running.
Event logs. In addition to events in Windows logs, there are also Exchange Serverspecific event logs
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.
Exchange Server 2010 SP1 or newer also includes the following DAG management scripts. These scripts
also work in the RTM release of Exchange Server 2010:
StartDagServerMaintenance.ps1. Use this script if you want to enable maintenance mode on a

server. This script moves all active databases including the PAM role to a different server and blocks
the server from receive any database activations requests.
StopDagServerMaintenance.ps1. Use this script if you want to take the DAG member server out of
maintenance mode. This script removes all blocks from a server and enables databases to be activated
on the server.
Note For examples on how to use the monitoring tools included in Exchange Server 2010,
see Monitoring High Availability and Site Resilience at
http://go.microsoft.com/fwlink/?LinkId=213763.
Question: Which users in your organization will have permission to manage DAGs?
Demonstration: How to Monitor Replication Health
In this demonstration, you will review how to use the Exchange Management Console and Exchange
Management Shell to review the available information regarding database-replication health.
Demonstration Steps
1. On VAN-EX1, click Start, click All Programs, click Microsoft Exchange Server 2010, and then click

3. Review the status of each of the Mailbox Database 1 database.
4. Close Exchange Management Console.

5. Click Start, click All Programs, click Microsoft Exchange Server 2010, and then click Exchange
Management Shell. Run the following cmdlets to verify database replication.
Test-ReplicationHealth
Get-MailboxDatabaseCopyStatus
6. Run the following script to verify replication and activation health (can be found in: C:\Program Files
\Microsoft\Exchange Server\V14\Scripts:
.\CheckDatabaseRedundancy.ps1 MaiboxDatabaseName Mailbox Database 1
Question: Why is monitoring these statistics important?

Lesson 3
Deploying Highly Available Non-Mailbox Servers
High availability for non-Mailbox servers varies depending on the server role. As in Exchange 2007, each
server role in Exchange 2010, has a unique method for providing high availability. To enable redundant
message routing between Exchange servers, Hub Transport servers require no configuration other than
the addition of a second Hub Transport server. Client Access servers require you to create a client access
array and to configure some type of load balancing. Edge Transport servers require the proper
configuration of mail exchanger (MX) records in Domain Name System (DNS).

Describe and configure high availability for Client Access servers.
Describe and configure high availability for Hub Transport servers.
Describe and configure high availability for Edge Transport servers.
How High Availability Works for Client Access Servers
A client access array is a load-balanced collection of Client Access servers that are in a single site. Because
all MAPI clients now rely on connections to Client Access servers, it is important to provide a redundant
server array to improve availability.
To enable high availability for Client Access servers, you first must deploy multiple Client Access servers.
Next, you need to configure either hardware-based NLB or software-based NLB (such as the Windows
Server 2008 NLB feature). You can also create multiple DNS A records in DNS for your Client Access
servers and configure round-robin DNS. Round-robin DNS enables you to distribute network connections
across the different Client Access servers, but it does not provide load balancing or automatic failover.
Then, add the name for the load-balanced array to the DNS. For example, you could add an A record for
casarray.contoso.com that points to 10.10.10.25. After adding the DNS record, you can create the client
access array, and then assign it to an Active Directory site by using the New-ClientAccessArray cmdlet.
Additionally, you must do the following:
Use the Set-MailboxDatabase cmdlet to assign the name of the client access array name to the
RpcClientAccessServer parameter for each mailbox database.
Use the Set-ClientAccessServer cmdlet to assign the name of the client access array name to the
AutoDiscoverServiceInternalUri parameter on each Client Access server that is part of the client
access array.
Use the Set-WebServicesVirtualDirectory -Identity EWS* cmdlet with the InternalUrl parameter
on each Client Access server that is part of the client access array.
Change the InternalURI in the Exchange Control Panel, offline address book, and Microsoft Exchange
ActiveSync. Do this in the Exchange Management Console, under Server Management, for each
Client Access server that is part of the client access array.
Additionally, you can configure the Kerberos authentication protocol for Client Access server NLBs to
increase security or if your organization has Apple Macintosh computer clients.
Note Only one client access array can exist in one 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.
How Shadow Redundancy Provides High Availability for Hub Transport

Servers
Key Points
Exchange Server 2010 includes a new shadow redundancy feature, which provides redundancy for
messages during the entire time they are in transit. This message redundancy is in addition to the
transport dumpster. With shadow redundancy, message deletion from the transport queue is delayed
until the transport server verifies that all of the next hops for that message have completed delivery. If any
of the next hops fail before reporting successful delivery, the transport server resubmits the message for
delivery to that next hop. If the next-hop server does not support shadow redundancywhich is the case
for Exchange 2003 servers and Exchange 2007 serversthe message is sent to the next hop and a shadow
copy of the message is not retained.
Shadow redundancy provides the following benefits:

It reduces the reliance on the state of the transport server queues. If redundant message paths exist
and a transport server fails, you can simply remove it from production without worrying about
emptying its queues or losing messages currently in transit.
It allows the transport server to be taken offline for maintenance tasks, without the risk of losing
messages in transit.
It reduces the need for hardware redundancy for transport servers for messages in transit.
It consumes less bandwidth than other forms of redundancy that create duplicate copies of messages
on multiple servers. With shadow redundancy, the only added network traffic is the discard status
being communicated between transport servers.
It provides resilience and simplifies recovery from a transport server failure because messages still in
transit within the Exchange Server 2010 organization are protected by the previous Exchange 2010
transport server.
Note The messages in the transport dumpster are also stored in the transport server
queue. In the event of a Hub Transport server failure, these messages are not protected by
the shadow redundancy feature.
Exchange Server 2010 implements shadow redundancy by extending the SMTP. These service extensions
allow SMTP hosts to negotiate shadow redundancy support, and communicate the discard status for
shadowed messages.
As an example, shadow redundancy message flow follows these stages, where Hub is a Hub Transport
server and Edge is an Edge Transport server:
1. Hub delivers message to Edge.
a. Hub opens SMTP session with Edge.
b. Edge advertises shadow redundancy support.
c. Hub notifies Edge to track discard status.
d. Hub submits message to Edge.
e. Edge acknowledges the receipt of message, and records the Hubs name for sending discard
information for the message.
f. Hub moves the message to the shadow queue for Edge, and marks Edge as the primary server.
Hub becomes the shadow server.
2. Edge delivers message to the next hop:
a. Edge submits message to third-party mail server.
b. Third-party mail server acknowledges the messages receipt.

c. Edge updates the discard status for the message as delivery complete.
3. Hub queries Edge for discard status (success case):
a. At end of each SMTP session with Edge, Hub queries Edge for discard status on messages
previously submitted. If Hub has not opened any SMTP sessions with Edge after the initial
message submission, it will open an SMTP session with Edge to query for discard status after a
specific time.
b. Edge checks local discard status and sends back the list of messages that have been delivered,
and removes the discard information.
c. Hub server deletes the list of messages from its shadow queue.
4. Hub queries Edge for discard status and resubmits the message (failure case):
a. If Hub cannot contact Edge, Hub resumes the primary server role and resubmits the messages in
the shadow queue.
b. Resubmitted messages are delivered to another Edge server, and the workflow starts from step 1.
Within Exchange Server 2010, the Shadow Redundancy Manager is the core component of a transport
server that is responsible for managing shadow redundancy. The Shadow Redundancy Manager is
responsible for maintaining the following information for all the primary messages that a server is
currently processing:
The shadow server for each primary message being processed.
The discard status to be sent to shadow servers.
For all the shadow messages that a server has in its shadow queues, the Shadow Redundancy Manager is
responsible for the following:
Maintaining the queue and checking primary server availability for each shadow message.
Processing discard notifications from primary servers.
Removing the shadow messages from the database once it receives all expected discard notifications.
Deciding when the shadow server should take ownership of shadow messages, thus making it the
primary server.
In addition to the shadow redundancy implemented at the SMTP protocol level, shadow redundancy also
enables the following features:
Delayed acknowledgement. Exchange 2010 transport servers use delay acknowledgement when
receiving messages from SMTP servers other than Exchange 2010 servers. In this case, the transport
server delays acknowledging a received message until it verifies that the message was successfully
delivered to the next hop. This way, if the Exchange 2010 server fails, the sending mail server will
assume that the message was never delivered and will attempt delivery again.
Shadow redundancy promotion. With Exchange Server 2010 SP1 or newer, shadow redundancy
promotion provides an additional level of protection when receiving messages from a non-Exchange
2010 SMTP server. Rather than just sending a delayed acknowledgement when the next hop cannot
be verified, the transport servers now forward the message to another Hub Transport server so that
the message is protected by shadow redundancy.
How High Availability Works for Edge Transport Servers
Edge Transport servers provide both inbound and outbound email delivery. For outbound delivery,
providing high availability is as simple as deploying multiple Edge Transport servers and creating an Edge
subscription. If you have deployed Exchange servers in multiple Active Directory sites, you may need
additional redundant Edge Transport servers.
Multiple DNS MX Records

The SMTP protocol was created with delivery redundancy in mind. It uses special DNS records called MX
resource records to locate the authoritative SMTP server for a domain. These records point to the SMTPs
fully qualified domain name, which in this case are the Edge Transport servers. You can create multiple
MX records and assign them weights. The protocol uses the lower-weighted records before the higher-
weighted records. MX records with the same weight are load balanced in round-robin load fashion. If one
of the hosts fails to respond, Exchange Server attempts the next host on the list.
Hardware-Based Load Balancing

High availability for inbound email delivery requires multiple load-balanced Edge Transport servers. You
can achieve load balancing either with a hardware load balancer or by using multiple DNS records. Using
a hardware load balancer balances inbound communication between Edge Transport servers and provides
redundancy in case of a server failure.
Like Hub Transport servers, Edge Transport servers also support shadow redundancy. However, shadow
redundancy does not cover all scenarios, because most of the messaging servers that the Edge Transport
role communicates with do not support shadow redundancy.
Lesson 4
Deploying High Availability with Site Resilience
Site resilience allows you to extend high availability for your Exchange servers beyond a single data
center. Exchange Server 2010 supports site resilience for mailbox databases that are protected in a DAG.
In Exchange Server 2003, the only option for implementing site resilience was to implement storage
replication. In Exchange Server 2007, you could use continuous cluster continuous replication or standby
continuous replication to provide site resilience. With the implementation of DAGs, configuring site
resilience in Exchange Server 2010 is significantly easier.

Describe requirements for creating a multiple site DAG.
Describe Datacenter Activation Coordination Mode.
Deploying Exchange 2010 for site resilience.
Describe the switchover and switchback process with site resilience.
Understand best practices for site resilient solutions.
Requirements for Creating a Multiple Site DAG
You can extend a DAG to one or more data centers in a configuration that provides site resilience for one
or multiple data centers. Such a configuration produces several design challenges that you must take into
account before implementing a multiple site DAG.
One Mailbox Server at Each Site

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 for the Mailbox servers, or for the databases.
When implementing a DAG across multiple sites, you do need to configure the DAG networks. 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 wide area network (WAN) link. When configuring the multisite
DAG, you need to collapse the networks that are automatically enumerated when you add servers to the
DAG into one MAPI network and one or more replication networks. However, there can be no routing
between the MAPI network and the replication network or between replication networks if you configure
multiple networks. The WAN link must support separate routes for all networks.
Round-Trip Network Latency Time

Each member of the DAG must have round-trip network latency no greater than 500 milliseconds
between each other member, regardless of the physical location of the DAG member.
Other Server Roles Must Be Available in Each Site

In addition to the Mailbox server in the alternate data center and the basic Active Directory servers such
as domain controllers and DNS servers, 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 processing capacity to run all three roles at the same
time.
Datacenter Activation Coordination Mode

Use the Datacenter Activation Coordination mode for DAGs that span multiple locations. This mode
prevents database copies from experiencing split-brain syndrome, which occurs when more than one DAG
member mounts the same database. This is a problem because there is no way to reconcile the different
content in the two mounted databases. Datacenter Activation Coordination mode is described in greater
detail in the next topic.
What Is Datacenter Activation Coordination Mode?
Datacenter Activation Coordination mode is a DAG property that prevents split-brain syndrome, which is
the mounting of the same database at two different Active Directory sites that cannot communicate with
one another. Datacenter Activation Coordination (DAC) mode prevents split-brain syndrome in a multi-
Active Directory site DAG implementation.
Suppose you have two data centers, each with two DAG members. The witness server for the DAG is in
the first data center. A power outage occurs, and as the administrator, you activate the DAG at the second
data center. Because you do not have majority quorum in the second data center, you can do this by
configuring an alternative witness server or by configuring the DAG to use a different quorum mode. As
long as the first data center stays offline, no problem occurs. Split-brain syndrome occurs when the first
data center is powered back up, but WAN connectivity between the two data centers is not immediately
restored. If DAC mode is not enabled, the first data center could mount the databases and achieve
majority quorum because it still does not know that the second data center already has the databases
mounted. This results in the same database being active at two different sites, which causes split-brain
problems when WAN connectivity is restored.
To prevent split-brain syndrome, Datacenter Activation Coordination mode uses a protocol called
Datacenter Activation Coordination Protocol (DACP). This protocol configures a bit in memory for each
Active Manager hosted on every Exchange server that is a DAG member, and has the following options:
0 Local database is not allowed to be mounted.
1 Local database is allowed to be mounted.
The DACP protocol is:
During Active Manager start up, DACP is set at 0.
In Datacenter Activation Coordination mode, the server tries to communicate with all other Exchange
servers that are members of the DAG to find a member that has its DACP bit set at 1.
If it finds a DAG member with a DACP of 1, the server sets its DACP bit to 1 and mounts its active
databases. Alternatively, if the server contacted all DAG members successfully, it also sets its DACP to
1 and mounts the database.
If the server cannot reach a server that has a DACP of 1, it cannot automatically mount its active
database.
DAC mode differs in the Exchange Server 2010 versions in the following way:
In Exchange Server 2010, DAC mode is limited to DAGs with at least three members that have two or
more members in the primary data center. When you enable DAC mode, you can use Exchange
Server cmdlets rather than the failover cluster tools to perform a data center switchover.
Exchange Server 2010 SP1 or newer supports two-member DAGs that have each member in a
separate data center. Two-member DAGs in DAC mode use the witness server boot time to provide a
weighted vote for mounting. DAC mode in Exchange Server 2010 SP1 or newer supports DAGs that
have all members deployed in a single Active Directory site, including single Active Directory sites that
have been extended to multiple locations.
Two-Member DAGs in DAC Mode

A two-member DAG in DAC mode may have difficulty achieving majority quorum when it relies on the
DACP setting alone. For this reason, the Datacenter Activation Coordination uses the DAGs witness server
boot time to help determine whether a database should be mounted. The Active Manager compares the
boot time of the witness server to the time when the DACP was set to 1. This provides the following
scenarios:
If the DACP setting was set earlier than the witness boot time, the DAG member is not allowed to
mount databases.
If the DACP setting was set later than the witness boot time, the DAG member is permitted to mount
databases.
You can enable DAC mode with the following cmdlet:
Set-DatabaseAvailabilityGroup -Identity <DAG Name>

-DatacenterActivationMode DagOnly
Question: When should you consider configuring the Datacenter Activation Coordination
mode?
Deploying Exchange 2010 for Site Resilience
To deploy Exchange 2010 for site resilience, you need to understand that not only Mailbox servers are
required in the other physical site, but also the following roles of servers:
Active Directory Domain Controller

Hub Transport server
Client Access server
Edge Transport server (if used)
The easy part is that for those servers you do not need special configuration to provide site resilience;
those roles must exist in the remote data center.
Active Directory Domain Controller

Every Exchange Server role requires a local Domain Controller (DC) to communicate with. If you do not
have a local DC available, Exchange services cannot start. Make sure you have at least one local DC
controller available for the remote site and that the physical location is defined in Active Directory (AD)
as an AD site.
Hub Transport Server

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 to
enable message routing between Exchange servers.
If you have applications or non-MAPI clients 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 Server

You cannot span a client access array over multiple Active Directory sites. Therefore, similar to a Hub
Transport server, you need to include a Client Access server in the Active Directory site in the alternate
data center.
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 will be used for a short time.
If the alternate data center will be used for a long time such as for a couple of weeks and not only for a
day or two, you should consider modifying the DNS record for the Client Access servers or the client
access array to reference the Client Access server in the alternate data center.
Outlook Anywhere and Exchange ActiveSync clients locate a Client Access server 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 caching DNS records. If the client computer caches the hostname of the Client
Access server, you can clear the cache on the client computer by specifying 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 or configure a short time to live (TTL) on
the DNS records.
Edge Transport Server

To provide site resilience for Edge Transport servers, you must have an 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 server 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, SMTP 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.
Switchover and Switchback Process with Site Resilience
Failover for databases within an Active Directory site is always automatic, and may not be noticed by
clients. You can also failback mailbox databases in the same site with no disruption in services. However,
switchover and switchback between sites is a manual process that will result in a short service outage.
The Switchover Process with Site Resilience

To access the site resilience cmdlets, you must enable DAC mode on the DAG before the failure occurs.
When the primary data center fails, the switchover process includes the following steps:
1. Reconfigure the DAG to remove the primary sites servers from the Windows Failover Cluster, but
retain them in the DAG. There are two options for configuring the DAG. If some Mailbox servers in
the primary site are still running but with not enough servers to maintain quorum, you need to stop
the DAG on the running servers. You can accomplish this by running the following cmdlet in the
Exchange Management Shell on a server in the primary data center:
Stop-DatabaseAvailabilityGroup <DAG Name> ActiveDirectorySite <Primary Site Name>
If all of the Mailbox servers in the primary site are unavailable, or if Active Directory replication with
the secondary data center has failed, you need to stop the DAG in the primary data center from an
Exchange server in the secondary data center. You can accomplish this by running the following
cmdlet in the Exchange Management Shell on a server in the secondary data center:
Stop-DatabaseAvailabilityGroup <DAG Name> ActiveDirectorySite <Primary Site Name>

-ConfigurationOnly
2. Reconfigure the DAG to use an alternative file-share witness, and restore the functionality in the
secondary site. To do this, first stop the cluster service on each of the secondary sites DAGs servers,
and then run the following cmdlet:
Restore-DatabaseAvailabilityGroup <DAG Name> -ActiveDirectorySite <Secondary Site Name>

-AlternateWitnessServer <Secondary Site Witness Server>
3. Start the cluster service on each of the servers in the DAG in the secondary site.
4. If you have blocked activation on any Mailbox servers in the secondary data center, you need to
remove the activation block. Available Active Managers will then mount the mailbox databases in the
secondary site.
5. If the database does not automatically mount, you need to manually move and activate the database
by using the following cmdlet:
Move-ActiveMailboxDatabase <database name> -SkipLagChecks -MountDialOverride:BestEffort

-SkipClientExperienceChecks -SkipHealthChecks -ActivateOnServer <Server Name>
6. Adjust DNS records, if necessary, for SMTP, Outlook Web App, Autodiscover, Outlook Anywhere, and
any legacy protocols. You can make adjustments manually, or use a third-party global-server DNS
server to make changes automatically.
The Switchback Process with Site Resilience

In most instances, after you recover the primary site, you need to perform a switchback to the primary
site. The switchback process includes the following steps:
1. Verify that the primary data center is capable of hosting Exchange services.
2. Reconfigure the DAG to add primary data center servers back into the switchover cluster. To do this,
run the following cmdlet:
Start-DatabaseAvailabilityGroup <DAG Name> ActiveDirectorySite <Primary Site Name>
3. If required, reconfigure the DAG to use the primary sites witness server. To do this, run the following
cmdlet:
Set-DatabaseAvailabilityGroup <DAG Name> WitnessServer <Primary Site Witness Server>
4. Manually reseed or allow replication to update the primary data centers database copies.
5. Schedule downtime for the mailbox databases, and then dismount them.
6. Adjust DNS records for SMTP, Outlook Web App, Autodiscover, Outlook Anywhere, and any legacy
protocols. You can accomplish this manually, or you can take advantage of third-party global-server
DNS server that performs the change automatically, and points it back to the primary data center.
7. Move the active databases back to primary data center by running the following cmdlet, and then
mount the databases in primary data center.
Move-ActiveMailboxDatabase <Database> ActivateOnServer <Server in Primary Site>

Best Practices for Site Resilient Solutions
By implementing certain best practices, you can ensure a successful, highly available, multiple-site
configuration. To begin, reduce failover time by using a TTL of five minutes or less on DNS records for all
relevant namespaces. Using a low TTL enables the DNS clients to more quickly discover DNS entries that
point to the secondary site.
If a failure occurs, it is important to ensure that the system works as designed. Therefore, you should
continually monitor and verify that all messaging-system components are functioning properly. To do
this, monitor all aspects of the Exchange Server 2010 environment to ensure that it is functioning
normally, and that mailbox data is successfully replicating to the secondary site in a timely manner. Next,
you can schedule periodic failover tests to provide an additional level of preparation, and to validate the
configuration and operation of the cross-site failover process.
You also should follow a change management process to ensure that each Mailbox server in the DAG,
each Client Access server, and each Hub Transport server are configured correctly and have the same
updates applied. This reduces the possibility of incompatibilities and unexpected behavior if a failover
occurs.
Finally, it is recommended that you follow the Windows Server Failover Clustering best practice of having
each node connected to multiple networks. Separating the MAPI and replication networks provides
enhanced performance. In some cases, you might also create multiple replication networks to provide
redundancy. However, to avoid network crosstalk, the MAPI and replication networks must not be able to
route to each other.
Question: In your organization, do you regularly perform disaster recovery activities such as
recovering a backup in Exchange Server?
Lab: Implementing High Availability
Lab Setup
2. Ensure that the 10135B-VAN-DC1, 10135B-VAN-EX1, 10135B-VAN-EX2, and the 10135B-VAN-EX3
3. If required, connect to the virtual machines. Log on to the virtual machines as

Lab Scenario
You are the messaging administrator for A. Datum Corporation. You have completed the basic installation
for three Exchange servers. Now you must complete the configuration so that they are highly available.
Exercise 1: Deploying a DAG

Scenario
You must complete the Mailbox server high availability configuration by creating a DAG and making the
Accounting database highly available.
1. Create a DAG named DAG1 by using the Exchange Management Shell.
2. Create a mailbox database copy of the Accounting database.

3. Verify successful completion of database copying.
4. Suspend the database copy on VAN-EX2.
X Task 1: Create a DAG named DAG1 by using the Exchange Management Shell
2. Use the New-DatabaseAvailabilityGroup cmdlet to create a DAG with the following information:
Name: DAG1
WitnessServer: \\VAN-DC1\FSWDAG1
WitnessDirectory: C:\FSWDAG1
IP Address: 10.10.0.80
3. Use the Add-DatabaseAvailabilityGroupServer cmdlet to add VAN-EX1 as a member of DAG1.

5. On the Database Availability Groups tab, add VAN-EX2 as a member of DAG1.
X Task 2: Create a mailbox database copy of the Accounting database

2. On the Database Management tab, add a mailbox database copy of Accounting to VAN-EX2.
X Task 3: Verify successful completion of database copying

On VAN-EX1, view the properties of the Accounting database, and ensure its status is Healthy.
X Task 4: Suspend the Accounting database copy on VAN-EX2

On VAN-EX1, suspend the Accounting database copy on VAN-EX2.
Results: After this exercise, you should have created a DAG and a mailbox database copy of the
Accounting database. The Accounting database copy on VAN-EX2 should remain in a suspended state.
Exercise 2: Deploying Highly Available Hub Transport and Client Access

Servers
Scenario
The network team used a hardware load balancer to load balance VAN-EX1 and VAN-EX2 for Client
Access connections. They have assigned a load balanced IP address of 10.10.0.30, and have created a DNS
record for the name CASArray.adatum.com. Now you must complete the Client Access configuration.
1. Create and configure a client access array for CASArray.adatum.com.
2. Assign the client access array to the databases.
X Task 1: Create and configure a client access array for CASArray.adatum.com

1. On VAN-EX1, open Exchange Management Shell.
2. Use the New-ClientAccessArray Fqdn casarray.adatum.com Name CASArray.adatum.com
Site Default-First-Site-Name cmdlet to create a new client access array named
CasArray.adatum.com for the Default-First-Site-Name Active Directory site.
X Task 2: Assign the client access array to the databases

1. On VAN-EX1, use the Exchange Management Shell to retrieve a list of all of the databases with the
Get-MailboxDatabase | ft Name, Server, RPC* cmdlet.
2. Use the Get-MailboxDatabase |Set-MailboxDatabase RpcClientAccessServer

casarray.adatum.com cmdlet to assign each database on VAN-EX1 and VAN-EX2 the
CasArray.adatum.com client access array as the RpcClientAccessServer.
3. At the PS prompt, use the Get-MailboxDatabase | ft Name, Server, RPC* cmdlet to verify the
correct setting.
Results: At the end of this exercise, you should have created a client access array and assigned it to the
databases.
Exercise 3: Testing the High Availability Configuration

Scenario
You have completed the high availability configuration. You now must verify that the high availability
configuration is working properly.
1. Create a SMTP connector associated with VAN-EX1 and VAN-EX2.
2. Stop the SMTP service on VAN-DC1.

3. Send an email to an internal user and an external SMTP address.
4. Use Queue Viewer to locate the message in the queue.
5. Start SMTP service on VAN-DC1 to allow queued message delivery.
6. Verify that the messages were removed from the shadow redundancy queue.
7. Verify the copy status of the Accounting database copy and resume the database copy.
8. Perform a switchover on the Accounting database to make the VAN-EX2 copy active.
9. Simulate a server failure.
X Task 1: Create a SMTP connector associated with VAN-EX1 and VAN-EX2

1. On VAN-EX2, if required, open Exchange Management Console.
2. Create an SMTP send connector named Internet Mail, and then configure an address space of * for
the connector.
3. Add VAN-DC1.adatum.com as the Smart host for the connector, and VAN-EX1 and VAN-EX2 as the
source servers.
X Task 2: Stop the SMTP server on VAN-DC1

On VAN-DC1, stop the Simple Mail Transfer Protocol (SMTP) service.
X Task 3: Send an email to an internal user and an external SMTP address

1. On VAN-EX1, log on to Outlook Web App as Adatum\Jason with the password Pa$$w0rd.
2. Create and send a new email addressed to terry@contoso.com and jane@adatum.com.
X Task 4: Use Queue Viewer to locate the message in the queue

1. On VAN-EX2, open Queue Viewer.
2. Connect to VAN-EX1 and VAN-EX2 to locate which server queues the email sent from Jason.
3. Make note of the server where the message is queued.
4. Examine the shadow redundancy queue on VAN-EX3.

X Task 5: Start SMTP service on VAN-DC1 to allow delivery of the queued message
1. On VAN-DC1, open Server Manager.
2. Start the SMTP service.
X Task 6: Verify that the messages were removed from the shadow redundancy queue
1. On VAN-EX2, open Queue Viewer.
2. Connect to VAN-EX3, where the message was queued in the shadow redundancy queue, and then
verify that it is no longer queued.
X Task 7: Verify the copy status of the Accounting database, and resume the database
copy
2. View the database copy health on the Suspended copy on VAN-EX2.

3. Resume the database copy on VAN-EX2, and wait until the copy status is Healthy.
X Task 8: Perform a switchover on the Accounting database to make the VAN-EX2

copy active
2. Verify that the active Accounting database is on VAN-EX1.
3. Select the Accounting database on VAN-EX2, and then activate the copy.
X Task 9: Simulate a server failure

1. On VAN-EX1, open the Exchange Management Console, and view the status of the Accounting
database.
2. In Hyper-V Manager, revert 10135B-VAN-EX2.
3. Verify the Accounting database is now active on VAN-EX1.
Results: After this exercise, you should have verified that the mailbox databases could fail over and switch
between DAG servers, and that Hub Transport shadow redundancy is working properly.

following steps:

Important Start the VAN-DC1 virtual machine first, and ensure that it starts fully before
Review Questions
1. What are the requirements for using the Datacenter Activation Coordination mode?
2. Which Exchange Server 2010 feature provides fault tolerance for message delivery?
3. In which scenarios might you use hardware load balancing with Edge Transport servers?
4. Besides planning for Exchanger Server failures, what other failures should you consider?
5. In which scenarios might you use hardware load balancing with Edge Transport servers?
6. To make a highly available Exchange Server 2010 organization, which components must be highly
available?
7. How many networks should you use for a DAG?
Common Issues Related to Creating High Availability Edge Transport Solutions

Identify the causes for the following common issues related to high availability Edge Transport servers,
and fill in the troubleshooting tips. For answers, refer to relevant lessons in the module.
Inbound email is not being

delivered evenly across all of the
Edge Transport servers.
After deploying highly available

Edge Transport servers, outbound
email is being returned as
possible spam.

1. An organization has several branch offices with a small number of employees. However, the
organization needs to deploy a high availability solution in the remote offices. What configuration
can it deploy to meet it business needs?
2. An organization uses a variety of service-level agreements for database availability for different
business units. It wants to minimize the number of mailbox servers it deploys. How can it do this?
Best Practices Related to Designing a High Availability Solution

Identify all possible failure points before designing a solution. Even the most elaborate and expensive
designs can have a simple and crippling failure point.
Document all of the components to the solution so that everyone involved in the deployment
understands how the solution is configured.
Follow change-management procedures. In some environments, it may be tempting to skip these
steps. However, not following proper change-management procedures often leads to extended,
unplanned downtime.
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 mailbox database 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.
8-1
Module 8
Implementing Backup and Recovery
Contents:
Lesson 1: Planning Backup and Recovery 8-3
Lesson 2: Backing Up Exchange Server 2010 8-12
Lesson 3: Restoring Exchange Server 2010 8-22

Lab: Implementing Backup and Recovery 8-35
8-2 Implementing Backup and Recovery
Module Overview
Your Microsoft Exchange Server databases contain the messages for all of your users. Thus, these
databases contain the data that is most important for you to ensure is retained and backing up the
databases that contain these messages is one of your key concerns regarding your messaging system.
Sometimes users accidentally delete their emails, and you, as the administrator, must restore their
messages. This can take a long time.
Microsoft Exchange Server 2010 contains new backup and restore features such as Exchange Native Data
Protection that you should consider before using the traditional backup-to-tape approach that most
organizations use nowadays. This module describes backup and restore features of Exchange Server 2010,
and details what you need to consider when you create a backup plan.
Plan backup and recovery.
Backup Exchange Server 2010.
Restore Exchange Server 2010.

Lesson 1
Planning Backup and Recovery
Before deciding on which backup type you want to use and which software to buy, you first need to
consider your available options. Exchange Server 2010 provides many new options for backing up your
databases and restoring single items.
In this lesson, you will learn the important considerations for backing up and restoring Exchange Server
2010, so that you can create a good plan for your organization.
Describe the importance of planning for disaster recovery.
Describe what you need to consider for highly available mailbox databases.
Explain what Exchange Native Data Protection is.
Identify and mitigate potential Exchange Server 2010 disasters.
Recover deleted items.

Describe backup and restore scenarios.
Discussion: The Importance of Planning for Disaster Recovery
This discussion details the importance of disaster recovery planning and reviews your organizations
current disaster recovery plans.
Question: What current plan does your organization have for disaster recovery?
Question: What issues have you seen with your current disaster recovery process?
Considerations for Highly Available Mailbox Databases
Before you can decide on what backup solution to use for Exchange 2010, it is important that you plan
your mailbox databases and storage solutions carefully. When planning a mailbox database deployment,
an organizations first critical decision is whether it should deploy database availability groups (DAGs) or
choose to implement standalone servers without any high availability solution. This decision will have a
significant impact on how the database and storage solution will be implemented.
Planning Mailbox Database Deployments Without DAGs

When organizations choose not to implement DAGs, the planning process for mailbox database
deployment is similar to the planning process for non-high available deployments in previous Exchange
server versions. With this type of deployment, organizations must understand that any type of failure will
result in downtime to their messaging solution, and they will have to restore their data and services by
using carefully planned backup procedures and strategies.
If your company chooses not to implement DAGs, then the following recommendations apply:
Backup policies. Because you only have one copy of the database, backup and restore becomes your
primary means of recovering from a database failure. This means that consistently backing up the
database is critical.
Mailbox database size. The maximum database size should be determined by the capacity of the
backup and restore process and the service level agreement (SLA) for recovering databases. The
Exchange 2010 Mailbox Server Role Requirements Calculator recommends 200 GB limit for databases
without DAGs.
Database and transaction log locations. With a single copy of the database, it is important that the
database and transaction logs be stored on separate drives, for performance and recovery reasons.
Storage solution. With a single copy of the database, providing redundancy at the storage level is very
important. You should use SANs with high levels of redundancy to remove a single point of failure.
Use redundant array of independent disks (RAID) 5 to enhance performance and fault tolerance for
databases, RAID 1 to provide fault tolerance for transaction logs and databases, and RAID 10 for
transaction logs if there is high demand for performance.
Considerations for Planning Mailbox Database Deployments with DAGs

The planning process for the mailbox database deployment changes when organizations choose to
implement DAGs. When databases are stored on multiple servers, users may not even be aware of a server
or database failure. These companies might choose not to perform backup and use Exchange Native Data
Protection (described in the next topic) to protect their data. If your company chooses to deploy DAGs,
then the following recommendations apply:
Backup policy. With DAGs, high availability is provided by having multiple database copies, so backup
and restore becomes much less important. With a sufficient number of databases, companies can
consider performing backups on larger time intervals or can even remove backup procedures
completely.
Mailbox database size. Because of the decreased importance of backup and recovery, the primary
consideration for database size becomes how long it would take to reseed the database if one
copy is lost. As such, the databases can be much larger. The Exchange 2010 Mailbox Server Role
Requirements Calculator recommends up to 2 terabytes (TB) for databases when DAGs are used.
Database and transaction log locations. With multiple database copies, separating the databases and
transaction log files is less important. Companies may still choose to do so for performance reasons,
but it is not required for redundancy and recovery reasons. If backup is not performed in the
organization, you should enable circular logging to prevent transaction logs from filling up the disks.
Storage solution. With multiple database copies that provide redundancy, it is less important to
consider an expensive disk system, such as SAN. You will more likely use DAS because of its lower
cost. Furthermore, if your organization has three or more copies of the databases, then you will more
likely use Just a bunch of disks (JBODs).
Question: When would you want or need to create multiple databases?

What Is Exchange Native Data Protection?
Compared to the previous Exchange Server versions, Exchange Server 2010 enables a much tighter
integration of high availability with disaster recovery, especially if the new Exchange Server 2010 high
availability features are sufficient to satisfy your backup requirements.
Exchange Server 2010 includes a new feature called Exchange Native Data Protection that allows you to
reduce or completely remove your traditional backup solutions for mailboxes and Exchange servers. You
should carefully consider whether this feature meets your disaster recovery requirements. Exchange
Native Data Protection includes the following features:
1. High availability minimizes downtime and data loss. If Exchange Server 2010 DAGs are the primary
means of disaster recovery, their high availability features allow you to minimize downtime and data
loss in the event of a mailbox database or Mailbox server failure. With DAGs, you can spread database
copies across multiple data centers or Active Directory Domain Services (AD DS) sites, which allows
you to address data center failures, and maintain offsite copies of a database. In some cases, it can be
less expensive to provide multiple copies of databases than it is to backup up very large databases.
2. Single item recovery and litigation hold policies for recovering deleted messages. In Exchange Server
2010, single item recovery ensures that all deleted and modified items are preserved so that you can
recover them. Users can no longer completely purge items from their mailboxes. Legal (or litigation)
hold preserves electronically stored information such as email messages so that users cannot delete
them. This feature replaces the necessity of performing a restore when a user deletes messages from
a mailbox when a compliance requirement requires investigating that mailbox.
3. Point-in-time database recovery with lagged copies of mailbox databases. When you configure a
mailbox database copy, you can configure the database copy to delay replaying the log files for as
many as 14 days. Thus, you continuously maintain a database in the state it was in during the
previous days or weeks. This means that if you have an issue with your current database, such as a
script changing many items at once, you can revert to a lagged database copy and commit the
transaction logs to a specific time.
4. Archive mailboxes, retention and archive policies, and Multi-Mailbox Search for managing large
mailboxes. By configuring archive mailboxes, you can provide users with a storage location for old
messages. You can also automate the process of managing messages in user mailboxes, including
moving messages into the archive mailbox, by configuring retention and archive policies. All of the
messages are available to the user, and can also be accessed through Multi-Mailbox Search.
As you consider implementing these features, you should evaluate the cost of your current backup
infrastructure, including hardware, installation, and license costs, and the management cost associated
with recovering data and maintaining the backups. Additionally, you should determine the SLAs for
protecting against and recovering from data lose or service failures. Depending on your organizations
backup requirements and SLAs, Exchange Server 2010 Native Data Protection may provide lower total
cost of ownership (TCO) than a traditional backup environment while at the same time ensuring that you
comply with the SLAs.
Even though it may appear that highly available deployments no longer require traditional backups, you
may still require them in your environment. Integrating high availability features as an alternative to
backups only works for the mailbox database, not for other Exchange Server resources, such as the Hub
Transport configuration. You still may need to consider using traditional backup for your other Exchange
2010 server roles.
Question: Would Exchange Native Data Protection be an option for your organization?
Disaster Mitigation Options in Exchange Server 2010
As you prepare to implement disaster-recovery solutions in Exchange Server 2010, you first must identify
the potential risks to the Exchange Server environment, and then identify the options for mitigating those
risks. The following table lists potential risks and the Exchange Server 2010 options for mitigating the risks.
Risks Risk mitigation strategies
Loss of a single Configure single item recovery by using the Recoverable Items folder.
message This option is described in the topic Options for Recovering Mailbox
Data and Databases later in this module.
Recover messages from backup by using the recovery database.
Loss of a single mailbox Configure mailbox-retention settings to ensure that you can recover
most deleted mailboxes before they are deleted permanently.
Recover mailbox by using the recovery database.
Loss of a database or Create a DAG on another server.

server Back up the Exchange Server 2010 data, and recover lost mailbox
databases from backup.
Install Exchange Server 2010 with /m:RecoverServer.
Loss or corruption of a Create a lagged database copy in a DAG environment.

mailbox database Back up the Exchange Server 2010 data, and recover lost mailbox
databases from backup.
Loss of a public folder Implement public folder replicas on other computers running Exchange
database Server 2010.
Question: What mitigation strategy can you follow to be able to recover single messages for
a mailbox?
Demonstration: Recovering Deleted Items
In this demonstration, you will review how to configure the global hold policy for recoverable items, so
that you can recover a deleted folder by using the Discovery Search Mailbox.
Demonstration Steps
1. On VAN-EX1, at the Exchange Management Shell prompt, type
Set-Mailbox Scott SingleItemRecoveryEnabled $true, and then press Enter.
2. At the Exchange Management Shell prompt, type New-ManagementRoleAssignment -Role

Mailbox Import Export -User adatum\administrator, and then press Enter.
3. In the Exchange Management Console, assign the Administrator account full access permissions to
the Discovery Search Mailbox.
4. In Scott MacDonalds mailbox, create a new folder, populate that folder with messages, delete the
folder, purge them from the Deleted Items folder, and clean the Recover Deleted Items.
5. Login to Microsoft Outlook Web App as Administrator, change to Options and in the Select what
to manage drop-down list, select My Organization.
6. In the Administrator Roles tab, add Administrator to the Discovery Management role.
7. Logout and login to Outlook Web App as Administrator, change to Options and in the Select what
to manage drop-down list, select My Organization.
8. Define a Mailbox Search with the following settings:
Mailboxes to Search: Scott MacDonald
Search name: Scott Recovery
Copy the search results to the destination mailbox: Checked
Select a mailbox in which to store the search results: Discovery Mailbox

Enable deduplication: Unchecked
Send me an email when the search is done: Checked
9. Open the Discovery Search Mailbox, and verify that it contains the deleted message.
10. Use the Search-Mailbox Discovery Search Mailbox -TargetMailbox Scott -TargetFolder
Restored Items cmdlet to recover the deleted items to its original mailbox.
11. Verify that the message was recovered by accessing Scott MacDonalds mailbox.
Question: What is the benefit of using this feature to recover mailboxes compared to
existing brick-level backup solutions?
Lesson 2
Backing Up Exchange Server 2010
Backing up your companys data is the most serious task in your Exchange Server installation. You cannot
recover necessary data if you have not backed it up correctly. In this lesson you will learn the different
ways that you can back up data with Exchange Server 2010.
Describe the backup changes in Exchange Server 2010.

Describe the backup requirements for Exchange Server 2010.
Describe how a Volume Shadow Copy Service (VSS) backup works.
Select an Exchange Server backup solution.
Back up Exchange Server 2010.

Changes to Backup in Exchange Server 2010
Exchange Server 2010 changes to the backup application-programming interface (API) and the underlying
database structure affects how you backup the Exchange Server database.
Removal of ESE Streaming APIs for Backup and Restore

Previously, Exchange Server used Extensible Storage Engine (ESE) streaming APIs for backup and restore.
Now, Exchange Server 2010 supports only VSS-based backups. To back up and restore Exchange Server
2010, you must use an Exchange Server-aware application that supports the VSS writer, such as Microsoft
System Center Data Protection Manager or a third-party Exchange Server-aware, VSS-based application.
Storage Group Removal

One significant change in Exchange Server 2010 is the removal of storage groups. In Exchange Server
2010, each database is associated with a single log stream as represented by a series of 1 megabyte (MB)
log files. Each Mailbox server can host up to 100 active and passive databases.
Database Not Closely Linked to a Specific Mailbox Server

Another significant change for Exchange Server 2010 is that databases no longer link closely to a specific
Mailbox server. Database availability groups expand the systems use of continuous replication, by
replicating a database to multiple servers. This provides better database protection and increases
availability. If failures occur, the other servers with database copies can mount the database.
Use DAGs to Implement Exchange Native Data Protection

Because you can have multiple database copies hosted on multiple servers, you also should consider using
Exchange Native Data Protection for your Exchange Server organization in which you enable circular
logging on your databases. This removes the transaction log files so they do not pile up. Transaction log
files are removed when you do a full Exchange Server backup. Circular logging accomplishes the same
task when using Exchange Native Data Protection.
Backup Requirements for Exchange Server 2010
The backup requirements for Exchange Server 2010 computers differ depending on the Exchange server
roles that you install on the computers. The following table lists the information that you need to back up
for each Exchange server role:
Exchange server role Backed-up data Purpose
All roles System State of server and System State includes the local
AD DS domain controllers configuration data of the machine
AD DS stores most Exchange Server
configuration information, which is required
to rebuild the server using Recover Server
mode
Mailbox server Databases and transaction Restore data if a database or storage group
logs is lost
Client Access server Server certificates used for Restore the server certificate on a new Client
Secure Sockets Layer (SSL) Access server
Specific Internet Restore IIS configuration
Information Server (IIS)
configuration
Hub Transport server, Message-tracking logs Restore tracking information for analysis
Edge Transport server
Edge Transport server Content-filtering database Restore the content-filtering configuration

Restore the Edge Transport server
configuration by enabling edge
synchronization
Unified Messaging Custom audio prompts Restore audio prompts

server
The Exchange Server environment includes additional information, such as the Offline Address Book,
availability data that a local folder stores, and other configuration data. This information is rebuilt
automatically when you rebuild the Exchange Server environment. AD DS store much of the
configuration information, which you can restore only if an AD DS is available. You must ensure that your
disaster-recovery planning includes backing up and restoring AD DS.
How Does a VSS Backup Work?
Microsoft Exchange Server 2007 and Microsoft Exchange Server 2003 include two different options
for data backup and recovery: ESE streaming backup APIs and support for the VSS backup APIs. ESE
streaming APIs are not available in Exchange Server 2010, thus you must back up Exchange Server with
VSS backup APIs.
What Is VSS?
VSS provides the backup infrastructure for Windows Server 2008, as well as a mechanism for creating
consistent point-in-time data copies, known as shadow copies.
VSS produces consistent shadow copies by coordinating with business applications, file-system services,
backup applications, fast-recovery solutions, and storage hardware. It includes the following components:
Writer. The VSS writer that is included with Exchange Server 2010 and that coordinates Exchange
Server 2010s input/output (I/O) with VSS.
Requestor. Backup or restore application, such as Windows Server Backup.
Provider. Low-level system or hardware interfaces, such as Storage Area Networks (SANs).
How VSS Backup Works

Backup solutions that use VSS create a shadow copy of the disk as the backup process begins. Then,
Exchange Server creates the backup with the shadow copy rather than the working disk, so that backup
does not interrupt normal operations.
This method offers the following advantages:
It produces a backup of a volume that reflects that volumes state when the backup begins, even if
the data changes while the backup is in progress. All the data in the backup is internally consistent,
and it reflects the volumes state at a single point in time.
It notifies applications and services that a backup is about to occur. The services and applications,
such as Exchange Server, therefore can prepare for the backup by cleaning up on-disk structures and
flushing caches.
Exchange Server Support for VSS Backup

To perform a VSS backup, you must enable the VSS on the Exchange server, and the third-party backup
solution must support the VSS backup and restore APIs.
Exchange Server 2010 support for VSS has the following limitations:
VSS support is at the database level.
VSS support is for normal backups and copy backups, but not for incremental or differential backups.
Selecting an Exchange Server Backup Solution
When selecting a backup solution for Exchange Server, you must consider your systems characteristics
and those of the software and hardware.
System Characteristics
System characteristics to consider include:
The amount of data you are backing up.
The time window in which the backup can occur.
The type of backup you are performing.
Recovery time requirements.
Archiving requirements.
Backup Software Selection Criteria

The following table provides some basic criteria for selecting backup software. Select the software that
best meets the needs of your Exchange Server deployment and disaster-recovery requirements.
Selection criteria Explanation
Backup architecture Your backup software should provide support for any operating systems that
you have. Additionally, the backup software should be able to back up
Exchange Server to your desired media, either on the local computer or over
the network. Windows Server Backup is not capable of backing up to a remote
tape drive.
Scheduling Your backup software should support the ability to schedule backups that you
require for your organization. Most backup software allows you to schedule
jobs at any time you require. However, it is easier to configure in some software
packages.
Brick-level backup If desired, ensure that your software supports brick-level backups.
support
Exchange Server VSS Your backup software must support the Exchange Server Backup VSS API to
API support perform online backups successfully.
Tape management Different backup software has varying degrees of flexibility for tape
management. This includes automated naming of blank tapes and preventing
existing tapes from being overwritten accidentally.
Vendor support Vendor support is essential if you experience any problems during disaster
recovery. Ensure that vendor support is available for your backup software.
Disaster-recovery Some backup software has a disaster-recovery option that provides complete
support disaster recovery for a failed server, including Exchange Server.
Hardware support Your backup software must support the technologies that your company uses,
including clustering or SANs.
Windows Server Backup

When you install the Exchange Management Console on a server running Windows Server 2008, it
updates Windows Server Backup to support Exchange Server 2010. Windows Server 2008 enables you to
perform VSS-based backups of Exchange Server data.
For many smaller organizations, Windows Server Backup provides a sufficient solution. However, larger
organizations may require a more robust backup strategy. Windows Server Backup limitations include:
Backups only performed at volume level. You can only perform full backups, not incremental or
differential backups.
Backup support for active databases but not passive databases.
Only available for Windows Server 2008 or Windows Server 2008 R2.
Windows Server Backup command-line tools are not compatible with Exchange Server 2010.
Backup Hardware Selection Criteria

The two most common types of backup hardware are tape and disk. Which you use depends on your
requirements. The following table lists the characteristics of using a tape or disk for backup:
Characteristic Tape Disk server Portable disk
Speed Slower Faster Faster
Capacity Up to 400 GB per tape Large 1+ terabyte (typical)

(Tape libraries allow the use of multiple tapes.) per disk
Off-site storage Yes Typically no Yes
Media Excellent Excellent OK

durability
Many organizations use disk-based backup as the first tier, and then utilize tape as a second tier. This
allows you to perform primary backups quickly to disk. Typically, any data that you need to archive off site
is backed up to tape from the disk backup.
Demonstration: How to Back Up Exchange Server 2010
In this demonstration, you will review how to install the Windows Server Backup program and how to use
Windows Server Backup to back up Exchange Server 2010. You will also use the Event Viewer to verify that
the Exchange Server databases were backed up correctly.
Demonstration Steps
1. In Server Manager, add the Windows Server Backup feature.
2. In Windows Server Backup, create a backup set to back up the C: drive and run the backup.
3. In Event Viewer, verify that the Exchange Server databases are part of the backup and that they have
been backed up successfully.
Question: Do you plan to can use Windows Server Backup as your primary Exchange Server
backup solution?
Lesson 3
Restoring Exchange Server 2010
Another important component in ensuring availability of email services is planning for recovery.
Organizations that implement high availability solutions still need to plan for scenarios in which the high
availability solutions are not enough. These scenarios might include something as minor as needing to
recover a single mailbox or message, to something as catastrophic as losing an entire data center. This
lesson discusses how to restore Exchange Server 2010.
Repair an Exchange database corruption.
Describe restore strategies.

Describe the process to recover data by using the recovery database.
Recover data by using the recovery database.
Describe dial-tone recovery.
Implement dial-tone recovery.
Recover computers that run Exchange Server.

Repairing Exchange Database Corruption
In Exchange Server 2003 and Exchange Server 2007, you can repair a mailbox or a public folder with the
Information Store Integrity Checker (Isinteg.exe) tool. To repair mailboxes, you need to dismount the
mailbox database on which that mailbox resides, and run the fixes while the database is offline.
Exchange Server 2010 does not use Isinteg.exe. Instead, you use the New-MailboxRepairRequest cmdlet
to detect and repair a corrupted mailbox while leaving the mailbox database online. This cmdlet was
introduced with Exchange Server 2010 Service Pack 1 (SP1). For public folders, you need to use the New-
PublicFolderDatabaseRepairRequest cmdlet to detect and correct replication issues in the public folder
database.
Note Once you use these cmdlets to begin the repair process, you can stop the process
only by dismounting the database.
The New-MailboxRepairRequest Cmdlet

Use the New-MailboxRepairRequest cmdlet to detect and fix mailbox corruptions. You can run this
cmdlet against a mailbox or against a database. During the repair process, only the current mailbox being
repaired is inaccessible; all other mailboxes in the database remain operational.
The New-MailboxRepairRequest cmdlet detects and fixes the following types of mailbox corruptions.
Corruption type Description
SearchFolder Detects and fixes Search folder corruptions.
AggregateCounts Detects and fixes aggregate counts on folders that are not reflecting the correct
values.
FolderView Detects and fixes views on folders that are not returning the correct contents.
ProvisionedFolder Detects and fixes provisioned folders that are pointing incorrectly into parent
folders that are not provisioned.
For example, the following cmdlet detects and repairs all corrupt items for user Christines mailbox:
New-MailboxRepairRequest -Mailbox Christine -CorruptionType

ProvisionedFolder,SearchFolder,AggregateCounts,Folderview
The New-PublicFolderDatabaseRepairRequest Cmdlet

The New-PublicFolderDatabaseRepairRequest cmdlet detects and fixes replication issues in public
folder databases. This cmdlet always runs against a public folder database. During the repair process, only
the public folder currently being repaired is inaccessible. The public folder database itself is available.
The New-PublicFolderDatabaseRepairRequest cmdlet detects and fixes replication state corruptions

(ReplState).
For example, the following cmdlet detects and repairs all corrupt items for the Public Folder Database 1
public folder database:
New-PublicFolderDatabaseRepairRequest Database Public Folder Database 1

CorruptionType ReplState
Question: In your Exchange Server environment, you experience corrupt mailbox items.
What can you do to remove these corrupt items from the mailboxes?
Restore Strategies
You can use several strategies to restore Exchange Server data. The strategy that you select depends upon
the data that you need to recover.
Hold Policy and Single Item Recovery

This is a new Exchange Server 2010 feature. When you enable the Single Item Recovery feature for a
mailbox, it keeps items that are purged from the Deleted Items folder in a new dumpster folder for a
specific time. This folder is not accessible to the end user, but it is accessible to administrators assigned to
the Discovery Management role. Essentially, you can ensure that items are not deleted for the duration
that you typically keep backups.
Deleted Mailbox Retention

By default, the mailbox database stores deleted mailboxes for 30 days. Within those 30 days, you can
reconnect the mailbox to another account and access its messages. After you connect the mailbox to an
account, the deleted mailbox retention period restarts if the mailbox is deleted again.
You can extend the deleted mailbox retention period on mailbox databases. However, extending the
deleted mailbox retention period causes the mailbox database to grow to hold the additional deleted
mailboxes.
You can permanently delete mailboxes with the Removemailbox Permanent True cmdlet.
Database Restores
Restoring a database overwrites the existing database with a restored copy of the database. After you
restore the database, you can replay the current transaction logs to bring the database to its current state.
You typically restore a database when it becomes corrupt or a disk fails.
This type of restore affects all user mailboxes in the database. It is not suitable for recovering a mailbox or
deleted items, because replaying the transaction logs deletes the items again. Additionally, replaying the
transaction logs can take a long time.
Recovery Database
The recovery database restores databases without affecting current mailboxes. After you restore a
database to the recovery database, you can copy messages to a folder or merge them into user mailboxes.
This type of restore recovers mailbox content for a single mailbox, without affecting other users. However,
the recovery database has the following requirements and characteristics:
The server must have enough free disk space to restore the database. Effectively, there must be
enough total storage space on the server to store two database copies simultaneouslythe live
version and the restored version.
The server does not support public folder databases.
Dial-Tone Recovery
Dial-tone recovery is the process of implementing user access to email services without first restoring data
to user mailboxes. Dial-tone recovery enables users to send and receive email as soon as possible after a
database or server loss. This module discusses dial-tone recovery in more depth later.
Recovery Server
A recovery server is a dedicated server for restoring Exchange Server databases. This can be useful to test
backups to ensure they are capturing functions properly. However, improvements in recovery-database
performance reduces the requirement to use a recovery server for data recovery.
You install a recovery server in a completely separate forest from your production Exchange Server
organization. When you install the recovery server, you must configure it the same as the original server,
including the organization name, storage group name, and logical database name. Between the original
server and the recovery server, the LegacyExchangeDN attribute also must match.
Note For more information about the LegacyExchangeDN attribute, see the Microsoft
Knowledge Base article XADM: How to Use Legacydn.exe to Correct Exchange
Organization or Administrative Group Name.
After you restore a database to the recovery server, you can connect mailboxes on the recovery server to
users, and then save messages to a personal folder (.pst) file. Then you can import the PST file into a
mailbox on the production Exchange server.
Process for Recovering Data by Using the Recovery Database
The recovery database is a recovered database that can coexist on the same server that hosts the original
database. Users cannot access it directly. Only administrators can access it to recover single items, folders,
mailboxes, or complete databases from the recovery database.
The recovery database replaces the recovery storage group from previous Exchange Server versions.
You can use the Exchange Management Shell to create a recovery database.
Recovering Data by Using the Recovery Database

To recover data by using the recovery database, complete the following steps:
1. Restore the database that you want to recover.
2. Use the Exchange Management Shell to create a new recovery database.
3. Mount the recovery database, and merge the data from the recovery database mailbox into the
production mailbox. You can use the Exchange Management Shell restoremailbox cmdlet to
perform this task.
When to Use the Recovery Database

You can use the recovery database in the following scenarios:
Dial-tone recovery. When you implement dial-tone recovery, you set up a dial-tone mailbox database
on the same server or on an alternate server to provide temporary access to email services. You then
use the recovery database to restore the temporary data into the production database after you
recover the original database from backup.
Individual mailbox recovery. You can recover individual mailboxes by restoring the database that
holds the mailbox to the recovery database. Then you can extract the data from the deleted mailbox,
and copy it to a target folder or mailbox in the production database.
Specific item recovery. If a message no longer exists in the production database, you can recover the
database that held the message to the recovery database. Then you can extract the data from the
mailbox and copy it to a target folder or mailbox in the production database. However, you also
should consider by using hold policy for this situation, as recovering the database might be time
consuming.
Demonstration: How to Recover Data by Using the Recovery Database
In this demonstration, you will review how to create a recovery database and how to restore data to the
recovery database.
Demonstration Steps
1. Use Windows Server Backup to restore the Exchange Server databases to C:\DBBackup.
2. At the Exchange Management Shell prompt, type New-MailboxDatabase

-Name RecoverDB -Server VAN-EX1 -EDBFilePath c:\DBBackup
\C_\Program Files\Microsoft\Exchange Server\V14\Mailbox\Accounting
\Accounting.edb -Logfolderpath c:\DBBackup\C_\Program Files
\Microsoft\Exchange Server\V14\Mailbox\Accounting -Recovery, and then press Enter. This
command creates the recovery database using the recovered Accounting database.
3. Use the eseutil /p c:\dbbackup\c_\Program Files\Microsoft\Exchange Server\v14\Mailbox

\Accounting\Accounting.edb command to repair the recovered database.
4. At the Exchange Management Shell prompt, type Mount-Database RecoverDB, and then press
Enter.
5. Use the Get-MailboxStatistics -Database RecoverDB command to display the mailboxes in the
recovery database.
6. At the Exchange Management Shell prompt, type New-MailboxRestoreRequest -Identity

MichiyoSato -RecoveryDatabase RecoverDB, and then press Enter.
Question: What is the difference between using Single Item Recovery and performing a
restore by using the recovery database?
What Is Dial-Tone Recovery?
Dial-tone recovery is the process of implementing user access to email services without first restoring data
to user mailboxes. Dial-tone recovery enables users to send and receive email as soon as possible after a
database or server loss. Users can send and receive email messages, but they do not have access to the
historical mailbox data. You then can recover the database or server, and restore the historical mailbox
data. After you bring the recovered database back online, you can merge the dial-tone database and the
recovered database into a single up-to-date mailbox database.
When to Use Dial-Tone Recovery

Use the dial-tone recovery method when it is critical for users to regain messaging functionality quickly
after a mailbox server or database fails, and when you cannot restore historical data from a backup
quickly enough. The loss may result from hardware failure or database corruption. If the server fails, it will
take significant time to rebuild the server and restore the databases. If you have a large database that
fails, it may take several hours to restore the database from backup.
If the original mailbox server remains functional, or if you have an alternative mailbox server available, you
can restore messaging functionality within minutes by using dial-tone recovery. This enables continued
email use while you recover the failed server or database.
Process for Implementing Dial-Tone Recovery
There are several dial-tone recovery scenarios. However, all scenarios follow the same general steps.
Implementing Dial-Tone Recovery

Follow these general steps to implement dial-tone recovery:
1. Create the dial-tone database. For messaging client computers to regain functionality as quickly as
possible, create a new database for the client computers. There are two methods for creating the dial-
tone database:
a. Create the dial-tone database on the same server as the failed database. Use this method if the
drive that contained the database failed or if the database is corrupt.
b. Create the dial-tone database on a different server than the failed database. Use this method to
utilize a different server as a recovery server or if the original server fails.
2. If necessary, configure the mailboxes that were on the failed database to use the new dial-tone
database. You must configure the mailboxes to use the new database if you create the dial-tone
database on a different server.
3. If necessary, configure the Microsoft Office Outlook client profiles:
If the server with the failed database is operational, you do not need to reconfigure Office
Outlook client computers to use the new mailbox database. When the Outlook client computer
tries to connect to the mailbox, the client profile reconfigures automatically to use the mailbox
database on the original or new Mailbox server.
If the original server is not available, and you are using AutoDiscover for Outlook 2007 client
computers, the user profile updates automatically.
If you are using previous Outlook client computers, you need to reconfigure the user profiles
manually to use the new server.
If users are using Outlook Web App, they will connect automatically to their mailboxes when
they access Outlook Web App on a Client Access server.
Note At this point, users can connect to their mailboxes in the dial-tone database. The
dial-tone database does not contain any data, so the mailboxes will be empty. Additionally,
the database does not retain user-specific settings, such as folder hierarchy, Inbox rules,
meetings, and contacts. However, users should have messaging functionality. If the client
computers are running Outlook 2007 or Outlook 2003, and you configure the client
computers to run in cached mode, users receive a prompt to connect or work offline when
they connect to the dial-tone database. If users choose to connect to the server, they will
see an empty mailbox (local cached copy is replaced with the empty mailbox). If they
choose to work offline, they will see all of the historical data stored in the offline folders
(.ost) file.
4. Restore the failed databases from backup. After the dial-tone database is operational and you
reconfigure the client computers to use the new database, if necessary, you can work on restoring the
failed database. If the original server is operational, you can restore the database on the failed server
by using a recovery database. If the original server is not operational, you can recreate the failed
database on another server, and then restore both to the new server.
5. Merge the data in the two databases. Because you have restored messaging functionality by
implementing the dial-tone database, users will be sending and receiving email while you are
restoring the original databases. When the recovery is complete, users should be able to access both
the original and the dial-tone data. This means that you must merge the contents of the dial-tone
database with those of the original database. To do this, you will use the recovery database.
Best Practice
You should merge the dial-tone database into the original database. Be sure to initiate the merge in the
correct direction. The dial-tone database is likely to be much smaller than the original database, so the
merge will happen relatively fast. Not all of the features from the original mailbox will be available in the
dial-tone database. For example, any rules or forms that the user configured will not be available. For a
full list of features that you cannot recover during a dial-tone recovery, see the article Considerations and
best practices when resetting an Exchange mailbox database on the Microsoft Help and Support website.
This article also provides suggestions on how to recover these features. Note, however, that these client
features are restores if you merge the dial-tone database into the original database.
Process for Recovering Computers That Run Exchange Server
When recovering a failed Exchange Server, you have several options. The option you choose determines
the process that you use to restore the server.
Exchange Server Recovery Options

When you need to replace a failed server, you have the following options:
Restore the server. You can restore the server from a full computer backup set, and then restore
your Exchange Server information. When you restore a server, you are reproducing the server
configuration, including the server security identifier. This option is feasible only if you have a full
server backup, including the System State backup, and you have replacement hardware that is very
similar to the failed server. You would also use this option when you have an Exchange 2010 server
that has many custom configurations to it such as a Client Access Server (CAS) server role that uses
Windows Load Balancing for high availability, and also includes certificates with Outlook Web Access
redirection settings.
Rebuild the server. This option involves performing a new installation of Windows Server and an
Exchange Server 2010 installation in Recover Server mode, which gathers the previous settings
from AD DS and then you can restore your Exchange Server databases. This option is used most
often to recover standardized Exchange servers such as Mailbox or Hub Transport servers as their
configuration is mainly stored in AD DS. Additionally, we recommend that you use this method, which
the next section details, to recover a server.
Use a standby server. You can use a standby recovery server as part of the Mailbox server recovery
strategy. This option involves keeping recovery servers available with the operating system and other
software installed. Having available standby recovery servers reduces the time you need to rebuild a
damaged server.
Note We recommend that you do not use the restore server option for recovering
Exchange servers. Instead, you should rebuild the server by using the Recover Server
installation mode.
What Is Recover Server Mode?

If an Exchange server fails, and is unrecoverable and needs replacement, you can perform a server
recovery operation. Exchange Server 2010 Setup includes a switch called /m:RecoverServer that you can
use to perform the server recovery operation.
Running Exchange Server Setup with the /m:RecoverServer switch causes Setup to read configuration
information from AD DS for the server with the same name as that from which you are running Setup.
Once you gather the servers configuration information from AD DS, the original Exchange Server files and
services are installed on the server, and the Exchange server roles and settings that AD DS stored then are
applied to the server.
Important When you run Exchange Server Setup in Recover Server mode, it must be able
to connect to AD DS, and read the Exchange Server configuration information that links to
the name of the computer that is running Exchange Server. This means that the computer
account still must exist in AD DS. If you delete the computer account, you will not be able to
restore the Exchange Server.
Restoring a Server by Using Recover Server Mode

The steps for restoring a member server running Exchange Server 2010 are:
1. Install Windows Server 2008 on the computer that you are rebuilding. Use the same computer name
as the failed server. On the server that you are rebuilding, install any Windows Server 2008 service
packs and software updates that the damaged server was running.
2. Reset the AD DS computer account for the failed server. After resetting the account, join the
computer to the domain.
3. Install Exchange Server on the computer by running Exchange Server 2010 Setup in Recover Server
mode. To do this, run Setup /mode:RecoverServer from the Exchange Server installation files.
4. If you are recovering a Mailbox server, and the drives that contain the Exchange Server database files
and log files were lost, restore the Exchange Server 2010 databases and transaction logs to the server.
If you are recovering another server role, recover the role-specific information.
Note The Recover Server mode installation can recover only server configuration data that
AD DS stores. This means that the rebuild may not preserve every custom setting, or restore
data, such as custom scripts, that may have existed on the failed server. Therefore, you
should be prepared to recreate any Exchange Server configuration settings or files that you
cannot recover from AD DS.
Lab: Implementing Backup and Recovery
Lab Setup
running:

4. Log on to VAN-SVR1 as Administrator, using the password Pa$$w0rd.
5. In Microsoft Hyper-V Manager, click VANSVR1, and, in the Actions pane, click Settings.
7. Browse to C:\Program Files\Microsoft Learning\10135\Drives, click Exchange2010SP2.iso, and

then click Open.
8. Click OK.
9. On VAN-SVR1, close the AutoPlay dialog box.

Lab Scenario
You are a messaging administrator for A. Datum Corporation. Your organization has deployed Exchange
Server 2010. You now want to ensure that all Exchange Server-related data is backed up and that you can
restore not only the full server or database, but also a mailbox or mailbox folder.
Exercise 1: Backing Up Exchange Server 2010

Scenario
You must create a backup of your Exchange Server 2010 mailbox database to ensure that you can restore
it when necessary.
1. Populate a mailbox.
2. Perform a backup of the mailbox database by using Windows Server Backup.
3. Delete a message and a mailbox.
X Task 1: Populate a mailbox

1. On VAN-EX1, log on to Parnas mailbox by using Outlook Web App. Use the logon name
Adatum\Parna and the password Pa$$w0rd.
2. Send a message to George with the subject Message before Backup.
3. Restart the Microsoft Exchange Information Store service.
X Task 2: Perform a backup of the mailbox database by using Windows Server Backup
1. Use Server Manager to install Windows Server Backup.
2. Perform a custom backup of the C:\ drive by using a VSS full backup. Store the backup files on
\\VAN-DC1\Backup.
X Task 3: Delete messages in mailboxes

1. Log on to Georges mailbox by using the logon name Adatum\George and the password Pa$$w0rd,
and then delete the message from Parna.
2. Log on to Parnas mailbox by using the logon name Adatum\Parna and the password Pa$$w0rd,
and then delete all messages from the Sent Items folder.
Results: After this exercise, you should have created a backup of an Exchange Server database, and
deleted messages.
Exercise 2: Restoring Exchange Server Data

Scenario
Some of your users complain that they are missing messages from their mailboxes. You now need to use
the backup you created to recover their messages.
1. Restore the database by using Windows Backup.
2. Create a recovery database by using the backup files.

3. Recover a mailbox from the recovery database.
X Task 1: Restore the database by using Windows Backup

On VAN-EX1, using Windows Server Backup, recover the Exchange Server databases to an alternate
location: C:\DBBackup.
X Task 2: Create a recovery database by using the backup files

1. On VAN-EX1, create a recovery database by using the restored database in C:\DBBackup. Use the
following command to create the recover database:
New-MailboxDatabase -Name RecoverDB -Server VAN-EX1 -EDBFilePath

c:\DBBackup\C_\Program Files\Microsoft\Exchange Server\V14
\Mailbox\Accounting\Accounting.edb -Logfolderpath c:\DBBackup
\C_\Program Files\Microsoft\Exchange Server\V14\Mailbox
\Accounting-Recovery
2. In Exchange Management Shell, switch to the c:\dbbackup\c_\Program Files\Microsoft

\Exchange Server\v14\Mailbox\Accounting directory, enter the following command in the PS
prompt, and then press Enter:
eseutil /R E02 /i /d
3. Mount the recovery database by using the Mount-Database RecoverDB command.
4. List all mailboxes that are in the recovery database by using the Get-MailboxStatistics -Database
RecoverDB command.
X Task 3: Recover a mailbox from the recovery database

1. On VAN-EX1, recover a mailbox by using the Restoremailbox -Identity Parna -RecoveryDatabase
RecoverDB cmdlet.
2. Verify that you restored the message in the Sent Items folder by logging onto Parnas mailbox.
3. Use the Removemailboxdatabase -Identity RecoverDB command to remove the RecoverDB

database.
Results: After this exercise, you should have created a recovery database, and restored a complete
mailbox from the recovery database to their original locations.
Exercise 3: Restoring Exchange Servers (optional)

Scenario
After a hard-disk malfunction, one of your Exchange servers no longer is operational. You have a full
backup of the computer and the mailbox databases, so you need to restore everything to a newly
installed computer.
1. Shutdown VAN-EX1 and reset the computer account.
2. Prepare VAN-SVR1 as VAN-EX1.
3. Install Exchange Server 2010 with the RecoverServer mode.
4. Recover the mailbox databases from backup.

5. Test the recovery.
X Task 1: Shutdown VAN-EX1, and reset the computer account

1. In Hyper-V Manager, revert VAN-EX1 to the previous snapshot.
2. Using Active Directory Users and Computers, reset the VAN-EX1 computer account.
X Task 2: Prepare VAN-SVR1 as VAN-EX1

1. Rename VAN-SRV1 to VAN-EX1.
2. Join the computer to ADATUM domain.
X Task 3: Install Exchange Server 2010 with the RecoverServer mode

1. On the new VAN-EX1 server, run d:\setup /m:RecoverServer.
2. In Exchange Management Console, change Database Properties to This database can be

overwritten by a restore for all databases on the VAN-EX1.
X Task 4: Recover the mailbox databases from backup

Use Windows Server Backup to recover the Exchange Server databases.
X Task 5: Test the recovery

1. On the restored VAN-EX1, in the Exchange Management Console, mount the mailbox databases and
public folder database.
2. On VAN-DC1, open Internet Explorer and connect to https://VAN-EX1.adatum.com/owa. Log on

as Adatum\Parna with the password Pa$$w0rd, and then verify that the mailbox is accessible and
that all messages have been restored.
Results: After this exercise, you should have recovered a complete Exchange server by using a different
Windows Server, renaming it, installing Exchange Server in /m:RecoverServer mode, and recovering the
Exchange Server database from a backup. You have also tested the recovery.

following steps:

Review Questions
1. What kind of backup options for Exchange Server 2010 do you find suitable for your organization?
2. What options does Exchange Server 2010 include for restoring a single item from a mailbox?
Common Issues Related to Recovering Messages

Identify the causes for the following common issues related to recovering messages, and complete the
troubleshooting tips. For answers, refer to relevant lessons in the module.
Recover single mailbox items

quickly
Restore fails when it is urgent
Best Practices Related to Backup and Restore

Utilize your existing backup solution for Exchange Server backups, as you are already experienced
and familiar with it.
Try always to perform a full backup of your Exchange Server databases if you use a VSS-aware backup
solution. This reduces the time you need to recover the database to its most current state.
If you plan to implement Exchange Native Data Protection, create one more database copy on cheap
hard drives at a different site. This guarantees that you have an additional backup of your database
available.
9-1
Module 9
Configuring Messaging Policy and Compliance
Contents:
Lesson 1: Introducing Messaging Policy and Compliance 9-3
Lesson 2: Configuring Transport Rules 9-9
Lesson 3: Configuring Journaling and Multi-Mailbox Search 9-30

Lab A: Configuring Transport Rules, Journal Rules, and Multi-Mailbox
Search 9-41
Lesson 4: Configuring Personal Archives 9-47

Lesson 5: Configuring Messaging Records Management 9-54
Lab B: Configuring Personal Archives and Retention Policies 9-66

9-2 Configuring Messaging Policy and Compliance
Module Overview
Microsoft Exchange Server 2010 provides new tools for coping with a growing number of legal,
regulatory, and internal policy and compliance requirements that relate to email. Most organizations must
be able to filter email delivery based on several criteria, and to manage email retention and deletion. This
module describes how to configure the Exchange Server 2010 messaging policy and compliance features.
Describe messaging policy and compliance.
Configure transport rules.

Configure journaling and Multi-Mailbox Search.
Configure Personal Archives.
Configure messaging records management.

Lesson 1
Introducing Messaging Policy and Compliance
In most many countries, governments have implemented legislation that restricts the storage and
movement of certain information. Additionally, many organizations have implemented corporate security
policies that limit how to share information within the organization. Because email is a critical business
tools in most organizations, it is important that you configure your organizations messaging system so
that it is compliant with government legislation and corporate policies.
Messaging policies in Exchange Server 2010 enable messaging administrators to manage email messages
that are in transit and at rest, and ensure that your organization meets compliance requirements. This
lesson provides an overview of messaging policies and their use.
Describe messaging policy and compliance.
Identify compliance requirements.

Implement messaging policy and compliance.
What Is Messaging Policy and Compliance?
Messaging compliance features in Exchange Server 2010 consist of a set of rules and settings that restrict
message flow and storage. You can use these features to apply rules to messages as your organizations
users send and receive them. You can use the messaging policy and compliance features to regulate how
users store messages, and to search all user mailboxes for messages based on a variety of criteria. You can
apply these features to Exchange Server computers that are running the Edge Transport, Hub Transport,
and Mailbox server roles.
Types of Messaging Compliance Features

Exchange Server 2010 provides several options for implementing message policies and compliance:
Transport policies are rules and settings that you apply as messages pass through the Exchange
Server transport components. Transport policies restrict message flow or modify message contents
based on organizational requirements. For example, you can set restrictions on which users can send
email to each other and on message flow based on message contents. You also can apply legal
disclaimers to specific messages. You can configure transport rules on Hub Transport and Edge
Transport servers.
Exchange Server applies messaging records management policies to folders in users inboxes to
automate and simplify message retention. For example, you can configure a policy that retains
messages in user mailbox folders for a specific time, or you can configure a policy that automatically
deletes messages within a specific folder or within all the mailbox folders. Exchange Server 2010 also
provides retention tags that simplify the process for users who want to apply message retention or
deletion policies.
Journaling policies are rules and settings that enable you to save a copy of all messages that meet
specific criteria. For example, you can journal messages sent by a particular user or messages sent to a
particular distribution group. You can journal messages that recipients send or receive inside and
outside the organization.When you configure journaling, the messages are sent to a specified Simple
Mail Transfer Protocol (SMTP) address as a journal report. The journal report is an email message that
includes the Subject, Message ID, Sender, and Recipient of the original message together with an
attachment containing the original message.
Mailbox searching may be required for audit purposes to determine whether user mailboxes contain
specific types of content. With Exchange Server 2010, you can use the Exchange Control Panel to
search all user mailboxes for messages based on many different criteria.
Discussion: Compliance Requirements
Email is a primary means of communication in many organizations, and users typically send a great deal
of business information by email. This information may include confidential information, such as customer
data or business intelligence. One use of Exchange Server 2010 messaging policies is to provide features
that help you comply with legal requirements and corporate messaging policies regarding email
messages.
Question: What type of business does your organization conduct?

Question: What are some legislated compliance requirements for your organization?
Question: What additional compliance requirements does your organization have?
Question: How are you currently meeting these compliance requirements?

Options for Enforcing Messaging Policy and Compliance
Exchange Server 2010 provides many options for implementing messaging policies, including the
following:
Transport rules. You can define transport rules on both the Edge Transport and Hub Transport
servers. On Edge Transport servers, you can restrict message flow based on message data, such as
specific words or text patterns in the message subject, body, header, or From address; the spam
confidence level (SCL); and attachment type. You can configure the transport rules to quarantine
messages, drop or reject a message, append additional recipients to a message, and log an event. On
Hub Transport servers, you configure rules that support an extended set of conditions, which allows
you to control message flow based on distribution groups, internal or external recipients, message
classifications, and message importance.
Rights management integration. Exchange Server 2010 enables integration with Active Directory
Rights Management Service (AD RMS) to apply policies that restrict what recipients can do with their
received messages. For example, you can restrict users from printing or forwarding messages. You
also can use Microsoft Office Outlook or transport rules to enforce AD RMS templates, so that the
Office Outlook client or the Hub Transport server will apply the template based on specified message
criteria.
Message journaling. Exchange Server 2010 provides several options for saving copies of messages. For
example, you can configure journal rules on Hub Transport servers. You can journal messages
according to the messages distribution scope, and you can define the conditions that trigger the
journaling action by specifying as criteria an individual user, the sender, or the recipients distribution-
list membership. You also can configure message journaling for specific mailbox databases, or
implement message journaling as part of a messaging records management deployment.
Mailbox searching. The Multi-Mailbox Search feature enables users with the appropriate permissions
to search all mailboxes for specific content. In Exchange Server 2010, the mailbox search functionality
is available through the Multi-Mailbox Search interface in the ECP.The Multi-Mailbox Search interface
allows you to conduct searches across multiple mailboxes for items, including email, attachments,
Calendar items, Tasks, and Contacts. You can search across both primary mailboxes and archive
mailboxes.
Message retention and deletion. Administrators can use the messaging records management features
to retain messages that organizations require for business or legal reasons, and to delete unnecessary
messages. You can apply retention policies to folders that the administrator creates, and also to
default mailbox folders, such as the Inbox or Sent Items folders. When a message reaches a specified
retention limit, administrators can configure the messaging records management features to archive,
delete, or log the message, or flag it for user attention.
Personal Archives. Exchange Server 2010 allows you to create archive mailboxes for users so they can
store the contents of .pst folders and old messages that they want to retain. You can search and
manage archive mailboxes like any other mailboxes on the Exchange servers.
Lesson 2
Configuring Transport Rules
You can implement messaging policies and compliance by applying transport rules to messages as users
send them within the organization. By implementing transport rules, you ensure that all email messages
sent within the organization or to external recipients meet your organizations compliance requirements.
You also can apply rights management policies to messages by using transport rules. This lesson describes
how to implement transport rules in Exchange Server 2010.
Describe transport rules.
Describe transport rule components.

Configure transport rules.
Describe AD RMS.
Describe the AD RMS components.
Describe how AD RMS components work together.
Describe AD RMS interaction.
Configure AD RMS integration.
Describe options for moderated transport.
Configure moderated transport.

What Are Transport Rules?
Exchange Server applies transport rules to messages as they pass through Edge Transport or Hub
Transport servers. The Transport Rule agent applies transport rules on Hub Transport servers, and the
Edge Rule agent applies them on Edge Transport servers. Transport rules restrict message flow or content
modification while messages are in transit. With transport rules, you can:
Prevent specified users from sending or receiving email from other specified users.
Prevent inappropriate content from entering or leaving the organization.

Apply restrictions based on message classifications to restrict the flow of confidential organization
information.
Track or journal messages that specific individuals send or receive.
Redirect incoming and outgoing messages for inspection before delivery.
Apply disclaimers to messages as they pass through the organization.
Apply AD RMS templates to the messages based on message criteria.
Transport Rules on Hub Transport Servers

Transport rules configured on one Hub Transport server automatically apply to all other Hub Transport
servers in the organization. Exchange Server stores the transport rules in the Configuration container in
Active Directory Domain Services (AD DS), and replicates them throughout the Active Directory forest so
that they are accessible to all other Hub Transport servers. This means that Exchange Server applies the
same transport rules to all email messages that users send or receive in the organization.
Transport Rules on Edge Transport Servers

Exchange Server applies transport rules that you configure on an Edge Transport server only to email
messages that pass through that specific Edge Transport server. The transport rules are stored in Active
Directory Lightweight Directory Services (AD LDS), and Exchange Server does not replicate them to other
Edge Transport servers. Therefore, you can configure Edge Transport servers to apply distinct transport
rules depending on the email messaging traffic that they manage.
If you have more than one Edge Transport server and you want to apply a consistent set of rules across all
Edge Transport servers, you must configure each server manually, or export the transport rules from one
server and import them into all other Edge Transport servers.
Note Although the process for creating transport rules on Hub Transport servers and
Edge Transport servers is similar, the options available when creating the rules are not
identical. For example, when configuring the recipients to whom a rule will apply on a Hub
Transport server, you can configure specific recipients based on the Global Address List
(GAL). On the Edge Transport server, you can configure recipients based on text patterns in
the SMTP addresses rather than on specific GAL recipients.
Transport Rule Components
All transport rules, whether they apply to Hub Transport or Edge Transport servers, have similar
configurations.
Transport Rule Components

When configuring transport rules, consider the following components:
Conditions. Transport rule conditions indicate which email message attributes, headers, recipients,
senders, or other parts of the message Exchange Server uses to identify the email messages to which
it applies a transport rule action. If the data of the email message that the condition is inspecting
matches the conditions value, Exchange Server applies the rule as long as the condition does not
match an exception.
You can configure multiple transport rule conditions to narrow the rules scope to very specific
criteria. You also can decide not to apply any conditions, which means that the transport rule then
applies to all messages. There is no limit to how many conditions you can apply to a single transport
rule.
Note If you configure multiple conditions on the same transport rule, all the conditions
must be met for the transport rule to apply to a particular email message. When you specify
multiple values on a single condition, the condition is satisfied if at least one of the values is
met.
Actions. Exchange Server applies actions to email messages that match the conditions and for which
no exceptions are present. Each action affects email messages in a different way, such as redirecting
the email message to another address or dropping the message.
Exceptions. Exceptions determine which email messages to exclude from an action. Transport rule
exceptions are based on the same predicates that you use to create transport rule conditions.
Transport rule exceptions override conditions and prevent Exchange Server from applying a transport
rule action to an email message, even if the message matches all configured transport rule conditions.
You can configure multiple exceptions on a transport rule to expand the criteria for which Exchange
Server should not apply a transport rule action.
Note If you configure multiple exceptions on the same transport rule, only one exception
must match for the transport rule action to be cancelled. When you specify multiple values
on a single exception, the exception is satisfied if at least one of the values is met.
Predicates. Conditions and exceptions use predicates to define which part of an email message the
conditions and exceptions examine to determine whether Exchange Server should apply the transport
rule to that message. Some predicates examine the To: or From: fields, whereas other predicates
examine the subject, body, or attachment size. To determine whether Exchange Server should apply a
transport rule to a message, most predicates require that you specify a value that the predicates use
to test against the message.
Demonstration: How to Configure Transport Rules
In this demonstration, you will review how to configure transport rules. You can configure transport rules
by using either the Exchange Management Console or the Exchange Management Shell. If you are using
the Exchange Management Console on a Hub Transport server, access the Hub Transport container in the
Organization Configuration work area.
To configure transport rules by using the Exchange Management Shell, run the following cmdlets:
The Get-TransportRule, New-TransportRule, Remove-TransportRule, Set-TransportRule,

Enable-TransportRule, and Disable-TransportRule cmdlets create, remove, and configure transport
rules.
The Get-TransportRuleAction cmdlet retrieves a list of all available transport rule actions.
The Get-TransportRulePredicate cmdlet retrieves a list of all available rule predicates.
The Import-TransportRuleCollection and Export-TransportRuleCollection cmdlets import and

export a set of transport rules configured on a Hub Transport server or Edge Transport server.
Note Implementing transport rules with security features, such as digital signatures or
encryption, can result in potential issues. For example, if you add a disclaimer to digitally
signed messages, the signature becomes invalid. When users open the message, the original
message displays as an attachment and only the signature that the transport rule adds is
visible in plain text. If users encrypt messages by using Secure Multipurpose Internet Mail
Extensions (S/MIME) or another encryption tool, the transport rules can access the message
envelope headers and process messages based on unencrypted information. Transport rules
that require inspection of message content, or actions that may modify content, cannot
process with encrypted messages.
Regular Expressions in Transport Rules

Transport rules can use simple expressions or regular expressions when evaluating messages. A simple
expression is a specific value that must be matched exactly in a message. Predicates that use simple
expressions match specific words or strings. For example, a simple expression could be the title of a
document that your organization does not want distributed outside the organization, such as Yearly Sales
Forecast.doc. A piece of data in an email message must match a simple expression exactly to satisfy a
condition or exception in transport rules. If the previous title is changed to YearlySalesForecast.doc (spaces
removed), it will no longer match the transport rule.
Instead of specifying all possible variations for simple expressions, you can configure the transport rule
predicate to search for a text pattern that uses regular expressions. A regular expression is a flexible way to
find patterns of text in a message. The notation consists of two basic character types:
Literal characters. Text that must exist in the target string. These are normal characters, as typed.
Metacharacters. One or more special characters that are not interpreted literally. These indicate how
the text can vary in the target string.
You can use regular expressions to parse email messages to find specific text patterns in different parts of
a message. This enables you to detect messages with specific types of content, such as social security
numbers (SSNs), patent numbers, and phone numbers.
The following code sample demonstrates how to create a transport rule that uses a regular expression to
prevent sending messages that contain social security numbers. The regular expression used here is
\d\d\d-\d\d-\d\d\d\d. The portion \d\d\d requires that exactly three numeric digits appear in the first
segment, then two digits in the second, and four in the third segment.
New-TransportRule -Name "Social Security Number Block Rule" -

SubjectOrBodyMatchesPatterns '\d\d\d-\d\d-\d\d\d\d' -RejectMessageEnhancedStatusCode
"5.7.1" -RejectMessageReasonText "This message has been rejected because of content
restrictions"
Demonstration Steps
2. Under Organization Configuration, in the Hub Transport node, create a new transport rule with
the following configuration:
Name: Type Company Disclaimer HTML.
Condition: Choose sent to users that are inside the organization.
Action: Choose append disclaimer text and fallback to action if unable to apply.
Disclaimer text: Type the following:

<html>
<body>
 &nbsp
 &nbsp
This e-mail and attachments are intended for the individual or
group addressed.
</body>
</html>
3. Create another transport rule in the Exchange Management Console with the following configuration:
Name: Social Insurance Number Block Rule.
Condition: The message subject or body contains numbers in the following pattern 111-11-
1111.
Action: Choose send a rejection message.

4. To test the transport rules:
Send a message from one internal user to another. Verify that the HTML disclaimer is attached.
Send a message from one internal user to another with the string 111-11-1111 in the message
body. Verify that the sender receives a non-delivery report (NDR).
Note In a regular expression, the \d pattern string matches any single numeric digit. You
can use a variety of pattern strings to search the message contents for a consistent pattern.
For example, you can use \s to represent a space, or \w to represent any letter or decimal
digit. For detailed information about configuring regular expressions in a transport rule, see
the topic Regular Expressions in Transport Rules in Exchange Online Help.
Question: What transport policies will you need to implement in your organization?
What Is AD RMS?
AD RMS is an information-protection technology that works with AD RMS-enabled applications to help

safeguard digital information from unauthorized use.
Restrict Access to an Organizations Intellectual Property

Use AD RMS to restrict access to digital information so that users can view, change, or print
documentation only. This protects data by preventing users from forwarding, copying, or otherwise
transporting sensitive data outside the company network.
Limit the Actions Users Can Perform on Content

Enforce restrictions that limit the specific actions that a user can perform on a document or email
message. You can use Microsoft Office Word, Office Excel, and PowerPoint as AD RMS-enabled
applications. These applications allow you to set rights for viewing, changing, saving, and printing
documents, and to set the length of time a particular right is active. Depending on the application that
you are using, you can limit the action on content to the following restrictions:
View-only
Prevent change
Prevent print
Set expiration times on the content
AD RMS used with Outlook helps you protect email content. You can prevent users from forwarding
sensitive email messages to other email users, printing email messages, using messages offsite, and giving
messages to unauthorized users.
Limit the Risk of Content Exposure Outside the Organization

You can set rights so that users do not have permission to print or forward email content. This means that
users cannot forward the messages to recipients outside the organization. These options help reduce the
likelihood that an employee will disclose company information either maliciously or accidentally.
AD RMS Components
Several components interact with AD RMS. The following table lists these components.
Component Function
AD RMS It is used for AD RMS administration and configuration and handles all of the major
Certification AD RMS functions, including licensing, publishing, account certification, and recovery.
Server Cluster There is a limit of one AD RMS Certification Server Cluster per AD DS forest.
AD DS AD DS is an AD RMS prerequisite and is used to store users and groups used within
AD RMS. Clients query AD DS for the service connection point (SCP) to discover
registered AD RMS services.
Microsoft SQL The AD RMS database stores the configuration and log data. A Windows Internal
Server Database can be used in place of SQL but it is not supported in a production
environment.
AD RMS clients The client, which comes built-in to Windows Vista, Windows 7 and Windows
and Server 2008, is a free download for earlier Windows versions. There is also an add-
applications on client for Internet Explorer. It serves as the client component and interacts with the
AD RMS Certificate Server Cluster to encrypt and decrypt data.
Specific applications are enabled for, and can interact with, AD RMS. Authors can use
these applications to create and protect content, and recipients can use them to read
protected content and apply the appropriate rights to them.
(continued)
Component Function
Certificates and The AD RMS components use certificates and licenses to establish identity and allow
licenses clients to work with protected content. A variety of certificates and licenses are issued
to both the computer and user, and to both the content author and the content
consumer.
Rights policy Rights policy templates are used to control the rights of users and groups to rights-
templates protected content. They can include various conditions, such as specific recipients or
AD DS groups. Some other conditions are the period for which a use license for the
content remains valid and the period for which after publication the content can be
consumed. The use rights available include Full Control, View, Edit, Save, Print,
Forward, and Reply.
How AD RMS Works
The AD RMS components work together to enable secure creation, distribution, and consumption of
protected data.
How AD RMS Works

The following steps describe how AD RMS components interact to generate and protect rights-protected
content:
1. The first time a user tries to protect content by using AD RMS, the client application requests a rights
account certificate (RAC) and client licensor certificate (CLC) from the AD RMS server. This request
only occurs once for each user. It enables the user to publish online or offline, and to consume rights-
protected content.
2. The author then creates content by using an AD RMS-enabled application. The author can create the
file, and then specify user rights. Additionally, the AD RMS server generates the policy license
containing the user policies.
3. The author sends the rights-protected content to the recipient.
4. The recipient receives the file, and then opens it by using an AD RMS-enabled application or browser.
If the recipients computer does not contain an account certificate, the client application requests a
certificate, and the AD RMS cluster issues one. If this is the first time the recipient has tried to access
rights-protected content on the computer, the AD RMS server also issues a RAC.
a. The application sends a request for a use license to the AD RMS cluster that issued the publishing
license. However, if the file was published offline, the application also sends a request to the
server that issued the CLC. The request includes both the RAC and the publishing license for the
file.
b. The AD RMS cluster confirms or denies the recipients authorization. If the AD RMS cluster denies
the users authorization, the cluster checks for a named user and then creates a use license for the
user. The cluster decrypts the content key by using the clusters private key and re-encrypts the
content key with the recipients public key. It then adds the encrypted session key to the use
license. This ensures that only the intended recipient can access the file.
5. The AD RMS cluster sends the generated use license to the recipients computer. The application
examines both the license and the recipients account certificate. Exchange Server then grants the
user access per the content authors specifications.
How AD RMS Integration Works
Exchange Server 2010 integrates with AD RMS to provide several options for ensuring content protection
as users send messages through email. To use any of these features in an onsite Exchange Server
deployment, Exchange Server 2010 requires an on-premise Windows Server 2008 AD RMS deployment.
Enable Users to Protect Content

After deploying AD RMS in an organization, Outlook users can control who reads, copies, or forwards
messages regardless of where the messages are stored. When users create emails, they can set limits on
what the message recipients can do with the messages. This functionality does not require any Exchange
Server components other than those used for message delivery.
Exchange Server 2010 provides additional functionality, and expands the scenarios by which users and
administrators can apply protection to emailboth inside and outside the organization.
Implement AD RMS Prelicensing

One of the issues with using the Rights Management Service (RMS) to protect email is that the recipient
needs to be able to connect to the AD RMS server to read protected email. This is an issue when users
access their email while offline by using Outlook Anywhere, read mail by using a Microsoft Exchange
ActiveSync device, or access email through Outlook Web App. AD RMS prelicensing enables offline
access to protected mail, and makes it faster to open protected mail from Outlook and other mobile
clients. In this scenario, protected messages already contain the recipients end-user license, which
Exchange Server requires to decrypt and view the message upon delivery.
In Exchange Server 2010, the RMS Prelicensing built-in agent is on all Hub Transport servers, and is
enabled by default for the Exchange Server organization. You can disable the prelicensing agent with the
Set-IRMConfiguration -PrelicensingEnabled $false cmdlet.
Implement Outlook Protection Rules

Outlook Protection Rules allow you to rights-protect messages by applying an RMS template before the
message is sent. Outlook Protection Rules automatically trigger the client to apply an RMS template
(based on sender/receiver) to mail before it sends it. This feature also enables administrators to allow
users to manually add or remove protection policies from a message.
Note Outlook Protection Rules are only available for Office Outlook 2010 or later clients.
Implement Transport Protection Rules

This feature allows you to use transport rules to apply rights protection to messages. Transport Protection
Rules help organizations implement messaging policies by encrypting sensitive email content and by
using rights-management to control access to the content.
AD RMS uses XML-based policy templates to allow compatible information rights management (IRM)-
enabled applications to apply consistent protection policies. In Windows Server 2008, the AD RMS
server is accessible through a Web service that you can use to enumerate and acquire templates.
Exchange Server 2010 includes just the Do Not Forward template. When you apply the Do Not Forward
template to a message, only the specified recipients can decrypt the message. The recipients cannot
forward the message to anyone else, copy content from the message, or print the message.
You can create additional RMS templates in the on-premise AD RMS deployment to meet rights-
protection requirements in your organization.
Enable Journal Report Decryption

When you enable Journal Report Decryption, you grant permission for the Journaling agent to attach a
decrypted copy of a rights-protected message to the journal report. If the rights-protected message
contains supported attachments that have been protected by the AD RMS cluster in your organization,
the attachments are also decrypted. The Journal Report Decryption agent performs decryption.
Enable Transport Decryption

When you enable Transport Decryption, Hub Transport servers can decrypt rights-protected messages to
enforce messaging policies. The first Hub Transport server to handle a message in an Active Directory
forest performs transport decryption. After decryption, unencrypted content becomes available to other
transport agents on that server. For example, the Transport Rule agent on a Hub Transport server can
inspect message content and apply transport rules. Any actions specified in the rule, such as applying a
disclaimer or modifying the message, can be applied to the unencrypted message. After other transport
agents have inspected the message and possibly made modifications to it, the message is encrypted again
with the same user rights that it had before being decrypted by the Decryption agent. The message is not
decrypted again by other Hub Transport servers in the organization.
Enable IRM in Outlook Web App

After you enable IRM in Outlook Web App, users can use Outlook Web App to:
Send IRM-protected messages. Outlook Web App users can use the permissions feature when
composing a new message and select an applicable policy template to apply to the message. This
allows users to send IRM-protected messages from within Outlook Web App. The Client Access server
applies IRM protection to messages and message attachments.
Read IRM-protected messages. Messages protected by senders using your organizations AD RMS
cluster display in the Outlook Web App preview pane, without requiring additional add-ons or that
the users computer is enrolled in the AD RMS deployment. When you open or view a message in the
preview pane, the message is decrypted using the use license added to message by the pre-licensing
agent. Once decrypted, the message displays in the preview pane. If a pre-license is not available,
Outlook Web App requests one from the AD RMS server before displaying the message.
Note Before configuring Journal Report Decryption, Transport Decryption, or IRM for
Outlook Web App, you must provide Exchange servers with the right to decrypt IRM-
protected content. Do this by adding the Federated Delivery Mailbox to the super users
group configured on the AD RMS cluster. You must also use the Set-IRMConfiguration
cmdlet to enable the required features.
IRM Enhancements in Exchange Server 2010 SP1

IRM functionality in Exchange Server 2010 Service Pack 1 (SP1) includes the following features:
WebReady Document Viewing of IRM-protected attachments. In Exchange Server 2010 SP1, IRM
in Microsoft Office Outlook Web App supports WebReady Document Viewing of supported
IRM-protected attachments. This allows users to view IRM-protected attachments without having
to download them. Users can preview IRM-protected documents on computers that do not have
Microsoft Office installed. Along with the cross-browser and cross-platform support in Outlook
Web App, this functionality extends the reach of IRM to various browsers and operating systems.
IRM in Exchange ActiveSync. IRM in Exchange ActiveSync allows users with supported devices to
access IRM-protected messages without first having to activate the device for IRM, or by attaching
the device to a computer.
Cross-organization support. Exchange Server 2010 SP1 IRM features are supported in cross-
organization topologies, which provides for easier collaboration between two organizations through
Outlook Web App.
IRM logging. In Exchange Server 2010 SP1, you can enable logging of IRM features on the
Mailbox, Hub Transport, Client Access, and Unified Messaging server roles. IRM logs contain detailed
transaction and error information, allowing administrators to easily monitor and troubleshoot IRM
features.
Demonstration: How to Configure AD RMS Integration
In this demonstration, you will review how to configure and test AD RMS and Exchange Server 2010
integration. The first part of the demonstration will show you how to protect email messages by using
AD RMS. This feature does not require any special Exchange Server functionality. The second part of the
demonstration will show you how to configure a transport rule that applies AD RMS protection to a
message based on message properties.
Demonstration Steps
1. Open Outlook 2010 and create a new message for an internal recipient.
2. In the Message ribbon, click the Permission icon.
3. In the Windows Security dialog box, log on as the mailbox user.
4. In the Permission dialog box, select the Restrict permission to this document check box.
5. When the message appears, verify that the message now contains the Do Not Forward header. Send
the message.
6. Log on as the message recipient, open Outlook 2010, open the restricted message, and then log on
by using the user credentials. Verify that you do not have permission to forward the message.
7. On VAN-DC1, modify the permissions on the C:\inetpub\wwwroot\_wmcs\certification

\servercertification.asmx file to grant Read and Execute access to the Exchange Servers group and
the anonymous Internet Information Services (IIS) user account.
8. Restart IIS.
9. On an Exchange server, at the PS prompt, type the following cmdlet, and then press Enter. This
cmdlet enables AD RMS encryption on the Hub Transport server:
set-irmconfiguration InternalLicensingEnabled:$true.
10. Use the test-irmconfiguration cmdlet to test the IRM configuration.
11. In the Exchange Management console, create a new transport rule named AD RMS Test Rule, which
applies the Do Not Forward AD RMS template for all messages sent between two specified users.
12. Send a message from one of the specified users to the other. Verify that the Do Not Forward
template is applied to the message.
Question: Does your organization have AD RMS deployed? Are you planning to deploy AD
RMS?
Question: How will Exchange Server 2010 make it easier to deploy AD RMS?
Options for Configuring Moderated Transport
The Exchange Server 2010 moderated transport feature enables you to require moderator approval for all
email messages sent to specific recipients, and you can specify any type of recipient as a moderator. The
Hub Transport servers ensure that all messages sent to those recipients go through an approval process.
In any type of organization, you may need to restrict access to specific recipients. The most common
scenario is the need to control messages sent to large distribution groups. Depending on your
organizations requirements, you may also need to control messages sent to executive mailboxes or
partner contacts. You can use moderated recipients to accomplish these tasks.
You can also use transport rules to enforce moderation. For example, you could configure a transport rule
that sends a message for moderation based on any of the available criteria.
How Moderated Transport Works

When you configure a recipient as a moderated recipient, all messages sent to the recipient go through
the following process:
1. The sender creates a new message and sends it to the moderated recipient.
2. The categorizer intercepts the message, marks it for moderation, and then reroutes it to the
arbitration mailbox.
3. The store driver stores the message in the arbitration mailbox and sends an approval request to the
moderator.
4. The moderator uses the buttons in the approval request to either accept or reject the message.
5. The store driver marks the moderators decision on the original message stored in the arbitration
mailbox.
6. The Information Assistant reads the approval status on the message stored in the arbitration mailbox,
and then processes the message based upon the moderators decision:
If the moderator approves the message, the Information Assistant resubmits the message to the
submission queue, and the message is delivered to the recipient.
If the moderator rejects the message, the Information Assistant deletes the message from the
arbitration mailbox, and then notifies the sender that the moderator rejected the message.
Note Previous Exchange Server versions do not support moderated recipients. If a

message sent to a moderated distribution group is expanded on a Hub Transport
server that is running Exchange Server 2007, it will be delivered to all members of that
distribution group, and bypass the moderation process. If you have Exchange Server 2007
Hub Transport servers in your Exchange Server 2010 organization, and you want to
use moderated distribution groups, you must designate an Exchange Server 2010 Hub
Transport server as the expansion server for the moderated distribution groups. Doing
this ensures that all messages sent to the distribution group are moderated.
Bypassing Moderation
Exchange Server delivers messages from certain senders to the moderated recipient immediately,
bypassing the approval process, and considers the following senders as trusted senders.
Moderators. By definition, a moderator has the authority to determine what messages are
appropriate for a moderated recipient.
Senders that Exchange Server specifically allows to send messages. For each moderated recipient, you
can specify a list of senders for whom Exchange Server bypasses the approval workflow. Exchange
Server explicitly allows these senders to send to this recipient, and therefore trusts them.
Because these senders are considered trusted senders, messages from them do not go through the
approval process.. Exchange Server does not treat owners of distribution groups and dynamic distribution
groups automatically as trusted senders, and messages from these senders are subject to the approval
process. Additionally, the owner of a distribution group can be responsible for managing the distribution
group membership, but may not be able to moderate messages sent to it. To bypass moderation for
owners, you must either designate them as moderators or add them to the list of senders that are
explicitly allowed to send messages to the moderated recipient.
Demonstration: How to Configure Moderated Transport
In this demonstration, you will review how to configure a distribution list for moderation and how to
configure a transport rule that enforces moderation for all messages sent to a distribution list.
Note In this demonstration, you will configure a distribution list by using the Exchange
Management Console. If you need to enable a mailbox or contact for moderation, you will
need to use the set-mailbox cmdlet with the moderationenabled:$true and
moderationedby parameters.
Demonstration Steps
1. In the Exchange Management Console, under Recipient Configuration, click Distribution Group.
2. In the middle pane, right-click a distribution list, and then click Properties.
3. On the Mail Flow Settings tab, double-click Message Moderation.
4. In the Message Moderation dialog box, select the Messages sent to this group have to be
approved by a moderator check box. Add the group moderators and add any users who do not
require moderation to send to the group.
5. Create a new transport rule that forwards any message sent to a distribution list for moderation.
Choose a moderator for the rule, and then configure any exceptions that are required.
6. Send a message to the distribution group configured for moderation.
7. Send a message to the distribution group configured for moderation in the transport rule.
8. Open the mailbox of a moderator configured for both the distribution group and transport rule.
Approve both messages.
Question: Will you deploy moderated transport in your organization? If so, where would you
use it?
Lesson 3
Configuring Journaling and Multi-Mailbox Search
Message journaling and Multi-Mailbox Search are important components for enforcing messaging
compliance. Message journaling allows you to archive all messages automatically that meet criteria that
you specify. You can archive journaled messages to any SMTP address, including an Exchange mailbox,
Microsoft SharePoint document library, or a third-party archiving solution. In addition to message
journaling, Exchange Server 2010 also includes the Multi-Mailbox Search feature, which enables an
authorized user to search all of the organizations mailboxes based on specific criteria. This lesson
describes how to configure and manage message journaling and Multi-Mailbox Search in Exchange Server
2010.
Describe message journaling options.
Configure message journaling.
Manage the message journal mailbox.
Describe Multi-Mailbox Search.
Describe legal hold.
Configure Multi-Mailbox Search.

Message Journaling Options
Journaling enables you to save copies of all email messages in a collection mailbox when they are sent to,
or from, specified mailboxes, contacts, or distribution-group members. You also can configure journaling
based on messages sent to, or received from, mailboxes in a mailbox database, or configure journaling as
part of a managed folder content setting.
Messages that meet the journaling criteria are sent to the collection mailbox as a journal report. This
report includes detailed information such as the recipients address, the senders address, and the
messages subject.
How Journal Rules Work

When you create a journal rule, the Journaling agent, which runs on Hub Transport servers, monitors all
messages sent through the server. When a message matches the journal rule criteria, the server forwards a
copy of the message to a journal mailbox. You can configure the journal mailbox by using any Exchange
Server recipient. The recipient address can refer to another mailbox in the Exchange Server organization, a
document library on a Microsoft Windows SharePoint Services site, or an address used by other third-
party message-archival solutions.
Journal rules are based on message recipients and message senders. When you configure a journal rule,
you can choose any Exchange Server recipient including mailbox users, contacts, or distribution groups.
The Journaling agent sends to the journal mailbox a copy of all messages that the recipient sends or
receives.
You also can configure the following three journal rule scopes to limit which messages the Journaling
agent sends to the journal mailbox.
Scope Description
Internal Rules with this scope process messages sent and received by recipients inside the
organization.
External Rules with this scope process messages sent to recipients or from senders outside the
organization.
Global Rules with this scope process all messages that pass through a computer that has a Hub
Transport server. These include messages that journal rules processed previously in the
Internal and External scopes.
Journal rules configured on a Hub Transport server apply to the entire Exchange Server organization.
How Mailbox Database Journaling Works

You can also configure a journal mailbox for a mailbox database. When you assign a journal recipient for
a mailbox database, all messages sent to or received from recipients with mailboxes in the database also
are sent to the journal recipient.
Note You can also configure message journaling when you configure managed content
settings for a managed folder. With this option, any message that meets the managed
content settings criteria will also be journaled to a journal address.
Note Mailbox database journaling is a standard journaling option and is the only option
available for organizations with an Exchange Standard Client Access Licenses (CAL).
Journaling rules that apply pre-recipient journaling are premium journaling options that
require Exchange Enterprise CALs.
Journal Reports
When a message meets the journaling criteria, a journal report is sent to the SMTP address that the rule
lists. The journal report is a new email message that includes the original message, unaltered, as an
attachment.
The information that the journal report contains is organized so that every value in each header field has
its own line. The Journaling agent captures as much detail as possible about the original message. This
information is important in determining the messages intent, its recipients, and its senders. For example,
how the message identifies recipients (directly addressed in the To field or the Cc field, or included in a
distribution list) may determine how the recipient is involved in the discussion occurring in the message.
Demonstration: How to Configure Message Journaling
In this demonstration, you will review how to configure a message journaling rule by using the Exchange
Management Console. You can configure journaling rules by using either the Exchange Management
Console or the Exchange Management Shell.
To configure transport rules with the Exchange Management Shell, use the following commands:
Enable-JournalRule
Disable-JournalRule
Get-JournalRule
Set-JournalRule
New-JournalRule
Remove-JournalRule
Demonstration Steps
1. In Exchange Management Console, under Organization Configuration, click Hub Transport.
2. Create a new journal rule. Specify a name for the rule, and a journal mailbox. A copy of all messages
that the rule affects will be sent to the journal mailbox.
3. Specify the journal rule scope and recipients. The scope defines whether only internal or only external
messages, or both, will be journaled. All messages that the recipient sends or receives are journaled.
4. Send a test message to a journal recipient. Log on to the journal recipient mailbox, and then reply to
the message.
5. Log on to the journal mailbox and confirm that the journal mailbox contains a journal report for both
the sent message and the reply message.
Question: What are the advantages and disadvantages of using the Exchange Server 2010
message journaling feature?
Considerations for Managing the Message Journal Mailbox
In a large organization or if you configure journaling for a large number of users, the journal mailbox
can grow very rapidly. Additionally, the journal mailbox may contain highly confidential information that
should not be accessible to most users. This means that you will need to develop policies for managing
the journal mailbox.
Using a SharePoint Document Library for Journaling

You can configure SharePoint document libraries with SMTP addresses that will accept email messages. In
Exchange Server, you can configure a custom recipient by using the SharePoint document library email
address, and then configure journaling to use the custom recipient as the journal recipient. Using a
SharePoint document library as the journal recipient has several advantages:
You configure a location outside of Exchange Server in which to store your messages, which reduces
the size of the Exchange Server databases.
You can index the SharePoint document libraries to enhance the search experience.
You can specify security on SharePoint document lists to ensure that only authorized users can view
the journaled messages.
Considerations for Managing the Journal Mailbox Size

When configuring a journaling mailbox to accept journal reports, you must determine the maximum
size of the journaling mailbox. As with any other mailbox, the maximum size depends on the data that
the mailbox will store, the hardware resources that are available, and the disaster-recovery capabilities for
the server that contains the journaling mailbox. Additionally, you also must consider what will occur if a
journaling mailbox exceeds the configured mailbox quota.
Avoid using the Prohibit send and receive at (KB) option to set the journaling mailboxs storage limit.
When the mailbox exceeds the specified quota, it stops accepting journaling reports. When this happens,
NDRs are not sent to users or administrators, but rather are queued on Hub Transport servers. To reduce
the possibility that your journaling mailbox will reject journal reports because it has reached the
configured storage quota, either avoid configuring this option or configure your journaling mailboxs
storage quota to the maximum size allowable for your hardware resources and disaster-recovery
capabilities. If you are backing up the mailbox on a daily basis, consider specifying a retention policy to
remove backed-up messages regularly.
Considerations for Managing Journal Mailbox Security

Security is an important consideration when managing the journal mailbox. Journaling mailboxes may
contain sensitive information. You must secure journaling mailboxes because they collect messages that
your organizations recipients send and receive, and those messages may be part of legal proceedings or
subject to regulatory requirements. Create policies that govern who can access your organizations
journaling mailboxes and limit access to only those individuals who have a direct need for access. Ensure
that legal representatives approve your plan to ensure that your journaling solution complies with all the
laws and regulations that apply to your organization.
What Is Multi-Mailbox Search?
Many organizations need to be able to search mailboxes for specific content while performing compliance
audits. By using the Exchange Server 2010 Multi-Mailbox Search feature, organizations can now easily
search all user mailboxes.
How Multi-Mailbox Search Works

In Exchange Server 2010, the mailbox search functionality is now available through the Multi-Mailbox
Search feature in the ECP. The Multi-Mailbox Search feature allows you to search multiple mailboxes for
mailbox items (including email, attachments, Calendar items, Tasks, and Contacts) across both primary
and archive mailboxes. Advanced filtering capabilities include: sender, receiver, expiry policy, message
size, sent/receive date, cc/bcc, and regular expressions.
Multi-Mailbox Search uses the content indexes that Exchange Search creates. Having a single content-
indexing engine ensures no additional resources are utilized for crawling and indexing mailbox databases
during the mailbox search.
Discovery Management Role
A user who is a member of the Discovery Management role group can perform a Multi-Mailbox Search.
The Discovery Management role group is a universal security group that is created in AD DS during the
Exchange Server 2010 installation. The Discovery Management role group is assigned to the Mailbox
Search management role, which has permission to search all mailboxes in the organization.
Note Exchange Server 2010 uses role based access control (RBAC) to define what actions
users can perform in the Exchange Server organization. RBAC uses management roles and
management role groups to manage these permissions. For more information on
management roles and management role groups, see Module 10.
Viewing Search Results

All search results are stored in a special mailbox called Discovery Search Mailbox. It is not possible to store
results in any other mailbox. The Discovery Search Mailbox is always created during Exchange Server 2010
installation, and cannot be used for standard purposes such as sending and receiving email, because
delivery restrictions are applied to it. The user account associated with the Discovery Search Mailbox is
disabled, so no one can log on to this mailbox without being explicitly granted rights to do so. The
Discovery Management group has full access rights to the Discovery Search Mailbox.
Because the Discovery Search Mailbox should be able to store a large amount of data, it is assigned a 50-
gigabyte (GB) storage quota on creation. If you have multiple teams or individuals that perform discovery
searches and you do not want them to see results from other searches, you will need to create additional
Discovery Search Mailboxes. This can be done by using the Exchange Management Shell.
After you perform a search, a new folder is created in the Discovery Search Mailbox that bears the same
name as the search. Within that folder, a subfolder is created for each source mailbox that was searched.
Additionally, messages that the search returns are copied to the corresponding folder in the target
mailbox.
Multi-Mailbox Search Enhancements in Exchange Server 2010 SP1

The Multi-Mailbox Search functionality in Exchange Server 2010 SP1 includes the following new features:
Multi-Mailbox Search results preview. In Exchange Server 2010 SP1, discovery managers can
determine the number of items that will be returned by a discovery search, before the items are
copied to the selected discovery mailbox. Discovery managers are users who are members of the
Discovery Management role group. This functionality allows discovery managers to view the number
of hits the specified keywords return, and then modify the search queryif requiredbefore
messages returned by the search are copied to the discovery mailbox.
Annotations. Discovery managers can also add annotations to messages returned by the discovery
search.
Data deduplication. Multi-Mailbox Search includes the optional data deduplication feature. When
selected, Multi-Mailbox Search copies only a single instance of a message returned across multiple
folders within the same mailbox, or across different mailboxes. However, you should not select
deduplication if you want to see each instance of a message and its location.
What Is Legal Hold?
Besides searching the contents of users mailboxes, you can also perform Multi-Mailbox Searches on items
that users have deleted. Under some circumstancessuch as a court order or lawsuitit may be
necessary to retrieve items that users intentionally delete.
Legal hold, which is also known as litigation hold, is an option in Exchange Server 2010 that can be
applied to user mailboxes to achieve this result.
Dumpster 2.0
In previous versions of Exchange Server, the dumpster was a view that was stored per folder. Using this
approach, items in the dumpster remained in the folder from where they were soft-deleted either by
pressing the SHIFT+DELETE keys in any folder, or by clicking Delete from within the Deleted Items folder.
However, they were marked with the ptagDeletedOnFlag flag. These marked items were excluded from
normal Outlook views and quotas. In addition, data that was marked with this flag could not be searched
or indexed. These items were recoverable by end users by using the Recover Deleted Items tool accessible
through Outlook Web Access (OWA); however, the user was also able to delete these items permanently.
In Exchange Server 2010, Dumpster 2.0 functions differently. Dumpster 2.0 has now become a base
structure to the legal hold feature. Unlike version 1.0, Dumpster 2.0 is now a folder called Recoverable
Items. This folder is located inside the user's mailbox in the Non-IPM subtree, and it is not viewable
through the user interface. The Recoverable Items folder is indexed, can be searched, and you can prevent
deletions from this folder by implementing legal hold.
Using Legal Hold

Legal hold is enabled on a per-mailbox basis, and it is virtually transparent to the end user because
retention policies continue to operate. By enabling legal hold, you preserve almost all mailbox items from
both the primary mailbox and Personal Archive, even if the user deletes something, and you can perform
discovery searches on these items too.
In Exchange Server 2010, when a user deletes an item, the item is no longer marked with a
ptagDeletedOnFlag flag. Instead, it goes to the Deletions subfolder within the Recoverable Items folder.
From this folder, a user can retrieve items that were deleted. However, the user is no longer able to
permanently delete items from this folder. If a user deletes an item from Recoverable Items, it goes to the
Purges subfolder. The user can no longer access this item, but an administrator can, which prevents users
from intentionally hiding or destroying items.
You can use the legal hold feature to:
Place a hold on users' mailboxes and keep mailbox items in an unaltered state.
Preserve mailbox items that users attempt to delete or modify after the hold is placed.
Preserve mailbox items that are automatically deleted based on messaging records management
retention policies.
Keep the legal hold transparent from users by not having to suspend messaging records
management.
Enable discovery searches of items placed on hold.
Items in the Recoverable Items folder are not calculated toward the user's mailbox quota. The
Recoverable Items folder has its own quota, and two parameters apply to this quota:
RecoverableItemsWarningQuota and RecoverableItemsQuota. The default
RecoverableItemsWarningQuota and RecoverableItemsQuota values are 20 GB and 30 GB,
respectively. If these quotas are reached, an event is logged in the application log of the Mailbox server,
so it is important to monitor this event log. If you want to modify quota values for a mailbox database,
use the Set-MailboxDatabase cmdlet. If you want to modify quota values for an individual mailbox, use
the Set-Mailbox cmdlet.
To enable legal hold on a user mailbox, use the following command in Exchange Management Shell:
Set-Mailbox user@contoso.com -LitigationHoldEnabled $true
In Exchange Server 2010 SP1, it is also possible to use Exchange Management Console and Exchange
Control Panel to enable legal hold by modifying the properties of a users mailbox.
Authorized users that have been added to the Discovery Management RBAC role group or assigned the
legal hold management role can place mailbox users on legal hold. You can delegate the task to records
managers, compliance officers, or attorneys in your organization's legal department, while assigning the
least privileges.
Question: In which scenarios is it appropriate to use legal hold?

Demonstration: How to Configure Multi-Mailbox Search
In this demonstration, you will review how to configure Multi-Mailbox Search and legal hold. To use the
Multi-Mailbox Search feature, you must add the users who will perform the search to the Mailbox Search
management role. The easiest way to do this is to add the user to the Discovery Management universal
security group in AD DS or Active Directory. The user then can use the Exchange Control Panel to search
for messages based on multiple criteria. If a users mailbox is configured with legal hold, the search results
will include all messages in the mailbox, including purged messages.
Demonstration Steps
1. In Active Directory Users and Computers, add the user or group that will perform Discover searches to
the Discovery Management group.
2. Send a message with a key word or phrase in it. You will be searching on this key word or phrase.
3. Send a second message with a key word or phrase in it.
4. Connect to the destination mailbox and purge the second message from the mailbox and Deleted
Items folder.
5. Connect to the Exchange Control Panel on a Client Access server by using the account that will
perform the search.
6. On the Reporting tab, under Multi-Mailbox Search, configure the search parameters.
7. Select the Send me an e-mail when the search is done check box, and then start the search.
8. Open the email indicating the search is finished, and then click the Discovery Search Mailbox link.
9. Review the messages located by the search.

Lab A: Configuring Transport Rules, Journal Rules, and

Multi-Mailbox Search
Lab Setup

3. If required, connect to the virtual machines. Log on to VAN-DC1, VAN-EX1, and VAN-EX2 as
Adatum\Administrator using the password Pa$$w0rd.
4. Log on to VAN-CL1 as Adatum\Luca using the password Pa$$w0rd.
Lab Scenario
You are a messaging administrator in A. Datum Corporation. Your organization has deployed Exchange
Server 2010.
The legal and audit departments at A. Datum provided you with several requirements for implementing
messaging policy and compliance. These requirements include applying rights protection to some
messages sent inside and outside the organization, restricting message flow based on information in
message subjects, and restricting which messages are sent to critical distribution lists. You also must
ensure that you establish a separate and secure mailbox in which to retain all messages that the legal
department sends and receives. Additionally, an auditor must be able to retrieve all messages sent and
received by users with legal hold enabled.
Exercise 1: Configuring Transport Rules

Scenario
A. Datum Corporation is completing its Exchange Server 2010 deployment and is preparing to implement
messaging policies to manage email messages in transit and in user mailboxes. The project sponsors have
developed the following requirements for transport rules:
All messages sent to users on the Internet must have a disclaimer that the legal department approves.
External messages with the term customer in the message subject or body must be copied to the
CustomerService distribution group unless a member of the CustomerService group sent the
message.
All messages with the words confidential or private in the subject must have the Do Not Forward
AD RMS template applied.
A member of the Marketing group must approve all messages sent to the All Company distribution
list before the message is delivered.
1. Create a transport rule that adds a disclaimer to all messages sent to the Internet.
2. Create a transport rule that for the CustomerService distribution group Enable AD RMS integration
for the organization.
3. Configure a transport rule that applies the Do Not Forward AD RMS template to all messages with the
words confidential or private in the subject.
4. Configure a moderated group.
5. Test the transport rule configuration.
X To start the lab, complete the following steps

1. On VAN-EX1, click Start, point to All Programs, point to Microsoft Exchange Server 2010, and
then click Exchange Management Console.
2. Expand Microsoft Exchange On-Premises, expand Organization Configuration, and then click
Hub Transport.
3. In the Actions pane, click New Send Connector.
4. On the Introduction page, type Internet Connector as the connector name. In the Select the
intended use for this Send connector drop-down list, click Internet, and then click Next.
5. On the Address space page, click Add.

6. In the Address field, type *, click OK, and then click Next.
7. On the Network settings page, click Route mail through the following smart hosts, and then
click Add.
8. In the IP address field, type 10.10.0.10, click OK, and then click Next.
9. On the Configure smart host authentication settings page, click Next.
10. On the Source Server page, click Next, click New, and then click Finish.
X Task 1: Create a transport rule that adds a disclaimer to all messages sent to the
Internet
On VAN-EX1, create a new transport rule with the following settings:
Name: Internet E-Mail Disclaimer
Conditions: Sent to users outside the corporation
Actions: Add a disclaimer
Disclaimer text: This e-mail is intended solely for the use of the individual to whom it is
addressed
X Task 3: Create a transport rule for the CustomerService distribution group

Use the following settings to create a new transport rule that sends a copy of all messages sent to the
Internet with the term customer in the message body or subject to the CustomerService distribution
group:
Name: Customer Service Tracking
Condition: Sent to users outside the organization, and where the subject or message body
contain the word customer
Actions: Send a copy of the message to the CustomerService group
Exceptions: If the message is sent by a member of the CustomerService group
X Task 4: Enable AD RMS integration for the organization

1. On VAN-DC1, grant the Exchange Servers group and the IIS_IUSRS read and execute permission to
the C:\inetpub\wwwroot\_wmcs\certification\ servercertification.asmx file.
2. Restart IIS on VAN-DC1.
3. On VAN-EX1, use the set-irmconfiguration InternalLicensingEnabled:$true cmdlet to enable

AD RMS encryption.
X Task 5: Configure a transport rule that applies the Do Not Forward AD RMS template
to all messages with the words confidential or private in the subject
Create a new transport rule with the following settings:
Name: Confidential E-Mail Rule
Condition: Where the subject contains the words Confidential or Private
Actions: protect the message with the Do not Forward template
X Task 6: Configure a moderated group

1. On VAN-EX1, configure the All Company distribution group to require moderation.
2. Configure Andreas Herbinger as the groups moderator.
X Task 7: Test the transport rule configuration

1. On VAN-CL1, verify that you are logged on as Adatum\Luca, and then open Office Outlook 2007.
2. Send two messages to Carol@contoso.com. The first message should contain no settings, and the
second message should have the term customer in the subject.
3. On VAN-DC1, open Windows Explorer. Browse to the C:\inetpub\mailroot\queue folder. Open the
first EML file with Notepad. Scroll to the middle of the message, and verify that the disclaimer has
been added to the message.
4. On VAN-CL1, connect to the Outlook Web App site on VAN-EX1. Log on as Anna. Verify that the
member of the CustomerService group was copied on the message sent by Luca.
5. In Outlook, create a new message, and send it to the All Company distribution group.
6. Connect to the Outlook Web App site on VAN-EX1. Log on as Andreas. Approve the message.
7. In Outlook, verify that the message to the All Company distribution list has arrived.
8. In Outlook Web App, logged on as Andreas, create a new message with a subject of Private. Send
the message to Luca.
9. In Outlook, verify that Luca received the message and that it has the Do Not Forward template
applied. Verify that the Forward option is not available on the message.
Results: After this exercise, you should have configured a transport rule that ensures that all messages
sent to users on the Internet includes a disclaimer of which the legal department approves. Additionally,
you should have configured a transport rule that ensures that messages with a Company Confidential
classification are not sent to the Internet, and you should have configured a transport rule that applies the
Do Not Forward AD RMS template to all messages with the words confidential or private in the
subject. Lastly, you should have configured a moderated group by using the All Company distribution
group.
Exercise 2: Configuring Journal Rules and Multi-Mailbox Search

Scenario
In addition to requirements restricting message flow, the project sponsors at A. Datum Corporation also
have the following requirements for saving messages and enabling auditors to search all mailboxes:
A copy of all messages sent to and from the Executives group will be saved. The journal mailbox
should be accessible only with a special auditor account.
Implement an auditor account that has permission to search all user mailboxes and access the
journaled Executive messages.
Verify that legal hold can be applied to user mailboxes and that messages deleted from mailboxes on
legal hold can be recovered through a discovery search.
1. Create a mailbox for the Executives department journaling messages.
2. Create a journal rule that saves a copy of all messages sent to and from Executives department
members.
3. Create and configure the MailboxAuditor account.

4. Configure legal hold on a mailbox.
5. Test the journal rule, Multi-Mailbox Search, and legal hold configuration.
X Task 1: Create a mailbox for the Executives department journaling messages

Create a new recipient with the following attributes:
First name: Executives Journal Mailbox

User Logon name (User Principal Name): ExecutivesJournal
Password: Pa$$w0rd
Create the mailbox in Mailbox Database 1
X Task 2: Create a journal rule that saves a copy of all messages sent to and from
Executives department members
Create a new journal rule with the following attributes:
Rule name: Executives Department Message Journaling
Journal mailbox: Executives Journal Mailbox
Scope: Global
Recipient: Executives distribution group
X Task 3: Create and configure the MailboxAuditor account

1. Create a new recipient with the following attributes:
First name: Mailbox Auditor
User Logon name (User Principal Name): MailboxAuditor
Password: Pa$$w0rd
Create the mailbox in Mailbox Database 1
2. Grant the Mailbox Auditor account full access to the Executives Journal Mailbox and Discovery
Management Mailbox mailboxes.
3. Add the Mailbox Auditor account to the Discovery Management Active Directory group.
X Task 4: Configure legal hold on a mailbox

On VAN-EX1, in the Exchange Management Console, enable legal hold for George Schallers mailbox.
X Task 5: Test the journal rule and Multi-Mailbox Search configuration

1. On VAN-CL1, if required, open Outlook.
2. Create a new message, and then send it to Marcel Truempy. Marcel is a member of the Executives
group.
3. Connect to Outlook Web App as Marcel, and confirm that the message was delivered. Reply to the
message.
4. Connect to Outlook Web App as MailboxAuditor. Right-click Mailbox Auditor, and then click Open
Other Users Inbox. Open the Executives Journal Mailbox and verify that the two journaled
messages are in the Inbox.
5. In Outlook, send a message with the following properties:
To: George; Carol@contoso.com
Subject: Customer Order

Message body: Here is the order for Carol at Contoso. Her customer number is 1111-1111.
6. Connect to Outlook Web App as George Schaller and purge the message from Luca.
7. Connect to the Exchange Control Panel as the MailboxAuditor.

8. Create a new search named Customer Number Discovery. Configure the search to look for the
phrase customer number in George Schaller and Luca Dellamores mailboxes.
9. Wait until the search finishes, and then in the bottom right pane, click the Open link. In Outlook Web
App, verify that the discovery folder named Customer Number Discovery contains two subfolders
and contains the discovered messages, including the messages deleted by George.
Results: After this exercise, you should have created a mailbox for the Executives department journaling
messages, and then created a journal rule that saves a copy of all messages sent to and from Executives
department members. You also should have created and configured the MailboxAuditor account.

The virtual machines are required to complete this modules last lab.
Lesson 4
Configuring Personal Archives
A compliance issue that many organizations must solve is that much of the information users receive by
email is not stored within the email system. Because of mailbox size limits, many users move messages
from their mailboxes to personal storage table (PST) files, where the messages are not backed up
regularly, and where the messages are not available for discovery or indexing.
Exchange Server 2010 introduces Personal Archives as an option for ensuring that all messages are stored
in a mailbox on an Exchange server. This lesson describes how to configure and manage Personal Archives
in Exchange Server 2010.

Describe options for implementing mailbox archiving.
Describe how Personal Archives work in Exchange Server 2010.
Configure Personal Archives.
Identify options for implementing Personal Archives.

Discussion: Options for Implementing Mailbox Archiving
Some organizations have implemented mailbox archiving by using third-party products. These products
provide different types of functionality and implement the functionality in different ways. In this
discussion, you will review the mailbox archiving solutions that organizations have implemented.
Question: Do you have any archiving or journaling requirements in your organization?
Question: How are you currently meeting these requirements?

How Personal Archives Work in Exchange Server 2010
Exchange Server 2010 provides Personal Archives as a feature that enables users to move their PST files
back into the Exchange Server database. To implement a Personal Archive, create a second mailbox that
the user can use to store messages that are no longer current, but which they may need to retain. The
user can access this archive mailbox in Outlook 2010 or Microsoft Outlook Web App just like any other
folder in the user mailbox.
How Personal Archives Works

To implement Personal Archives, the Exchange Server administrator creates a new archive mailbox for
the users. This mailbox can be on the same database as the primary mailbox, or on another database if
Exchange Server 2010 SP1 is installed. If you have configured a hybrid Exchange Online deployment, the
archive mailbox can also be located on Exchange Online while the primary mailbox is on-premises. You
can create the archive mailbox when you create the primary mailbox, or add the archive mailbox later.
The archive mailbox appears as a folder in the users regular mailbox when the user accesses their mailbox
by using Outlook 2007, Outlook 2010 or Outlook Web App. Users can the move their PST folders, or any
other messages, into the archive mailbox simply by dragging and dropping email into an archive folder.
You can also use archive policies to automatically move messages into the Archive mailbox based on a
retention setting.One of the differences between the primary mailbox and the archive mailbox is that the
archive mailbox is not cached on the client computer when you configure Outlook in cache mode. This
decreases the mailbox cache size on the client, but also means that the user can access the mail in the
mailbox only when connected to the Exchange server.
You can manage the archive mailbox through retention policies. For example, you can configure archive
policies that will move messages from the primary mailbox to the secondary mailbox based on the
Retention Tags assigned to the primary mailbox folders. Retention policies that delete messages after a
specified retention period are also applied to messages when they are moved into the archive mailbox.
Personal Archives in Exchange 2010 SP1

The Personal Archives functionality in Exchange Server 2010 SP1 includes the following:
Provision personal archive on a different mailbox database. You can provision a user's personal
archive on a mailbox database different from the one where the user's primary mailbox resides. This
capability allows you to implement a tiered storage topology. You can also store a personal archive
mailbox on Exchange Online services.
Import historical mailbox data to archive. You can import historical mailbox data from .pst files
directly to the user's personal archive by using the New-MailboxImportRequest cmdlet in the
Exchange Management Shell. You can also import data from .pst files to the user's primary mailbox,
and both the personal archive and the primary mailbox can be exported to .pst files by using the
New-MailboxExportRequest cmdlet in the Exchange Management Shell.
Delegate access to archive. Delegates can access the delegating user's archive mailbox by using
Outlook 2010.
Demonstration: How to Configure Personal Archives
In this demonstration, you will review how to configure a Personal Archive mailbox for a user account.
You will also see how to access the mailbox by using Outlook Web App.
Demonstration Steps
1. On VAN-EX1, in the Exchange Management Console, click Recipient Management, and then click
Mailbox.
2. Right-click a mailbox, and then click Enable Archive.

3. On the mailbox properties, review the archive quota settings.
4. Use the get-mailbox cmdlet to view the mailbox settings. Review the ArchiveName and
ArchiveQuota settings.
5. Verify that you cannot view the archive mailbox in Outlook 2007, but can see it through Outlook
Web App.
Question: Will you implement Personal Archives in Exchange Server 2010?
Question: What are the benefits and disadvantages of the Personal Archives feature?
Considerations for Implementing Personal Archives
Personal Archives provides an excellent opportunity for organizations to ensure that all messages in the
email system are stored in a location where the messages can be managed and accessed. However,
deploying Personal Archives will also require careful planning to ensure that the implementation is a
success.
In many organizations, some users may have several gigabytes of data stored in PST files. If all of these
messages are moved into archive mailboxes, the amount of storage required for the mailbox databases
will increase dramatically. Exchange Server 2010 enables you to manage very large mailboxes, but
organizations may not have sufficient storage or other infrastructure components, such as backup
capacity, to increase the size of the Exchange Server data store greatly.
Some considerations for managing the implementation for Personal Archives include:
Consider an incremental implementation for Personal Archives. If your storage infrastructure cannot
handle implementing Personal Archives for all users, start by identifying the users that will benefit
most from Personal Archives. This may include users with the most critical information currently
stored in PST files, or it may include all executives in the organization.
Because of the decrease in disk I/O, it is now feasible to store mailbox databases on lower
performance and less expensive disk arrays by using SATA drives. Additionally, rather than depending
on redundant disk arrays and backup to provide high availability, you can use database availability
groups (DAGs) to provide the required level of availability. With Exchange Server 2010 SP1, you can
also consider creating mailbox databases that will contain only archive mailboxes and configure less
expensive storage for the database, or configure fewer copies of the database within the DAG.
To manage the size of the archive mailboxes, you can configure archive mailboxes with an archive
warning quota and an archive quota. When an archive mailbox exceeds the specified archive warning
quota, a warning event is logged in the Application event log. When an archive mailbox exceeds the
specified archive quota, messages are no longer moved to the archive, a warning event is logged in
the Application event log, and a quota message is sent to the mailbox user. By default, in Exchange
Server 2010 SP1, the archive warning quota is set to 45 GB, and the archive quota is set to 50 GB.
After you implement Personal Archives, you should consider removing the option for users to use PST
files. You can start moving users away from using PST files by creating a Group Policy object (GPO)
that prevents new items from being added to existing PST files. Making PST files read-only gives users
access to the PST files they may already have while encouraging them to keep the messages that they
want to keep in their mailboxes. Eventually, you may want to create a GPO to remove access to PST
files altogether.
Lesson 5
Configuring Messaging Records Management
An important requirement for many organizations is managing the email stored in users mailboxes. In
some cases, organizations may need to retain some messages while deleting others after a specified time.
Exchange Server 2010 uses messaging records management to implement this functionality through
retention policies and managed folders. This lesson describes how to implement messaging records
management in Exchange Server 2010.
Describe Retention Tags and retention policies.
Configure Retention Tags and retention policies.

Describe managed folders.
Deploy managed folders.
Implement managed custom folders and content settings.
Identify options for implementing messaging records management.

Messaging Records Management Options
Personal Archives provide organizations with one option for managing the content of user mailboxes.
Messaging records management provides a second option. With messaging records management, you
can define rules that determine how long messages are retained, at what point messages are moved into
the personal archive or another folder, and at what point messages are deleted.
Messaging records management in Exchange 2010 enables flexible management of the messages in user
mailboxes. With messaging records management, you can configure different policies that provide unique
message retention options for different business units or levels of management within your organization.
Exchange Server 2010 provides the following two options for configuring messaging records
management:
Retention policies. Retention policies were first introduced in Exchange Server 2010. To configure
retention policies, you configure retention policy tags that set different rules about how long
messages will be retained. You then collect one or more retention policy tags into a retention policy
and apply the policy to user mailboxes. The retention policy then applies default retention settings to
messages in the user mailbox, but also provides users with options for changing the default settings
for individual messages or folders.
Managed folders. Managed folders were first introduced in Exchange Server 2007, but the
functionality is also available in Exchange Server 2010. To configure managed folders, you first create
managed folder content settings which define the retention period for messages. You can then link
these managed folder content settings to the default mailbox folders or create custom managed
folders in user mailboxes. The managed content settings are linked to a managed folder mailbox
policy, and the policy is applied to user mailboxes. The managed content settings are applied to
messages in the user mailbox depending on the message location. Users can manage message
retention by moving messages into appropriate folders.
Note In Exchange Server 2010, you had to manage retention policy tags and retention
polices by using Exchange Management Shell cmdlets. You could configure managed
folders in the Exchange Management Console, or by using Exchange Management Shell
cmdlets. With Exchange Server 2010 SP1, the management options have been reversed.
You can now manage retention policies in the Exchange Management Console and the
Exchange Management Shell, but you can only configure managed folders in the Exchange
Management Shell.
What Are Retention Tags and Retention Policies?
In Exchange Server 2010, you use retention tags to tag messages or folders for retention or deletion. Each
retention tag is associated with one or more managed content settings, which define the time for which
items are retained, and what will happen when the retention period expires. You can associate multiple
retention tags with a retention policy, which then is assigned to a user mailbox.
Messages are processed based on the retention tags and their associated content settings. When a
message reaches a retention limit, Exchange Server archives or deletes it, or flags it for user attention.
Retention Tags
Retention tags are the building blocks for retention policies. Each retention tag defines a folder or set of
folders that the tag can be applied to and defines the settings for message retention. Retention tags
specify how long a message remains in a mailbox folder, and the action that Exchange Server should take
when the message reaches the specified retention age.
The following types of retention tags are available:

Retention policy tag. Retention policy tags are applied to default mailbox folders such as Inbox,
Deleted Items, and Junk Mail. For example, you can set a retention policy tag that applies to the
Deleted Items folder that deletes all of the messages in the folder after 30 days, but allows users to
still recover the messages.
Default Policy Tag. A default policy tag can be associated with a retention policy and applies to all
items in the mailbox that do not have a retention tag explicitly applied to them, or that do not inherit
a tag from the folder they reside in. To create a default policy tag, you create a retention tag that
applies to all other folders in the user mailbox. You cannot have more than one default policy tag
associated with a retention policy.
Personal Tags. Personal tags are retention tags available to users as part of their retention policy. A
user can opt-in to use additional personal tags by using the Exchange Control Panel, and can apply
them to folders or items in the mailbox. Personal tags can have only one setting for expiry of all
message types.
Archive Tags
You can configure a retention tag with an action to move messages to the personal archive mailbox when
the retention period expires. Tags that perform this action are named archive tags. When the retention
period expires on a message, the message is moved to the archive mailbox into a folder that has the
same name and is in the same hierarchy as the primary mailbox. You can only associate archive tags with
default policy tags and personal tags. You cannot create an archive tag that is assigned to a specific
mailbox folder.
Retention Policies
Retention policies group one or more retention tags and apply the tags to mailboxes. A retention policy
consists of one or more retention policy tags, a maximum of one default policy tag, and any number of
personal tags. You can link or unlink tags from a retention policy at any time.
You can apply retention policies to mailboxes by using the Exchange Management Shell, the Exchange
Management Console, or the Exchange Control Panel. A mailbox cannot have more than one retention
policy.
Retention Tags and Mailbox Folders

Retention policy tags apply to default folders as specified in the retention policy. Users cannot change the
retention policy tags associated with default folders. However, users can apply a different tag to an item in
a default folder, thereby causing the item to have a different retention setting than the folder in which it
resides. Similarly, an item in a user-created folder can also have a different tag than the folder within
which it resides.
Any individual message can have a maximum of one retention tag and a maximum of one archive tag
assigned to it. The archive tag dictates when the message will be moved to the archive mailbox, and the
retention tag dictates when the message will be deleted from either the primary mailbox or the archive
mailbox.
A mailbox item moved from one folder to another inherits any tags applied to the folder to which it
moves. If an item moves to a folder that does not have a tag assigned to it, the default policy tag applies
to it. If the item has a tag explicitly assigned to it, the tag moves with the item and always takes
precedence over any folder-level tags or the default tag.
Demonstration: How to Configure Retention Tags and Policies
In this demonstration, you will review how to configure the three types of retention tags, and how to
configure content settings for the retention tags. Then you will see how to combine the retention tags
into a retention policy and how to assign the retention policy to a user.
Demonstration Steps
1. On VAN-EX1, in the Exchange Management Console, click Organization Management, and then
click Mailbox.
2. Create new retention policy tag that removes deleted items from mailboxes after 30 days.
3. Create new retention policy and link the new retention policy tag to it. Link other retention policy
tags to the policy as required.
4. Apply the retention policy to users in the ITAdmins OU.
5. Start the managed folder assistant for Lucas mailbox and verify that the retention tags are available
in Outlook.
Question: Do you think you will implement retention policies?
Question: Which messaging records management option are you more likely to implement:
managed custom or default folders, or retention policies?
What Are Managed Folders?
In addition to retention policies, you can implement messaging records management by configuring
managed folders. When you configure managed folders, you can configure managed content settings
that specify how long to retain messages in specified email folders. You can apply managed content
settings to the default email folders or to managed custom folders that you create in user mailboxes. You
then can create managed folder mailbox policies that apply the content settings for a folder or group of
folders to specified users.
Note Exchange Server 2007 introduced managed folders, and Exchange Server 2010
supports managed folders that are configured in Exchange Server 2007.
Managed Folder Options

Use the following options when configuring managed folders:
Configure content settings for the default folders that are created in all user mailboxes. When
configuring content settings for the default folders, set restrictions on how long the folder retains
messages. For example, the managed content settings that you apply to a users Inbox folder could
specify that its contents be automatically deleted or moved to another folder after 60 days. You can
also use the Exchange Management Console to apply content settings to the entire Mailbox folder.
The content settings applied to this folder will apply to all folders in the user mailbox, including
folders they have created.
Configure custom managed folders and then apply content settings to the custom folders. When
creating a custom managed folder, you can add that folder the user mailbox. You then can configure
content settings to apply to that folder. This is a useful option when users require the same folder,
and you need to manage the messages in the folder identically for all users. For example, several
users might be working on a special project that requires that all email messages related to the
project be stored for a set period. You can create a managed custom folder in the user Inbox
specifically for that project.
Managed Content Setting Options

When you configure managed content settings, use the following options for configuring how users
manage messages:
Configure retention periods, which enable you to define how long content will remain in users
mailboxes. You can configure these policies by content age and message type, such as voice mail or
appointments.
Configure what action occurs when the retention period expires. For example, you can configure
messages to be deleted permanently, moved to the Deleted Items folder, or moved to another folder.
Configure journal settings to ensure copies of all messages in the specified folder are sent to another
recipient.
Managed Folder Mailbox Policies

Managed folder mailbox policies enable you to group managed folders and assign the managed folder
settings to user accounts. For example, you might have created a managed content setting for the Inbox
and the Sent Items folders, and a custom managed folder for a sales project. To apply these settings to
users, you need to create a managed folder mailbox policy and assign the Inbox, Sent Items, and the
custom managed folders to the policy. You then assign the policy to all of the users in the Sales
department.
User Interaction with Custom Managed Folders

When you create custom managed folders, users have to move email messages from their Inbox to the
appropriate folders. Managed content settings are applied automatically to messages that users have
moved. User also can sort messages into appropriate folders by using Outlook rules.
If you apply content settings to default folders in a user mailbox, no user interaction is necessary for the
settings to apply to the folders.
Process for Deploying Managed Folders
To implement managed folders, you must complete the following steps:
1. Specify the folders to which you want to apply managed content settings. You can apply managed
content settings to default folders in user mailboxes, or you can create managed custom folders in
user mailboxes.
2. Specify the managed content settings for selected folders. When you configure content settings, you
can configure options that define the message types you want to manage, how long to retain the
messages, and what action to take when messages expire. You also can configure journaling settings
that will save a copy of all messages in the folder.
3. Create a managed folder mailbox policy. You can use mailbox policies to group multiple managed
folders.
4. Apply the managed folder mailbox policy to users mailboxes. By default, no managed folder mailbox
policies are created or applied to user mailboxes.
5. Schedule the managed folder assistant to apply the changes to users mailboxes. The managed folder
assistant creates managed folders in users mailboxes and applies managed content settings to them.
By default, the managed folder assistant runs from 1 A.M. to 5 A.M. every day.
Managed Folder Assistant

The Managed Folder Assistant is a process that runs on Mailbox servers, and applies managed folder and
retention settings to mailboxes located on that server. The assistant retrieves the list of managed folders
associated with a policy, provisions managed folders in mailboxes, and processes items in those folders.
In Exchange Server 2010, the Managed Folder Assistant also applies retention policies for messaging
records management. If you modify the Managed Folder Assistant schedule, it affects both messaging
records management features. In Exchange Server 2010, the Managed Folder Assistant is a schedule-
based assistant that is scheduled to run from 01:00 through 09:00 (1:00 A.M. through 9:00 A.M.) every
day. You can modify the Managed Folder Assistant schedule to ensure there is minimal user impact. You
can also start and stop the assistant manually by using the Exchange Management Shell.
In Exchange Server 2010 SP1, the Managed Folder Assistant is a throttle-based assistant. Throttle-based
assistants do not run on a schedule; instead, they are configured to process all mailboxes on a Mailbox
server within a certain period of time known as a work cycle. Additionally, at a specified interval known as
the work cycle checkpoint, the Managed Folder Assistant refreshes the list of mailboxes to be processed.
During the refresh, the assistant adds newly created or moved mailboxes to the queue. It also reprioritizes
existing mailboxes that have not been processed successfully for a while because of failures, and moves
them higher in the queue so they can be processed during the same work cycle.
To start the Managed Folder Assistant on Exchange Server 2010 SP1, you use the Exchange Management
Shell. If you want to run the Managed Folder Assistant for one specific mailbox, run the following cmdlet.
Start-ManagedFolderAssistant -Identity Sten@contoso.com
The preceding command will apply all retention policies or managed folders to a specific mailbox.
Considerations for Implementing Messaging Records Management
Messaging records management policies deal primarily with other message retention issues. By
implementing messaging records management policies, you can ensure that certain messages are deleted
in user mailboxes and that certain messages are retained for an extended period.
Note Remember that messaging records management requires an Exchange Enterprise

CAL for each mailbox on which it is enabled.
Ensure that you have business and legal approval before configuring messaging records management
policies. This is particularly important if you are configuring policies that will delete messages from
user mailboxes.
You can use retention policies and managed folder mailbox polices to group a collection of folders
with associated retention tags or content settings. If different user groups in your organization have
different requirements for messaging records management, you can create a unique policy for each
user group that includes just the folders that should apply to those users.
If your organization requires messages to be retained or managed based on projects, consider using
managed custom folders to apply messaging records management policies. With managed custom
folders, you can create the required folders in the mailboxes for all users associated with the projects,
and then ensure appropriate management of the folders messages.
If you want to automate the messaging records management process for all users, consider using
retention policies. With retention policies, you can set default tags that will be assigned to all folders,
while providing users with the option of overriding the tags.
Consider the default retention policy configuration. By default, no retention policies are applied to
any user mailboxes. However, when you enable a personal archive for a mailbox, the Default Archive
and Retention Policy is automatically assigned to the user mailbox. This default policy moves all
messages more than two years old to the archive mailbox. You can modify this default behavior
ensuring that the default policy is not applied when you enable a personal archive, or by changing
the default policy.
Use retention policies to limit mailbox sizes. You can use retention policy tags to remove old
messages from folders such as the Deleted Items folder, or the Sent Items folder.
Consider migrating managed folder settings to retention policies. In Exchange Server 2010 SP1, you
can use the Port Managed Folder wizard in the Exchange Management Console to migrate managed
folders to retention tags, thereby maintaining the same retention settings as the managed folder.
When you run the wizard, the retention tags created by porting managed folders contain the
managed folder name in the LegacyManagedFolder property. After you port or create retention
tags, you must link the tags to a retention policy and apply the policy to a mailbox. When the
Managed Folder Assistant processes the mailbox and finds a managed folder that matches a ported
retention tag, the assistant applies the retention tag to the managed folder. The ported retention tag
must be linked to the user's retention policy for this to occur.
Lab B: Configuring Personal Archives and Retention

Policies
Lab Setup
2. Ensure that the 10135B-VAN-DC1, 10135B-VAN-EX1, and the 10135B-VAN-CL1 virtual machines are
running:
Lab Scenario
You are the messaging administrator for A. Datum Corporation. Your organization has deployed Exchange
Server 2010.
The legal and audit departments at A. Datum provided you with several requirements for implementing
messaging policy and compliance. First, you must enable Personal Archives for all of the users in the
Marketing department. Additional requirements include configuring rules that will ensure that some
messages are retained for an extended period, while other messages are deleted when they expire.
Exercise 1: Configuring Personal Archives

Scenario
A. Datum Corporation is also concerned about the number of emails that some users are storing in PST
files. In particular, some members of the Executives and Marketing group have several gigabytes (GB) of
data stored in PST files. To provide these users with larger mailboxes, the project team has agreed to
provide the members of the Executives and Marketing group with archive mailboxes. You need to
configure the mailboxes for these users.
1. Create an archive mailbox for all members of the Marketing and Executives groups.
2. Verify that the archive mailbox was created for members of the Marketing group.
X Task 1: Create an archive mailbox for all members of the Marketing group
On VAN-EX1, in the Exchange Management Console, under Recipient Management, click Mailbox.
Sort the mailbox list by organizational unit, select all of the users in the Executives and Marketing
OUs, and then create an archive mailbox for them.
X Task 2: Verify that the archive mailbox was created for members of the Marketing
group
Log on to Outlook Web App as Manoj, and then verify that the archive mailbox was created.
Results: After this exercise, you should have configured archive mailboxes for all members of the
Marketing group.
Exercise 2: Configuring Retention Policies

Scenario
A. Datum also wants to ensure proper management of messages in the user mailboxes, and automate
message management in user mailboxes. The project sponsors have provided the following requirements:
Items in a users Deleted Items mailbox folder must be permanently deleted after 30 days.
Items in a users mailbox that have no other retention tag applied must be moved to archive after 365
days.
Users in Executives groups must be able to apply a Business Critical tag to specific items in their
mailboxes. These items should be moved to archive after 3 years.
To test this implementation, the executives have approved a pilot project to use retention policies for the
Marketing and Executives groups.
1. Create and configure retention tags.
2. Create and configure retention policies for the Marketing group.
3. Create and configure retention policies for the Executives group.

X Task 1: Create and configure retention tags

1. Use the Exchange Management Console to create a retention tag named Adatum Deleted Items,
that removes items from Deleted Items folder after 30 days.
2. Use the Exchange Management Console to create a retention tag named Adatum
DefaultMoveToArchive that moves items to Archive after 365 days, if they are not tagged with
another retention tag.
3. Create a retention tag for Personal folders that can be applied to personal items, and that retains
messages for 3 years before moving to archive. Name the tag Adatum BusinessCritical.
X Task 2: Create and configure retention policies for the Marketing group
1. Create a new retention policy by using the Exchange Management Console. Name the retention
policy Marketing Group Retention.
2. Add the Adatum Deleted Items and Adatum DefaultMoveToArchive retention tags to the
Marketing Group Retention policy.
3. Apply the Marketing Group Retention policy to mailboxes in the Marketing OU.
X Task 3: Create and configure retention policies for the Executives group
1. Create a new retention policy by using the Exchange Management Console. Name the retention
policy Executive Group Retention.
2. Use the Exchange Management Console to add the Adatum Deleted Items, Adatum
BusinessCritical, and Adatum DefaultMoveToArchive retention tags to the retention policy.
3. Apply the Executive Group Retention policy to mailboxes in the Executives OU.
Results: After this exercise, you should have configured Retention Tags and retention policies for the

following steps:
Important Start the 10135B-VAN-DC1 virtual machine first, and ensure that it is fully
started before starting the other virtual machines.
6. Wait for 10135B-VAN-DC1 to start, and then start 10135B-VAN-EX1. Connect to the virtual machine.
7. Wait for 10135B-VAN-EX1 to start, and then start 10135B-VAN-EX2. Connect to the virtual machine.
Review Questions
1. You need to ensure that a copy of all messages sent to a particular distribution group is saved. You
only want copies of messages sent to the distribution group, not copies of all messages sent to
individual members of the group. What should you configure?
2. You need to ensure that a user can search all Exchange Server organization mailboxes for specific
content. What should you do? What user training will you need to provide?
Common Issues Related to Implementing Messaging Policies

Identify the causes for the following common issues related and fill in the troubleshooting tips. For
Transport rules that use regular

expressions are not applied consistently.
Message recipients report that they are

receiving error messages when they
receive digitally signed messages from
other users in the organization.
After you implement a transport rule,

users report that some of the messages
they send to Internet recipients are not
delivered and they do not receive
notification of why the messages were
not delivered.

1. A. Datum Corporation has deployed an AD RMS server, and users are using it to protect email.
However, users report that when they protect email messages, users outside the organization cannot
read the messages. What should A. Datum messaging administrators do?
2. Woodgrove Bank has implemented message journaling for all messages sent to and from the legal
and compliance teams. These messages need to be available to auditors for seven years. The
mailboxes used for journaling are growing rapidly. What should the messaging administrators at
Woodgrove Bank do?
Best Practices Related to a Particular Technology Area in this Module

Implementing messaging policies in Exchange Server 2010 can be complicated and the optimal
configuration will be different in every organization. However, it is critical that you start thinking
about this issue now in order to implement the policies and configurations that will meet your
organizations legal requirements.
Implement messaging policies only after extensive testing in a lab environment. If you configure
messaging policies incorrectly, you could potentially delete messages that should be retained, or
disrupt message delivery. Additionally, some messaging policies may have unintended consequences.
Because of this, be sure to test all messaging policies thoroughly, and implement the policies in the
production environment incrementally.
Planning messaging policies always involves discussions with legal and compliance personnel who
may not understand how you can use Exchange Server to enforce messaging policies. Be prepared to
explain what Exchange Server can and cannot do in terms that people who are not messaging experts
can understand.
10-1
Module 10
Securing Microsoft Exchange Server 2010
Contents:
Lesson 1: Configuring Role-Based Access Control 10-3
Lesson 2: Configuring Audit Logging 10-26
Lesson 3: Configuring Secure Internet Access 10-34

Lab: Securing Exchange Server 2010 10-52
10-2 Securing Microsoft Exchange Server 2010
Module Overview
In many organizations, Microsoft Exchange Server 2010 provides a critical business function for both
internal and external users. Additionally, many organizations expose at least a few of their Exchange
servers to the Internet. For these reasons, it is important that you do what you can to secure the Exchange
Server deployment. There are several components to securing your Exchange Server deployment:
configuring administrative permissions appropriately and securing the Exchange Server configuration. This
module describes how to configure permissions and secure Exchange Server 2010.

Configure role-based access control (RBAC) permissions.
Configure audit logging.
Configure secure Internet access.

Lesson 1
Configuring Role-Based Access Control
Exchange Server 2010 uses the RBAC permissions model to restrict which administrative tasks users can
perform on the Mailbox, Hub Transport, Unified Messaging, and Client Access server roles. With RBAC,
you can control the resources that administrators can configure and the features that users can access.
This lesson describes how to implement RBAC permissions in Exchange Server 2010, and how to configure
permissions on Edge Transport servers.
Describe RBAC.
Describe management role groups.

Identify Exchange Server 2010 built-in management role groups.
Manage RBAC permissions.
Configure custom management role groups.
Describe management role assignment policies.
Work with management role assignment policies.
Describe Exchange Server split permissions.
Configure RBAC split permissions.
Configure Active Directory Domain Services (AD DS) split permissions.

What Is Role-Based Access Control?
RBAC is the new permissions model in Exchange Server 2010. With RBAC, you do not 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.
When you configure RBAC permissions, you can define precisely which Exchange Management Shell
cmdlets a user can run and which objects and attributes the user can modify.
All Exchange Server administration tools, including Exchange Management Console, Exchange
Management Shell, and Exchange Control Panel (ECP), use RBAC to determine user permissions.
Therefore, permissions are consistent regardless of which tool you use.
If RBAC allows the cmdlet to run, the cmdlet actually runs in the security context of the Exchange Trusted
Subsystem and not the user's context. The Exchange Trusted Subsystem is a highly privileged universal
security group that has read/write access to every Exchange Serverrelated object in the Exchange
organization. It is also a member of the Administrators local security group and the Exchange Windows
Permissions universal security group, which enables Exchange Server 2010 to create and manage AD DS
objects.
RBAC Options
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 management role group,
or to a custom management 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 assignment policies. Management role assignment policies are used to assign end-
user 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.
Note You also can use direct role assignment to assign permissions. Direct 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 role assignments are useful when you need to provide a granular set of permissions
to a specific user only. However, it is recommended that you avoid using direct 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?
What Are Management Role Groups?
A management role group is a universal security group that simplifies the process for assigning
management roles to a group of users. All members of a role group are assigned the same set of roles.
Role groups are assigned administrator and specialist roles that define major administrative tasks in
Exchange Server 2010, such as organization management, and recipient management. Role groups enable
you to more easily assign a broader set of permissions to a group of administrators or specialist users.
Use management role groups to assign administrator permissions to groups of users. To understand how
management role groups work, you need to understand their components.
Components of Management Role Groups

Management role groups use several underlying components to define how RBAC assigns permissions as
assigned:
Role holder. A role holder is a user or security group that you can add to a management role group.
When a user becomes a management role-group member, RBAC grants it all of the permissions that
the management roles provide. You can either add user accounts 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 users
or groups 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 a
role group can manage in the Exchange Server organization.
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 cmdlet, including its parameters, which 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 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,
organizational units, recipient objects, and more.
Examples of Management Role Groups

Management role groups define who can perform specific tasks and the scope within which
administrators can perform those tasks. For example, you can use RBAC to assign permissions as the
following table shows:
Role Management Management role Management role

holder role group Management role entries scope
Gregory Organization Organization All Exchange cmdlets Organization

Management Management
Alice Help Desk HelpDesk Cmdlets related to Organization

mailbox and user
account management
Jason Sales Admins SalesAdminRole Cmdlets related to Sales department

Recipient organization unit (OU) in
management only AD DS or Active Directory
Built-In Management Role Groups
Exchange Server 2010 includes several built-in role groups that you can use to provide varying levels of
administrative permissions to user 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 Role holders have access to the entire Exchange Server 2010 organization
Management and can perform almost any task against any Exchange Server object.
View-Only Organization Role holders can view the properties of any object in the organization.
Management
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, properties on
mailboxes, 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, transport rules, and can also export audit logs.
Server Management Role holders have access to Exchange server configuration. They do not
have access to administer recipient configuration.
Help Desk Role holders can perform limited recipient management.

(continued)
Role group Description
Public Folder Role holders can manage public folders and databases on Exchange servers.
Management
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.
Demonstration: Managing Permissions Using the Built-In Role Groups
In this demonstration, you will review how to manage RBAC permissions in Exchange Server 2010 by using
the built-in role groups. You will see how to add users to the built-in role groups and how RBAC assigns
the resulting permissions to the user accounts.
Demonstration Steps
1. On VAN-EX1, in Active Directory Users and Computers, add a user or security group to the Recipient
Management group.
2. On VAN-EX2, log on using the delegated user account. Open the Exchange Management Console
and the Exchange Management Shell.
3. Verify that the user has read access to the Exchange Server organization configuration.
4. Verify that the user cannot modify the settings on the Mailbox databases.
5. Verify that the user can modify the settings for mailboxes and distribution groups. Verify that the user
account has permission to move mailboxes to another server.
6. In the Exchange Management Shell, use the get-exchangeserver | FL cmdlet to verify that the user
has Read permission to the Exchange server information.
7. Use the Set-User cmdlet to verify that user has permission to modify the Active Directory account.
Process for Configuring Custom Role Groups
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.
Configuring a Custom Management Role Group

RBAC offers a variety of ways in which you can 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 add the branch office administrators to the role group. You can use the
New-RoleGroup cmdlet to create the group or create the group using the ECP. 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. You can also view this information in the Exchange Control
Panel.
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 and 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. You can use the ECP or
the New-RoleGroup cmdlet to create the link between the role group, the management roles, and
the management scope.For example, consider the following command:
New-RoleGroup Name BranchOfficeAdmins roles Mail Recipients, Distribution Groups,

Move Mailboxes, Mail Recipient Creation RecipientOrganizationalUnitScope
Adatum.com/BranchOffice
5. It does the following:
Creates a new role group named BranchOfficeAdmins.
Assigns the Mail Recipients, Distribution Groups, Move Mailboxes, and Mail Recipient Creation
management roles to the BranchOfficeAdmins role group.
Configures a management role scope limited to the BranchOffice OU in the Adatum.com
domain.
Demonstration: Configuring Custom Role Groups
In this demonstration, you will review how to create a custom role group and how to assign management
roles to the group. You also will verify that the correct permissions are assigned to the user accounts.
Demonstration Steps
1. On VAN-EX1, open the Exchange Control Panel. Log in as Adatum\administrator.
2. Create a new group in Active Directory Users and Computers, verify that the group has been created
in the Microsoft Exchange Security Groups OU and that the user has been added to the group.
3. Log on to the Exchange Server using the delegated user account, and open the Exchange
Management Console. Verify that the user can modify mailboxes and create new mailboxes only in
the Marketing OU.
Question: Will you implement custom management roles in your organization? If so, how
will you configure the management roles?
What Are 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 specific mailboxes.
In Exchange Server 2010 Service Pack 1 (SP1), you can use the ECP to view and modify the default
management role assignment policy and configure additional management role assignment policies with
different permissions. If you create a custom management role assignment policy, you must assign it to
the applicable mailboxes.
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.
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.
Working with Management Role Assignment Policies
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.
Note To view the default management role assignment policy configuration, use the
Get-ManagementRoleAssignment RoleAssignee Default Role Assignment Policy
cmdlet. This cmdlet lists all the management roles that are assigned to the default
role assignment policy. To view the details of each management role, use the
get-managementrole rolename | FL cmdlet. For example, executing the
get-managementrole Mybaseoptions | FL cmdlet displays all management role
entries associated with the Mybaseoptions management role.
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 by using
the RoleAssignmentPolicy parameter on the New-Mailbox, Set-Mailbox, or Enable-Mailbox
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.
Question: How will you configure role assignment policies in your organization?
What Are Exchange Server Split Permissions?
AD DS and Exchange Server 2010 are highly integrated, and there is no option for changing this. In many
small or medium sized organizations, the same administrators are responsible for managing both the
Exchange environment and the AD DS environment. This is called a shared permissions model.
However, in many larger organizations, different teams of administrators are responsible for managing
the AD DS and Exchange Server infrastructures. These organizations often have two separate IT groups
that manage the organizations Exchange Server infrastructure (including servers and recipients), and that
manage the AD DS infrastructure. Normally, this means that Exchange Server administrators cannot
manage AD DS objects, and vice versa. This model of administration is often called a split permissions
model. Split permissions enable organizations to assign specific permissions and related tasks to specific
groups within the organization.
When you implement split permissions, you remove the ability of Exchange administrators to create
security principals by using the Exchange management tools. This applies to both user account and
security groups. The end result of implementing split permissions is that security principals must now be
created using AD DS management tools. Once the object has been created, you can use the Exchange
management tools to configure the Exchange specific attributes on the security principals.
Exchange Server 2010 SP1 defaults to the shared permissions model. You do not need to change anything
if this is the permissions model you want to use. This model does not separate the management of
Exchange Server and Active Directory objects from within the Exchange Server management tools. It
allows administrators using the Exchange Server management tools to create security principals in AD DS.
Split Permissions Options in Exchange Server 2010 SP1

Exchange Server 2010 SP1 options for implementing split permissions:
RBAC split permissions. When you implement RBAC split permissions, you remove the ability for
Exchange administrators to run the cmdlets that create security principals in AD DS.
Active Directory split permissions. When you implement Active Directory split permissions, you
remove the permissions for the Exchange servers to create security principals in AD DS. Because
Exchange Management Shell cmdlets run in the security context of the Exchange servers, this
prevents anyone from using the Exchange management tools to create AD DS security principals.
Configuring RBAC Split Permissions
By default, administrators who are assigned to either the Mail Recipient Creation role or the Security
Group Creation and Membership role can create security principals in AD DS. In Exchange Server 2010,
the Organization Management role group is assigned both of these role assignments, while the Recipient
Management role group is assigned the Mail Recipient Creation Role role assignment.
When you configure RBAC split permissions, you remove theses management role assignments from the
default management role groups. This means that the members of the management role groups no
longer have permission to run the cmdlets used to create security principals, thus blocking them from
creating these objects by using any of the Exchange Server 2010 management tools. When you enable
RBAC split permissions, Exchange Server administrators will not be able to use the following cmdlets:
New-Mailbox
New-MailContact
New-MailUser
New-RemoteMailbox
Remove-Mailbox
Remove-MailContact
Remove-MailUser
Remove-RemoteMailbox
Additionally, the associated features in the Exchange Management Console and Exchange Control Panel
(such as the New Mailbox Wizard) will generate an error if you try to use them.
Configuring RBAC split permissions does not prevent administrators from using the AD DS management
tools to create security principals. If an Exchange administrator has AD DS permissions to create security
principals, they can do so by using the AD DS tools. They can then configure the Exchange attributes
using the Exchange management tools.
Configuring RBAC split permissions also does not modify the underlying RBAC principle that Exchange
servers through the Exchange Trusted Subsystem group have permissions to create security principals in
Active Directory. RBAC split permissions doesnt remove permissions from the Exchange Trusted
Subsystem account, it only removes permission to run cmdlets from Exchange administrators.
To configure RBAC split permissions, you must do the following:
1. Disable Active Directory split permissions if it is enabled. You can do this by running Exchange Server
Setup with setup.com with the /PrepareAD parameter and the /ActiveDirectorySplitPermissions
parameter set to false. If AD DS split permissions are not enabled, and your organization is using the
shared permissions model, you can skip this step.
2. Create a new role group that will contain the administrators that will be able to create security
principals in AD DS. This is an optional step, but enables you to configure a special group of Exchange
administrators that will still be able to use the Exchange Management tools to create security
principals.
3. Create regular and delegating role assignments between the Mail Recipient Creation role and the
new role group. This step is optional and applies only if you created the special role group mentioned
in the previous step.
4. Create regular and delegating role assignments between the Security Group Creation and
Membership role, and the new role group. The step is optional.
5. Remove the regular and delegating management role assignments between the Mail Recipient
Creation role, and both the Organization Management and Recipient Management role groups.
6. Remove the regular and delegating role assignments between the Security Group Creation and
Membership role, and the Organization Management role group.
After configuring RBAC split permissions, only members of the new role group that you create can
create security principals, such as mailboxes. The new role group will only be able to create the objects;
it will not be able to configure the Exchange Server attributes on the new object. An Active Directory
administratorwho is a member of the new groupwill need to create the object, and then an Exchange
Server administrator will need to configure the Exchange Server attributes on the object. If you want the
new role group to also be able to manage the Exchange Server attributes on the new object, you need to
assign the Mail Recipients role to the new role group.
Configuring Active Directory Split Permissions
Active Directory split permissions differ from RBAC split permissions in that when you implement Active
Directory split permissions, the Exchange servers no longer have permission to create AD DS security
principals because these permissions that are normally granted to the Exchange Windows Permissions
group are removed. Since the Exchange Trusted Subsystem group, which contains all of the Exchange
2010 servers, is the only member of the Exchange Windows Permissions group, these permissions are
removed from the Exchange servers.
Enabling Active Directory split permissions means that:
You can no longer create mailboxes, mail-enabled users, distribution groups, and other security
principals from the Exchange Server management tools.
You cannot add and remove distribution group members from the Exchange Server management
tools.
The Exchange Trusted Subsystem and Exchange servers no longer have permissions to create security
principals.
Exchange servers and the Exchange Server management tools can only modify the Exchange
attributes of existing security principals in AD DS.
You can only enable Active Directory split permissions when you run the Exchange Server 2010 SP1 or
later setup program. When you run the GUI version of setup during the initial deployment of Exchange
Server 2010 SP1, you can choose to enable split permissions. You can also use the command line setup
program with the /PrepareAD option and the /ActiveDirectorySplitPermissions option set to true
when you first install Exchange Server 2010 SP1, or you can run this command after installing Exchange to
change an existing deployment to use Active Directory split permissions.
When you run setup to implement Active Directory split permissions, the setup program makes the
following changes to the AD DS and Exchange deployments:
It creates a new OU called Microsoft Exchange Protected Groups.
It creates the Exchange Windows Permissions security group in the Microsoft Exchange Protected
Groups OU.
It does not add the Exchange Trusted Subsystem security group to the Exchange Windows
Permissions security group.
It does not create nondelegating management role assignments to management roles with the
following management role type:
MailRecipientCreation
SecurityGroupCreationandMembership
It does not add access control entries (ACEs) that would have been assigned to the Exchange
Windows Permissions security group to the Active Directory domain object.
To disable Active Directory split permissions, you can rerun Exchange setup with the /PrepareAD and the
/ActiveDirectorySplitPermissions parameters, setting the ActiveDirectorySplitPermissions parameter
to false.
Lesson 2
Configuring Audit Logging
In organizations where multiple Exchange Server administrators exist, it can sometimes be difficult to trace
changes that have been made to the Exchange configuration objects. Additionally, it can be difficult to
provide information about users accessing other mailboxes or performing other types of data access.
Exchange Server 2010 SP1 contains new logging functionality that can provide you with information
about administrative tasks performed on your Exchange servers.
Objectives
Describe administrator audit logging.
Describe mailbox audit logging.
Configure audit logging.

What Is Administrator Audit Logging?
In Exchange Server 2010, administrator audit logging captures data about changes made to your
organization by users and administrators. By default, administrator audit logging captures information
about all changes made to the Exchange server deployment.
Exchange Server 2010 administrator audit logging logs tracks all Exchange Management Shell cmdlets
that make changes to the Exchange environment. Since all tasks performed in the Exchange Management
Console and Exchange Control Panel are translated to Exchange Management Shell cmdlets, all changes
are logged no matter which tool you are using to perform the task.
Audit logging is intended to show what actions were taken to modify objects in an Exchange Server
organization, rather than what objects were viewed. Cmdlets are audited if the cmdlet is on the cmdlet
auditing list, and one or more parameters on that cmdlet are on the parameter-auditing list. By default,
the Test-, Get-, and Search- cmdlets are not logged because these cmdlets are usually not security-critical,
and they cannot directly change anything on Exchange Server objects. All other cmdlets are logged.
You can configure administrator audit logging in the Exchange Management Shell by using the
Set-AdminAuditLogConfig cmdlet. This cmdlet uses several parameters that allow you to configure
audit logging. Some of the most important parameters for this cmdlet are:
AdminAuditLogEnabled. When set to False, logging is not enabled. By default, this is the case for
Exchange Server 2010, but logging is enabled by default in Exchange Server 2010 SP1.
TestCmdletLoggingEnabled. This parameter enables Test- cmdlet logging.
AdminAuditLogCmdlets. This parameter specifies which cmdlets are logged when administrator
audit logging is enabled. By default, all cmdlets are logged, as indicated by the * wildcard character.
AdminAuditLogParameters. This parameter specifies whether cmdlet parameters are logged. By

default, this parameter is set to log all cmdlet parameters, as indicated by the * wildcard character.
AdminAuditLogAgeLimit. This parameter specifies how long each log entry should be kept before it
is deleted. The default age limit is 90 days.
AdminAuditLogMailbox. This parameter controls which mailbox is used to store the logged results.
This applies only to Exchange Server 2010.
If you want to see how administrator audit logging is currently configured.
Each time a cmdlet is logged, Exchange Server creates an audit log entry. Exchange Server 2010 stores
audit logs in a hidden, dedicated arbitration mailbox that you can only access by using the Exchange
Control Panel Auditing Reports page, or the Search-AdminAuditLog or New-AdminAuditLogSearch
cmdlets. The logs are not accessible from Microsoft Outlook Web App or Microsoft Office Outlook. In
addition, no one can delete audit log entries.
In Exchange Server 2010, you specify the administrator audit log mailbox. Exchange Server 2010 SP1 uses
a dedicated mailbox for administrator audit logging. You cannot modify this dedicated mailbox.
The ECP Auditing Reports page, and the Search-AdminAuditLog and New-AdminAuditLogSearch
cmdlets work only with Exchange Server 2010 SP1 administrator audit logs. To view the contents of an
Exchange Server 2010 audit log mailbox, you must open the audit mailbox using Outlook Web App, or
use an email client such as Office Outlook.
In Exchange Control Panel, you can view only a few administrator audit logging reports. If you want to
search the logs by specifying your own search parameters, you must use the Exchange Management Shell.
For example, suppose you want to search Set-Mailbox usage between 2/16/2012 and 3/16/2012, and
send the search results to Andreas@adatum.com. Run the following cmdlet:
New-AdminAuditLogSearch -Cmdlets Set-Mailbox -StartDate 02/16/2012

-EndDate 03/16/2012 -StatusMailRecipients Andreas@adatum.com
-Name "Mailbox changes report"
After you run the New-AdminAuditLogSearch cmdlet, Exchange Server may take up to 15 minutes to
deliver the report to the specified recipient.
You can also use same parameters with the Search-AdminAuditLog cmdlet, except for the
StatusMailRecipients parameter that specifies to send a report by email. The Search-AdminAuditLog
cmdlet provides the report inside the Exchange Management Shell window.
What Is Mailbox Audit Logging?
Mailbox audit logging allows you to log mailbox access by mailbox owners, delegates (including
administrators with full mailbox access permissions), and administrators. Mailboxes are considered
accessed by an administrator only in the following scenarios:
For discovery searches.
When Mailbox exports are specified through the New-MailboxExportRequest cmdlet.
For Microsoft Exchange Server Messaging Application Programming Interface (MAPI) Editor mailbox
access.
When you enable audit logging for a mailbox, you can specify which user actions should be logged. You
can also specify whether to log mailbox owner, delegate or administrator actions. Audit log entries also
include important information such as the client IP address, host name, and process or client used to
access the mailbox. For items that are moved, the entry includes the name of the destination folder.
Mailbox audit logs are generated for each mailbox that has mailbox audit logging enabled. Log entries
are stored in the Audits subfolder of the audited mailbox Recoverable Items folder. If you move a mailbox
to another Mailbox server, the mailbox audit logs for that mailbox also move because they are located in
the mailbox.
By default, mailbox audit log entries are retained in the mailbox for 90 days.
Unlike administrator audit logging, mailbox audit logging is not enabled by default, so you have to
activate it manually. In addition, mailbox audit logging is activated on a per-mailbox basis and not as a
general option. When you enable mailbox audit logging for a mailbox, access to the mailbox and certain
administrator and delegate actions are logged by default.
To log actions taken by the mailbox owner, you must specify which owner actions should be audited.
However, for mailboxes such as the Discovery Search Mailboxwhich may contain more sensitive
informationconsider enabling mailbox audit logging for mailbox owner actions such as message
deletion. It is recommended that you only enable auditing of the specific owner actions necessary to meet
business or security requirements.
To enable mailbox auditing on a specific mailbox, use the Exchange Management Shell. The following
example enables mailbox auditing on Terri Chudziks mailbox:
Set-Mailbox -Identity "Terri Chudzik" -AuditEnabled $true
To disable mailbox auditing, change the $true parameter to $false.
To search the mailbox audit log, you can use both the Exchange Control Panel and the Exchange
Management Shell. The Exchange Control Panel allows you to generate reports for nonowner mailbox
access, which is the most common report for this type of auditing. However, in this report you can only set
a date range as your filter. If you want to specify all available options, use the Exchange Management
Shell to perform your search.
The following example searches for users who accessed Terris mailbox during 2010, limiting results
to 2000:
Search-MailboxAuditLog -Identity Terri -LogonTypes Admin,Delegate -StartDate 1/1/2010 -

EndDate 12/31/2010 -ResultSize 2000
The results return to the Exchange Management Shell window.

The following example searches Terris and Jans mailboxes and sends the results to a specific mailbox:
New-MailboxAuditLogSearch Name "Admin and Delegate Access" -Mailboxes "Terri Chudzik","

Jan Dryml " -LogonTypes Admin,Delegate -StartDate 1/1/2012 -EndDate 2/31/2012 -
StatusMailRecipients "auditors@adatum.com"
This command locates access attempts by administrators and delegates during 2010. Results are sent to
email alias auditors@adatum.com.
Demonstration: Configuring Audit Logging
In this demonstration, you will review how to configure administrator audit logging and mailbox audit
logging, and how to search audit logs from both the Exchange Control Panel and the Exchange
Management Shell.
Demonstration Steps
1. Log on to VAN-EX1 and VAN-EX2 as Administrator with password Pa$$w0rd.
2. Check the administration audit logging configuration by using the Get-AdminAuditLogConfig

cmdlet.
3. Perform a search of the administrative audit log by using the Search-AdminAuditLog cmdlet.
4. Enable mailbox auditing for Jan Drymls mailbox and enable Send As permissions for Ebru Ersan.
5. As Ebru Ersan, send an email message from Jans mailbox to Administrator.
6. Using the Exchange Control Panel, perform a search for mailboxes accessed by non-owners.
Lesson 3
Configuring Secure Internet Access
Exchange Server 2010 provides access to user mailboxes from a wide variety of clients. In many cases,
these clients may be located outside the corporate network and may be accessing the user mailboxes
through an Internet connection. Because the Exchange servers cannot provide this functionality without
being accessible from the Internet, it is important that the connections from the Internet be as secure as
possible. This lesson describes how to configure secure access to the Exchange servers from the Internet.
Describe how to implement Exchange Server security.
Describe secure Internet access components.

Deploy Exchange Server 2010 for Internet access.
Secure Client Access server traffic from the Internet.
Secure SMTP connections to the Internet.
Describe reverse proxy.
Configure secure access.

Exchange Server Security Guidelines
The design of Exchange Server 2010 makes it secure when you deploy it. Many of its features, such as
server roles, Kerberos version 5 authentication, and self-signed certificates ensure that the servers present
a minimal attack surface and facilitate encryption for most network traffic sent to and from Exchange
servers.
To maintain Exchange Server security, implement regular processes to monitor and validate the Exchange
Server configuration.
Apply Security and Software Updates

One of the most critical components for maintaining Exchange Server security is to install all security
updates as soon as possible after their release. Be sure to apply both the operating-system updates and
the Exchange Server updates.
Before update installation, test the deployment of all software updates on your Exchange servers. To do
this, you need a test environment that emulates your production environment.
Run the Exchange Best Practices Analyzer Tool Regularly

The Exchange Best Practices Analyzer automatically examines your Exchange Server deployment and
determines whether the configuration is set according to Microsoft best practices. Use the Exchange Best
Practices Analyzer as part of a proactive health check, which can expose availability or scalability issues
that pertain to your Exchange Server installations. You also can use it as a reactive troubleshooting tool
for problem diagnosis and identification.
For most environments, we recommend running the Exchange Best Practices Analyzer at least once per
quarter. However, it is a best practice to run this tool once a month on all servers installed with Exchange
Server.
Additionally, you should run the Exchange Best Practices Analyzer in the following scenarios:
Whenever you make significant configuration changes to an Exchange server. For example, you
should run it after you add or remove connectors or create an EdgeSync connection to an Edge
Transport server.
Immediately after you install a new Exchange Server role or remove an existing Exchange Server role.
After you install a Windows service pack or Exchange Server service pack.
Avoid Running Additional Software on Exchange Servers

One way to reduce an Exchange servers attack surface is to avoid running unnecessary software on the
server. Ideally, you should dedicate the Exchange server to Exchange server roles, and the only additional
software that you should install are utilities, such as anti-virus software and server-management tools.
Install and Maintain Anti-Virus Software

Virtually all organizations deploy anti-virus software to guard against malicious email. You also should
deploy file-level, anti-virus software on the Exchange servers to ensure that the servers are secure from
virus attacks.
Enforce Strong Passwords in Your Organization

If you enable remote access to your Exchange Server organization, attackers from outside the
organization can use brute force password attacks to attempt to compromise user accounts. Therefore, it
is very important that you define and enforce password policies for all user accounts. This includes
mandating the use of strong passwords. A password is strong if it meets several requirements for
complexity that make it difficult for attackers to figure out. These password requirements include rules for
password length and character categories. By establishing strong password policies for your organization,
you can help prevent an attacker from impersonating users, and thereby prevent the loss, exposure, or
corruption of sensitive information.
Secure Internet Access Components
Exchange Server 2010 enables users to access their mailboxes from many different types of messaging
clients and from almost anywhere. To provide secure access for the messaging clients, you need to
understand what types of access each client type requires.
Client Access to Exchange Servers

The following table lists the access requirement for clients when connecting to the Exchange servers from
the Internet.
Client Access requirements
Outlook Anywhere Outlook 2007 and Outlook 2003 clients required access to the remote
procedure call (RPC), Exchange Web Services (EWS), and online address book
virtual directories on a Client Access server. Outlook 2010 clients only require
access to the RPC virtual directory.
Access to the Autodiscover virtual directory on a Client Access server if
Autodiscover is enabled
Protocol requirements: HTTPS
Microsoft Outlook Access to Outlook Web App and ECP virtual directories on a Client Access
Web App server
Microsoft Exchange Access to the Microsoft-Server-ActiveSync virtual directory on a Client Access

ActiveSync server
Access to the Autodiscover virtual directory on a Client Access server if
Autodiscover is enabled
(continued)
Client Access requirements
Internet Message Access to the IMAP4 service on a Client Access server

Access Protocol Access to a SMTP Receive connector on either a Hub Transport server, a Edge
version 4rev1 (IMAP4) Transport server, or another SMTP server
Protocol requirements: IMAP4, SMTP (Port 25 or 587)
Post Office Protocol 3 Access to the POP3 service on a Client Access server
(POP3) Access to a SMTP Receive connector on either a Hub Transport server, a Edge
Transport server, or another SMTP server
Protocol requirements: POP3, SMTP (Port 25 or 587)
Note In addition to the Client Access components, you also need to configure the
environment to support secure sending and receiving of SMTP email. In most cases, this
includes deploying an Edge Transport server in the perimeter network.
Options for Configuring Internet Access

There are several options available to provide the necessary access to the Client Access and transport
servers. The most common options include:
Virtual Private Network (VPN). Some organizations require that all clients use a VPN to connect to the
internal network. The VPN gateway may be a Windows Server 2008 Routing and Remote Access
server, or a third-party solution. By enabling VPN access, users can access all resources on the internal
network, including the Exchange servers. Using a VPN does not require modifications to the
messaging clients, and users can use the same server names externally and internally.
Implementing a VPN solution also simplifies the network perimeter configuration because you only
enable a single option for accessing the internal network. VPNs also provide advanced client security
options such as multi-factor authentication and Network Access Protection. However, the VPN
solution also limits the options that users have for accessing their email. They will be able to access
their email only from clients that can establish a VPN connection to the internal network.
Firewall configuration. Virtually all 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 messaging clients need to be configured to use a server
name that resolves to an external IP address on the firewall. If users connect to the Exchange servers
from both inside and outside the organization, this 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 name, such as mail.contoso.com,
when 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 Domain Name System (DNS) zone to provide name
resolution to the more generic name.
Configuring firewalls to provide access to the Exchange servers is easy, but does raise potential
security issues. Standard firewalls can filter network traffic based on source and destination IP
addresses and ports, but cannot analyze the contents of the 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.
Reverse proxy configuration. As an alternative to the standard firewall, you can use a reverse proxy, or
application layer firewall, to enable access to the internal Exchange servers. When you configure a
reverse proxy, it terminates all client connections and scans 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. When you use a reverse proxy, you must configure messaging clients to use a
server name that resolves to an external IP address on the firewall.
Deploying Exchange Server 2010 for Internet Access
When deploying Exchange Server 2010 so that it is accessible from the Internet, you must deploy all
server roles on the internal network, except for the Edge Transport server role. You should deploy the
Edge Transport server role in the perimeter network, and it should run on a server that is not an internal
domain member.
The recommended deployment for Exchange Server 2010 Internet access includes two firewalls in a back-
to-back firewall scenario, which enables you to implement a perimeter network between the two. An
external firewall faces the Internet and protects the perimeter network. You then deploy an internal
firewall between the perimeter and internal networks.
Configuring External Firewalls for Internet Access

The Internet facing or external firewall in this deployment protects the perimeter network. You configure
the firewall to accept packets based on source and destination IP addresses and ports. To support the
Exchange Server deployment, you need to configure the external firewall with the firewall rules that the
following table lists:
Destination port Address
25 Source address: All

Destination address: Edge Transport server
May also need to configure the external IP address of the internal firewall as a
destination address, if POP3 and IMAP4 clients are using port 25 to relay
messages through a Hub Transport server
80, 443 Source address: All

Destination address: External IP address of the internal firewall
(continued)
Destination port Address

Only required for POP3 access

Only required for IMAP4 access
587 Source address: All

Only required if POP3 and IMAP4 clients are using the SMTP client submission
port to send SMTP email
Configuring Internal Firewalls for Internet Access

The internal firewall may be another standard firewall or reverse proxy. To support the Exchange Server
deployment, configure the internal firewall with the following firewall rules:
Destination
port Address
25 Source address: Edge Transport server
Destination address: Hub Transport server
May also need to configure the internal IP address of external hosts as a source address,
if POP3 and IMAP4 clients are using port 25 to relay messages through a Hub Transport
server
80, 443 Source address: Internal IP address of the external firewall

Destination address: Client Access server
110, 995 Source address: External IP addresses

Only required for POP3 access
143, 993 Source address: External IP addresses

Only required for IMAP4 access
587 Source address: External IP addresses

Destination address: Hub Transport server
Only required if POP3 and IMAP4 clients are using the SMTP client submission port to
send SMTP email
(continued)
Destination
port Address
50636 Source address: Hub Transport servers on the internal network
Required for the Hub Transport server to replicate information to the Edge Transport
servers using EdgeSync
3389 Source address: Administrator computers on the internal network

Required if you want to use Remote Desktop to administer the Edge Transport server
remotely
Note Edge Transport servers also listen on port 50389 for unencrypted LDAP connections.
This port is used only for administering the AD LDS instance on the Edge Transport server
using standard LDAP tools. However, this port does not have to be open on the internal
firewall.
Securing Client Access Traffic from the Internet
To ensure that the client connections are as secure as possible, implement the following
recommendations:
Create and configure a server certificate. By default, all Client Access servers are configured with
self-signed certificates during Exchange Server 2010 installation. Because clients do not trust this
certificate, you should replace the certificate with one from a public Certification Authority (CA) or
from an internal CA. If you use an internal enterprise CA, the certificates will be trusted by computers
that are the internal domains members, but not by other client computers.
Require Secure Sockets Layer (SSL) for all virtual directories. With Exchange Server 2010, you can
configure all of the Client Access server virtual directories to require SSL.
Enable only required client access methods. You should enable access to only the client access
options that your organization requires. For example, if your organization only requires Exchange
ActiveSync and Outlook Web App connectivity from the Internet, then only allow access to those
virtual directories through the firewall. If your organization does not require POP3 or IMAP4 access,
then you can disable those services on the Client Access server and ensure that the required ports are
not accessible from the Internet.
Require secure authentication. Forms-based authentication is the most secure authentication

mechanism for Outlook Web App. Other client access options, such as Outlook Anywhere or
Exchange ActiveSync, cannot use forms-based authentication, and may need to use authentication by
Microsoft Windows NTLAN) Manager, also known as NTLM, or use basic authentication. If you
configure the virtual directories to require SSL, the network traffic that authenticates the user is
encrypted. You can also implement multifactor authentication. For example, you can require that all
client computers use a trusted certificate or smart card, in addition to the user name and password.
You also can implement a third-party multifactor authentication mechanism, such as RSA SecureID.
Enforce remote client security. One of the difficulties in ensuring client access security is that you may
not have control over the client devices that users use to access their mailboxes. For example, users
may be using their home computers or public kiosks to access Outlook Web App. If you require
certificate authentication for client connections, you can restrict which clients can access the
Exchange mailboxes. Rather than implement Outlook Web App, you also might choose to implement
Outlook Anywhere and restrict access to computers that are members of your internal domain by
implementing certificate based IPSec authentication for client connections.
Require TLS/SSL for IMAP4 and POP3 access. To help secure communications between your POP3
and IMAP4 clients and the Client Access server, configure the Client Access server to use a certificate
for these protocols, and then force all clients to use Transport Layer Security (TLS) or SSL to encrypt all
authentication and message access traffic.
Implement an application layer firewall or reverse proxy. To provide additional security, place an
application layer firewall or reverse proxy between the Internet and the Client Access server. This
firewall can decrypt all network traffic between the client and the Client Access server, and inspects
the traffic for malicious code.
Securing SMTP Connections from the Internet
If you enable POP3 and IMAP4 connections from the Internet to your Client Access servers, you must
provide a means by which those clients can send email using SMTP. As part of ensuring security for your
client-access deployment, you also need to ensure secure SMTP connectivity.
Providing SMTP Connectivity for POP3 and IMAP4 Clients

You can use POP3 and IMAP4 only to retrieve, not send, messages from user mailboxes. To enable clients
to send email, you must configure the clients to use an SMTP server that relays the messages to both
internal and external recipients.
To enable the POP3 and IMAP4 clients to send email, you must configure a Hub Transport server SMTP
Receive connector to accept SMTP connections from the Internet. Configure the SMTP Receive connector
to require authentication, so that only users with valid accounts in the Exchange Server organization can
relay messages through the server.
Note If you accept anonymous SMTP connections from the Internet on the Hub Transport
server, using the Default SMTP Receive connector, you need to create an additional SMTP
Receive connector for the POP3 and IMAP4 clients, and configure the new connector to
required authenticated connections.
Note You cannot use an Edge Transport server to accept authenticated SMTP
connections, and then use it to relay SMTP messages from POP3 and IMAP4 clients. You can
configure a SMTP Receive connector on an Edge Transport server that uses port 587, and
you can configure the Receive connector to accept authenticated connections. However,
you cannot configure the connector to authenticate the client connections using the users
internal Active Directory account.
Securing SMTP Connections

To secure the SMTP connections to the Hub Transport server, complete the following steps:
1. Enable TLS for SMTP client connections. You can configure the SMTP Receive connector on the Hub
Transport server to require TLS security or to enable basic authentication, only after you initiate a TLS
session. If you have a trusted certificate assigned to the SMTP service, 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 is configured to use port 25, while the Client
Receive connector is configured to use port 587. By default, both connectors are configured to
require TLS security and to 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 Receive connectors block anonymous relays, and you
should 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.
Note In some cases, you may need to enable anonymous relay to allow internal
applications to send SMTP email through the Exchange server. If you require this
functionality, then configure restrictions on the Receive connector so that only the IP
addresses that you specify can relay through the server.
4. Enable IMAP4 and POP3 selectively. If only some users in your organization require POP3 and IMAP4
access, then disable this option on all other mailboxes.
Benefits of Using Reverse Proxy
You may want to use a reverse proxy server to manage incoming requests to a Client Access server. A
reverse proxy server provides the following advantages over a direct connection to a Client Access server:
Security. The reverse proxy server provides an extra protective layer between the network and
external computers. This is because the reverse proxy server is the endpoint for all client connections.
The reverse proxy server then creates a new connection to the internal server.
Application layer filtering. Most reverse proxy servers also can operate as application layer firewalls.
Application layer filtering enables the proxy to open up the entire TCP/IP packet and inspect the
application data for unacceptable commands and data. For example, an HTTP filter intercepts
communication on port 80 and inspects it to verify that the commands are authorized before passing
the communication to the destination server. Firewalls that are capable of application-layer filtering
can stop dangerous code at the networks edge before it does any damage.
SSL bridging. If you must encrypt communication between the reverse proxy server and the Client
Access server, do this by ending the SSL session between the Web browser and reverse proxy server.
You then establish a new SSL session between the reverse proxy server and the Client Access server.
This protects the Client Access server from direct access from the Internet, enables the reverse proxy
server to filter the data packets before they reach the Client Access server, and encrypts the data
along the whole path between the Web browser and the Client Access server.
Load balancing. A reverse proxy server can distribute the traffic that is destined for a single URL to
a group of servers. You automatically implement Web load-balancing features when you publish
Outlook Web App and Outlook Anywhere. Outlook Web App automatically selects a rule by using
cookie-based load balancing. With cookie-based load balancing, the reverse proxy server forwards
all requests that relate to the same session (the same unique cookie provided by the server in each
response) to the same server. Outlook Anywhere uses source-IP-based load balancing. With source-
IP-based load balancing, the reverse proxy server forwards all requests from the same client (source)
IP address to the same server. Other Exchange services and features, such as Exchange ActiveSync,
must use cookie-based load balancing. This also includes the Exchange services, such as the offline
address book and the Availability Service.
SSL offloading. Instead of configuring the Client Access server to provide SSL encryption, you can
offload that function to the reverse proxy server. Not only does it encrypt data that is sent between
the Web browser and the Client Access server, but it also enables the reverse proxy server to inspect
the data packets and apply filters before they reach the Client Access server. If you offload SSL
encryption to a proxy server, data that is sent between the reverse proxy server and the Client Access
server will not be encrypted unless you use SSL bridging.
Demonstration: Configuring Threat Management Gateway for Outlook

Web App
In this demonstration, you will review how to create an Outlook Web App publishing rule in the Microsoft
Forefront Threat Management Gateway (TMG).
Demonstration Steps
1. On VAN-TMG, open the Forefront TMG Management console.
2. In the Firewall Policy node, create an Exchange Server publishing rule by using the New Exchange
Publishing Rule Wizard. Configure the rule with the following settings:
Name: OWA Access Rule

Exchange version: Exchange Server 2010
Service: Outlook Web App
Server Connection Security: Use SSL to connect the published Web server or server farm
Internal site name: VAN-EX1.Adatum.com
Public Name Details page: mail.Adatum.com
3. Create a new Web Listener with the following settings:
Name: HTTP Listener
Client Connection Security: Do not require SSL secure connections from clients
Web Listener IP Addresses: External
Authentication Settings: HTML Form Authentication
Single Sign-On (SSO) Settings: Enabled
SSO domain name: ADatum.com

4. On the Authentication Delegation page, click Basic authentication.
5. Accept the default User Sets configuration, finish the wizard, and then apply the changes.
Question: Has your company deployed a reverse proxy? If so, what kind? How does your
reverse proxy compare to the TMG?
Lab: Securing Exchange Server 2010
Lab Setup
running:
3. The 10135B-VAN-TMG and the 10135B-VAN-CL1 virtual machines will be started later in this lab:
10135B-VAN-TMG: Forefront Threat Management Gateway server in the Adatum.com domain
10135B-VAN-EX1: Windows 7 client computer in the Adatum.com domain
Adatum\Administrator, using the password Pa$$w0rd. Do not log on to VAN-EX2 at this point.
Lab Scenario
A. Datum Corporation has deployed Exchange Server 2010. The company security officer has provided
you with a set of requirements to ensure that the Exchange Server deployment is as secure as possible.
The specific concerns included in the requirements include:
Exchange Server administrators should have minimal permissions. This means that, whenever possible,
you should delegate Exchange Server management permissions.
Any configuration changes made to the Exchange server environment should be audited. The audit
logs must be available for inspection by company auditors.
The organization must have the option of auditing all non-owner access to user mailboxes. The audit
logs must be available for inspection by company auditors.
Ensure that client connections to the Client Access servers are as secure as possible by deploying a
TMG server.
Exercise 1: Configuring Exchange Server Permissions

Scenario
A. Datum Corporation has completed the Exchange Server 2010 deployment, and now is working on
integrating Exchange Server and recipient management with their current management practices. To
meet the management requirements, you need to ensure that:
Members of the ITAdmins group can administer individual Exchange servers, but they should not be
able to modify any of the Exchange Server organization settings.
Members of the HRAdmins group must be able to manage mail recipients throughout the entire
organization. They should not be able to manage distribution groups and should not be able to
create new mailboxes.
Members of the SupportDesk group should be able to manage mailboxes and distribution groups for
users in the organization. They should also be able to create new mailboxes.
1. Configure permissions for the ITAdmins group.

2. Configure permissions for the Support Desk and HRAdmins groups.
3. Verify the permissions.
X Task 1: Configure permissions for the ITAdmins group

On VAN-EX1, in Active Directory Users and Computers, add the ITAdmins group to the Server
Management group.
X Task 2: Configure permissions for HRAdmins and Support Desk groups

1. On VAN-EX1, open the Exchange Management Shell. Use the following command to create the
HRAdmins role group:
New-RoleGroup Name HRAdmins roles Mail Recipients
2. Use the following command to create the SupportDesk role group:
New-RoleGroup Name SupportDesk roles Mail Recipients, Mail Recipient Creation,

Distribution Groups
3. On VAN-EX1, open the Exchange Management Console. Access the Role Based Access Control
(RBAC) User Editor from the Exchange Management Console Toolbox node. Log on as
Adatum\administrator using the password Pa$$w0rd.
4. Add Anna Lidman to the SupportDesk group.

5. Add Paul West to the HRAdmins group.
X Task 3: Verify the permissions

1. On VAN-EX2, log on as Shane. Shane is a member of the ITAdmins group. Open Exchange
Management Console and verify that the account has the following permissions:
Can modify the Issue warning at (KB) setting for the Accounting mailbox database.
Cannot modify Hub Transport settings at the organization level. For example, try to modify the
accepted domain settings.
Cannot modify recipient settings. For example, try modifying any properties on one of the
mailboxes.
2. Log off VAN-EX2.

3. On VAN-EX1, open Internet Explorer and connect to https://van-ex1.adatum.com/ecp. Log on as
Adatum\Anna, and verify that the account has the following permissions:
Can modify mailbox settings for users by using the Exchange Control Panel. For example, try
modifying the department attribute for Andreas Herbinger.
Can modify distribution lists using the Exchange Control Panel. For example, add a group
description for the Accounting group.
Note You cannot create or delete user accounts and mailboxes in Exchange Control Panel.
If you want to test whether Anna can create user accounts and mailboxes, add Anna to the
local Administrators account on VAN-EX2, and log on to VAN-EX2 as Anna. Then open
Exchange Management Console and verify that you can create a mailbox. In a production
environment, you could install the Exchange Management tools on a Windows 7 client
computer.
4. Close Internet Explorer, and open it again and connect to https://van-ex1.adatum.com/ecp. Log on
as Adatum\Paul, and verify that the account has the following permissions:
Can modify mailbox settings for users by using the Exchange Control Panel.
Cannot modify distribution lists using the Exchange Control Panel.
Exercise 2: Configuring Audit logging

Scenario
You now need to configure audit logging on the Info@Adatum.com shared mailbox.
1. Create and configure an Info@Adatum.com mailbox.

2. Enable audit logging on the Info@Adatum.com mailbox.
3. Perform SendAs activity on the Info@Adatum.com mailbox.
4. Verify that the activity is logged.
5. Verify the administrator audit logging configuration.
6. Make a change to Michiyo Satos mailbox.
7. Verify that the change was logged.

X Task 1: Create and configure an Info@Adatum.com mailbox

1. On VAN-EX1, log on as Adatum\Administrator using the password Pa$$w0rd.
2. In the Exchange Management Console, in Recipient Management, create a new mailbox-enabled

user in the CustomerService OU with the name and logon name of Info, using the password
Pa$$w0rd.
3. Grant all users in the CustomerService OU Full Access and SendAs permission to the Info mailbox.
X Task 2: Enable audit logging on the Info@Adatum.com mailbox

Open the Exchange Management Shell, and then run the following cmdlet to enable mailbox audit
logging for the support mailbox:
Set-Mailbox -Identity "Info" -AuditDelegate SendAs,SendOnBehalf

-AuditEnabled $true
X Task 3: Perform SendAs activity on the Info@Adatum.com mailbox

1. On VAN-EX1, open Outlook Web App by typing https://van-ex1.adatum.com/owa in Internet
Explorer.
2. Log on as Adatum\Anna using the password Pa$$w0rd.
3. Create a new message, and then send it from the Info@Adatum.com account to Administrator.
X Task 4: Verify that the activity is logged

1. On VAN-EX1, open Internet Explorer, type https://van-ex1.adatum.com/ecp, and then log on to
the Exchange Control Panel as Adatum\Administrator using the password Pa$$w0rd.
2. Open Roles&Auditing, click Auditing, and then run a non-owner mailbox access report for the
Info@Adatum.com mailbox. Include a date range from yesterdays date to tomorrows date, and then
select the All non-owners option when running the report.
3. Verify that the SendAs activity from Task 3 is logged.
X Task 5: Verify the administrator audit logging configuration

2. Verify that administrator audit logging is enabled by typing Get- AdminAuditLogConfig.
X Task 6: Make a change to Michiyo Satos mailbox

1. On VAN-EX1, open the Exchange Management Console, expand Recipient Management, and then
click Mailbox.
2. Open the Properties dialog box for Michiyo Sato, and change retention period for deleted items
to 20 days. Save changes.
X Task 7: Verify that the change was logged

1. On VAN-EX1, in the Exchange Management Shell, run the following cmdlet:
Search-AdminAuditLog -Cmdlets Set-Mailbox -StartDate 01/01/2012

-EndDate (Tomorrows date)
2. Verify that you see a result for the event logged from Task 6.
Results: After this exercise, you should have configured audit logging.
X To prepare for the next exercise

1. On the host computer, in Hyper-V Manager, right-click 10135B-VAN-EX2, click Revert, and then
click Revert.
2. Start the VAN-TMG and VAN-CL1 virtual machines.
3. Log on to VAN-TMG as Adatum\Administrator using the password Pa$$w0rd. Do not log on to

VAN-CL1 at this point.
Results: After this exercise, you should have configured and verified permissions in the Exchange Server
deployment.
Exercise 3: Configuring a Reverse Proxy for Exchange Server Access

Scenario
A. Datum Corporation has decided to enable users to access their mailboxes remotely by using Outlook
Web App. To provide maximum security for the external clients, A. Datum wants to deploy a Forefront
TMG server as a reverse proxy. You must encrypt all connections to the TMG server, and all connections
from the TMG server to the Client Access server.
1. Request a server certificate with multiple storage area networks (SANs) on the Client Access server.
2. Export the certificate from the Client Access server.
3. Import the certificate on the TMG server.
4. Configure an Outlook Web Access publishing rule.
5. Configure the Client Access server.
6. Test the Outlook Web App publishing rule.

X Task 1: Request a server certificate with multiple SANs on the Client Access server
1. On VAN-EX1, run the New Exchange Certificate Wizard using the following configuration options:
Friendly name: Adatum Mail Certificate
Outlook Web App: Outlook Web App is on the intranet and uses a host name of
VAN-EX1.adatum.com
Outlook Web App: Outlook Web App is on the Internet and uses a host name of
mail.adatum.com
Exchange ActiveSync: Enabled and uses a host name of mail.adatum.com
Autodiscover: Used on the Internet
Long URL: Used for AutoDiscover with a host name of Autodiscover.adatum.com
Organizational Unit: Messaging

State/province: BC
2. Save the file using the name CertRequest.req.
3. Copy the text of the certificate request file to the clipboard.
4. Connect to http://van-dc1.adatum.com/certsrv, and create an advanced certificate request using a

certificate request file. Paste the contents of the certificate request file into the Saved Request field.
Request a Web server certificate.
5. Download the certificate and save it to the C: drive.

6. In the Exchange Management Console, use the Complete Pending Request Wizard to import the
Adatum Mail certificate.
7. In the Exchange Management Console, use the Assign Services to Certificate Wizard to assign the
Adatum Mail certificate to Internet Information Services (IIS).
X Task 3: Export the certificate from the Client Access server

On VAN-EX1, in Exchange Management Console, export the certificate to C:\CertExport.pfx.
X Task 4: Import the certificate on the TMG server

On VAN-TMG, use the Certificates MMC to import \\VAN-EX1\c$\CertExport.pfx into the
Computer Personal store.
X Task 5: Configure an Outlook Web Access publishing rule

1. On VAN-TMG, open the Forefront TMG Management console.
2. In the Firewall Policy node, use the New Exchange Publishing Rule Wizard to create an Exchange
Server publishing rule. Configure the rule with the following settings.
Name: OWA Rule
Exchange version: Exchange Server 2010

Service: Outlook Web Access
Server Connection Security: Use SSL to connect the published Web server or server farm
Internal site name: VAN-EX1.Adatum.com
Public Name Details page: mail.Adatum.com
3. Create a new Web Listener with the following settings:
Name: HTTPS Listener

Client Connection Security: Require SSL secured connections with clients
Web Listener IP Addresses: External
Listener SSL Certificates: mail.adatum.com

Authentication Settings: HTML Form Authentication
Single Sign On Settings: Enabled
SSO domain name: Adatum.com

4. Configure Authentication Delegation to use Basic authentication.
X Task 6: Configure the Client Access server

1. On VAN-EX1, in the Exchange Management Console, configure the owa (Default Web Site) and
ecp (Default Web Site) to use the following configuration
External URL: https://mail.adatum.com/owa or https://mail.adatum.com/ecp

Basic authentication
Note During this task, click OK to dismiss any messages that indicate that VAN-EX2 is not
accessible.
2. Use the IISReset command to restart the IIS service.
X Task 7: Test the Outlook Web App publishing rule

1. On the host computer, in Hyper-V Manager, modify the 10135B-VAN-CL1 settings to connect the
network adapter to Private Network 2.
2. On VAN-CL1, log on as Adatum\Administrator and modify the network adapter settings to use an
IP address of 131.107.0.50, and a default gateway of 131.107.0.1.
3. Open the c:\windows\system32\drivers\etc\hosts file and add the following line to the file:
131.107.1.1 mail.adatum.com
4. Open Internet Explorer, and connect to https://mail.adatum.com/owa.
5. Log on as adatum\administrator using the password Pa$$w0rd. Verify that you access the user
mailbox.
6. In the Outlook Web App window, click Options. Verify that you can connect to the Exchange Control
Panel.
Results: After this exercise, you should have configured a Forefront Threat Management Gateway server
to enable access to Outlook Web App on the Client Access server. You will also have verified that the
access is configured correctly.

following steps:

Review Questions
1. You need to enable members of the Human Resources department to configure user mailboxes for
the entire organization. What should you do?
2. In which scenario you should implement RBAC split permissions in your Exchange Server 2010
organization?
3. How can you identify if someone was accessing another users mailbox?
4. Users in your organization are using POP3 clients from the Internet. These users report that they can
receive, but not send, email. What should you do?
5. Your organization has deployed Forefront TMG. You need to ensure that remote users can access the
Client Access server inside the organization by using cellular mobile clients. What should you do?
Common Issues Related to Configuring Exchange Server Publishing Rules on a

Reverse Proxy
Identify the causes for the following common issues related to configuring Exchange Server publishing
rules on a reverse proxy, and complete the troubleshooting tips. For answers, refer to relevant lessons in
the module.
Clients cannot connect to the published

sites, and they receive internal server errors.

sites, and they receive certificate errors.

sites, and they receive site-not-found errors.

1. Your organization has configured an SMTP Receive connector on an Edge Transport server to enable
IMAP4 users to relay messages. However, you discover that your Edge Transport server is being used
to relay spam to other organizations. What should you do?
2. You have added the ServerAdmins group in your organization to the Exchange Server 2010 Server
Management group in AD DS or Active Directory. All the members of the ServerAdmins group report
that they receive errors when they start the Exchange Management Console. What should you do?
3. Your organization is planning to deploy Forefront TMG to enable access to a Client Access server
from the Internet. The organization is concerned about the cost of acquiring multiple certificates to
enable access, but also wants to ensure that users do not receive certificate related errors. What
should you do?
Best Practices Related to Configuring Exchange Server Permissions

When you configure permissions in the Exchange Server organization, ensure that users have the
minimal permissions required for them to perform their tasks. Add only highly trusted users to the
Organization Management role group, because this group has full control of the entire organization.
Do not enable RBAC or Active Directory split permissions if you do not have a usage scenario to
support these permissions models. Enable administrative audit logging on shared mailboxes.
Whenever possible, use the built-in role groups to assign permission in the Exchange Server
organization. Creating custom role groups with customized permissions is more complicated and may
lead to users having too many, or too few, permissions.
Ensure that you document all permissions that you assign in the Exchange Server organization. If
users are unable to perform required tasks, or if they are performing tasks to which they should not
have access, you should be able to identify the reason by referring to your documentation.
11-1
Module 11
Maintaining Microsoft Exchange Server 2010
Contents:
Lesson 1: Monitoring Exchange Server 2010 11-3
Lesson 2: Maintaining Exchange Server 2010 11-19
Lesson 3: Troubleshooting Exchange Server 2010 11-25

Lab: Maintaining Exchange Sever 2010 11-34
11-2 Maintaining Microsoft Exchange Server 2010
Module Overview
After you deploy Microsoft Exchange Server 2010, you must ensure that it continues to run optimally by
maintaining a stable environment. To maintain a stable environment, you must monitor the Exchange
Server performance, and make adjustments as required. This module describes how to monitor and
maintain your Exchange Server environment.
This module also describes troubleshooting techniques. From time to time, problems arise that need to be
fixed. Although troubleshooting problems can be complex, using a troubleshooting methodology can
help you pinpoint the problem and then determine the proper method to use to fix the problem.
Monitor Exchange Server 2010.
Maintain Exchange Server 2010.
Troubleshoot Exchange Server 2010.

10135B: Configuring, Managing, and Troubleshooting Microsoft Exchange Server 2010 Service Pack2 11-3
Lesson 1
Monitoring Exchange Server 2010
Monitoring practices typically are an afterthought, and people often configure them after deploying the
solution. However, having a well-tuned and consistently used monitoring solution can greatly improve
your ability to identify, troubleshoot, and repair issues before end users notice them. Reducing end-user
problems and preventing more serious problems are worth the additional thought and effort that it
requires to design a comprehensive monitoring solution for your Exchange Server organization.
In this lesson, you will review the basic monitoring tools as well as the metrics that you should monitor.
Describe the importance of performance monitoring.

Identify key monitoring metrics for monitoring Exchange Server 2010.
Collect performance data for the Exchange server.
Collect performance data for the Mailbox server.
Collect performance data for the Hub Transport and Edge Transport servers.
Collect performance data for the Client Access server.
Use the collected performance data.

Why Is Performance Monitoring Important?
Monitoring the Exchange Server environment is important for the following reasons:
Identifying performance issues. When problems arise, you can pinpoint and repair them without
relying on users to report the problems.
Identifying growth trends to improve plans for upgrades. As the system grows and usage patterns
change, hardware modifications may be required to accommodate these changes. Identifying trends
also allows you to forecast future changes that might be necessary.
Measuring performance against service level agreements. Demonstrating whether Exchange Server
meets performance-based service level agreements and measuring the end-user experience shows
the value that Exchange Server administrators are providing.
Identifying security issues and denial-of-service attacks. When performance and other metrics stray
from the established baselines, you can correlate these incidents to identify and mitigate the source.
Since Exchange Server 2010 is complex, you need to monitor several aspects. Primarily, you should gather
and monitor metrics from the processor, memory, disk, and the Exchange services. You may monitor
additional information, depending on the Exchange Server roles that you install.
Tools for Monitoring Exchange Server
Most enterprise environments already use monitoring and alerting systems across their IT infrastructures.
In cases where a monitoring solution does not exist, Microsoft System Center Operations Manager 2007
or System Center Essentials (with the Exchange Server 2010 management pack) provide an easily
deployable Exchange Server monitoring solution.
Enterprise-class monitoring solutions also allow you to customize the data you want to collect, which can
be helpful when tracking down specific problems, or when default monitoring sets do not collect the
appropriate data. Since each deployment is unique, adjustments are required to fit particular usage and
hardware scenarios.
In instances where a problem exists on a single or limited number of servers, you can use the Performance
and Reliability Monitor to collect additional performance data that standard monitors might not capture.
Collecting Performance Data for the Exchange Server
When monitoring Exchange servers, you should know which performance aspects are most important.
You can use the common counters and threshold values detailed in this lesson to identify potential issues
proactively, and help identify the root cause of issues when troubleshooting.
Since these values are general guidelines, it is important to trend and perhaps adjust these values to meet
the needs of the specific environment. You can determine values that work in a specific environment by
documenting normal operating values to create a baseline. After creating the baseline, set thresholds so
that when performance metrics are not met, you know that the server is not operating optimally.
Processor
The processor is one of the fundamental components that you need to monitor to ensure server health on
all Exchange Server roles. Standard counters include the total percentage of processor time, the
percentage of user-mode processor time, and the percentage of privilege-mode processor time.
Group Counter Description Expected value
Processor _Total\% Shows the percentage of processor Should be less than 75% on
Processor Time time during which the process is average.
executing processes.
_Total\% User Shows the percentage of processor Should remain below 75%.
Time time that is spent in user mode. This
represents the time spent processing
applications, environment subsystems,
and integral subsystems.
_Total\% Shows the percentage of processor Should remain below 75%.

Privileged Time time that is spent in privileged mode.
This represents the time processing
operating system components and
hardware-manipulating drivers.
An additional counter related to processor performance is the processor queue length. If a processor
queues length is greater than the specified threshold value, this may indicate that there is more work
available than the processor can handle. If this number is greater than 10, per processor core, this is a
strong indicator that the processor is at capacity, particularly when coupled with high CPU utilization.
Although you typically do not use processor queue length for capacity planning, you can use it to identify
whether systems within the environment are capable of running the loads, or whether you should
purchase faster processors for future servers.
System Processor Shows the number of threads each Should not be greater than
Queue Length processor is servicing. You can use this 5 per processor core.
counter to identify whether processor
contention or high CPU utilization is due
to insufficient processor capacity.
Memory
Another key performance indicator is the memory counter. Tracking the available memory and how much
memory has to be written to the page file can tell you when you need to increase server memory, or
reduce server load.
Memory Available Shows the amount of physical memory, in Should remain above 100
Mbytes megabytes (MB), immediately available for MB at all times.
allocation to a process, or for system use. It
is equal to the sum of memory assigned to
the standby (cached), free, and zero page
lists.
Pool Paged Shows the portion of shared system No set value, this will vary
Bytes memory that you can page to the disk by deployment. Monitor
paging file. Paged pool is created during for increases in pool paged
system initialization, and is used by kernel- bytes, which may indicate
mode components to allocate system a possible memory leak.
memory.
Transition Pages Indicates system cache pressure. Should be less than 100,
Repurposed/sec on average, and spikes
should be less than 1,000.
Page Reads/sec Shows that data must be read from the Should be below 100 on
disk instead of memory. Indicates there is average.
not enough memory, and paging is
beginning. A value of more than 30 per
second means the server is no longer
keeping up with the load.
(continued)
Memory Pages/sec Shows the rate at which pages are read from Should be below 1000
(contd) or written to disk, to resolve hard page faults. on average.
This counter is a primary indicator of the
kinds of faults that cause system-wide delays.
Pages/sec is the sum of Memory\Pages
Input/sec and Memory\Pages Output/sec. It
is counted in numbers of pages, so it can be
compared to other counts of pages, such as
Memory\Page Faults/sec, without conversion.
Pages/sec includes pages retrieved to satisfy
faults in the file system cache (usually
requested by applications) and non-cached
mapped memory files.
Pages Input/sec Shows the rate at which pages are read from Should be below 1000
disk to resolve hard page faults. Hard-page on average.
faults occur when a process refers to a page
in virtual memory that is not in its working
set or is elsewhere in physical memory, and
which must be retrieved from disk. When a
page is faulted, the system tries to read
multiple contiguous pages into memory to
maximize the benefit of the read operation.
Compare the value of Memory\Pages
Input/sec to the value of Memory\Page
Reads/sec to determine the average number
of pages read into memory during each read
operation.
Pages Shows the rate at which pages are written to Should be below 1000
Output/sec disk to free space in physical memory. Pages on average.
are written back to disk only if they are
changed in physical memory, so they are
likely to hold data, and not code. If a large
number of pages are output, this can indicate
a memory shortage. Windows operating
systems write more pages back to disk to free
up space when physical memory is in short
supply. This counter shows the number of
pages, and you can compare it to other page
counts without conversion.
MSExchange ADAccess Domain Controllers

Exchange Server relies heavily on Active Directory Domain Services (AD DS) for information. Therefore, it
is essential to measure the response time and connection health.
MSExchange LDAP Read Shows the time in milliseconds (ms) Should be below 50 ms on
ADAccess Time that it takes to send a Lightweight average, and spikes should
Domain Directory Access Protocol (LDAP) read not be higher than 100 ms.
Controllers request to the specified domain
controller and receive a response.
LDAP Search Shows the time (in ms) to send an Should be below 50 ms on
Time LDAP search request and receive a average, and spikes should
response. not be higher than 100 ms.
LDAP Searches Shows the number of LDAP searches Should be below 10, at all
timed out per that returned LDAP_Timeout during times, for all roles. Higher
minute the last minute. values may indicate issues
with the resources of AD DS
and Active Directory
Lightweight Directory
Services (AD LDS) on Edge
transport servers.
Long running Shows the number of LDAP Should be less than 50 at all
LDAP operations on this domain controller times. Higher values may
operations/min that took longer than the specified indicate issues with AD DS
threshold per minute. (Default and resources of AD LDS on
threshold is 15 seconds.) Edge transport servers.
Monitoring Services and Logs

It is also important to verify that each of the Exchange services are running and servicing requests. You
can monitor services by polling the service status using the Services management tool, the Get-Service-
cmdlet, or a non-Microsoft monitoring tool. Items logged in the Event logs may also indicate Exchange
server problems. These events typically are classified as Errors or Warnings.
Collecting Performance Data for the Mailbox Server
When you collect performance data about Mailbox servers, you may focus on disk-response time and the
speed with which 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 on average.
If the disk queue length begins to grow, this is another indicator that the disk system is not meeting
demand. All of these may require you to purchase additional or faster disks, or to modify the disk
configuration.
There are many performance counters for Mailbox servers for which you can 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 disk performance is meeting demands. As disk latency increases,
database reads and writes take more time. Monitor the following performance counters for Mailbox server
logical disks.
Logical Avg. Disk Shows the average time for On average, should be below 20 ms
Disk sec/Read reading data from the disk. at all times.
Avg. Disk Shows the average time for On average, should be below 100 ms
sec/Write writing data to the disk. at all times.
Avg. Disk Shows the average number of Should be below 20 ms on average,

sec/Transfer bytes transferred to or from the and spikes should not be higher
disk during write or read than 50 ms.
operations.
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.
MSExchangeIS Messages Shows the current Should be below 50 at all times, and not
Mailbox and Queued for number of submitted be sustained for more than 15 minutes.
MSExchangeIS Submission messages that are not Otherwise, this counter may indicate
Public yet processed by connectivity issues with the transport
transport. servers or that backpressure is occurring.
MSExchangeIS
The Client Access and transport servers use Microsoft Remote Procedure Call (RPC) to communicate with
Mailbox servers. Therefore, it is important to monitor the response time for RPC requests, to be sure that
the mailbox server is responding quickly enough to support the load.
MSExchange RPC Requests Shows the overall RPC Should be below 70 at all times.
IS requests that are currently
executing within the
information store process.
RPC Averaged Shows the RPC latency (in Should not be higher than 25 ms on
Latency ms) averaged for all average.
operations in the last 1,024
packets.
RPC Shows the current number Should closely correspond to historical

Operations/sec of RPC operations occurring baselines. Values much higher than
per second. expected indicate that the workload
has changed, while values much lower
than expected indicate a bottleneck
preventing client requests from
reaching the server.
RPC Num Slow Shows the number of RPC Should be less than 1 on average, and
Packets packets in the past 1,024 should be less than 3 at all times.
packets that have latencies
longer than 2 seconds.
Question: If any of these performance counters measured outside its normal range, what is
the most likely cause?
Collecting Performance Data for the Hub Transport and Edge 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 on
average. Another indicator that the disk system is not keeping up with demand is if 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
database reads and writes take more time.
Monitor the following performance counters for transport server logical disks.
LogicalDisk Avg. Disk Shows the average time (in seconds) On average, should be below 20
sec/Read for reading data from the disk. ms at all times.
Avg. Disk Shows the average time (in seconds) On average, should be below 100
sec/Write for writing data to the disk. ms at all times.
Avg. Disk Shows the number of messages in Should be 0 at all times.

Queue Length the poison message queue.
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.
MSExchange Log Shows the amount of work (in count of log Should be less than 1,000
Database Generation files) that needs to be redone or undone to at all times.
==> Checkpoint the database file(s) if a process crashes.
Instances Depth
Version Shows the total number of allocated Should be less than 200
buckets version buckets. Shows the default at all times.
allocated backpressure values as listed in the
edgetransport.exe.config file.
Log Record Shows the number of log records that Should be less than 10
Stalls/sec cannot be added to the log buffers per- per second on average,
second, because they are full. If this and spikes should not be
counter is non-zero most of the time, then greater than 100 per
the log buffer size may be a bottleneck. second.
MSExchange Transport Queues

Additionally, you also should monitor the transport server queues to ensure delivery of email messages.
MSExchange Aggregate Delivery Shows the number of messages Should be less than 3,000
Transport Queue Length (All queued for delivery in all queues. and not more than 5,000.
Queues Queues)
Active Remote Shows the number of messages in Should be less than 250
Delivery Queue the active remote delivery queues. at all times.
Length
Active Mailbox Shows the number of messages in Should be less than 250
Delivery Queue the active mailbox queues. at all times.
Length
Retry Mailbox Shows the number of messages in a Should be less than 100
Delivery Queue retry state that are attempting to at all times.
Length deliver a message to a remote
mailbox.
Unreachable Queue Shows the number of messages in Should not exceed 100.
Length the Unreachable queue.
Largest Delivery Shows the number of messages in Should be less than 200.
Queue Length the largest delivery queues.
Poison Queue Shows the number of messages in Should be 0 at all times.

Length the poison message queue. Poison
messages are messages that were
detected as harmful. These messages
often cause a Transport service
failure.
Collecting Performance Data for the Client Access Server
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
database reads and writes take more time.
Monitor the following performance counters for the Client Access server logical disk.
LogicalDisk Avg. Disk Shows the average time (in seconds) Should be below 20 ms on
sec/Read for reading data from the disk. average.
Avg. Disk Shows the average time (in seconds) Should be below 100 ms on
sec/Write for writing data to the disk. average.
ASP.NET Services and Applications

Microsoft Outlook Web App and the Exchange Web Services rely heavily on the Microsoft .NET
Framework and 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.
ASP.NET Application Shows the number of times the application Should be 0 at all
Restarts has been restarted during the Web servers times.
lifetime.
Worker Process Shows the number of times a worker process Should be 0 at all
Restarts has restarted on the computer. times.
Requests Shows the current number of requests Should be less than

Current (including those that are queued) currently 5,000 at all times.
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 configuration
section for the process model, ASP.NET
begins rejecting requests. The maximum
value is 5,000. The server returns a 503 error
if the counter exceeds this value.
Request Wait Shows how long (in ms) the most recent Should be less than
Time request was waiting in the queue. 1,000 ms at all times.
ASP.NET Requests in Shows the number of requests in the Should be less than
Applications Application application request queue. The maximum 5,000 at all times.
Queue value is 5,000. The server return a 503 error if
the counter exceeds this value.
MSExchange Web Services

Additionally, Outlook Web App, the Outlook Anywhere (RPC/HTTP) Proxy, Microsoft Exchange
ActiveSync, Offline Address Book downloads, and the Availability Service response times are valuable
metrics to monitor.
MSExchange Average Response Shows the average time (in ms) Should be less than 100 ms
OWA Time that elapsed for the request. at all times. Higher values
Used to determine the latency may indicate high user load
that a client is experiencing. or higher than normal CPU
time.
Average Search Shows the average time (in ms) Should be less than 100 ms
Time that elapsed while waiting for a at all times.
search to complete.
RPC/HTTP Number of failed Shows the rate at which the RPC Should be 0 at all times.
Proxy back-end proxy attempts fail to establish a
connection connection to a back-end server.
attempts per
second
MSExchange Average Request Shows the average time that Varies by devices, carrier, or
ActiveSync Time elapsed while waiting for a configuration. You must use
request to complete. Determines a baseline to set this
the rate at which the Availability threshold.
Service requests are occurring.
MSExchangeFS: Download Task Shows a value of 1 if the task is Should be 0 at all times.
OAB Queued queued for execution, otherwise Values greater than 0
shows 0. indicate a failure to copy
Offline Address Book data
files from Mailbox servers.
Using the Collected Performance Data
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-of-
month accounting close process 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 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.
Lesson 2
Maintaining Exchange Server 2010
Maintaining the Exchange Server messaging solution is an ongoing process that requires discipline, not
only for the administrator but also for the organization. Using change management techniques to control
change has many benefits as described in this lesson.
Change management often includes controlling which software updates are applied, how the updates are
applied, and when the updates are applied. It also includes managing your hardware upgrades.
In this lesson, you will review the importance of change management, and techniques you can use to
perform upgrades to your Exchange Server computers.

Describe change management.
Describe the change management process.
Describe software updates.

Deploy software updates.
Determine when to upgrade your hardware.
Implement hardware upgrades.

Discussion: What Is Change Management?
The change management process controls environmental change through a frameworksuch as the
Microsoft Operations Frameworkthat includes change management components. Change management
is important, because it can lead to better application availability, better educated IT staff, and a more
predictable infrastructure. Planning which changes to deploy, and how and when to deploy them, falls
into the purview of a change management framework.
Question: How does your organization address change management?

Question: Are there some situations where change management is more important?
Question: What are the benefits of having a formal change management process?
Question: Are there situations in which you cannot follow the normal change process?
Considerations for Managing Change
The change management process varies widely from organization to organization. The basic components
for managing change are:
Adopt a process model like the Microsoft Operations Framework. A number of well-defined
frameworks are available. Adopting an established framework may make educating employees easier,
because they already may be familiar with the framework.
Define a process and use it consistently. Once you have a process, ensure that everyone involved
understands why it was adopted, and how to follow the process.
Support the change management process. If you do not support the process properly, it will not be as
effective as possible. It is essential that everyone works to support the process.
Successful change management depends on everyonefrom the engineers who implement the changes,
to the executives who must understand the process and follow it. It is also important to understand that
although managing change requires additional upfront work, the process ensures proper and effective
change. Properly implementing changes the first time saves time and work effort, and improves user
satisfaction, which is the real benefit to managing changes.
Process for Deploying Exchange Software Updates
You can update Microsoft Exchange Server 2010 by applying rollup update packages and service packs.
Unlike other products such as Windows Server, you cannot update Exchange Server by releasing single
update files, but rather must use packages with several updates and fixes. Service packs and update
rollups are part of the servicing strategy for Exchange Server 2010. They provide an effective and easy
method for distributing Exchange 2010 fixes and modifications. We recommend that you install the latest
service pack and update rollup to keep the product up-to-date.
Update rollups for the release to manufacture (RTM) version of Exchange Server 2010, also known as
Exchange Server 2010 Service Pack 0, will continue to be released as long as Exchange 2010 is supported
in accordance with the support timeline that the Microsoft Support Lifecycle website describes.
The latest update rollup in the series includes the fixes that were released in previous update rollups for
the same series. For example, if you install Update Rollup 3 for Exchange Server 2010 RTM, it includes the
fixes that were released in Update Rollup 1 and Update Rollup 2. Therefore, you always need just the
latest Update Rollup to be current.
Applying rollup packages and service packs typically is a simple procedure. However, in some scenarios,
you should consider the following:
When you install an update rollup package, Exchange tries to connect to the certificate revocation list
(CRL) website. Exchange examines the CRL list to verify the code signing certificate. If Exchange Server
cannot connect to the CRL website, you might experience a long installation time for the rollup
package, or you might receive an error message during setup. To work around this issue, and to
reduce installation times, turn off the Check for publishers certificate revocation option on the
server that you are upgrading.
When you apply an update rollup package, the update process may update the Logon.aspx file. If you
have modified the Logon.aspx file, you will not be able to update the file successfully. For example, if
you modified the Logon.aspx file to customize Outlook Web App, it may not be updated correctly,
and after the update process is finished, Outlook Web App may display a blank page. To work around
this issue, rename the Logon.aspx file before you apply the update rollup, and then after you apply
the update, re-create the Outlook Web App customizations in the Logon.aspx file.
If you have deployed Client Access server to Client Access server proxying, you must apply the update
rollup to the Internet-facing Client Access servers before you apply the update rollup to non-Internet-
facing Client Access servers.
When you install an update rollup, the Setup program automatically stops the appropriate Exchange
services and services related to Internet Information Services (IIS)-. Therefore, during the installation
process, the server may be unable to service user requests. We recommend that you install an update
rollup during a period of scheduled maintenance or during a period of low business impact.
When you install an update rollup on a server that is a database availability group (DAG) member,
several services will be stopped during the installation, including all Exchange services and the
Windows Cluster service. The general process for installing update rollups on a DAG member is:
1. Run the StartDagServerMaintenance.ps1 script to put the DAG member into maintenance mode,
and prepare it for the update rollup installation.
2. Install the update rollup.
3. Run the StopDagServerMaintenance.ps1 script to take the DAG member out of maintenance
mode and put it back into production.
4. Optionally rebalance the DAG by using the RedistributeActiveDatabases.ps1 script.
5. You also can use this process to install operating-system updates from Microsoft Update.
Determining the Need for Hardware Upgrades
Exchange Server 2010 uses hardware more efficiently than previous Exchange Server versions, which
means there may be less need than in the past to upgrade hardware. In particular, Exchange Server 2010
reduces disk activity. Disk capacity is one of the most commonly required hardware upgrades.
Proactively monitoring hardware performanceprocessor, memory, disk, or networkis the best way to
determine whether bottlenecks exist in the environment. Another valid trigger for researching hardware
issues is gathering and examining user feedback. You should not rely solely on user feedback as the first
indication of issues, but it can help you pinpoint particular user issues with the hardware.
However, since Exchange Server 2010 Service Pack 2 (SP2) fully supports virtual environments, you might
consider deploying new virtual Exchange servers instead of upgrading hardware on existing physical
servers. This approach provides better load balancing and resource distribution. Also, you achieve a
higher level of redundancy. For example, if you want to host more mailboxes, you do not have to upgrade
hardware resources on a current Mailbox server. Rather, you can deploy a new Mailbox server, move some
mailboxes to it, and then form a Database Availability Group (DAG). In this way, you scale out your
Exchange environment instead of scaling it up.
Lesson 3
Troubleshooting Exchange Server 2010
Even in a well-maintained Exchange Server organization, problems can arise that you must identify and
repair. Although general troubleshooting guidelines exist, often experience and an analytical attitude
provide the best tools for successfully discovering the problems source and fixing it.
Develop a troubleshooting methodology.

Identify troubleshooting tools that you can use.
Troubleshoot Mailbox servers.
Troubleshoot Client Access servers.
Troubleshoot Message Transport servers.

Developing a Troubleshooting Methodology
The goal of troubleshooting is to identify and diagnose problems, and then determine and execute the
necessary repair. There are many troubleshooting methods, and they vary by the type of problem that
you are trying to resolve. Implementing a repeatable troubleshooting process is important so that you can
quickly resolve problems. A common troubleshooting method is to:
1. Clearly define the problem. Obtain an accurate description of the problem by verifying the reported
problem, including when you noticed it and how you can reproduce it. The more clearly defined the
problem statement, the easier it will be to complete the remaining steps.
2. Define the problem's scope. By defining scope, you actually define the area that the problem affects.
For example, scope can be defined by the number of users affected by a specific problem. Or, scope
can present a number of services that experience troubles.
3. Gather information related to the problem. Turn up logging, review event logs, and try to reproduce
the problem. In many cases, you will have an idea about what the problem is after completing your
problem statement. However, be sure to gather as much accurate information as possible, without
coming to conclusions and making premature decisions about the nature of the problem.
4. List the potential cause of the problem. With the problem statement and gathered data, you can
enumerate all potential problem causes. This step requires a little creativity to come up with all of the
components related to the issue. It is important to be thorough, and to explore all possible options.
Search your company knowledge base, product support documentation, and the Internet for
information about possible causes.
5. Rank the possible causes by probability, and define their solutions. Create a list of either solutions or
additional troubleshooting that is required to address each potential cause. Search your knowledge
base, product support documentation, and the Internet for information about possible resolutions.
6. Rank solutions by ease of resolution and impact to complete. It would be obvious to try the most
likely solutions first, one at a time, until you discover the solution. In some cases, however, the
solutions are invasive and require long outages or more resources to complete, in which case you
might want to try the less probable but less invasive solutions first.
7. Try the most probable and easily implemented resolutions first. Work through the list of solutions,
one at a time, until you resolve the issue, or gather additional information that changes the definition
of the problem.
8. Reduce logging to normal. To reduce server loads, be sure to return all settings back to normal.
9. Document resolution and root cause for future reference. Although you may remember details of the
solution later, documenting the root cause and the resolution will reduce resolution times in the
future.
Troubleshooting 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 invaluable tool enables you to identify potential issues
based on deviations from best practices, and for gathering a great deal of information about the
Exchange Server organization that you can 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, 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.
Other tools such as the Performance and Reliability Monitor check 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.
You can use many other tools in addition to Microsoft Management Console (MMC) snap-ins, the
Exchange Management Console, the Exchange Management Shell, and Active Directory Users and
Computers, to manage and troubleshoot an Exchange Server 2010 organization. The following table lists
these tools.
Tool name Description
ADSI Edit Use for low-level AD DS and Active Directory editing. Install with the
(adsiedit.msc) Remote Server Administration Tools.
DNS Resolver (DNSDiag) Use to troubleshoot Domain Name System (DNS) issues. The tool
(Dnsdiag.exe) simulates the Simple Mail Transfer Protocol (SMTP) services internal
code path, and prints diagnostic messages that indicate how the DNS
resolution is proceeding.
DSACLS Use this command-line tool to query and change permissions and
(dsacls.exe) security attributes of Active Directory objects.
Error Code Look-up Use to determine error values from decimal and hexadecimal error
(Err.exe) codes in Windows products. This is a downloadable tool.
Event Viewer Use this MMC snap-in to view logged events such as errors and
(eventvwr.msc) warnings.
Exchange Server Database Use to perform offline database procedures, such as defragmentation
Utilities and integrity checking.
(Eseutil.exe)
Exchange Server Jetstress Use as a benchmarking tool to validate your storage subsystem.
Exchange Profile Analyzer Use to collect estimated statistical information from a single mailbox
(epa.msi) 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 Use to display a hierarchical list of node objects that correspond to
Control folders in the Exchange store.
(Extreeview.ocx)
Information Store Integrity Use to find and remove errors in the public and private information
Checker store databases. Intended for disaster-recovery situations, but not for
(isinteg.exe) routine maintenance.
Internet Information Services Use to configure Outlook Web App settings.

(IIS) Manager
(iis.msc)
Inter-Organization Replication Use to replicate public folder information (including free/busy

(exscfg.exe; exssrv.exe) information) between Exchange organizations. You can use this
between forests.
LDP Use to perform LDAP searches against AD DS.

(ldp.exe)
Exchange Load Generator Use as a benchmarking tool to test the response of servers to mail
(Loadgen.msi) loads.
Microsoft Baseline Security Use to scan local or remote systems for common configuration errors,
Analyzer (MBSA) and to verify security best practices.
GUI: MBSA.exe
Command line: mbsacli.exe
(continued)
Tool name Description
Microsoft Error Reporting Exchange 2010 uses Microsoft Error Reporting (also known as Watson
2.0) 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.
MTA Check Use when the message transfer agent (MTA) will not start due to
(Mtacheck.exe) corruption or suspected corruption in the MTA database.
This tool provides a soft recovery of a corrupted MTA database.
Process Monitor Use to monitor real-time file system, registry, and process/thread
(procmon.exe) activity.
RPC Ping utility Use to confirm the remote procedure call (RPC) connectivity between
(rpings.exe and rpingc.exe) the computer that is running Exchange, and any of the client
workstations on the network.
Telnet Use to troubleshoot Exchange mail flow.

(telnet.exe)
Microsoft Remote Use for testing and troubleshooting connectivity to Exchange Server
Connectivity Analyzer from Internet using various protocols.
Discussion: Troubleshooting Mailbox Servers
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.
Question: A database has gone offline. What process can you use to troubleshoot the
problem?
Discussion: Troubleshooting Client Access Servers
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.
Question: Outlook users can no longer connect to the system. What process can you use to
troubleshoot the problem?
Discussion: Troubleshooting Message Transport Servers
You can apply standard troubleshooting techniques to the unique problems that can occur with 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.
Question: Users are reporting non-deliverable and slow-to-deliver outbound email. What
process can you use to troubleshoot the problem?
Lab: Maintaining Exchange Server 2010
Lab Setup
2. Ensure that the 10135B-VAN-DC1 and the 10135B-VAN-EX1 virtual machines are running:
Lab Scenario
You are the messaging administrator at A. Datum Corporation. You need to configure basic monitoring by
using the Performance and Reliability Monitor. You also must troubleshoot issues with a mailbox database
and a Client Access server.
Exercise 1: Monitoring Exchange Server 2010

Scenario
You are the messaging administrator at A. Datum Corporation. You need to configure basic monitoring
using the Performance and Reliability Monitor. Before implementing Microsoft Systems Center Operations
Manager to monitor your Exchange Server 2010 computers, you must create a data collector set to
monitor key performance components that are running on your Mailbox server.
1. Create a new data collector set named Exchange Monitoring.
2. Create a new performance-counter data collector set for monitoring basic Exchange Server
performance.
3. Create a new performance-counter data collector set for monitoring Mailbox server role performance.
4. Verify that the data collector set works properly.
X Task 1: Create a new data collector set named Exchange Monitoring

On VAN-EX1, open the Performance Console, and create a data collector set named Exchange
Monitoring.
X Task 2: Create a new performance counter data collector set for monitoring basic
Exchange Server performance
1. Create a performance data collector set named Base Exchange Monitoring.
2. Add the following performance counters to monitor basic Exchange Server performance on VAN-EX1:
Object Counter
Processor % Processor Time

% User Time
% Privileged Time
Memory Available Megabytes (MB)

Page Reads/sec
Pages Input/sec
Pages/sec
Pages Output/sec
Pool Paged Bytes
Transition Pages Repurposed/sec
MSExchange ADAccss LDAP Read Time

Domain Controllers LDAP Search Time
LDAP Searches timed out per minute
Long running LDAP operations/Min
System Processor Queue Length

X Task 3: Create a new performance counter data collector set for monitoring Mailbox
server role performance
1. Create a performance data collector set named Mailbox Role Monitoring.
2. Add the following performance counters to monitor basic Exchange Server performance on VAN-EX1:
Object Counter
LogicalDisk Avg.Disk sec/Read

Avg.Disk sec/Transfer
Avg.Disk sec/Write
MSExchangeIS RPC Averaged Latency

RPC Num Slow Packets
RPC Operations/sec
RPC Requests
MSExchangeIS Mailbox Messages Queued for Submission
MSExchangeIS Public Messages Queued for Submission
X Task 4: Verify that the data collector set works properly

1. Start the Exchange Monitoring data collector set and let it run for five minutes.
2. Stop the Exchange Monitoring data collector set, and then review the latest report.
Results: After this exercise, you should have created a data collector set for monitoring VAN-EX1 that
uses the performance counters that this module recommends.
Exercise 2: Troubleshooting Database Availability

Scenario
You are the messaging administrator for A. Datum Corporation. After recovering from a hardware failure,
your monitoring software reports that one of the mailbox databases is not mounted. You must
troubleshoot and repair the database problem.
1. Identify the scope of the problem.
2. Review the event logs.
3. Run the Best Practices Analyzer.
4. List the probable causes of the problem, and rank the possible solutions if multiple options exist.
5. Review the database configuration.
6. Reconfigure and mount the database.

X Preparation
Before you begin this exercise, complete the following steps:
1. On VAN-EX1, open a Exchange Management Shell. At the prompt, type

d:\ Labfiles\Lab11Prep2.ps1, and then press Enter.
2. When prompted, type N, and then press Enter.
3. Close the Exchange Management Shell.
X Task 1: Identify the scope of the problem

2. Identify which, if any, mailbox databases are not mounted.
3. List the database(s) that are dismounted.
X Task 2: Review the event logs

1. On VAN-EX1, attempt to mount MailboxDB100. Review the warning message, and then click No.
2. Open the Event Viewer. In the Application Log and System Log, review the events generated, and
make note of any errors.
X Task 3: Run the Best Practices Analyzer

1. On VAN-EX1, run Exchange Best Practices Analyzer. Perform a Health Check scan of just VAN-EX1.
2. Review the ExBPA report, and note issues identified by the scan that may have an impact on the
scenario.
X Task 4: List the probable causes of the problem, and rank the possible solutions if
multiple options exist
List the problems and possible solutions:
Problem Possible solution

X Task 5: Review the database configuration

1. On VAN-EX1, open Exchange Management Console and review the database configuration.
2. Open Windows Explorer, and locate the database files.
X Task 6: Reconfigure and mount the database

1. On VAN-EX1, open Exchange Management Shell and reconfigure the database using the
Move-DatabasePath cmdlet with the ConfigurationOnly parameter.
2. Mount the database.
Results: After this exercise, you should have used a troubleshooting technique to identify and fix a
Mailbox server problem.
Exercise 3: Troubleshooting Client Access Servers

Scenario
You are the messaging administrator for A. Datum Corporation. Users report that they cannot log on to
Outlook Web App. You need to determine and then repair the problem.
1. Verify the problem by attempting to reproduce the problem.
2. Review the event logs.
3. Use the Test cmdlets to verify server health.
4. List the probable causes of the problem, and rank possible solutions if multiple options exist.
5. Check the Outlook Web App configuration.
6. Verify that you resolved the problem.
X Preparation
1. On VAN-EX1, open Exchange Management Shell. At the prompt, type d:\ Labfiles\Lab11Prep3.ps1,
and then press Enter.
X Task 1: Verify the problem by attempting to reproduce the problem

1. Attempt to log on to https://van-ex1.adatum.com/owa as Administrator using the password
Pa$$w0rd.
2. Make note of the error displayed.


1. On VAN-EX1, open Event Viewer, and then review any errors listed in the Application and
System logs.
2. Make note of any errors.
X Task 3: Use the Test cmdlets to verify server health

1. On VAN-EX1, open the Exchange Management Shell, and run the Test-ServiceHealth cmdlet.
2. Run the Test-OwaConnectivity URL https://VAN-EX1.adatum.com

/OWA -TrustAnySSLCertificate cmdlet to test Outlook Web App connectivity. Log on as
Adatum\administrator.
3. Review the results of the cmdlets, and then make note of any errors.
List the problems and possible solutions:
X Task 5: Check the Outlook Web App configuration

1. Open Exchange Management Console, and then review the Outlook Web App configuration
on VAN-EX1.
accessible.
2. Take the necessary actions to fix the problem. Run IISReset after fixing the problem.
X Task 6: Verify that you resolved the problem

Attempt to log on to https://van-ex1.adatum.com/owa as Adatum\Administrator with the
password Pa$$w0rd.
Results: After this exercise, you should have used a troubleshooting technique to identify and fix a Client
Access server problem.

following steps:
After making the configuration change, the Exchange Management Console instructs you to restart IIS so
that the new configuration options can be applied.
Review Questions
1. Users are reporting issues with sending email to a remote domain. You need to determine the
problem and then resolve it. What should you do?
2. Recent organizational growth has resulted in two issues. It has caused several memory thresholds to
exceed recommended issues, as well as the average read-latency threshold for the logical disk that
stores the page file. What issue should you address first?
3. After reviewing the trend information retrieved from the monitoring system, you noticed that the
processor usage for one of the four Mailbox servers is higher than average. What should you do?
Common Issues Related to Troubleshooting Exchange Server Problems

Identify the causes for the following common issues related to troubleshooting Exchange server problems,
and complete the troubleshooting tips. For answers, refer to relevant lessons in the module.
Outbound email messages are queuing on the

Hub Transport server.
Multiple sources are simultaneously reporting

different problems.
Users are reporting slowness or other subjective

problems.

1. A company has recently experienced growth because of a popular new product. The company has
had numerous Mail server outages and downtime due to undocumented changes. What should the
company invest in to ensure that it can support continued growth?
2. A database has gone offline, and the organization needs to troubleshoot the problem. A number of
impatient users have mailboxes stored in the offline database. What is the best way to address the
situation?
3. An Exchange Server service pack was recently released, and the company has decided to deploy it.
What should you do before scheduling the deployment?
Best Practices Related to Troubleshooting Exchange Server Problems

Follow the same steps each time you troubleshoot a problem. This way you get into a habit of
making good decisions and finding the answers quickly.
Be diligent about separating facts about the issue from feelings or other subjective information. A
single persons subjective observation could cause you to troubleshoot the wrong problem and delay
resolution of the actual issue.
Ask a lot of questions about the problem before starting to troubleshoot. If you have not properly
defined the problem, you cannot properly target your troubleshooting steps.
12-1
Module 12
Upgrading from Exchange Server 2003 or Exchange Server
2007 to Exchange Server 2010
Contents:
Lesson 1: Overview of Upgrading to Exchange Server 2010 12-3
Lesson 2: Upgrading from Exchange Server 2003 to Exchange Server 2010 12-12
Lesson 3: Upgrading from Exchange Server 2007 to Exchange Server 2010 12-31
12-2 Upgrading from Exchange Server 2003 or Exchange Server 2007 to Exchange Server 2010
Module Overview
Many organizations already use Microsoft Exchange Server 2003 or Microsoft Exchange Server 2007 to
provide messaging services. When these organizations choose to implement Microsoft Exchange Server
2010, they can upgrade the existing Exchange Server organization to Exchange Server 2010. Alternately,
they can deploy a parallel Exchange Server organization, and then move mailboxes and other data from
one organization to the other.
Most organizations might choose to perform an upgrade because it is significantly easier and results in
minimal disruption for the messaging users. This module provides an overview of the options that
organizations have when they choose to implement Exchange Server 2010. This module also provides
details on how to upgrade an existing Exchange Server 2003 or Exchange Server 2007 organization to
Describe the general Microsoft Exchange Server 2010 upgrade scenarios and strategies.
Upgrade from Microsoft Exchange Server 2003 to Exchange Server 2010.
Upgrade from Microsoft Exchange Server 2007 to Exchange Server 2010.

Lesson 1
Overview of Upgrading to Exchange Server 2010
When you decide to implement an Exchange Server 2010 messaging system in your organization, you
may need to maintain both your previous messaging system and Exchange Server 2010 until you ensure
the new implementation works correctly. While you upgrade the system, users will need to send email and
schedule meetings. The Exchange Server 2010 implementation should disrupt normal business processes
minimally, if at all.
This lesson describes the options that are available for upgrading existing messaging systems to Exchange
Server 2010, and it provides recommendations for when to use each approach.

Describe the upgrade options for Exchange server.
Describe the upgrade scenarios that are supported in Exchange Server 2010.
Explain the various upgrade strategies.
Describe tools that can help to prepare migration.

Upgrade Options for Exchange Server
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 server or Exchange Server 2007 organization, and then move data and functionality from the
existing Exchange servers to 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. However, you can
implement this option only if your organization is running Exchange Server 2003 or Exchange Server
2007 currently.
Migration. In this scenario, you upgrade from a non-Exchange Server messaging system to Exchange
Server 2010 or from an existing Exchange Server organization to a new Exchange Server organization,
without retaining any of the existing organizations Exchange configuration data. In a migration, you
install a new Exchange Server 2010 messaging system, and then migrate the current messaging
systems data and services to Exchange Server 2010. Microsoft supports a migration upgrade from
previous Exchange Server versions or non-Exchange messaging systems to Exchange Server 2010.
If you use a migration scenario, it becomes significantly more complicated to configure

interoperability, as opposed to configuring coexistence in an upgrade. By default, the two messaging
systems share no information. Therefore, you must configure all connections between the systems.
Note Exchange Server 2010 does not provide any migration tools or connectors to other
messaging systems such as Novell GroupWise or Lotus Domino. You can configure Simple
Mail Transfer Protocol (SMTP) connectivity between Exchange Server 2010 and messaging
systems by using SMTP Send and Receive connectors. Exchange Server 2010 does not
provide any tools for enabling coexistence or for migrating mailboxes to Exchange Server
2010. However, there are third-party tools that can help you with migration from a non-
Microsoft email system to Exchange Server.
Important When you perform a migration from one Exchange Server organization to
another, you also need to deploy a second Active Directory Domain Services (AD DS)
forest, and then migrate all user accounts to the second forest. Each Exchange Server
organization requires a unique Active Directory forest.
Note To upgrade an Exchange Server 2000 organization to Exchange Server 2010, you
must perform a migration. Alternately, you can upgrade the Exchange Server 2000
organization completely to Exchange Server 2003 or Exchange Server 2007, and then
perform an upgrade to Exchange Server 2010. Also, be aware that Exchange Server 2010
does not support in-place upgrade from any previous version.
Supported Upgrade Scenarios
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.
AD DS Requirements for Upgrading to Exchange Server 2010

To upgrade from a previous Exchange Server version to Exchange Server 2010, you must meet the
following AD DS requirements:
The schema master must be running the Windows Server2003 operating system Service Pack 1 or
newer.
At least one global catalog server in each site must be running the Windows Server2003 operating
system Service Pack 1 or newer.
The Active Directory forest must be at Windows Server2003 forest-functional level or higher.
Each Active Directory site must have at least one domain controller and one global catalog server
with a writeable AD DS copy. Exchange Server 2010 cannot use the Windows Server 2008 operating
system read-only domain controllers (RODCs) or read-only global catalog servers (ROGCs.
Supported Upgrade Deployments

When upgrading an existing Exchange Server organization to Exchange Server 2010, Microsoft supports
the following upgrade deployments:
Exchange Server version Exchange organization upgrade
Microsoft Exchange Server 2000 Not supported
Microsoft Exchange Server 2003 Service Pack 2 or newer Supported
Microsoft Exchange Server 2007 Service Pack 2 or newer Supported
Mixed Exchange Server 2007 and Exchange Server 2003 Supported

organization
Note When upgrading from Exchange Server 2007, you must upgrade all of your
organizations Exchange Server 2007 servers to Service Pack 2.
Note Before you install Exchange Server 2010 servers into an existing Exchange Server
2003 organization, you must configure the organization to run in native mode.
After you deploy a new Exchange Server 2010 organization, you cannot add servers that are 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.
Upgrade Strategies
When planning an Exchange Server 2010 upgrade, you can choose between several options for the
upgrade process. Choosing the best option for your organization depends on your current environment,
your organizations requirements for data migration, and your project timeline.
Choosing a Single-Phase or Multiphase Upgrade

Your first choice when planning the upgrade is to decide whether to use a single-phase or multiphase
upgrade:
Single-phase upgrade. In a single-phase upgrade, you replace your existing messaging system with
Exchange Server 2010, and move all required data and services to the new system. In a single-phase
migration, you do not need to plan for an extended period of coexistence between the two systems.
You typically perform this type of upgrade on a weekend. This enables you to shut down the entire
messaging system and replace it with Microsoft Exchange Server 2010 by Monday morning, when
users return to work. In this scenario, there is no period of coexistence or interoperability.
While this upgrade is the fastest option, it also introduces 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.
Coexistence Components
In most coexistence scenarios, you must ensure that users with mailboxes on both messaging systems
have access to the following:
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 know, nor should it matter, which 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 the 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.
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.
Note If you implement an upgrade to Exchange Server 2010, the design of the upgrade
process ensures the maintenance of these coexistence components throughout the
coexistence.
Migration Preparation Tools
Microsoft provides several tools that can help you prepare your existing environment for deployment and
deploy Exchange Server 2010. It is recommended that you run these tools prior to the Exchange Server
2010 installation.
Exchange Server Best Practices Analyzer

Run the Exchange Server Best Practices Analyzer in the current Exchange Server 2003 or Exchange Server
2007 messaging environment. It is freely available as a download from the Microsoft Download Center.
Use this tool to compare your Exchange Server organization configuration against the current Microsoft
list of best practices. After performing a scan, this tool provides you with a detailed report about issues
that were identified on the current platform.
Exchange Deployment Assistant

The Exchange Deployment Assistant is a web-based tool that can help you deploy Exchange Server 2010
in the existing environment. The Exchange Deployment Assistant wizard presents a series of questions
about your current environment, and based on your answers, provides instructions on how to deploy
Exchange Server 2010. Besides providing instructions on how to deploy Exchange Server 2010 on-
premise, it can also help you deploy Exchange Server 2010 in the cloud, or in coexistence between the
cloud and on-premise. You can find this tool at http://go.microsoft.com/fwlink/?LinkId=213767.
Exchange Pre-Deployment Analyzer

You can use the Exchange Pre-Deployment Analyzer (ExPDA) to perform an overall topology readiness
scan of your environment. When you run ExPDA, it provides a detailed report that alerts you if there are
issues within your organization that could prevent you from deploying Exchange Server 2010. For
example, the ExPDA notifies you if you have not deployed the minimum required Exchange Server service
pack on all of your existing Exchange servers.
The checks performed by ExPDA are similar to the prerequisite checks implemented by Exchange Best
Practices Analyzer in the Exchange Server 2010 Setup program. In fact, ExPDA is based on the Exchange
Best Practices Analyzer engine. However, unlike Exchange Server 2010 Setup, this tool focuses only on
overall topology readiness, and not on the ability to run Exchange Server 2010 on the local computer.
Requirements Calculator for Exchange 2010 Mailbox Server Roles

The Exchange 2010 Mailbox Server Role Requirements Calculator is an Excel-based tool that you use
before deploying the Mailbox server role. Because the Mailbox server role is critical for your deployment,
Microsoft provides the calculator to help you determine the Mailbox Server role requirements for your
organization. The calculator allows you to input all the relevant information regarding your intended
designinformation such as database size, high availability, and number of serversand provides
recommendations for your Mailbox server role requirements.
Lesson 2
Upgrading 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 to Exchange Server 2010 for these organizations. This lesson describes how to upgrade an Exchange
Server 2003 organization to Exchange Server 2010.
Describe how to prepare an Exchange Server 2003 organization for Exchange Server 2010.
Explain the process for installing Exchange Server 2010 in an Exchange Server 2003 organization.
Describe how client access works during coexistence.
Describe how to implement client access.
Describe the considerations for Microsoft Office Outlook client coexistence.
Describe the considerations for message transport coexistence.
Describe the considerations for administration coexistence.
Describe the process for removing Exchange Server 2003 from an organization.
Preparing the Exchange Server 2003 Organization for

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 by using the
/PrepareLegacyExchangePermissions parameter and the /PrepareAD parameter.
Changes Made by the PrepareLegacyExchangePermissions Setup Parameter

You must run the Setup /PrepareLegacyExchangePermissions command 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
attributes, such as the proxy address, on mail-enabled user objects. It could 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 that is 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.
Note For more information on the /PrepareLegacyExchangePermissions Setup

parameter, see the Preparing Legacy Exchange Permissions page on the Microsoft
TechNet website.
You can run Exchange Server 2010 Setup with the /PrepareLegacyExchangePermissions
parameter on a computer that is running Windows Server 2008 or newer, or on a computer that
is running the Windows Vista operating system with SP2 or newer. You must install the
prerequisite software on the computer where you run Setup. If you run the command from a
computer that is running Windows Server 2008 R2, all the prerequisite components are installed
already, except for Microsoft .NET Framework 3.5 and the Active Directory management tools.
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.
Process for Installing Exchange Server 2010 in an Exchange Server 2003

Organization
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. This means that you should
modify the AutoDiscover settings both internally and externally, to point to the Exchange Server 2010
2. Install 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 organization, and plan to
deploy only one or two Exchange Server 2010 servers, you can perform a typical installation
and install the Client Access server role, Hub Transport server role, and the Mailbox server
role simultaneously.
4. Install Exchange Server 2010 Unified Messaging servers.
5. For organizations with multiple sites, there are typically two types of Active Directory sites: Internet-
accessible 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.
How Client Access Works During Coexistence
The Client Access server role provides the functionality that a front-end server provided in Exchange
Server 2003, and it includes additional functionalities in Exchange Server 2010. All client connectivity,
including Microsoft Office Outlook MAPI connectivity, now goes through the Client Access server role.
You must deploy the Client Access server role in every Active Directory site that includes an Exchange
Server 2010 Mailbox server.
Client Access During Coexistence

After you deploy the Exchange Server 2010 Client Access and Mailbox servers, the process that non MAPI
clients use when accessing the user mailboxes depends on the type of client that you are using and the
mailboxs location.
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 URL, such as https://mail.contoso.com, to connect to an
Exchange Server 2003 front-end server, you should modify the Domain Name System (DNS) or firewall
configuration to forward connections to the Exchange Server 2010 Client Access servers URL:
When a Microsoft Outlook Web App client connects to the Client Access server and the user mailbox
is located on an Exchange Server 2003 back-end server, the client redirects to the Exchange Server
2003 URL configured on the Client Access server. For example, if the client connects to the Exchange
Server 2010 Client Access server by using the URL of https://Mail.contoso.com, the request might be
redirected to https://legacy.contoso.com. The client then communicates with the Exchange Server
2003 front-end server to access the user mailbox.
When an Outlook Web App client connects to the Client Access server and the user mailbox is located
on an Exchange Server 2010 Mailbox server, the Client Access server communicates with the Mailbox
server to provide access to the user mailbox.
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 HTTP, and provides access to the user mailbox.
When an Exchange ActiveSync client connects to the Client Access server and the user mailbox is
located on an Exchange Server 2010 Mailbox server, the Client Access server connects to the Mailbox
server by using remote procedure call (RPC), 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 RPC proxy service on the Client Access
server connects to the back end server by using RPC.
located on an Exchange Server 2010 Mailbox server, the RPC proxy service on the Client Access server
connects to the Mailbox server by using RPC.
Considerations for Client Access During Coexistence

When implementing client access during coexistence, consider the following:
Whether a user sees the Outlook Web App client of Exchange Server 2003 or Exchange Server 2010
depends on the location of the users mailbox. For example, if the users mailbox is located on an
Exchange Server 2003 back-end server and the Client Access server is running Exchange Server 2010,
the user will see the Exchange Server 2003 version of Outlook Web Access.
The version of Exchange ActiveSync that clients use also depends on the server version that hosts the
users mailbox. The users mailbox must be located on a server that is running Exchange Server 2003
Service Pack 2 or Exchange 2010 to have Direct Push enabled for Exchange ActiveSync.
You cannot use an Exchange Server 2003 front-end server to access mailboxes on Exchange Server
2010 Mailbox server. Additionally, because Exchange Server 2010 does not support Microsoft Outlook
Mobile Access, users cannot access their mailboxes through the Client Access server by using Outlook
Mobile Access.
The Outlook Web App URL used to access Outlook Web App depends on whether the users mailbox
is located on an Exchange Server 2003 back-end server or on an Exchange Server 2010 Mailbox
server. If the mailbox is located on an Exchange Server 2003 back-end server, the URL typically is
https://<servername or FQDN>/Exchange. If the mailbox is located on an Exchange Server 2010
Mailbox server, the URL typically is https://<servername or FQDN>/owa.
If the users connect to the /owa virtual directory on the Client Access server, and their mailbox is
located on an Exchange Server 2003 server, Exchange Server 2010 redirects their Web browser to the
/exchange virtual directory on the Exchange Server 2003 front-end server. If users connect to the
/exchange virtual directory on the Client Access server, and their mailbox is located on an Exchange
Server 2010 mailbox server, Exchange Server 2010 redirects the client request to the /owa virtual
directory.
Important If you have multiple Exchange Server 2003 servers, you must have an
Exchange Server 2003 front-end server deployed. For each Exchange Server 2010 Client
Access server, you can only configure one Outlook Web Access 2003 URL for redirection.
You can accomplish this with a single Exchange Server 2003 front-end server or a load
balanced array of Exchange Sever 2003 front-end servers.
Implementing Client Access Coexistence
During coexistence, you need to ensure that users have access to their mailboxes on both the Exchange
Server 2003 back-end servers and Exchange Server 2010 Mailbox servers. The following steps describe
how to enable this:
1. Obtain the required server certificates. To support external client coexistence with the Exchange
Server 2010 Client Access server and legacy Exchange server, you may need to acquire a new
certificate. You should request a certificate that supports at least the following subject alternative
names:
The primary URL used to access the Exchange 2010 Client Access server. For example, you might
use a name such as mail.contoso.com.
The AutoDiscover server name. Normally, you would us a name such as

autodiscover.contoso.com.
An alternate name for the URL that connects to the Exchange Server 2003 front-end server. For
example, you might use a name such as legacy.contoso.com.
2. Install and configure the Exchange 2010 Client Access server. You should configure the following
settings:
Configure the external name space during or after Setup by using the Exchange Management
Console or Exchange Management Shell (EMS).
Configure the Client Access server virtual directories to meet your company requirements.
Configure the Exchange 2003 URL for Outlook Web App redirection. To do this, use the Set-
OWAVirtualDirectory -Exchange2003URL cmdlet. For example, you could use a cmdlet such as
set-owavirtualdirectory LON-EX3\owa* Exchange2003Url https://legacy.contoso.com
/exchange.
Note The Exchange Server 2003 URL must refer to an Exchange Server 2003 front end
server or a load balanced array of front end servers if you have multiple Exchange Server
2003 servers that host mailboxes.
3. Configure DNS. To configure DNS, you should:
Create the legacy host record, such as legacy.contoso.com, in your external DNS infrastructure,
and configure it to reference the Exchange Server 2003 front-end server. This record is required
to ensure that the client computers on the Internet can locate the Exchange Server 2003 front-
end server when they are redirected to the legacy URL.
Create the host record for Autodiscover, which is Autodiscover.contoso.com, and configure it to
reference the Exchange Server 2010 Client Access server.
Create or modify the host record for the primary URL, which is mail.contoso.com, and configure it
to reference the Exchange Server 2010 Client Access server.
4. If you are using RPC over HTTPS on the Exchange Server 2003 servers, configure the Exchange Server
2003 front-end server to not participate in an Exchange managed RPC-HTTP topology. This is
because the Exchange 2010 Client Access server operates as the RPC over HTTPS proxy server rather
than the Exchange Server 2003 front-end server. To disable this setting in Exchange System Manager,
select the Not part of an Exchange managed RPC-HTTP topology option on the RPC-HTTP tab of
the front-end servers properties.
5. Test all client scenarios, and ensure they function correctly.

Considerations for Outlook Client Coexistence
Exchange Server 2003 and Outlook 2003 or earlier clients require system public folders to provide access
to free\busy information and to enable offline clients to download the offline address book. Exchange
Server 2010 and Outlook 2007 or newer clients do not use public folders to provide this functionality. As
you upgrade your Exchange Server organization, you need to ensure that all messaging clients continue
to have access to the services they require.
Note Make sure that you upgrade your Outlook 2003 client to the latest service pack
(currently, it is SP3). Also, you should be aware of some known issues when using Outlook
2003 and Exchange Server 2010. For more information about these issues see Common
Client Access Considerations for Outlook 2003 and Exchange 2010.
Maintaining Free\Busy Information

Exchange Server 2003 collects free\busy information from all mailboxes, and stores in the SCHEDULE+
FREE BUSY system public folder. In Exchange Server 2010, the Availability service collects availability
information from Exchange Server 2010 Mailbox servers and from the Exchange Server 2003 system
public folders.
Outlook 2003 or earlier clients require the system public folders to access the free\busy information.
Outlook 2007 or newer clients can use the availability service on a Client Access server to access this
information.
If your organization includes 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 Offline Address List

Another difference between Exchange Server 2003 and Exchange Server 2010 is the method that they use
to distribute offline address book to Outlook 2007 clients. In Exchange Server 2003, a system folder stores
the offline address book, and clients must connect to the folder to download it. Outlook 2007 clients
connecting to an Exchange Server 2007 Client Access server use a web service to download the offline
address book.
Offline address book web publishing integrates seamlessly with the offline address book in previous
Exchange Server versions. Outlook 2007 downloads the offline address book from the web service, and all
other clients download the offline address book from the system folder.
In an Exchange 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 that is running
Exchange Server 2010. You will also need to configure the offline address book so that it is distributed
through the Exchange web service.
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

Another issue that may arise in a coexistence scenario is public-folder access. You must consider how
users access public folders and provide access between Active Directory sites when designing the access
solution for public folders.
In Exchange Server 2010, public folders are accessible only to users with an Outlook client that is using
MAPI or Outlook Web App. Also, public folder contents for users with Exchange Server 2010 mailboxes
are only accessible through Outlook Web App if a replica of the public folder is located on an Exchange
2010 Mailbox server. Previous Exchange Server versions provided access to public folders to MAPI,
Outlook Web Access, Internet Message Access Protocol version 4rev1 (IMAP4), and Network News
Transfer Protocol (NNTP) clients. If you have users that access public folders by using these clients,
maintain a replica of the public folders on an Exchange 2003 server. For IMAP4 and NNTP clients, provide
access to the public folder through an Exchange Server 2003 front-end server, or by allowing the clients
to connect directly to the Exchange Server 2003 back-end server that hosts the public folder.Another
consideration when designing a coexistence strategy for public folders is providing access to public-folder
replicas between Active Directory sites. When you install a server that is running Exchange Server 2003,
the default configuration includes a public-folder store. When you install an Exchange Server 2010
Mailbox server, it does not configure a public-folder database by default.
If users require access to public folders in an Active Directory site that does not contain any Exchange
Server 2003 servers, then configure at least one of the sites Mailbox servers with a public-folder database.
When you configure this database, the server participates in public-folder hierarchy replication so that all
users can view the Active Directory sites public-folder hierarchy. If you do not configure this database, the
client must connect to a server with a different sites public-folder database to view the hierarchy.After
adding the public-folder database to the Exchange 2010 server, you can replicate any public folder
between servers that are running Exchange Server 2003 and the Exchange Server 2010 Mailbox server.
Exchange Server 2010 by default enables public-folder referrals between Active Directory sites for MAPI
clients. It also enables public-folder referrals across the routing-group connector that is created by default
when you install the organizations first Hub Transport server. You can enable or disable public-folder
referrals across the connectors as you create additional routing-group connectors.
Considerations for Message Transport Coexistence
To support coexistence between different Exchange versions, all servers that are running Exchange Server
2010 are added automatically to a single routing group when you install Exchange Server 2010. The
Exchange System Manager in Exchange Server 2003 or Exchange 2000 Server recognizes the Exchange
Server 2010 routing group as Exchange Routing Group (DWBGZMFD01QNBJR) within Exchange
Administrative Group (FYDIBOHF23SPDLT). The Exchange Server 2010 routing group includes all
Exchange Server 2010 servers, regardless of the Active Directory site in which they reside.
Important You never should modify the default configuration for the Exchange Server 2010
routing group. Exchange Server 2010 does not support moving servers from this routing group to
another, renaming the Exchange Server 2010 routing group, or manually adding Exchange
2003/2000 Servers to the Exchange Server 2010 routing group.
Installing Exchange Server 2010 Hub Transport Servers

When you install the first Exchange Server 2010 Hub Transport server in an existing Exchange
organization, you must specify an Exchange Server 2003 bridgehead server that will operate as the first
routing-group connectors bridgehead server. The routing-group connector links the routing group where
the Exchange Server 2003 resides with the Exchange Server 2010 routing group.
The Hub Transport server that you are installing, and the Exchange Server 2003 bridgehead that you
select, are configured as the source and target servers on two reciprocal routing-group connectors. The
selected bridgehead server is added automatically to the membership of the ExchangeLegacyInterop
universal security group, and is granted the permissions that are required to send email to, and receive
email from, Exchange Server 2010. This routing-group connector creates a single connection point
between Exchange Server 2003 and Exchange Server 2010.
Message Flow During Coexistence

When you have mailboxes located on both Exchange Server 2010 and Exchange Server 2003 servers, all
messages that you send between the Exchange Server versions travel across the routing-group connector
that is created when you install the first Hub Transport Server. For example, if a user with a mailbox on an
Exchange Server 2003 server sends a message to a user with a mailbox on an Exchange Server 2010
server, the message is sent by using the following process:
1. The Exchange 2003 server that hosts the mailbox sends the message to the Exchange Server 2003
bridgehead server that you configure on the routing-group connector.
2. The Exchange 2003 bridgehead server sends the message to the Exchange Server 2010 Hub Transport
server that is the bridgehead server on the routing-group connector.
3. The Exchange Server 2010 Hub Transport server sends the message to the Exchange 2010 Mailbox
server hosting the user mailbox.
Optimizing Message Routing Between the Messaging Systems

When you install the first Hub Transport server in the existing Exchange organization, this enables
message routing between the two messaging systems. However, all messages flow through the single
routing-group connector that you configure during installation. When configuring the message routing
topology, you should consider:
Adding additional Hub Transport and Exchange Server 2003 servers as bridgehead servers to the
default routing-group connector. This provides redundancy if one of the servers is unavailable and
provides load balancing.
If your organization has multiple locations and multiple routing groups, you should create additional
routing-group connectors to optimize message routing. If you use only the default routing-group
connector that is created during the Hub Transport server installation, it routes all messages from
Exchange Server 2010 recipients to Exchange Server 2003 recipients through the Active Directory site
where the Hub Transport bridgehead server is located. The messages then go across the routing-
group connector and through the Exchange Server 2003 routing-group connectors to recipients on
Exchange 2003 servers.
To optimize message routing, consider creating a new routing-group connector in each routing
group as you deploy a Hub Transport server in the corresponding Active Directory sites. This enables
you to send messages between the messaging systems, without routing them to another company
location. You must use Exchange Management Shell to manage routing-group connectors.
If you implement multiple routing-group connectors between the two Exchange Server versions, you
also must suppress link-state updates on Exchange Server 2003. Servers that are running Exchange
Server 2003 maintain a link-state routing table that determines a messages routing inside the
organization. If a particular routing group is inaccessible by using the lowest cost route, the routing
group master updates the link-state table to show the links state as down.
Exchange Server 2010 Hub Transport servers do not use link-state routing, and Exchange Server 2010
cannot propagate link-state updates. When no Hub Transport server in a site is available, the Hub
Transport server does not recalculate the route. If multiple paths exist between the Exchange Server
2010 routing group and any Exchange Server 2003 routing group, you must suppress minor link-state
updates to ensure that message looping does not occur when the Hub Transport server recalculates a
route.
You should suppress link-state updates for each server that is running Exchange Server 2003 or
Microsoft Exchange 2000 Server. This enables the servers that are running Exchange Server 2003 to
queue at the failure point rather than recalculating the route.
Considerations for Administration Coexistence
As you perform the upgrade to Exchange Server 2010, you also must plan for continued administration of
the organization.
Comparing Administrator Delegation

Exchange Server 2003 provides predefined security roles for delegating Exchange administrative
permissions. These roles are a collection of standardized permissions that you can apply at either the
organizational or administrative group level. In Exchange Server 2003, there is no clear separation
between administration of users and groups by the Windows Active Directory administrators and
Exchange recipient administrators.
Exchange Server 2010 uses Role-Based Access Control (RBAC) to assign permissions. You can use RBAC to
restrict the EMS cmdlets that users can run and the attributes that they can modify. RBAC provides you
with significantly more flexibility in assigning permissions than what was available in Exchange Server
2003.
Most organizations use the role groups that you create in AD DS to assign permissions in an Exchange
Server 2010 organization. You create these groups when you run Exchange Server 2010 Setup with the
/PrepareAD switch. To configure Exchange Server 2010 administrative permissions, you can add users to
the predefined Active Directory groups.
Replicating Exchange Administrative Designs

Due to the design differences of administrative permissions in Exchange Server 2010 compared to
previous Exchange 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 Server 2003 administrative

option Exchange Server 2010 equivalent
Assign Exchange Full Administrator Add users or groups to the Exchange Organization
role at the organization level. Administrator role group.
Assign Exchange Administrator role Exchange Server 2010 does not have a role group equivalent to
at the organization level. the Exchange Administrator role. You can create a role group
and assign the required permissions through RBAC.
Assign Exchange View Administrator Add users or groups to the Exchange View-Only Administrator
role at the organization level. role.
Assign Exchange Full Administrator Create a new role group that is assigned all management roles,
role at the administrative group but with a limited scope.
level.
Assign Exchange View Administrator Create a new role group with View-Only permissions and a
role at the administrative group limited scope.
level.
Assign recipient administrators with Add users and groups to the Exchange Recipient Administrator
Exchange View Administrator role role group.
and Active Directory permissions.
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 need to use the Exchange System Manager. You also can
manage recipients with 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.
Completing the Migration
In a coexistence scenario where Exchange Server 2010 is installed in an Exchange Server 2003 or Exchange
Server 2007 organization, email address policies and address lists created in the previous Exchange Server
version display, but they cannot be managed by using Exchange Server 2010 Exchange Management
Console or Exchange Management Shell.
Email address policies and address lists that exist in Exchange Server 2003 use Lightweight Directory
Access Protocol (LDAP) syntax filters, which are not supported in Exchange 2010. To edit these email
address policies and address lists using Exchange Server 2010 management tools, you must upgrade
the LDAP filters to the OPATH syntax. Because of this, it is necessary that you upgrade these objects
to a version that is supported by Exchange Server 2010 Management tools. You can use Exchange
Management Shell to upgrade email address policies and address lists. You will also need to upgrade
distribution groups created on older Exchange system to the version supported by Exchange Server 2010
to achieve full functionality.
To upgrade default email address policy you should run the following command:
Set-EmailAddressPolicy "Default Policy" -IncludedRecipients AllRecipients
If you want to upgrade default address lists to a version that can be edited with Exchange Server 2010
tools, you should run the following cmdlets:
Set-AddressList "All Users" -IncludedRecipients MailboxUsers
Set-AddressList "All Groups" -IncludedRecipients MailGroups
Set-AddressList "All Contacts" -IncludedRecipients MailContacts
Set-GlobalAddressList "Default Global Address List" -RecipientFilter {(Alias -ne $null -

and (ObjectClass -eq 'user' -or ObjectClass -eq 'contact' -or ObjectClass -eq
'msExchSystemMailbox' -or ObjectClass -eq 'msExchDynamicDistributionList' -or
ObjectClass -eq 'group' -or ObjectClass -eq 'publicFolder'))}
Besides upgrading email policies and address objects, you should be sure that you modify the message
routing infrastructure before you remove the older version of Exchange Server. When you install the first
Hub Transport server in the existing Exchange Server organization, you automatically enable message
routing between the two messaging systems. However, all messages flow through the Routing Group
connector that you configure during installation. When you move all resources to Exchange Server 2010,
there is no need for message traffic to go through the Routing Connector any more.
In Exchange Server 2003, you probably had a SMTP connector from the Exchange Server 2003 Front-End
Server towards the Internet. A new Send Connector on the Exchange Server 2010 Hub Transport Server
needs to be created that will replace the old Exchange Server 2003 SMTP Connector. Send Connector will
allow the Hub Transport Server to send SMTP mail to the Internet directly (or to the Edge Transport
Server). You should also consider modifying authentication options on the Receive connector on Hub
Transport server, if this server will receive messages directly from Internet.
Process for Removing Exchange Server 2003 from the Organization
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 2010 servers.
Then you can start removing the Exchange 2003 servers.
Moving Resources to Exchange Server 2010 Servers

After you deploy the Exchange Server 2010 servers, you can move the following resources to the new
servers:
Mailboxes. You can move mailboxes from Exchange Server 2003 SP2 to Exchange Server 2010.
Perform the move by using the Exchange Management Console or EMS move request cmdlets. You
cannot use the Exchange System Manager on the Exchange Server 2003 server to move the mailbox.
When you perform the move, the mailbox will be offline and end users will not be able to access their
mailboxes. Exchange Server 2003 does not have resource mailboxes. Instead, you must use shared
mailboxes to represent resources. If you move a shared mailbox from Exchange Server 2003 to
Exchange Server 2010, the move request cmdlets creates the mailbox as a shared Exchange 2010
mailbox. After you move the mailbox to Exchange 2010, you can convert it to a resource mailbox.
Public folders. If you require system folders or other public folders after the upgrade, create replicas of
the public folders on the Exchange 2010 server hosting the public-folder database. Wait for
replication to complete, and then remove the replicas on the Exchange Server 2003 servers.
Message transport connectors. When you deploy Exchange Server 2010 servers in the Exchange Server
2003 organization, all Internet messages continue to flow through the Exchange Server 2003 SMTP
connectors. To move this functionality to the Exchange Server 2010 servers, create new SMTP Send
and Receive connectors on the Exchange Server 2010 Hub Transport servers. Then modify the cost for
the Exchange Server 2003 SMTP connectors so that the Exchange Server 2010 Send connectors have
a lower cost. Also, configure the external MX records, or the SMTP gateway server to forward all
messages to the Exchange Server 2010 Hub Transport server. Test the message flow by using the new
connectors, and then remove the SMTP connectors on the Exchange Server 2003 servers.
Offline Address Book generation server. You can use the Exchange Management Console to configure
the Exchange 2010 Mailbox server as the offline address book generation server. You also should
enable web distribution of the offline address book.
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. We recommend 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. Exchange Server 2003 Mailbox servers require
an Exchange Server 2003 bridgehead server to send messages between routing groups. After you
remove the last mailbox server in a routing group, you also can remove the routing groups
bridgehead servers.
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
2003 and the Exchange 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 2003
server as the new bridgehead server.
3. Remove the Exchange Server 2003 front-end servers. Users who connect to their mailboxes by using
non-MAPI clients must be able to communicate with a front-end server that is the same Exchange
Server version as the server hosting the user mailbox.
Lesson 3
Upgrading from Exchange Server 2007 to
The second scenario for upgrading to Exchange Server 2010 is for organizations that are running
Exchange Server 2007 currently. This scenarios upgrade process is similar to upgrading from Exchange
Server 2003, but there are some important differences. This lesson describes how to complete the
upgrade from Exchange Server 2007 to Exchange Server 2010.
Explain the process for installing Exchange Server 2010 in an Exchange Server 2007 organization.
Describe how client access works during coexistence.
Describe how to implement client access.
Describe the considerations for message transport coexistence.
Describe the considerations for administration coexistence.
Describe the process for removing Exchange Server 2007 from an organization.
Process for Installing Exchange Server 2010 in an Exchange Server 2007

Organization
Complete the following steps to deploy Exchange Server 2010 servers in an Exchange Server 2007
organization:
1. Update all of the Exchange Server 2007 servers to Service Pack 2. Exchange Server 2010 Setup checks
the server versions of all Exchange servers and the requirement checks fail if a server is not upgraded.
Exchange Server 2007 SP2 includes several schema updates that are required for interoperability with
If an organization only has a single Active Directory site, use the following process for deploying
2. 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 settings, both internally and externally, to point to the Exchange Server 2010 Client
Access server.
Note Later sections of this lesson include more information on how to configure the
client-access settings, including the AutoDiscover settings.
3. Install the Exchange Server 2010 Hub Transport server. Both Exchange Server 2007 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.
4. Install Exchange Server 2010 Unified Messaging servers. If you have deployed Unified Messaging in
Exchange Server 2007, add the Exchange Server 2010 UM Server to one of your organizations dial
plans.
5. 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.
6. Install the Exchange Server 2010 Edge Transport servers. Exchange Server 2010 Edge Transport
servers can synchronize only with Exchange Server 2010 Hub Transport servers.
For organizations with multiple sites, there typically are two types of AD DS sites: Internet-accessible 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 2010 servers in both Internet accessible and
non-Internet accessible sites. Before deploying any Exchange Server 2010 Mailbox server in a site, you
must deploy Exchange Server 2010 Client Access and Hub Transport servers.
How Client Access Works During Coexistence
The Client Access server role in Exchange Server 2010 has changed significantly from the Client Access
server in Exchange Server 2007. The most important change is that all client connectivity, including
Outlook MAPI connectivity, now goes through the Client Access server role.
Client Access During Coexistence

After you deploy the Exchange Server 2010 Client Access and Mailbox servers, the process for when non-
MAPI clients access the user mailboxes depends on the type of client that you are using, and on the
location of the user mailbox.
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 URL, such as https://mail.contoso.com, to connect to an
Exchange Server 2007 Client Access server, you should modify the DNS or firewall configuration to
forward connections to the Exchange Server 2010 Client Access servers URL.
When an Outlook Web App client connects to the Client Access server, and the user mailbox is
located on an Exchange 2007 Mailbox server, the Autodiscover service on the Exchange Server 2010
Client Access server redirects the client to the external URL that you configure on the Exchange Server
2007 Client Access server. For example, if the client connects to the Exchange Server 2010 Client
Access server by using the URL of https://Mail.contoso.com, the Autodiscover service redirects it to
https://legacy.contoso.com. The client then communicates with the Exchange 2007 Client Access
server to access the user mailbox.
When an Outlook Web App client connects to the Client Access server and the user mailbox is located
on an Exchange Server 2010 Mailbox server, the Client Access server communicates with the Mailbox
server to provide access to the user mailbox.
When an Exchange ActiveSync client connects to the Client Access server, and the user mailbox is
located on an Exchange 2007 Mailbox server, the process will depend on whether the mobile devices
supports Autodiscover:
If the device does not support Autodiscover, the Exchange Server 2010 Client Access server
proxies the client request to the Exchange Server 2007 Client Access server by using HTTPS, and
then the Exchange Server 2007 Client Access server connects to the Exchange Server 2007
Mailbox server and provides access to the user mailbox.
If the Mobile client does support Autodiscover, the Autodiscover service on the Exchange Server
2010 Client Access server redirects the client to use the external URL configured on the Exchange
Server 2007 Client Access server.
When an Exchange ActiveSync client connects to the Client Access server, and the user mailbox is
located on an Exchange 2010 Mailbox server, the Client Access server connects to the Mailbox server
by using RPC and provides access to the user mailbox.
located on an Exchange Server 2007 Mailbox server, the RPC proxy service on the Client Access server
connects to the back-end server by using RPC.
located on an Exchange 2010 Mailbox server, the RPC proxy service on the Client Access server
connects to the back-end server by using RPC.
If the user mailbox is on an Exchange Server 2007 Mailbox server in a different Active Directory site,
the Exchange Server 2010 Client Access server always proxies the client requests. For Outlook Web
App and Exchange ActiveSync clients, the Client Access server proxies the requests by using HTTP to
an Exchange Server 2007 Client Access server. For Outlook Anywhere clients, the Client Access server
proxies the request using RPC to an Exchange Server 2007 Mailbox server.
When a MAPI client connects to the user mailbox, and the user mailbox is on an Exchange Server
2007 server, the MAPI client connects directly to the Mailbox server. If the user mailbox is on an
Exchange Server 2010 server, the MAPI client connects to an Exchange 2010 Client Access server.
Note When you move a user 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.
Considerations for Client Access during Coexistence

When implementing client access during coexistence, consider the following:
Whether a user sees the Outlook Web App client of Exchange Server 2007 or Exchange Server 2010
depends on the location of the users mailbox. For example, if the users mailbox is located on an
Exchange Server 2007 Mailbox server and the Client Access server is running Exchange 2010, the user
sees the Exchange Server 2007 version of Outlook Web Access.
You cannot use an Exchange Server 2007 Client Access server to access mailboxes on Exchange Server
2010 Mailbox server.
Implementing Client Access Coexistence
During coexistence, you need to ensure that users with mailboxes on both Exchange Server 2007 Mailbox
servers and Exchange Server 2010 Mailbox servers can access their mailboxes. The following steps describe
how to enable this:
1. Obtain the required server certificates. To support external client coexistence with the Exchange
Server 2010 Client Access server and legacy Exchange servers, you may need to acquire a new
certificate. You should request a certificate that supports at least the following Subject Alternative
Names:
The primary URL to use to access the Exchange 2010 Client Access server. For example, you might
use a name such as mail.contoso.com.
The AutoDiscover server name. Normally, you would us a name such as

autodiscover.contoso.com.
An alternate name for the URL to use to connect to the Exchange 2007 Client Access server. For
example, you might use a name such as legacy.contoso.com.
Note The Exchange Server 2010 Client Access server requires this certificate, but you also
might install the same certificate on the Exchange 2007 Client Access server. The Exchange
Server 2007 Client Access server requires a certificate with subject alternative names that
include the alternate name, legacy.contoso.com, and the Autodiscover server name.
2. Install and configure the Exchange Server 2010 Client Access server. You should configure external
name space during or after Setup by using the Exchange Management Console or EMS.
3. Modify the external URLs on the Exchange Server 2007 Client Access server to use the alternate name.
If you are using legacy.contoso.com as the alternate name, configure this as the external URL for the
Outlook Web App, Offline Address Book, Unified Messaging, Web Services and Exchange ActiveSync
virtual directories.
4. Configure DNS. To configure DNS, you should:
Create the legacy host record, which is legacy.contoso.com, in your external DNS infrastructure,
and configure it to reference the Exchange Server 2007 Client Access server.
Create or modify the host record for Autodiscover, which is Autodiscover.contoso.com, and
configure it to reference the Exchange 2010 Client Access server.
Create or modify the host record for the primary URL, which is mail.contoso.com, and configure it
to reference the Exchange Server 2010 Client Access server.
5. If you use Outlook Anywhere on the Exchange Server 2007 servers, disable Outlook Anywhere on the
Exchange Server 2007 Client Access server. When you implement Outlook Anywhere on the Exchange
Server 2010 Client Access server, it proxies the Outlook Anywhere client requests directly to the
Exchange Server 2007 Mailbox server.
6. Test all client scenarios, and ensure they function correctly.

Considerations for Message Transport Coexistence
A second coexistence component 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 2007
organization, message transport works as follows:
Each version of Exchange Mailbox server must use an equivalent version of the Hub Transport server
when routing messages within the same site. This means that you must deploy the Exchange Server
2010 Hub Transport server before deploying the Exchange 2010 Mailbox servers, and that you must
not remove the last Exchange 2007 Hub Transport server until you have removed all of the mailboxes
from the Exchange Server 2010 Mailbox servers.
If you have both Exchange Server 2007 and Exchange Server 2010 servers deployed in a site,
messages will flow from the Exchange 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 would follow the reverse
route.
Message routing between Active Directory sites can use Hub Transport servers on either Exchange
Server version. If you installed an Exchange Server 2010 Hub Transport server in one site, it can send
messages to Exchange Server 2007 Hub Transport servers in another site.
Message routing to and from the Internet can use either Exchange Server 2007 or Exchange Server
2010 Hub 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. As you deploy Exchange Server 2010 Hub
Transport servers, you can add them to the edge subscription or configure the Exchange Server 2007
Edge Transport servers to forward messages to the Exchange Server 2010 Hub Transport servers. 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.
Note In Exchange Server 2010, you can view message-tracking information using the
Exchange Management Console or the Exchange Control Panel. If an administrator or user
views the message-tracking information in Exchange Control Panel, the message can be
tracked only on Exchange Server 2010 Hub Transport servers. Administrators can track
messages on both Exchange Server 2010 and Exchange Server 2007 Hub Transport servers
by using the Message Tracking tool in Exchange 2007 and the Tracking Log Explorer tool in
Edge Transport Server Coexistence

If you deploy the Exchange Server 2007 Edge Transport server role, you can retain or replace the server
with an Exchange Server 2010 Edge Transport server.
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.
Considerations for Administration Coexistence
When implementing Exchange Server 2010 in an Exchange Server 2007 organization, you also need to
plan for administrative coexistence. In this scenario, you need to 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 the different Exchange Management Consoles:
You can perform actions that create new objects, such as new mailboxes or a new offline address
book, on 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 cannot manage Exchange Server 2007 Mailbox databases from the Exchange Server 2010
Management Console, although you can view these databases.
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
that have mailboxes on an Exchange Server 2007 Mailbox server.
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 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 only Exchange Server 2007 and Exchange Server 2010 transport rule objects from
the corresponding version of the Exchange Management Console.
You can view only Exchange Server 2007 and Exchange Server 2010 servers from their
corresponding version of the Exchange Management Console.
The Queue Viewer tool in Exchange Server 2010 Management Console cannot connect to an
Exchange Server 2007 server to view queues or messages.
Delegating Administration During Coexistence

The model for delegating administrative permissions has changed significantly in Exchange Server 2010.
Exchange 2007 Setup creates several Active Directory groups with designated permissions in Active
Directory and in the Exchange organization. To delegate permissions, you just add users to the
appropriate Active Directory groups.
RBAC replaces this model in Exchange Server 2010, where you will 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 Active Directory, and the Exchange Server 2007 groups are retained.
When assigning permissions on Exchange Server 2007 servers, use the Exchange Server 2007 groups.
When assigning permissions on Exchange Server 2010 servers, use the Exchange Server 2010 role groups.
You also can delegate permissions in an Exchange 2007 organization. The following table describes some
options for creating an Exchange Server 2010 administrative design that emulates an Exchange Server
2003 design:
Exchange Server 2007 administrative option Exchange Server 2010 equivalent
Assign users to the Exchange Organization Add users or groups to the Organization
Administrators group. Management role group.
Assign users to the Exchange View-Only Add users or groups to the View-Only Organization
Assign users to the Exchange Recipient Add users or groups to the Recipient Management
Administrators group. role group.
Assign users to the Exchange Public Folder Add users or groups to the Public Folder
Assign users as server administrators for a Create a custom role group that includes only server
specific Exchange 2007 server. management roles and with a scope limited to a
single server.
Process for Removing Exchange Server 2007 from the Organization
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.
Moving Resources to Exchange Server 2010 Servers

Before removing the Exchange Server 2007 servers, you should move all required functionality and data
to the Exchange Server 2010 servers:
Transport connectors. You can add Exchange Server 2010 Hub Transport servers as source servers on
Send connectors created in Exchange Server 2007. To upgrade message-transport functionality, add
the Exchange Server 2010 Hub Transport servers to the Send connectors, and then remove the
Exchange Server 2007 servers.
Mailboxes. You can move mailboxes from Exchange Server 2007 SP2 to Exchange Server 2010. This
move occurs online, and end users can access their mailboxes during the move. You must perform the
move from the Exchange Server 2010 server using the move request cmdlets in the EMS, or by using
the New Local Move Request option in the Exchange Management Console. You cannot use the
Move-E-mail box functionality on the Exchange Server 2007 server to move mailboxes to Exchange
2010 servers.
Public folders. If you require system folders or other public folders after the upgrade, create replicas of
the public folders on an Exchange Server 2010 server hosting the public-folder database. Wait for
replication to complete, and then remove the replicas on the Exchange Server 2007 servers.
Removing Exchange 2007 Servers

As you move mailboxes and message delivery to the Exchange Server 2010 servers, you can start
removing the previous Exchange Server versions. We recommend the following process for removing
Exchange Server 2007 servers:
1. Remove Mailbox servers first. As you move mailboxes from Exchange Server 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. The Exchange Server 2010 Unified
Messaging server can coexist with Exchange Server 2007 Mailbox 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. Users who connect to their mailboxes by
using Outlook Web App clients must be able to communicate with a Client Access Server that is the
same Exchange Server version as the server hosting the user mailbox.
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.
Review Questions
1. Your organization is deploying Exchange Server 2010 in an Exchange 2003 organization. You have
made the changes to Active Directory. What is the first Exchange 2010 server role that you should
deploy? How will this deployment change the user experience?
2. Why do you need to configure a new external URL on Exchange Server 2007 Client Access servers
when you deploy Exchange Server 2010 Client Access servers?
3. Your organization includes two locations and Active Directory sites. You have deployed Exchange
Server 2007 servers in both sites. You now are deploying Exchange Server 2010 servers in one of the
sites and removing the Exchange Server 2007 servers. When can you remove the last Exchange 2007
Hub Transport server in the site?
Common Issues Related to Upgrading to Exchange 2010

Identify the causes for the following common issues related to upgrading to Exchange Server 2010. For
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.
(continued)
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 using Outlook Web App
from the Internet, but users with mailboxes on
the Exchange Server 2007 Mailbox servers
cannot.
You have deployed Exchange Server 2010

servers in your Exchange Server 2007
organization. You need to modify the settings
on both Exchange Server 2007 and Exchange
Server 2010 servers, but you cannot see both
servers in the Exchange Management Console.

1. A. Datum has three office locations and three Active Directory sites. They have deployed Exchange
Server 2003 servers in all offices, but have enabled Internet access to the servers only in the main
office. What high-level process should A. Datum use to upgrade to Exchange Server 2010?
2. Your organization has deployed Forefront Threat Management Gateway (TMG) to secure access to
the Client Access server deployment. You have completed all of the steps required to enable access to
both the Exchange 2010 Client Access server and the Exchange 2007 Client Access server. What
changes do you need to make on the TMG server?
3. Your organization is deploying Exchange Server 2010 in an Exchange Server 2003 organization. Your
organization does not provide Internet access to messaging clients, and all users are located in a
single office. You deploy an Exchange Server 2010 server using a standard installation. What else do
you need to do before you start moving mailboxes to the Exchange Server 2010 server? Users need to
be able to access their mailboxes by using Outlook Web App and Outlook 2003.
Best Practices Related to Upgrading to Exchange Server 2010

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 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, we recommended a one-to-four ratio
of Client Access server or front-end server processor cores to Mailbox server or back-end server cores.
In Exchange Server 2010, we recommend a three-to-four ratio.
Use certificates with subject alternative names rather than using wildcard certificates when you obtain
certificates for the Client Access servers. Wildcard certificates are less secure, because they can be
used to secure connections to any server name. If an attacker obtains a copy of the certificate, they
can use it to secure connections to any server name while using your domain name.
Tools
Remote Connectivity Testing client access connections during http://go.microsoft.com/fwlink

Analyzer the upgrade to Exchange Server 2010 /?LinkId=179969
13-1
Module 13
Implementing Microsoft Exchange Online with
Contents:
Lesson 1: Introduction to Exchange Online 13-3
Lesson 2: Deploying Exchange Online 13-13

Lesson 3: Implementing Federated Delegation 13-27
13-2 Implementing Microsoft Exchange Online with Microsoft Office 365
Module Overview
Increasingly, migrating to Microsoft Exchange Online as an organizations messaging host has

become an attractive option for Exchange administrators who currently run Exchange servers in their
organizations data centers. The reason for this interest is that moving Exchange administration and
management to the cloud reduces operational, licensing, and setup costs.
Exchange Online is available through Microsoft Office 365, which provides cloud-based versions of
Microsoft products. This module will help you understand the features of Office 365 and Exchange Online,
and plan an Exchange Online solution.
Microsoft Exchange Server 2010 Service Pack 1 (SP1) or newer contains functionality that can help
you connect your existing Exchange organization to Exchange Online. A hybrid deployment allows
collaboration between users who use Exchange Server mailboxes and Exchange Online mailboxes. The
Federated Delegation feature also enhances collaboration by allowing you to share information between
Exchange on-premises organizations and Exchange Online organizations.
Describe the features of Exchange Online.
Explain how to deploy Exchange Online.
Explain how to implement Federated Delegation.

Lesson 1
Introduction to Exchange Online
If you currently do not have an Exchange organization in your company, you can start with Exchange
Online as your messaging system. However, for organizations that currently maintain a messaging system,
it is important to understand Exchange Online and its coexistence options.
Describe Office 365.

Describe the Exchange Online features.
Describe Exchange Online user subscriptions.
Describe Microsoft Forefront Online Protection for Exchange.
Describe Exchange Online deployment scenarios.

What Is Office 365?
Office 365 is a suite of five Microsoft services that are now available in an online version: Exchange Online,
Lync Online, SharePoint Online, Office Professional Plus, and Office Web Apps. It is a subscription-
based service with various pricing options.
Exchange Online
Exchange Online provides Exchange Server email, calendar, and contacts in addition to antivirus and anti-
spam protection. You can connect your existing Exchange Server 2010 organization to Exchange Online to
provide hybrid deployment features such as free/busy information and MailTips for your users. Exchange
Online features are described in the next topic.
Lync Online
Lync Online provides instant messaging (IM) and presence, online meeting, audio and video calling, and
screen sharing to your users. You can connect your organizations existing Microsoft Office
Communications Server 2007 or Microsoft Lync Server 2010 servers to Lync Online.
SharePoint Online
SharePoint Online allows you to create and manage SharePoint sites directly from the cloud. You can
share documents or keep teams updated by using a common SharePoint team site that does not require
you to set up SharePoint in your own data center. You can also share a SharePoint site between
organizations if you do not want to set up servers in a perimeter data center.
Office Professional Plus

Office Professional Plus is the same as Microsoft Office Professional 2010 that includes all Office desktop
applications, including Microsoft Word and Microsoft Excel. It also includes an on-demand, per-user
license model, and connects to the cloud.
Additionally, Office Professional Plus has the following available features:
Makes Microsoft Office Professional Plus 2010 client applications available as a monthly subscription.
Enables a per-user license with as many as five simultaneous installations.
Supports 32-bit and 64-bit installations.
Provides easy access and management through the Office 365 online portal.
Note Office Professional Plus is not a streaming client. It includes Office Web Apps in the
license. Office Professional Plus provides the full Office Professional 2010 feature set on the
local machines, but it differs in license management.
Office Web Apps

Office Web Apps allow you to create, view, share, and edit your Microsoft Office documents directly on
the web. You do not need a locally installed version of Microsoft Office if you want to work on your
content.
Question: What Office 365 services would you use in your company? Why?
Exchange Online Features
Exchange Online provides most of the features that are available in Exchange Server 2010 along with
additional features such as the ability to configure your Unified Messaging IP Gateway in Exchange
Control Panel. Other key Exchange Online features include:
Migration and hybrid deployment. Exchange Online provides migration tools, which enable users
to be moved automatically to Exchange Online. Or, you can connect your Exchange Server 2003,
Exchange Server 2007, or Exchange Server 2010 environment to the cloud and enjoy hybrid
deployment features, which let you share calendar free/busy data between cloud and on-premises
users and migrate whenever you want.
Compliance and archiving. Exchange Online provides the archiving and eDiscovery capabilities of
Exchange Server 2010 with built-in personal archives, multi-mailbox search, retention policies,
transport rules, and optional legal hold to preserve email.
Multiple management tools. Exchange Online includes management tools, such as the Exchange
Management Console, Exchange Control Panel, Windows PowerShell, and the Microsoft Online
Services Portal. The web-based Exchange Control Panel from Exchange Server 2010 is available in
Exchange Online, which enables you to manage policies, security, user accounts, and groups. You can
also use PowerShell to manage all aspects of your hosted Exchange environment remotely across the
Internet or continue to use the Exchange Management Console.
Enhanced web experience. The Microsoft Outlook Web App experience is available in Windows
Internet Explorer, Firefox, and Safari. Instant messaging integration allows users to chat from within
Outlook Web App.
Advanced routing options. Exchange Online allows you to route outbound email through your on-
premises infrastructure. This means you can perform custom post-processing of outbound email, use
third-party data loss prevention (DLP) appliances, and deliver email to business partners through
private networks.
Forefront Online Protection for Exchange. Forefront Online Protection for Exchange is included for
automatic anti-spam and antivirus scanning.
Hosted voicemail with Unified Messaging. You can replace your on-premises voicemail system by
integrating your on-premises private branch exchange (PBX) with hosted voicemail provided by
Exchange Online.
Note When referring to the local Exchange Server organization, we use the term on-
premises to differentiate it from Exchange Online, which is the online Exchange services
version.
Exchange Online supports the following messaging clients:
Outlook Web App (Internet Explorer, Firefox, and Safari)

Outlook 2011 for Mac (without Personal Archives)
Entourage 2008 Exchange Web Services Edition
Features from Exchange Server 2010 that are currently unavailable in Exchange Online include:
Public folders
A catch-all messages mailbox
Custom and hierarchical address lists

Global address list (GAL) segmentation
Secure/Multipurpose Internet Mail Extensions (S/MIME) in Outlook Web App
Application connectivity for the Messaging Application Programming Interface (MAPI), Collaboration
Data Objects (CDO), and the WebDAV library
GAL synchronization with multiple on-premises Active Directory Domain Services (AD DS) forests
Note Exchange Online features are subject to change. Refer to the Exchange Online
Service Description document available at http://go.microsoft.com/fwlink/?LinkId=207232
for updated feature lists.
Exchange Online User Subscriptions
To provide Exchange Online to your users, a user subscription license is required for each user. You can
subscribe to only Exchange Online, or to Exchange Online along with other features in Office 365. Office
365 is available in two service plans:
Office 365 for small businesses
Office 365 for midsize businesses and enterprises
The Office 365 for small businesses service plan provides Exchange Online Kiosk subscriptions. The Office
365 for enterprises service plan includes all subscription options. This topic focuses only on the Exchange
Online subscription options.
You can subscribe to Exchange Online by choosing one of three service plans:
Exchange Online Kiosk
Exchange Online Plan 1
Exchange Online Plan 2

The following table provides details about each user subscription.
Exchange Online
Feature kiosk Exchange Online plan 1 Exchange Online plan 2
Mailbox size 500 megabytes 25 gigabytes (GB) shared 25 GB for the users
(MB) between the primary mailbox mailbox plus unlimited
and archive mailbox archive mailbox storage
Outlook Web App Yes Yes Yes

(regular and light
versions)
Post Office Protocol Yes Yes Yes

(POP3)
Internet Message No Yes Yes

Access Protocol
(IMAP4)
Outlook Anywhere No Yes Yes

(MAPI)
Microsoft Exchange No Yes Yes

ActiveSync
Exchange Web No (no direct Yes Yes

Services access to kiosk
user mailboxes
through Exchange
Web Services)
Inbox rules No Yes Yes
Delegate access No (cannot access Yes Yes

other users
mailboxes, shared
mailboxes, or
resource
mailboxes)
Instant messaging No Yes (requires Lync Online or Yes (requires Lync Online
interoperability in Microsoft Lync Server 2010) or Microsoft Lync Server
Outlook Web App 2010)
Short Message No Yes Yes

Service (SMS)
notifications
Personal Archives No Yes Yes
Voicemail (Unified No No Yes

Messaging)
Legal hold No No Yes
Note Exchange Online subscription options are subject to change. Refer to the Office 365
website for updated information.
What Is Forefront Online Protection for Exchange?
Current messaging environments require a robust antivirus and anti-spam solution to minimize the
impact of malicious messaging. Forefront Online Protection for Exchange is an antivirus, anti-spam service
that is included with Exchange Online or can be purchased separately for your Exchange on-premises
environment. It is a hosted version of Forefront Protection 2010 for Exchange Server that requires no
hardware or software installation.
Forefront Online Protection for Exchange includes the following functionality:

It covers incoming, outgoing, and internal email messages. This helps protect your organization from
malicious content that originates from behind your firewall.
Multiple and complementary antivirus engines help catch email-borne viruses and other malicious
code.
The service uses proprietary anti-spam technology to achieve high accuracy rates.
All functionality is built into the service. No configuration is necessary to start or maintain the filtering
technology. Forefront Online Protection for Exchange just requires a Forefront Online Protection for
Exchange Send connector so messages will be sent to the Forefront Online Protection for Exchange
domain for scanning.
A highly customizable filter helps you comply with corporate policies and government regulations.
By creating a forced Transport Layer Security (TLS) rule in the policy filter, you can help ensure that
sensitive email is encrypted during transport.
When you register to Exchange Online or Office 365, you automatically use Forefront Online Protection
for Exchange for any message that is received for or sent from your online tenant; no extra configuration
is needed. The Hybrid Configuration Wizard in Exchange Server 2010 Service Pack 2 (SP2) configures
Forefront Online Protection for Exchange and automatically customizes the Send and Receive connectors.
Exchange Online Deployment Scenarios
When considering Exchange Online, you need to consider your business needs so that you can decide
between the following Exchange Online deployment scenarios:
Maintaining an Exchange on-premises organization only (Exchange Online is not used).

Migrating Exchange on-premises to Exchange Online so that all of your users are hosted in the cloud.
Connecting Exchange on-premises to Exchange Online for a hybrid deployment.
Exchange On-Premises
In an Exchange on-premises installation, you maintain a local installation of Exchange Server in your data
center. This means that your company manages its messaging environment in its own data centers.
The on-premises scenario allows you to perform maintenance, upgrades, and customization at your
convenience. However, this model requires considerable upfront capital for such expenses as hardware,
software, licenses, IT personnel for maintenance, and physical building space.
Exchange Online
In an Exchange Online environment, all of your mailboxes are hosted in the cloud. You do not host any
Exchange servers in your data center. Instead, you purchase the Exchange Online service from Microsoft.
This scenario provides rapid deployment and easy scalability. You also receive automatic upgrades to the
latest technology, ensuring an easy and seamless upgrade experience.
Hybrid Deployment
A mixed Exchange on-premises and Exchange Online environment is a hybrid deployment, which means
that features such as Free/Busy and calendar sharing functions are available between on-premises and
online mailbox users. This scenario provides the best features of both implementations, such as hosting
the primary mailboxes on-premises and moving the archive mailboxes to Exchange Online. Additionally,
a hybrid deployment allows you to migrate to Exchange Online in stages.
A hybrid deployment includes the following functionality:
Exchange on-premises and Exchange Online management from a single tool by using Exchange
Management Console or Exchange Management Shell.
Mailbox moves between the Exchange on-premises and Exchange online environments by using
Exchange Management Shell and Exchange Management Console.
Calendaring, including free/busy information and full calendar sharing, between hosted and on-
premises users.
Addresses for internal users resolved against GAL.
MailTips, anti-spam scanning, and out-of-office autoreplies understand that recipients are internal.
Delivery reports to track messages across the online/on-premises boundary.
Multi-mailbox search performed across all mailboxes.
Considerations
Consider the following questions so that you can decide on the most suitable scenario for your
organization:
Does your organization want to move all mailboxes to Exchange Online or only consider a subset of
mailboxes?
Is your organization interested in moving just some of the functionalitysuch as mailbox archivingto
the cloud?
Does your organization often use mailbox delegation? If yes, you need to ensure that both the
mailboxes and the mailboxes with delegation rights to those mailboxes are either hosted online or
hosted on-premises.
Is it important to have full control of the features and functionality of your messaging system?
Do organizational policies, governmental regulations, or compliance requirements exist with regards

to storing messaging data outside the organizations local area network (LAN)?
Does your organization satisfy the client requirements for Exchange Online?
Does your organization have a reliable connection to the Internet with sufficient bandwidth to move
all mailboxes to the cloud?
Does your organization have many mobile users or users who work outside the corporate offices that
would benefit from a connection to the cloud rather than to the corporate data center?
Does your organization use public folders a lot? Exchange Online does not support public folders.
Therefore, you should not move users that depend on public folders to Exchange Online.
Lesson 2
Deploying Exchange Online
If you are planning to move from an Exchange on-premises deployment to Exchange Online, you must
consider how to move the existing data such as the user accounts and the mailbox content.
You use many of the same tools to manage these users as you do the on-premises users. This lesson
describes your migration options and the tools you can use to manage the mailboxes both during and
after migration.
Describe the Exchange Online migration options.
Explain how to migrate users to Exchange Online.
Describe how to implement and manage a hybrid deployment.
Explain the Hybrid Configuration Wizard.
Explain the management tools available for Exchange Online.

Exchange Online Migration Options
Exchange Online offers various built-in tools and migration options to fit the migration needs of your
organization.
IMAP Migration
The most common way to migrate from third-party messaging systems such as Lotus Notes or
GroupWise to Exchange Online is to use the IMAP migration process. To use this process:
Ensure that your existing messaging system allows access to the mailboxes by using the IMAP4
protocol.
Create a comma separated values (.csv) file to list the users you want to migrate.
Use the Exchange Control Panel to migrate mailbox contents to the respective online mailboxes.
This migration option supports the widest range of email platforms, including Exchange Server 5.5 and
Exchange 2000 Server.
Limitations include:
Only email messages migrate to the online mailbox, not calendar or contacts.
There is no coexistence. You need to migrate all mailboxes at the same to ensure that you do not lose
data.
You can only move up to 1000 mailboxes at once. Currently, the Microsoft Online Portal can only
read .csv files with a maximum of 1000 rows per file. If you need to move more than 1000 mailboxes,
you must create additional .csv files (each containing a maximum of 1000 mailboxes) and import each
file into Exchange Online.
Cutover Exchange Migration

Cutover Exchange migration migrates all mailboxes from an Exchange on-premises installation to
Exchange Online at the same time. This migration method does not support a coexistence phase; you
must migrate all or nothing.
For example, you would use cutover Exchange migration when you want to migrate all mailboxes in a
short period such as few days or a weekend.
Cutover Exchange migration uses Outlook Anywhere (Exchange Server 2007 or 2010) or remote
procedure call (RPC)-over-HTTP (Exchange Server 2003) to connect to the source mailboxes, and it copies
all contents to the online mailboxes.
Cutover Exchange migration includes the following features:
The migration service provisions new mailboxes in your cloud-based organization. It creates a cloud-
based mailbox for each user account in your Exchange on-premises organization. It also synchronizes
on-premises distribution groups and contacts to the cloud.
After the migration service creates the new cloud-based mailboxes, it migrates all mailbox items, such
as messages, contacts, or calendar items, from the Exchange mailboxes to the corresponding cloud-
based mailboxes.
After the initial migration, the Exchange and cloud-based mailboxes are synchronized every 24 hours,
so that new email sent to the Exchange mailbox is copied to the corresponding cloud-based mailbox.
This is required until you finalized the migration process and changed the Domain Name System Mail
Exchanger (DNS MX) record so that all new messages are sent directly to the cloud-based mailbox.
You do not need additional Exchange 2010 servers on-premises to perform this migration. However,
similar to IMAP migration, you are limited to migrating up to 1000 mailboxes.
Staged Exchange Migration

Staged Exchange Migration is similar to cutover Exchange migration except that it allows for some
coexistence, which means that you can choose to migrate mailboxes in stages. You can use staged
Exchange migration when you cannot migrate quickly, your company requires a longer coexistence phase,
and a hybrid deployment is not an option.
It uses Outlook Anywhere or RPC-over-HTTP for the connection and requires a .csv file. After a mailbox
has migrated, Directory Synchronization updates the information, and the user is automatically reachable
in Exchange Online at their original email address as well as in the Exchange on-premises environment
through a mail-enabled user.
This migration method is available for Exchange Server 2003 and later. It requires you to configure and
install the Directory Synchronization tool before migration.
Hybrid Deployment
Hybrid Deployment is the smoothest migration method with the least impact to the users. This option
allows you to use the Exchange Management Console or the Exchange Management Shell to migrate
your users to or from Exchange Online. Hybrid deployment also provides full coexistence in a way that
users can exchange free/busy times or MailTips, which is not possible in the other migration options.
Hybrid deployment is used when you require long term coexistence or do not plan to move all your
mailboxes to Exchange Online. It is also the only option if your company requires you to preserve Outlook
.ost files on the client.
The principal benefit of this approach is that mailbox moves occur over the Internet by using the Mailbox
Replication Proxy (MRSProxy) service. The Client Access servers that are required to communicate
between Exchange on-premises and Exchange Online perform the mailbox moves. You do not need to
create .csv files. Additionally, this approach allows the mailbox to stay online during the move. Outlook
only needs to be restarted when the move is completed.
To use this migration method, you must configure your Exchange Server organization for hybrid
deployment. This is required to have features such as free/busy information available for both on-
premises mailboxes and cloud-based mailboxes. You need at least one Exchange Server 2010 SP1 or later
machine, Directory Synchronization configured as well as Exchange Federated Delegation. In Exchange
Server 2010 SP2 and newer, you can use the Hybrid Configuration Wizard to configure a hybrid
deployment as described later in this module.
Question: Which Exchange Online migration option would be suitable for a larger
organization with 2000 mailboxes?
Migrating to Exchange Online
Migrating an existing messaging system to Exchange Online is a complex task that includes many
unknown variables, such as the size of your system, the client protocol you use, and the messaging system
you use. However, most migrations follow a general pattern that consists of the following steps:
1. Connect directory and message routing to Exchange Online.
As mentioned previously, establishing a connection to Exchange Online ensures that your existing
email directory is synchronized to Exchange Online. Depending on your source directory, you can use
the Directory Synchronization tool to synchronize the Exchange Online directory, or you can use
other tools such as a .csv file if you use legacy systems. Be sure that all existing Simple Mail Transfer
Protocol (SMTP) addresses in your source messaging system are also created in Exchange Online.
Otherwise, you will lose messages when you configure the DNS MX record after the migration.
You also need to verify that your existing messaging system can send messages to Exchange Online.
2. Migrate the mailboxes.
Choose your preferred migration method, either with Microsoft tools or with non-Microsoft tools.
You can perform a staged migration or migrate everything at the same time. This depends on your
organizations size, the existing messaging environment, and other factors.
3. Switch the DNS MX record so that it points to Exchange Online.
After mailbox migration completes, you must change your companys DNS MX record so that it
points to Exchange Online. This causes all inbound message traffic to flow directly to Exchange
Online. After you make this change, you should no longer see many messages in your local
messaging system.
4. Finalize the migration and remove the old Mailbox servers.
Shut down everything in your on-premises messaging system. Check for the following:
Any inbound or outbound messages flowing through the system.
Any mailbox access after the time you switched over to Exchange Online.
After everything is shut down, you can remove your old mail servers from the data center and retire
them.
Implementing a Hybrid Deployment
You can choose to run Exchange Online independently from your existing messaging infrastructure, but
the functionality that is available in a hybrid deployment can help you manage mailbox migrations for
your on-premises and online users more efficiently.
Configure Active Directory Federation Services

You can configure Active Directory Federation Services (AD FS) to allow single sign-on and centralized
user management. AD FS is not a requirement, but we recommend implementing this tool to improve
user satisfaction.
With AD FS, your users can access online services with their domain credentials the same way they access
their on-premises applications. There is no need for a client-side sign-in tool.
Using AD FS provides the following benefits:
Better manageability and lower total cost of ownership (TCO).
Passwords are kept within the organization. Microsoft does not see credentials and passwords
because they are not synchronized to the cloud.
Organizations retain security control over user accounts and password expiration.
Simplified configuration and management. It does not require changes to the Active Directory code
or alterations of the enterprise Active Directory deployment.
With AD FS, you can deploy a multi-factor authentication system, which can include soft certificate and
smartcard authentication from out-of-the-box products such as RSA and Swivel.
You can customize the login page for Exchange Online and your other federated web applications such as
SharePoint Online.
Implement Active Directory Synchronization

After implementing AD FS, you should also implement Active Directory synchronization between your
organizations Active Directory forest and Exchange Online. You do this with the Directory
Synchronization tool.
The Directory Synchronization tool provides simplified management through integration with your local
Active Directory forest. This enables you to use the Active Directory information, so you do not have to
administer the organization from two locations.
The Directory Synchronization tool updates the Microsoft online environment whenever changes occur in
AD DS. This means that changes such as adding a new employee, deleting an employee, and changing
contact information automatically propagates to Exchange Online, so you do not have to update
Exchange Online manually. These synchronized items are read-only in the cloud, and you continue to
manage them with the AD DS tools.
The Directory Synchronization tool synchronizes changes every three hours. To protect your security, it
does not update sensitive information such as domain passwords. This tool also updates distribution
groups and the GAL and plays an important role during coexistence between your on-premises
organization and Exchange Online.
Run Hybrid Configuration Wizard

After you run the Hybrid Configuration Wizard that is available in Exchange Server 2010 SP2, you will
enable your Exchange on-premises organization and your Exchange Online tenant for hybrid deployment
features such as MailTips, free-busy information sharing, and so on. The Hybrid Configuration Wizard is
described in more detail in the next topic.
Question: You want to connect your Exchange Server organization to Exchange Online.
What options would you configure and why?
What Is the Hybrid Configuration Wizard?
Exchange Server 2010 SP2 introduces the Hybrid Configuration Wizard to ease the process of configuring
a hybrid deployment for your Exchange on-premises organization. It provides a wizard and cmdlets that
enable you to establish and manage your on-premises environment and Exchange Online in a hybrid
deployment by using the Exchange Management Console.
Before you run the Hybrid Configuration Wizard, you must set up Active Directory synchronization
between your AD LDS and Exchange Online, and then add your Exchange Online tenant as Office 365 in
The Hybrid Configuration Wizard configures the following:
Federated Delegation. The wizard checks to see if there is an existing federation trust with the MFG for
your organization. If present, the existing federation trust is used to support the hybrid deployment. If
not present, the wizard creates a federation trust for your organization with the MFG. The wizard then
adds the domains that you selected to the federation trust.
Enable Mailbox Replication Service (MRS) proxy. The wizard enables the MRS proxy on all Client Access
servers that were selected in the wizard to enable mailbox moves between your on-premises
organization to Exchange Online and the other way around.
Add <domain>.mail.onmicrosoft.com to accepted domains. The wizard adds a coexistence domain (by
default: <domain>.mail.onmicrosoft.com) to the accepted domains list of your on-premises
organization. This coexistence domain is used for mail flow between your on-premises organization
and your Exchange Online tenant and is added as a secondary proxy domain to any email address
policy of your organization.
Configure secure mail flow between premises. The wizard configures selected Hub Transport servers
and Forefront Online Protection for Exchange on your Office 365 organization for secure mail
routing. It creates or updates existing Send and Receive connectors in your on-premises organization
and Inbound and Outbound connectors in Forefront Online Protection for Exchange . The wizard
allows you to decide if your Exchange Online tenant directly sends the messages to the Internet, or if
it will forward all external messages to your on-premises environment first before these messages are
routed outside your organization.
Using the Hybrid Configuration Wizard, you can manage the following features:
Free/busy sharing. This feature allows viewing free/busy information between on-premises users and
users in Exchange Online.
Mailbox moves. The mailbox move feature allows moving mailboxes from on-premises to Exchange
Online and from Exchange Online to Exchange on-premises. It also preserves the users Microsoft
Office Outlook profiles and offline .ost folders.
Message tracking. This feature allows you to use delivery reports to track messages between on-
premises and Exchange Online.
MailTips. The MailTips feature allows you to retrieve information while composing a message such as
Out-of-Office notification for a user that is currently absent.
Online archiving. This feature allows storing personal archives in your Exchange Online tenant.
Outlook Web App redirection. The Outlook Web App redirection provides a single URL to the users
when their mailbox is moved from on-premises to Exchange Online.
Secure mail. Secure mail enables secure message delivery between the on-premises and cloud
organizations through the TLS protocol. All messages that are transferred between your on-premises
organization and Exchange Online are encrypted and transferred directly without any other server
involvement.
Question: Is it necessary to use the Hybrid Configuration Wizard if you want to configure a
hybrid deployment?
Managing a Hybrid Deployment
A hybrid deployment includes some special management and monitoring requirements due to its
complex configuration that automatically exchanges information between your Exchange on-premises
organization and Exchange Online. The complexity of that configuration is not visible to end users, but
administrators will need to monitor specific areas of the deployment to ensure that it functions properly.
Key areas you need to consider in a hybrid deployment:
Make sure your Directory synchronization tool is reliably running. Directory Synchronization is
the one tool that is required in a hybrid deployment to synchronize your Exchange on-premises
environment with Exchange Online. For example, when you configure a personal archive for a
mailbox that is stored in the cloud, Directory Synchronization synchronizes the mailboxes properties
so Exchange Online recognizes the archive. If Directory Synchronization is not running, then
Exchange Online will not recognize the change and the user will be unable to use their archive.
Office 365 monitors your Directory Synchronization activity automatically and will send a message
to the technical account when Directory Synchronization does not occur for a day.
Use the Exchange Management Console to create and manage mailboxes so that Directory
Synchronization can synchronize them correctly. When you use this tool to synchronize your users,
distribution lists, and contacts, keep in mind that synchronization occurs in one direction onlyfrom
your Exchange on-premises organization to the cloud. For example, if a user is created on-premises,
Directory Synchronization will create it in the cloud; however, if you create a user in the cloud,
Directory Synchronization does not synchronize and create the user in your AD DS.
Monitor message routing between on-premises and cloud. Message routing between Exchange
on-premises and Exchange Online is one of the most important factors for a successful hybrid
deployment. You need to make sure that the messages flow successfully and are not queued
somewhere. For this reason, it is recommended that you monitor the queues in your Exchange
on-premises environment so that you can immediately react if messages are queued for too long.
Use monitoring software to monitor your federated delegation. Federated delegation is the basis for
your information exchange between Exchange on-premises and the cloud. If federated delegation
does not work correctly, your users will not retrieve any free/busy information, MailTips, or other
information between your on-premises and cloud deployments. You should consider testing
federated delegation with your monitoring software as you will then be notified immediately if it
does not work. Also consider the following test cmdlets:
Test-FederationTrust
Test-FederationTrustCertificate
Test-OrganizationRelationship.
Regularly run Microsoft Remote Connectivity Analyzer to verify your configuration. Remote
Connectivity Analyzer is a Microsoft tool that can verify your configuration, such as your Exchange
Web Services (EWS) or your ActiveSync settings, and ensure that all settings are configured properly.
This will prevent issues that you did not recognize previously. Because a hybrid deployment uses
those services to communicate between cloud and on-premises, it is recommended that you run
these test occasionally to verify that the configuration did not change in any way.
Monitor your middle-tier components. A hybrid deployment involves not only Exchange servers but
other components as well, such as firewalls, so you must ensure that these components function
correctly so youre your hybrid deployment works as you expect. Therefore, you should consider
monitoring any middle-tier component that is involved in the deployment. These can include
products such as Microsoft Forefront Threat Management Gateway (TMG), Active Directory
Federation Services (AD FS), and others.
Exchange Online Management Tools
Exchange Online provides several tools to manage your organization. You can choose between Microsoft
Online Services Portal, the Exchange Control Panel, the Exchange Management Shell, and the Exchange
Management Console. Depending on your configuration, you can manage your Exchange Online users by
using the same tools as you use to manage your Exchange on-premises users. The benefit of this type of
configuration is that you do not need to consider where your mailboxes are hosted.
Microsoft Online Services Portal

You can use the Microsoft Online Services portal to manage your Exchange Online mailboxes. You
perform tasks common across the Office 365 services within the portal, and you can follow links to the
Exchange Control Panel, where you can manage settings specific to Exchange Online.
Generally, you use the portal for the following tasks:
Provisioning new mailboxes and security groups.
Managing common user properties.
Creating and managing service requests.
Adding and managing SMTP domains.
Migrating mailboxes.
You can only perform the following tasks in the portal:
Password resets
Cross-premise permissions
Service subscriptions
License assignments
Exchange Control Panel

The Exchange Control Panel in Exchange Online is almost the same as the version available in your
Exchange Server 2010 on-premises installation. It includes new features such as creating mailboxes in your
cloud deployment.
In Exchange Online, the Exchange Control Panel is considered the central management platform for
creating and managing users, distribution groups, and contacts. You also can configure organization-wide
settings such as Unified Messaging IP gateways and Exchange ActiveSync access settings. The Exchange
Control Panel is organized into the following high-level categories:
Users and Groups. Mailboxes, distribution groups, external contacts, and email migration.
Roles. Administrator roles, user roles, and auditing.
Mail Control. Rules, journaling, eDiscovery, and delivery reports.
Phone and Voice. Unified Messaging dialing plans, Unified Messaging gateways, Exchange ActiveSync
access, and Exchange ActiveSync device policy.
As with Exchange Server 2010, administrators can provide access to the Exchange Control Panel features
by using role-based access control (RBAC).
Exchange Management Console

You can add your Exchange Online organization to your Exchange Management Console so that you can
view and manage both on-premises and online configurations from one place. This feature was
introduced with Exchange Server 2010 SP1.
Exchange Management Shell

You can use the Exchange Management Shell with remote PowerShell to connect to Exchange Online,
which allows you to perform management tasks by using cmdlets and scripts.
Exchange Online uses almost the same PowerShell cmdlets as Exchange Server 2010 SP1 or later.
However, some cmdlets and parameters are disabled in Exchange Online because these features do not
apply in the data center environment.
Lesson 3
Implementing Federated Delegation
Federated delegation enables Exchange Server 2010 and Exchange Online users to share availability and
contact information with users in other Exchange organizations. Users can share information such as
free/busy data and calendar details. They can book meetings with a partner organizations users by using
exactly the same steps as booking meetings with users inside the organization.
Describe federated delegation.
Describe the components that are required for federated delegation.
Describe how federated delegation works for availability information access.
Explain how to configure a federated trust.
Explain how to configure organization relationships and sharing policies.

What Is Federated Delegation?
Federated delegation uses standard federation technologies to allow organizations to establish trusted
relationships with each other to share information such as free/busy, MailTips, and multi-mailbox search
between premises or delivery reports.
To establish federation trust, organizations exchange certificates with a trusted federation gateway, and
use those certificates to authenticate and secure all communications between them. Since Exchange
Server 2010 SP1 a self-signed certificate is automatically created and used for the federation trust.
In Exchange Server 2010, you use the Microsoft Federation Gateway (MFG) to establish the federation.
The MFG is an identity service that runs over the Internet and works as a trust broker for Federated
Delegation. To enable federated delegation, the organization must register with the MFG, and then
configure a federated delegation using an organization relationship with another organization that also
registers with the MFG. The organization relationship also includes the type of information that should be
shared, such as free/busy information with details.
The MFG then acts as a hub for all connections that the organizations make to each other. For example, in
a federated delegation scenario, the Client Access servers in each organization should be able to establish
an authenticated and secure connection with each other to enable the exchange of availability
information or to enable calendar sharing. The Client Access servers use the federated trust that you
configure with the MFG to verify the other organizations Client Access servers and to encrypt all traffic
sent between the organizations.
Note The MFG only provides a broker service to establish the communication between
the organizations. The MFG does not authenticate individual users or require any user
accounts from either organization. Although the MFG uses Windows Live as the
authentication mechanism, it shares no user accounts with Windows Live.
In a federation delegation scenario, each organization only needs to manage its user accounts and its
trust relationship with the MFG. After the organization establishes the trust relationship with the MFG, you
can configure other trusted organizations with which you want to share information, and the types of
information that you want to share.
When you enable federation delegation, the communications between organizations are sent through the
organizations Client Access servers. This communication is transparent to the messaging clients. This
means that the feature works with any client that can connect to Exchange Server 2010, including Outlook
Web App, Microsoft Office Outlook 2007, and Outlook 2010.
Note Outlook 2007 requires GAL synchronization between Exchange organizations

because Outlook 2007 clients need to pick a recipient from the GAL. Refer to
http://go.microsoft.com/fwlink/?LinkId=213773 for more information.
Components Required for Federated Delegation
To set up federated delegation, you must configure three major components in Exchange Server 2010.
Federation Trust
Federation trust establishes a trust with MFG. The federation trust configures the MFG as a federation
partner with the Exchange Server organization. This means that Exchange Web Services on the Client
Access servers can validate all MFG authentication requests. You establish the federation trust by
submitting the organizations certificate to Microsoft Federation Gateway and downloading the MFG
certificate.
Organization Identifier
The organization identifier defines which of the Exchange organizations authoritative accepted domains
are available for federation. If an organization supports multiple SMTP domains, you can include one or
all of the domain names in the organization identifier. Users can participate in federated delegation only if
they have email addresses in the domains that you configure with the organization identifier.
The first domain that you specify with the organization identifier is the Account namespace. MFG creates
federated user identifiers within this account namespace when the Client Access server requests a
delegation token for an Exchange Server organization user. This process is transparent to the Exchange
Server organization.
Organization Relationships
An organization relationship allows you to establish a federated delegation with another federated
organization for the purpose of sharing availability (free/busy), MailTips, or other information.
Organization relationships are one-to-one relationships established between two organizations. They
apply automatically to all users in that organization. To configure an organization relationship, you must
establish federation trust with the Microsoft Federation Gateway and configure the organization identifier.
When you create an organization relationship with an external organization, it allows users in the external
organization to access your users information, such as availability information. This enables users in the
external organization to easily schedule meetings with your users. No replication of GAL information is
required because Outlook 2010 and Outlook Web App allow users to enter the SMTP address of an
external recipient when scheduling meetings. For Outlook 2007, you still need to configure GAL
replication. For users in your organization to have similar access to availability information as users in the
external organization, the administrator in the external organization must also create an organization
relationship with your organization.
Sharing Relationships
As an alternative to an organization relationship, you can also use sharing policies to enable users to share
calendar and contact information with users in external federated organizations. After configuring the
sharing relationship, a user can send a sharing invitation to an external recipient to share his/her calendar
or contact folder. Using sharing policies, you control the domains with which your users share
information, and the extent of sharing. You can also disable a sharing policy for a user or a group of users
to deny sharing for those users.
Sharing policies are assigned to mailbox users. A default sharing policy applies to all users, and it
allows you to share contacts, calendar, and availability information with all domains. After you create a
federation trust with the MFG and configure the federated organization identifier (OrgID), users can send
sharing invitations to users in any external organization.
Note Although organization relationships and sharing policies allow sharing of availability
information with external users, they are intended for different scenarios. Organization
relationships are created to collaborate with external organizations. Sharing policies govern
what your users can share on an ad-hoc basis with users in external organizations, including
organizations with which an organization relationship does not exist.
How Federation Delegation Works for Exchange Online
Federated delegation is also used to share information between the Exchange on-premises organization
and Exchange Online. When you configure the organization relationship on both sides, users are allowed
to view availability information, MailTips, and track messages by using delivery reports.
The following steps describe the communication flow when an on-premises user invites a user that is
hosted on Exchange Online to a meeting.
1. A user in the Contoso.com organization invites an Exchange Online user to a meeting. This meeting
request is sent to the Exchange Web Service on the Client Access server at Contoso, Ltd.
2. The Contoso Client Access server checks with a Contoso.com domain controller to verify that the user
has permission to utilize the organization relationship to request availability information and that an
organization relationship is configured with Exchange Online. If both verifications succeed, the Client
Access server continues with the next step.
3. The Contoso Client Access server connects to the MFG and requests a security token for the Contoso
user. Because you configure Contoso.com in the organization identifier, the MFG issues the token.
4. The Contoso Client Access server sends a request for the users availability information to the
Exchange Online Client Access server. The request uses the Autodiscovery endpoint entry that is
configured in the organization relationship to contact the remote server and also includes the security
token with the request.
5. The Exchange Online Client Access server validates the security token and then checks with a domain
controller in Exchange Online to verify that the organization has an organization relationship with
Contoso.com.
6. The Exchange Online Client Access server retrieves the users availability information from the users
Mailbox server.
7. The Exchange Online Client Access server sends the availability information to the Contoso Client
Access server.
8. The Contoso Client Access server provides the availability information to the Contoso, Ltd user.
Question: In your organization, what connectivity do you need to consider between

Microsoft Federation Gateway and Exchange Online?
Configuring a Federation Trust
Before you can configure an organization relationship with another organization, both organizations must
configure a federation trust with the MFG.
Prerequisites for Configuring a Federation Trust

Before configuring the federation trust, you must ensure that your organization meets the following
prerequisites:
Obtain a trusted certificate. Setting up a federation trust with the MFG does not require a certificate
from a public certificate authority (CA). In Exchange Server 2010 SP1, a self-signed certificate is
created automatically when you create a federation trust. However, you require a trusted certificate
so that Exchange Online can communicate with your Client Access server. The certificate requires a
private/public key pair that is both a client and server certificate, and a Subject Key Identifier. This
certificate must be deployed on all Exchange Server 2010 Client Access servers.
Note As a best practice, you should use the Microsoft Remote Connectivity Analyzer
available at http://go.microsoft.com/fwlink/?LinkId=248382 to verify that Microsoft trusts
the certificates you installed on your Client Access servers.
Configure the authoritative domains. You must configure all SMTP domain names that you want to
use for federated delegation as authoritative accepted domains in Exchange Server.
Configure external DNS records. To enable federated delegation, you need to ensure that servers
from other organizations can resolve your servers names on the Internet. Additionally, you need to
configure DNS with a text (TXT) resource record that provides proof-of-ownership for your domain
name. The MFG uses the proof-of-ownership record to ensure that your servers are authoritative for
the domain name that you provide.
Perform the following steps to create this proof-of-ownership record:
1. Obtain the application identifier that is created when you create a federation trust. You can
obtain this identifier by running the Get-FederationTrust Identity FederationTrustName | fl
ApplicationIdentifier cmdlet.
2. Create a new TXT record on the DNS server that is accessible from the Internet. The TXT record
should include the following information:
domainname IN TXT AppID=ApplicationIdentifier.
Establishing the Federation Trust with Microsoft Federation Gateway

You can set up and manage the federation trust by using the Exchange Management Console or
the Exchange Management Shell. On the machine where you run these tasks, you should deploy the
certificate you want to use. The machine also needs to have Internet connectivity either direct or through
an Internet proxy to reach MFG.
If you are using the Exchange Management Console, click Organization Configuration, and then click
New Federation Trust to start the New Federation Trust wizard. When you run the wizard, you must
configure a certificate that will validate the trust. When you use the Exchange Management Console to
create the federation trust, it receives the name Microsoft Federation Gateway automatically.
If you are using the Exchange Management Shell, run the New-FederationTrust Name TrustName -
Thumbprint <org-cert-thumbprint> cmdlet.
Configuring Relationships and Sharing Policies in Organizations
After you create the federated trust, the next steps to create a federated delegation are to configure
the organization relationships and sharing policies that will enable your organizations users to share
information with other organizations.
Configuring Organization Relationships

Organization relationships define the external domains with which you want to share information, and
what types of information you will share. An organization relationship can be viewed as a permission to
access certain types of information in your organization based on one or more domain names.
To configure organization relationships in the Exchange Management Console, click Organization

Management, and then click New OrganizationRelationship. When configuring the organization
relationship, you can configure the following:
Name. Use a descriptive name.
Enable or disable the organization relationship.
Enable the sharing of free/busy information. If you enable this option, you can configure the
following levels of free/busy access:
No calendar sharing.
Calendar sharing with free/busy information only.
Calendar sharing with free/busy information, plus subject and location.
Specify a security distribution group. If you specify this option, the free/busy information only for
users in the group is accessible through the organization relationship.
Configure the information for the external organization. At a minimum, you must enter the domain
name of the external organization. If you want to add your Exchange Online tenant, just use your
<domain>.onmicrosoft.com name. Alternatively, you can enter the external organizations
information manually, including the domain names, application Uniform Resource Identifier (URI),
and Autodiscover endpoint.
Additional configuration settings are available by using Exchange Management Shell. For example,
you can configure the organization relationship to allow or disallow MailTips and message tracking
based on delivery reports.
Configuring Sharing Policies

Sharing policies define which users in your organization can share information with other organizations,
and what types of information those users can share.
The Default Sharing Policy is created automatically when you install Exchange Server 2010. This policy
enables sharing with all domains, but enables only calendar sharing with free/busy information. The policy
is not assigned to mailboxes. You can modify all settings for the Default Sharing Policy.
If you want to enable users to participate in federated sharing, you can add the mailboxes to the Default
Sharing Policy or create a new sharing policy. When you create a new sharing policy, you can configure
the following:
The domain name for the external domain.

The sharing actions that are permitted under the policy. Options include:
Calendar sharing with free/busy information only.
Calendar sharing with free/busy, subject and location.

Calendar sharing with free/busy, subject, location, and body.
Contacts sharing.
Calendar sharing with free/busy information only and contacts sharing.
Calendar sharing with free/busy, subject and location, and contacts sharing.
Calendar sharing with free/busy, subject, location and body, and contacts sharing.
The mailboxes to which the sharing policy will be assigned.
Question: In your organization, what factors should you consider when defining your
sharing policy?
Review Questions
1. What Exchange Online Deployment Options do you have?
2. What additional functionality will Forefront Online Protection for Exchange provide to your
company?
3. What functionality does Federated Delegation provide?
4. When planning a hybrid deployment for your organization, what components do you need to
consider implementing and what is their purpose?
5. You created a new mailbox in Office 365 and now your on-premises users complain that they cannot
see the new mailbox? What can you do?
Common Issues Related to a Hybrid Deployment

Identify the causes for the following common issues related to a hybrid deployment.
Free/busy information is not available for

mailboxes in the cloud when accessing the
information of mailboxes that are stored on-
premises.
Moving mailbox between Exchange Online and

on-premises fails.
Tools
The following tools can be used to monitor and test a hybrid deployment.
Microsoft Remote Troubleshooting of your on- http://go.microsoft.com/fwlink

Connectivity Analyzer premises single-sign-on, /?LinkId=248382
ActiveSync, or EWS.
Test-FederationTrust Make sure the federation trust is Exchange Management Shell

working correctly.
Start-OnlineCoexistenceSync Start a manual Directory Microsoft Online Directory Sync Shell

Synchronization to synchronize
your AD DS with Office 365
immediately.
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
Implementing Unified Messaging
Contents:
Lesson 1: Overview of Telephony A-3
Lesson 2: Introducing Unified Messaging A-12
Lesson 3: Configuring Unified Messaging A-29

Lab: Implementing Unified Messaging A-42
A-2 Implementing Unified Messaging
Appendix Overview
Unified Messaging combines voice and email messaging into one location, accessible from a telephone
and a computer. Microsoft Exchange Server 2010 Unified Messaging integrates Exchange Server with
telephony networks and makes the Unified Messaging features available in the user mailbox. This module
describes how Unified Messaging works with your telephony system and Exchange Server environment,
and how to configure Unified Messaging.
Describe telephony systems.
Describe Unified Messaging features and integration with Exchange Server 2010.
Configure Unified Messaging.

10135B: Configuring, Managing, and Troubleshooting Microsoft Exchange Server 2010 Service Pack 2 A-3
Lesson 1
Overview of Telephony
Unified Messaging enables you to integrate telephony systems with Exchange Server 2010. You must have
an understanding of core telephony concepts to understand how Unified Messaging works and how to
implement it.
In this lesson, you will learn the basics about a telephony system and what protocols Unified Messaging
provides.
Describe types of telephone systems.
Describe telephony-system components.
Describe types of Private Branch Exchange (PBX) phone systems.
Describe Voice over IP (VoIP) gateway.
Describe Unified Messaging protocols.

Types of Telephone Systems
There are three general types of business telephone systems: Centrex, Key Telephone System, and PBX.
You can integrate each of these phone systems with Unified Messaging.
Centrex Phone System

Phone companies lease a Centrex phone system (also known as Central Office Telephone Exchange) to
businesses. The Centrex phone system uses the phone companys central office (CO) exchange to route
internal calls to an extension.
When an organization leases a Centrex phone system, the organization leases connections to the phone
companys CO. These connections can be multiple analog telephone lines or a single T1-circuit that has a
demultiplexer at the customer site that supports analog phones.
With Centrex, the telephone companys CO provides all telephone switching. For example, when an
external caller calls a user in the office, the CO switches the call and sends it along an available line to the
users internal extension number. If a user inside the office calls another internal user by using the internal
extension, the exchange routes the call to the CO and then back to the correct phone extension.
A new Centrex version, called IP Centrex, is available. With IP Centrex, the organization does not rent
phone lines from the telephone companys CO. Instead, the CO sends the phone calls through a VoIP
gateway, which routes them through the Internet. At the organizations office, another VoIP gateway
translates the call to a traditional circuit-switched call.
Key Telephone System

A Key Telephone System is similar to the Centrex system in that the organization leases several phone
lines from the telephone companys CO. However, with the Key Telephone System, each phone line
connects to multiple telephones in the organization. When someone calls the company, all phones ring
that are associated with that line. Businesses with Key Telephone Systems often arrange for someone to
answer incoming calls, and then announce the call to the correct recipient.
PBX Business Phone Systems

PBX systems are different from Centrex or Key Telephone Systems in that they typically have only a single
connection to the CO, and all call switching happens on the organizations premises. The connection to
the CO usually occurs through a T1 or E1 line, both of which provide multiple channels to enable multiple
calls over the same line. T1 or E1 lines with multiple channels also are known as trunk lines.
The PBX routes internal phone calls, and calls between external and internal users. In a PBX system, each
user has a telephone extension. When an internal user places a call to another internal user, they use just
the extension number, and the PBX routes the call to the appropriate extension.
Users make external telephone calls through a PBX by dialing a number like 9 or 0, and then the external
number. You can configure the external access number on the PBX, which automatically selects an
outgoing trunk line to complete the call. The PBX accepts incoming calls and automatically forwards them
to the appropriate organizational extension.
In larger organizations, PBXs make it possible for users to reach other users in different locations just by
dialing an extension number. This may involve networking multiple PBXs.
Components of a Telephony System
Telephony administrators use specialized terminology to describe many of the features and concepts that
relate to PBXs. When deploying Unified Messaging servers, you need to understand these terms and how
they relate to Unified Messaging.
Direct Inward Dialing

A Direct Inward Dialing (DID) phone number is a unique number that an organization assigns to a person.
It lets that individual receive calls directly from an external phone without having to transfer the call. The
DID is a combination of company-specific phone number and the users extension. If the organization has
implemented a PBX, the PBX uses a mapping of DID numbers to internal extensions to route calls to the
correct phone. Exchange Server Unified Messaging does not require DID use, but you can improve callers
experiences by using it. If you use DID numbers, outside callers hear a personalized greeting when the
person they are calling either is on the phone or does not answer it. Without DID numbers, the call first
goes to an automated attendant (or a receptionist), and the caller can select the person they are calling
using either the telephone keypad or speech inputs. Then, as a second step, the call is sent to the
extension, where the caller hears a personalized greeting for the person he or she called.
Dial Plan
A dial plan consists of the rules that a PBX uses to determine what action to take when it receives a set
of dialed numbers. For example, a 9 often triggers call setup to an outside line so that users can call
external phone numbers. When 9 is not the first number, the PBX needs to know how many numbers to
collect before taking action. If internal extension numbers are three digits long, it waits for just three
numbers before taking action.
Within a dial plan, each individual receives a unique extension number in this range. Users within a given
dial plan can dial an extension number to reach all others in the plan. The dial plan can span multiple
PBXs, so users only have to dial an extension to reach other users, even though they are on different PBXs.
Exchange Server Unified Messaging utilizes certain dial-plan information, such as an extensions
number of digits. In Unified Messaging, the specific dial plan, plus the extension number, provides each
subscribers unique user identifier. This unique identifier enables routing the message to the correct
Exchange server mailbox.
Hunt Group
A hunt group is a collection of extensions. In most cases, a hunt group represents a set of identical
resources that an application or a group shares. This provides more efficient access to applications, like
voice mail, an auto attendant, or even a call center, so that callers do not experience a busy signal.
Instead, the PBX hunts for an open line to which to connect them.
Hunt groups also distribute calls to business groups that have identically capable endpoints, like telesales
or support. By sharing the resource, hunt groups can find open channels so that callers receive busy
signals less often.
You can implement a hunt group between the PBX and the VoIP gateway when you need a VoIP gateway
for Unified Messaging. This hunt group accesses Unified Messaging. Additionally, it is the target for
diverted calls for an automated attendant, or after an unanswered phone call or busy signal.
Pilot Number
A pilot number is the address or label that the PBX uses to identify a hunt group. It is an unused
extension, meaning it is not associated with a person or phone.
For example, there may be a specific extension number 3900 for the telesales team, which may be the
pilot number for the hunt group of telesales extension numbers. When a call comes into the 3900 sales
number, the PBX recognizes it as a pilot number and searches for an available line within the sales hunt
group. The PBX then delivers the call to an available sales extension number.
When you use the PBX with Unified Messaging, it uses a pilot number to target a diverted call to the
Unified Messaging server so that the caller can leave a message. Subscribers use a pilot number to access
messages that their Exchange server mailboxes store. Additionally, each Unified Messaging auto attendant
uses a pilot number.
Coverage Path
A PBX uses a set of directions that you configure for each extension, and it tells the PBX where to route
unanswered calls and calls that receive busy signals. The set of directions is a coverage path. If a DID call
arrives at the Unified Messaging server via a users desktop phone, and the line is busy or not answered
within a certain number of rings, the PBX knows to send the call to the pilot number for the hunt group
that attaches to the VoIP gateway. The PBX routes the call through the VoIP gateway to the Unified
Messaging server, where the caller can record a voice message. The Unified Messaging server sends the
voice message to the Unified Messaging users mailbox.
Call Transfer
Users transfer calls routinely from one extension to another. An unsupervised transfer occurs when a user
transfers a call to the next extension without determining whether the extensions user answers the call.
For example, consider when a user transfers a call to voice mail when a phone is not answered or is busy.
Unified Messaging uses unsupervised transfers. For example, if the auto attendant transfers a call, or if a
Unified Messaging subscriber uses Unified Messaging to call another subscriber, it sends the call to the
appropriate extension by using an unsupervised transfer.
Types of PBXs
The PBX system is the most common type that medium- and large-size organizations use. There are
several types of PBX systems available.
Analog PBX
Analog PBX systems send voice and signaling information, like the touch tones of dialed phone numbers,
as actual analog sound. Analog PBX systems never digitize the sound. To direct the call, the PBX and the
phone companys CO listens for the signaling information.
Digital PBX
Digital PBXs encode analog sound into a digital format. They typically encode the voice by using a
standard industry audio codec, G.711. Once digital PBXs encode the sound, they send the digitized voice
on a channel by using circuit switching.
The process of circuit switching establishes an end-to-end, open connection, and leaves the channel open
for the calls duration and for only the calls users. Some PBX manufacturers have proprietary signaling
methods for call setup.
IP PBX
IP PBXs carry voice-over data networks. The IP phone contains a network adaptor, so it is part of the
network. The phone converts voice into digitized packets, which it then places on the data network. The
network sends the voice packets by using packet switching, a technique that enables a single network
channel to handle multiple calls.
The IP PBX also acts as a gateway between the internal packet-switched network and the external circuit-
switched networks that telephone companies use. In this situation, external phone calls arrive at the IP
PBX on the normal public phone lines, and the IP PBX converts the phone call to packets sent on the
internal IP-based network.
Hybrid PBX
Hybrid PBXs provide both digital and IP PBX capabilities. This hybrid approach enables a customer to run
a mixture of digital and IP-based phones. Most modern PBXs are in this hybrid category.
What Is a VoIP Gateway?
Telephony and computer systems traditionally use different types of networks to enable communication
between attached devices. A telephony system typically uses a circuit-switching network, while the
computer system traditionally uses a packet-switching network. You may need to deploy a VoIP gateway
to translate data between a circuit-switched network and the data-switched network.
Circuit-Switched Networks
A circuit-switched network uses a dedicated connection between two network devices. For example, you
pick up the telephone receiver and dial a phone number. By answering the call, the recipient completes
the circuit. After the two nodes establish a call between them, only these two nodes may use the
connection. When one of the nodes ends the call, this cancels the connection.
Circuit-switched networks, such as the Public Switched Telephone Network (PSTN), transmit multiple calls
across the same transmission medium. Frequently, the medium that a PSTN uses is copper. However, it
also may use fiber optic cable.
There are two basic types of circuit-switched networks: analog and digital. Analog typically is for voice
transmission. For many years, the PSTN was analog only. However, circuit-based networks like PSTN
are transitioning from analog to digital. To support an analog voice-transmission signal over a digital
network, the analog transmission signal must be encoded or converted into a digital format before it
enters the telephony wide area network (WAN). On the connections receiving end, the digital signal must
be decoded or converted into analog signal format.
Packet-Switched Networks
Packet switching is a technique that divides a data message into smaller units, known as packets. The
network sends the packets to their destination by the best route available, and then reassembles them at
the receiving end.
In packet-switched networks, such as the Internet, hosts route packets to their destination through the
most expedient route. However, not all packets traveling between two hosts travel the same route, even if
they are from a single message. This almost guarantees that the packets will arrive at different times and
out of order. The IP and TCP protocols are designed to guarantee delivery of the packets and to ensure
that the packets are provided to the application in the correct order. A packet-switched network routes
packets individually between nodes over data links that other nodes may share. With packet switching,
unlike circuit switching, multiple connections to nodes on the network share the available bandwidth.
VoIP
VoIP is a technology that enables an IP-based network to act as the transmission medium for telephone
calls. It sends voice data in IP packets rather than by circuit-switched telephone lines. Translating a call
from a circuit-switched network to a packet-switched network is complicated because the underlying
network connections are so different.
VoIP Gateway
A VoIP gateway is a third-party hardware device or product that converts traditional phone-system or
circuit-switching protocols into data-networking or packet-switched protocols. The VoIP gateway
connects a telephone network with a data network.
Unified Messaging servers can connect only to packet-switched data networks. This means that
organizations with a traditional PBX must deploy a VoIP gateway to communicate between the PBX and
the Unified Messaging server.
The following table lists the types of telephony systems, and explains when a VoIP gateway is required.
Types of telephony system VoIP gateway requirement
Traditional Centrex VOIP gateway required
IP Centrex VOIP gateway may not be required
Key Telephone System VOIP gateway required, and some systems are not supported
Traditional PBX VOIP gateway required
IP or hybrid PBX VOIP gateway may not be required
Note For a list of VoIP gateways and IP/PBX systems that Unified Messaging supports, see
the Telephony Advisor for Exchange 2010 website.
Lesson 2
Introducing Unified Messaging
Unified Messaging enables users to receive email, voice, and fax services in their Exchange Server
inbox, and allows users to access mailbox contents by phone. This simplifies the experience for users,
because they must access and manage only one location for all message types. This also provides more
functionality for users because they can use traditional messaging clients to access voice or fax messages,
and they can use telephone technology to access email messages. Unified Messaging also simplifies
administrators workloads because they must manage this data in one location only.
This lesson introduces the features and requirements for Exchange Server 2010 Unified Messaging.
Describe Unified Messaging.
Describe Unified Messaging communication.
Describe server communications for Unified Messaging.
Describe Unified Messaging call-answering features.
Describe Microsoft Office Outlook Voice Access features.
Describe how Unified Messaging works with a VoIP gateway.
Describe the new Unified Messaging features in Exchange Server 2010 Service Pack 1 (SP1).
Integrate Unified Messaging with Lync Server 2010.
Describe international Unified Messaging requirements.

What Is Unified Messaging?
Unified Messaging provides the convergence of voice and email messaging into one store, accessible from
a phone, a computer running an email client, and mobile devices.
Most users and information technology (IT) departments manage their voice mail separately from their
email. Usually, voice messages and email exist as separate inboxes on separate servers, and users access
them with different clients. Frequently, each communication tool requires a separate address list, which
can make it difficult to keep all address lists synchronized. Unified Messaging brings these tools together,
and it offers an integrated store and user experience for all Exchange Server message types.
Unified Messaging Features

Unified Messaging provides the following core features:
Call answering. Call answering enables the system to answer the telephone and record a message
when the user is unavailable. Unified Messaging then delivers the voice message as a message
attachment to the users mailbox, where the user can access the message by using his or her
computer with Microsoft Office Outlook, Microsoft Outlook Web App, or Microsoft Exchange
ActiveSync, or by phone, using Outlook Voice Access.
Outlook Voice Access. Exchange Server Unified Messaging provides users with full access to their
Exchange Server mailbox from any phone. Outlook Voice Access enables users to use the phone to
retrieve their email, voice mail, calendar, and personal contacts. They also can compose messages,
and reply to or forward messages, and they can accept or decline meeting requests. Outlook Voice
Access provides some enhanced features, such as a simple but useful feature that sends an Ill
be late message to everyone invited to a specific meeting. Outlook Voice Access users can use
automatic speech recognition (ASR) or dual-tone multifrequency (DTMF) to choose options and
perform actions when connected to the mailbox.
Play on Phone. This feature lets a Unified Messaging-enabled user listen to a voice message using
a telephone instead of playing the message over his or her computer speakers or headphone. If
the user receives a voicemail, and the user is in a location that is not private or the voice message
is confidential, he or she likely will not want to play the voice message through the computer. The
Play on Phone feature enables the user to access the message in Office Outlook or Outlook Web App,
and then instruct the Unified Messaging server to call a phone number. When the user answers the
phone, the voice message plays.
Voicemail preview. The Unified Messaging role uses Automatic Speech Recognition (ASR) on newly
created voice messages. When users receive voice mails, they receive messages that contain the voice
recordings and clear text that Unified Messaging creates from recordings.
Protected voice mail. Unified Messaging provides this functionality so that users can send private mail,
which Microsoft Rights Management Services (RMS) protects. However, Unified Messaging restricts
users to only forwarding, copying, or extracting the voice file from mail. This functionality increases
Unified Messaging confidentiality, and users can rely on Unified Messaging if they want to limit their
audience.
Call-answering rules (Personal Auto Attendant). The Unified Messaging role allows Unified Messaging-
enabled users to create and customize call-answering rules to enhance their callers call-answering
experience.
Unified Messaging Protocols
There are a number of voice-related, IP-based protocols. A Unified Messaging environment with Exchange
Server 2010 uses the following:
Session Initiation Protocol (SIP). SIP is a real-time signaling protocol that creates, manipulates, and
tears down interactive communication sessions on an IP network. You can use SIP in conjunction
with Transport Layer Security (TLS) to provide security. Exchange Server Unified Messaging uses SIP
mapped over Transmission Control Protocol (TCP) and supports TLS for secured SIP environments.
SIP clients, such as IP/VoIP gateways and IP/PBXs, can use TCP port 5060 or port 5061 (for Secure SIP)
to connect to SIP servers.
Real-Time Transport Protocol (RTP). RTP is for voice transport between the IP gateway and the Unified
Messaging server. RTP provides high-quality, real-time, streaming voice delivery. One of the issues
with sending voice messages over an IP network is that voice requires real-time transport, with
specific quality requirements to ensure that the voice sounds normal. If the protocol uses large
packets, listeners must wait for the entire packet to arrive before they can respond. Any delay in
packet delivery can produce undesirable periods of midstream silence. Packet loss can cause voice
garbling.
For More Information Request for Comment (RFC) 3550 (which updates RFC 1889)
describes RTP, while RFC 3261 (which updates RFC 2543) describes SIP.
Real-Time Facsimile or T.38. Real-Time Facsimile or T.38 is an Internet fax-transport protocol. T.38
sets procedures for fax transmission when a portion of the path includes an IP network. The Unified
Messaging system uses it to relay a fax that a user originally sends, via voice line across an IP network,
in real time.
Overview of Unified Messaging Communications
Unified Messaging combines voice and email messaging in the Exchange Server store, and it integrates
telephony networks into Exchange Server 2010.
Phone calls enter the organization through an IP PBX or a legacy PBX. Legacy PBX needs a Unified
Messaging IP Gateway to talk to a Unified Messaging protocol, such as SIP, whereas most of the IP PBX
already supports this feature.
The Unified Messaging role communicates with the regular phones or PSTN by using the PBX. The public
telephone network that connects to the PBX communicates by using Time Division Multiplex (TDM). TDM
is a technique of transmitting multiple digitized data, voice, and video signals simultaneously over one
communication media. It does this by interleaving pulses representing bits from different channels or time
slots.
Unified Messaging handles all internal communications, as follows:
It connects to Active Directory Domain Services (AD DS) by using Lightweight Directory Access
Protocol (LDAP).
It connects to the Mailbox server by using Messaging Application Programming Interface (MAPI).
It accepts requests from that Client Access server as RPC.

In the case of OCS 2007 integration, it accepts SIP request from the OCS server for missed call
notifications.
As usual, any Exchange Server client computer that is running Outlook 2007, Outlook 2010, or Outlook
Web App communicates to the Client Access server role. In Exchange Server 2010, Outlook 2007 and
Outlook 2010 access the Client Access server for Unified Messaging release Web-services requests.
However, there is no separate Unified Messaging virtual directory as there was in Exchange Server 2007.
Server Communications for Unified Messaging
To install Unified Messaging servers, you also must have the Mailbox, Hub Transport, and Client Access
server roles installed in the same Active Directory site. The Unified Messaging servers cannot provide full
functionality unless they can communicate with all of these server roles.
Unified Messaging Server Communication with Domain Controllers

The Unified Messaging server performs AD DS directory lookups for recipient information. You must add
each Unified Messaging-enabled user to a dial plan and then assign each user an extension number in
AD DS. This provides the user mailbox with a unique identifier.
The Unified Messaging server performs AD DS directory lookups in several different scenarios, including:
Locating the Mailbox server that hosts the user mailbox so that the Unified Messaging server can
send voice messages or faxes to the mailbox, or extracting the users personal greeting from the
Mailbox server.
Locating users prerecorded spoken names from AD DS.
Locating subscriber extensions and other attributes, such as department names or email addresses,
when users call the auto attendant.
Unified Messaging Server Communication with Other Server Roles

The Unified Messaging server communicates with the following Exchange Server 2010 server roles, except
the Edge Transport server role:
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 through 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 server role. 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 by using
Simple Mail Transfer Protocol (SMTP).
Client Access server role. 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 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.
Call-Answering Features of Unified Messaging
Call handling describes how an Exchange Server 2010 Unified Messaging server answers and handles
incoming calls. The Unified Messaging server can handle a variety of incoming calls.
Voice Calls
The Unified Messaging server uses voice-call handling when an internal or external user leaves a voice
message for Exchange Server 2010 Unified Messaging system user. The Unified Messaging server creates
Multipurpose Internet Mail Extensions (MIME) messages from incoming calls, and then submits them to a
Hub Transport server by using SMTP. The Hub Transport server submits the message to the users Mailbox
server. The Unified Messaging server always uses SMTP to send voice messages, even if the mailbox
resides on the same computer on which you install the Unified Messaging server role.
Outlook Voice Access

To access their Exchange Server 2010 mailbox by using Outlook Voice Access, users must dial a subscriber
access number that is on a Unified Messaging dial plan. A dial plan consists of the rules that a PBX uses to
determine what action to take when it receives a set of dialed numbers. A welcome message and a series
of telephone user-interface voice prompts enable the user to listen to messages in the mailbox or
manipulate mailbox contents. These voice prompts help the user navigate and interact with the Unified
Messaging system by using touch-tone or speech inputs.
Unified Messaging Auto Attendants

When anonymous or unauthenticated users call into an organization, voice prompts assist them in placing
calls to Unified Messaging-enabled users. Additionally, when you want to make an internal call, Unified
Messaging automatically places the call when you say the persons name that you are calling. Unified
Messaging auto attendant is a series of voice prompts comprised of WAV files that callers hear instead of
a human operator. The Unified Messaging auto attendant lets callers navigate the menu system, place
calls, or locate users by using DTMF or voice inputs.
When you configure a Unified Messaging auto attendant, you can create custom WAV files and replace
the default prompts to meet your organizations needs.
Outlook Voice Access Features
Outlook Voice Access enables Unified Messaging users to access their Exchange Server 2010 mailbox by
using mobile devices or an analog, digital, or wireless telephone.
What Users Can Do with Outlook Voice Access

When accessing their Exchange Server 2010 mailbox, users can:
Listen to new and saved email and voicemail messages.
Forward, reply, save, and delete email and voice messages.
Interact with their calendars, including:
Listening to daily calendar appointments and meeting details.
Accepting or declining meeting requests.
Sending an Ill be late message to meeting participants.
Reply to meeting requests by using voice inputs to send messages to meeting participants.
Decline or cancel meetings.
Interact with their global address list (GAL) and their personal contact list. These interactions can
include:
Locating a person in the GAL or personal contact list.
Inputting a telephone extension number to leave a message.
Sending voice messages.
Change their PIN, spoken name, or greetings.
Outlook Voice Access is central to the Unified Messaging infrastructure because it allows users to access
their mailboxes through universally accessible telephones.
How Unified Messaging Works with a VoIP Gateway
The following steps describe the communication flow for an organizations incoming phone calls when it
deploys Exchange Server 2010 Unified Messaging:
1. A caller dials a users number in the organization. This caller could be inside or outside the
organization. Unified Messaging connects the call to the PBX. The PBX uses the call recipients
extension number to route the call to the appropriate desk phone, which then rings. If the recipient
does not answer the call, the PBX checks its configuration to see where to route the unanswered call.
In this case, the PBX routes the unanswered calls for this phone to the number associated with the
VoIP gateway.
2. The VoIP gateway converts the circuit-switched protocols to packet-switched protocols. It uses the
information about the Exchange Server Unified Messaging environment, which you configure during
the VoIP gateway installation, to route the call to the appropriate Unified Messaging server. The
Unified Messaging server receives the now VoIP-based, packet-switched call.
3. The Unified Messaging server contacts AD DS to retrieve the recipient information. This AD DS
lookup occurs by using the combination of dial plan plus extension number, which provides a unique
identifier for each mailbox. The Unified Messaging server uses this information to contact the users
mailbox to play the individuals greeting. Then the Unified Messaging server answers the call and
captures the voice message.
4. The Unified Messaging server packages the message into a voice message for Exchange Server. It
then uses SMTP to route the message to a Hub Transport server in the same site. The Hub Transport
server routes the voice message to the users Exchange Server mailbox, where it is stored. The
message is accessible to the Unified Messaging subscriber through Outlook Voice Access, Outlook,
Outlook Web App, or Exchange ActiveSync.
These steps describe the communication flow when Exchange Server 2010 Unified Messaging answers a
call. The process is similar when you use other systems, such as Outlook Voice Access or auto attendant
access. For example, when using Outlook Voice Access, the user calls a number that you configure the
PBX to forward automatically to the VoIP gateway. The gateway then forwards the call to the Unified
Messaging server, which checks AD DS for the user mailbox location. It then uses MAPI to connect to
the appropriate Mailbox server. When you use an auto attendant, the PBX forwards the phone number
through the VoIP gateway to the Unified Messaging server, which locates the requested information in
AD DS and Active Directory.
Exchange Server 2010 SP1 Changes Supporting Unified Messaging
The Unified Messaging server role has been improved in Exchange Server 2010 SP1, with new
features added. This section describes the differences between Exchange Server 2010 RTM and
Exchange Server 2010 SP1 Unified Messaging.
Exchange Control Panel (ECP) Improvements

One of the new Unified Messaging related features in Exchange 2010 SP1 is the new functionality that is
available in the ECP. The following new options are provided:
Creating and configuring Unified Messaging Objects in the ECP. With Exchange 2010 SP1, you can
now manage all UM components in the ECP when Exchange is deployed in multi-tenant deployment.
In this configuration, you can create UM dial plans, UM mailbox policies, UM IP gateways, and UM
auto attendants, and enable users for UM without any Exchange management tools installed.
Unified Messaging reporting feature additions. The Unified Messaging reporting features added in
Exchange Server 2010 SP1 include call summaries and statistics and call details for Unified Messaging
-enabled users. These reports are displayed in the Exchange Control Panel.
Unified Messaging Dial Plan Improvements

A second enhancement in Exchange 2010 SP1 relates to the following new features with Unified
Messaging dial plans:
Unified Messaging Dial Plan Wizard and Set-UMServer addition. When deploying Unified Messaging
in Exchange Server 2010, you had to add or associate a Unified Messaging server with a Unified
Messaging dial plan after you created the dial plan. In SP1, you can add or associate a Unified
Messaging server with a Unified Messaging dial plan when you create a Unified Messaging dial plan.
An additional page has been added to the New Unified Messaging Dial Plan wizard that lets you add
a Unified Messaging server to the dial plan.
Secondary Unified Messaging dial-plan addition. In Exchange Server 2010 SP1, you can add a
secondary Unified Messaging dial plan for a Unified Messaging-enabled user. Secondary dial plans
allow administrators to assign two extension numbers to a Unified Messaging-enabled user.
Deployment and Migration Improvements

Exchange Server 2010 SP1 provides the following support for Lync Server 2010 deployment and
migration:
Lync Server 2010 deployment support. You must deploy Lync Server 2010 if you are deploying
Unified Messaging in a cross-premises environment. Unified Messaging is fully supported and
functional with Lync Server 2010, including Message Waiting Indicator notifications.
Lync Server 2010 migration support. If you are deploying or migrating from
Microsoft Exchange Server 2007 to Exchange Server 2010 and your Exchange deployment is
integrated with Lync Server 2010, Exchange Server 2010 SP1 includes support for migration of SIP
Uniform Resource Identifier (URI) dial plans (SIP URI dial plans) that are used with
Microsoft Office Communications Server 2007 and Office Communications Server 2007 R2. Also, in
Exchange Server 2010 SP1, it is no longer required that you have an Office Communications Server
location profile that has the same name as the phone context property of the SIP URI dial plan.
Important Do not include spaces in the dial plan name or it will not perform properly.
Communication Improvements
Exchange Server 2010 SP1 provides the following language support, Call Answering improvements, and
Caller Name Display enhancements:
New Unified Messaging Language Pack additions. Unified Messaging language packs make it possible
for the Exchange Server 2010 Unified Messaging server to speak additional languages to callers and
recognize languages other than U.S. English (en-US) when callers use Automatic Speech Recognition
(ASR) or when voice messages are transcribed.
Call Answering Rules improvements. Using Call Answering Rules, end users can control how their
incoming calls should be handled. Call Answering Rules are applied to incoming calls much as Inbox
rules are applied to incoming email messages.
Caller Name Display enhancements. Caller ID resolution has been enhanced in

Exchange Server 2010 SP1. Names can now be displayed for voice messages from unresolved
numbers using Caller Name Display. With Caller Name Display, IP gateways or IP PBXs pass caller
name information as part of the SIP FROM header.
Unified Communications Managed API addition. Beginning with Exchange Server 2010 SP1, the
Unified Messaging server relies on Unified Communications Managed application programming
interface (API) v. 2.0 (UCMA) for its underlying SIP signaling and speech processing. This dependency
requires that the UCMA platform and prerequisites be installed on the Unified Messaging server
before Exchange Server 2010 Unified Messaging SP1 installation or upgrade.
Integrating Unified Messaging with Lync Server 2010
Lync Server 2010 is Microsofts SIP based instant messaging and web conferencing server. Lync Server
2010 can be deployed as a full featured VOIP solution for an organization. However, Lync Server does not
provide any option for accepting or storing voice messages. Exchange Server 2010 Unified Messaging
provides Lync Server 2010 with the voice mailbox feature.
As described above, Lync Server requires some type of VOIP solution in order to integrate with the PSTN.
You can use the Enterprise Voice feature in Lync Server 2010 to provide that VOIP solution. This means
that you do not need additional hardware to connect Unified Messaging to your PBX or possibly to the
PSTN if you deploy Enterprise Voice in Lync.
Lync Server 2010 also provides other features that integrate into Unified Messaging:
A single inbox for multiple types of communication. Integrating Unified Messaging with Lync 2010
enables you to consolidate users email and voicemail messages in their Inbox. When a user does not
answer his or her phone, the caller can leave a voicemail, which appears as a message in the users
mailbox. The integration also provides features such as call notification, where the Outlook user is
notified through email when another user calls his or her phone number.
Instant messaging. The Lync client provides instant messaging (IM) functionality that is hosted on the
Lync servers. The solution provides IM features, such as group IM, and extends the internal IM
infrastructure to external IM providers. As part of the IM solution, Lync tracks presence information
for all Lync users, and it provides this information to the Lync client and other applications, such as
Outlook 2010. The Lync client is integrated with Exchange Server 2010 so that information such as
meeting status or out of office messages from Exchange is displayed in the Lync client presence
information.
Web and audio video conferencing. Lync Server can host on-premise conferences, which you
can schedule or reschedule, and they can include IM, audio, video, application sharing, slide
presentations, and other forms of data collaboration. When the Lync client is installed on a client
computer that is also running Outlook 2007 or later, users can create online meetings that are hosted
on the Lync server by using Outlook. The meeting request information includes the URL required to
connect to the Lync hosted meeting.
VoIP telephony. Enterprise Voice enables Lync 2010 users to place calls from their computers by
clicking an Outlook or Lync client contact. Users receive calls simultaneously on all their registered
user endpoints, which may be a VoIP phone, mobile phone, or Lync client. The Lync Attendant is an
integrated call-management client application that enables a user, such as a receptionist, to manage
many conversations simultaneously.
Outlook Web App integration. You can configure the integration of Exchange 2010 SP1 and Lync 2010
so that Outlook Web App can also act as a Lync web client. With this integration, users can sign in or
sign out of instant messaging from Outlook Web App. Once signed in, the user will automatically
sign into IM every time they sign into Outlook Web App. User-presence information and the Lync
contact list are displayed in Outlook Web App, enabling users to perform tasks such as chatting with
other Lync users by using instant messaging directly from OWA.
International Requirements for Unified Messaging
Unified Messaging provides language packs to satisfy international Unified Messaging requirements. In
multiple language environments, you should install the applicable Unified Messaging language packs,
because some Unified Messaging users prefer their voice prompts in a different language or because they
receive email messages in multiple languages that they need to access by using Outlook Voice Access. If
you do not install the Unified Messaging language pack for a particular language, email messages will not
be translated to the users language when they are relayed to the user.
Several key components rely on Unified Messaging language packs to enable users and callers to interact
effectively with Exchange Server 2010 Unified Messaging in multiple languages. Each language pack
includes:
A Text-to-Speech (TTS) engine to read and convert messages when Outlook Voice Access users access
their inboxes.
The prerecorded prompts used to configure Unified Messaging dial plans and auto attendants.
ASR support for speech-enabled Unified Messaging dial plans and auto attendants.
To install a language pack, run Setup.com /AddUMLanguagePack, which is found in the Exchsrvr\Bin
directory of the Exchange Server installation.
Once you install your language packs, you can change the default language configured for each dial plan.
Users automatically use the default language if their configured language setting in Outlook Web App is
not available as a language pack. For example, if you install only the English and German language packs,
and the English language pack is the default on the dial plan, a user with the French language
configuration in Outlook Web App will hear English prompts.
In Exchange Server 2007, each language pack included the TTS engine but only supported ASR for US
English. In Exchange Server 2010, all available language packs contain ASR support. Exchange Server 2010
SP1 provides full support for 26 languages.
Lesson 3
Configuring Unified Messaging
To enable Unified Messaging in Exchange Server 2010, you first need to understand how Exchange Server
2010 implements Unified Messaging. Then you need to configure the Unified Messaging server role and
its required components.
This lesson describes the basic Exchange Server 2010 Unified Messaging components.

Describe the process for installing Unified Messaging.
Implement a Unified Messaging dial plan.
Implement a Unified Messaging IP gateway.
Implement a Unified Messaging hunt group.
Implement a Unified Messaging mailbox policy.
Create a Unified Messaging auto attendant.
Configure call-answering rules.

Process for Installing Unified Messaging
Complete the following steps to install Unified Messaging:
1. Install the Unified Messaging server role. You must install a Mailbox server, a Hub Transport server,
and a Client Access server before you can install the Unified Messaging server role. You can install the
Unified Messaging role on the same computer that runs these prerequisite roles or on a separate
computer.
Note Before you install the Unified Messaging server role on a Windows Server 2008
computer, you must install the Desktop Experience feature. This feature provides the
Windows Media Encoder and Windows Media Audio Voice Codec that the Unified
Messaging server requires.
2. Create a Unified Messaging dial plan. A dial plan is the telephony extension-numbering 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 Unified Messaging dial
plan, you need to associate it with a Unified Messaging server.
3. Create a Unified Messaging IP gateway. A Unified Messaging 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.
4. Create a Unified Messaging hunt group. A hunt group groups phone numbers together for specific
purposes. 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 Unified Messaging dial plan. You can customize that hunt group or create
additional ones.
5. Configure a Unified Messaging mailbox policy. A Unified Messaging mailbox policy is created by
default each time you create a Unified Messaging dial plan. You can configure that mailbox policy
or create a new one. When you configure the policy, you can specify 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 international calling
restrictions.
6. Enable mailboxes for Unified Messaging. You must enable mailboxes to allow the mailboxes to access
Unified Messaging services. You must associate each user mailbox with a Unified Messaging mailbox
policy and a unique extension number.
7. Create a Unified Messaging auto attendant object. The auto attendant feature is an optional
component. To enable the auto attendant, you must create and configure an associated dial plan.
Note These steps describe the process of installing Unified Messaging in an Exchange
Server 2010 environment. To complete this installation in a production environment, you
also must configure the PBX and the VoIP gateway to route calls to the Unified Messaging
servers.
What Is a Unified Messaging Dial Plan?
The Unified Messaging dial plan is the basic Unified Messaging administrative unit. 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 also controls the numbering scheme
and the outbound dialing plan.
How Unified Messaging Uses Dial Plans

The Unified Messaging dial plan is an Active Directory container object that is a logical representation of a
telephony dial plan that you configure on a PBX. The 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 in each an extension. When
you configure Unified Messaging, you enter the extension length. You also can configure many other dial-
plan settings, including:
Access numbers for subscriber of this dial plan.

Default greetings that are used when dial-plan subscribers call into the Unified Messaging server.
Dial codes for dialing external phone numbers and international numbers.
Features such as whether subscribers can transfer callers to other users and whom callers can contact.
Time limits for calls, messages, and idle timeouts.
Default language for voice prompts.
The audio codec format for voice messages, such as MP3.
Note You need at least one Unified Messaging dial plan, and that dial plan requires a
Unified Messaging server and an associated Unified Messaging IP gateway.
Implementing a Dial Plan

Unified Messaging requires at least one Active Directory dial-plan object, and must have an associated
Unified Messaging server and IP Gateway object. Implementing a dial plan is a two-step process:
1. Create and configure a Unified Messaging dial-plan object. Create a Unified Messaging dial-plan
object for an organization, and then apply it to the entire organization. You can create and configure
a dial plan by using the Exchange Management Shell, Exchange Management Console, or the ECP. To
create a new dial plan by using the Exchange Management Shell, use the New-UMDialplan cmdlet.
2. Add a Unified Messaging server to the dial plan. Installing the Unified Messaging server role on a
computer running Exchange Server 2010 enables the server role. However, for the Unified Messaging
server to answer and process incoming calls, you also must add the Unified Messaging server to a dial
plan. You can add one Exchange Server 2010 Unified Messaging server to multiple dial plans
concurrently. To use the Exchange Management Shell to modify a dial plans configuration, use the
Set-UMDialplan cmdlet.
Note With Exchange Server 2010, you had to add the Unified Message server to the dial
plan after you created it. With Exchange Server 2010 SP1, these steps have been combined
in one wizard or one Exchange Management Shell cmdlet.
What Is a Unified Messaging IP Gateway?
The Unified Messaging IP gateway is an AD DS container object that logically represents a physical IP
gateway hardware device that translates between the circuit-switched telephone network and an IP or
packet-switched network. The Unified Messaging IP gateway can represent either a VoIP gateway or an
IP-PBX.
The Unified Messaging IP gateway contains one or more Unified Messaging hunt-group objects and
other Unified Messaging IP gateway-configuration settings, including the actual IP gateway object. The
combination of the IP gateway object and a Unified Messaging hunt-group object establishes a logical
link between an IP gateway hardware device and a Unified Messaging dial plan.
Note Before an IP gateway can process calls, a Unified Messaging IP gateway must be
associated with at least one Unified Messaging dial plan.
Implementing Unified Messaging IP Gateways

You can create a Unified Messaging IP gateway by using the Exchange Management Shell or Exchange
Management Console. When you create a new Unified Messaging IP gateway object, you enable Unified
Messaging servers to connect to the VoIP gateway or IP PBX.
By default, IP gateways remain in an enabled state after you create them. However, you can enable or
disable the Unified Messaging IP gateway. If you disable a Unified Messaging IP gateway, it can be in one
of two disabled modes. The first disabled mode forces all associated Unified Messaging servers to drop
existing calls. The second disabled mode forces the Unified Messaging server associated with the Unified
Messaging IP gateway to stop handling any new calls that the IP gateway presents.
To create a new Unified Messaging IP gateway by using the Exchange Management Shell, use the
New-UMIPGateway cmdlet.
What Is a Unified Messaging Hunt Group?
The Unified Messaging hunt group is a logical representation of an existing PBX or IP PBX hunt group.
When the hunt groups pilot number receives a call, the PBX or IP PBX looks for the next available
extension number to deliver the call. When the calls recipient does not answer an incoming call, or the
line is busy because the recipient is on another call, the PBX or IP PBX routes the call to the Unified
Messaging server. Unified Messaging hunt groups act as a connection or link between the Unified
Messaging IP gateway and the Unified Messaging dial plan. Therefore, you must associate a single Unified
Messaging hunt group with at least one Unified Messaging IP gateway and one Unified Messaging dial
plan.
Unified Messaging hunt groups 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 Unified
Messaging hunt group. The pilot number enables the Unified Messaging server to associate the call with
the correct dial plan so that it can route the call correctly.
Implementing Unified Messaging Hunt Groups

When you create a new hunt-group object, you enable Unified Messaging servers in the specified dial
plan to communicate with the IP gateway object. When creating a new hunt-group object, you need to
specify the dial plan, and the pilot identifier or pilot number, that you want it to use with the new hunt
group. You can configure Unified Messaging hunt groups by using the Exchange Management Console,
the Exchange Management Shell, or the Exchange Control Panel. In the Exchange Management Shell, use
the New-UMHuntGroup command.
Question: Is it possible to create a Unified Messaging hunt group without an available

Unified Messaging IP gateway?
What Is a Unified Messaging Mailbox Policy?
Unified Messaging mailbox policies apply and standardize Unified Messaging configuration settings for
Unified Messaging-enabled users. You can create Unified Messaging mailbox policies, and then add the
policy to Unified Messaging-enabled mailboxes to apply a common set of policies or security settings.
Unified Messaging mailbox policies are required before you can enable users to use Unified Messaging.
Implementing Unified Messaging Mailbox Policies

Create Unified Messaging mailbox policies in the Active Directory Configuration container, using either
the Exchange Management Shell or Exchange Management Console. When you create a dial plan, a
single, default Unified Messaging mailbox policy is created for it. However, you can create additional
Unified Messaging mailbox policies based on your organizations needs.
When you create a Unified Messaging mailbox policy, you can configure the following settings:
Dial plan (required).
Maximum greeting length.
Number of unsuccessful login attempts before it resets the password.
Minimum number of digits that a PIN requires.
Number of days until users must create a new PIN.

Number of previous passwords that it does not allow.
Restrictions on in-country/region or international calling.
Protected voicemail settings.
Each Unified Messaging-enabled users mailbox must link to only one Unified Messaging mailbox policy.
Enabling Users for Unified Messaging

You enable user accounts to use Unified Messaging after you configure the Unified Messaging
components. To enable user accounts, use the ECP, run the Enable Unified Messaging Wizard in the
Exchange Management Console, or use the Enable-UMMailbox cmdlet in the Exchange Management
Shell.
When you enable a user account for Unified Messaging, you must specify a Unified Messaging mailbox
policy and an extension, and you must assign a PIN or configure the system to generate the users initial
PIN. When you enable a user for Unified Messaging, Exchange Server sends the user an email message
indicating that the account is enabled. The message also contains the PIN. The user must use touch-tones
to input a PIN when accessing the Unified Messaging-enabled mailbox. Speech recognition is not enabled
for PIN input.
What Is a Unified Messaging Auto Attendant?
A Unified Messaging auto attendant is an optional component of the Unified Messaging server. It creates
a voice-menu system that enables external and internal callers to navigate through voice menus to locate
and place, or transfer, calls to company users or organizational departments.
When anonymous or unauthenticated users call an external business telephone number, or when internal
callers call a specified extension number, voice prompts help them place a call to a user, or locate and call
a user.
The Unified Messaging auto attendant uses a series of WAV files that callers hear instead of a human
operator. The Unified Messaging auto attendant lets callers navigate the menu system, place calls, or
locate users using DTMF or voice inputs.
A Unified Messaging auto attendant provides:
Corporate or informational greetings, such as business hours or directions to a location.
Custom corporate menus that you can customize to have more than one level.
A directory search function that enables callers to search the organizations name directory.
The ability for callers to connect to the telephone of, or leave a message for, organizational members.
Creating Auto Attendants

Each Unified Messaging auto attendant that you create is represented as an Active Directory object.
There is no limit to how many Unified Messaging auto attendants you can create, and each auto
attendant can support an unlimited number of extensions. However, you should design menu systems for
auto attendants carefully to ensure that the user has a positive experience. If you design them incorrectly,
it can be very frustrating to users if the time it takes to connect correctly is lengthy or it is difficult to
navigate through the system.
A Unified Messaging auto attendant can reference only one Unified Messaging dial plan. However,
Unified Messaging auto attendants can reference or link to other Unified Messaging auto attendants.
When you create an auto attendant, you must provide the associated dial plan and extension numbers.
After creating the auto attendant, you can configure alternative greetings by specifying the WAV files to
use. You also can configure different settings for work and nonwork hours, and features such as call
transferring.
Create auto attendants in the Exchange Management Console or by running the

New-UMAutoAttendant cmdlet in the Exchange Management Shell.
Rules for Call Answering
Call-answering rules, also known as Personal Auto Attendants, allow users to create and customize rules to
enhance the experience that callers have when their calls are answered. For example, the call-answering
rules can include features such as special greetings by contact or time of the day.
Using call answering rules, the caller can decide to:
Leave a voice message for the Unified Messaging-enabled user.
Transfer to an alternate contact of the Unified Messaging-enabled user.
Transfer to an alternate contacts voicemail.
Transfer to other phone numbers that the Unified Messaging-enabled user configures.
Use the Find-Me feature or locate the Unified Messaging-enabled user via a supervised transfer.
Call-answering rules consist of conditions, a greeting and menu, and actions. You can configure call-
answering rules in Outlook Web App or Outlook 2010.
Conditions
The following conditions are available:
If the caller is: calling from a specified phone number, or if the caller is a personal contact.
If it is during this period: working hours or nonworking hours to a specific time defined.
If the users schedule shows a status of free, tentative, busy, or away.
If you turn on automatic replies, such as when you turn on an automatic Out of Office message.
Greeting and Menu

Greeting and Menu is the area where the caller can take specific actions that users predefine. For example,
after hearing a greeting that you previously recorded, you can provide a prompt so that the caller can dial
you at home.
Actions
Actions define the tasks that occur when callers choose specific menu selections. You can select the
following actions:
Find me at the following numbers: Defines a recording text, the number key to press to transfer, and
enables you to call two phone numbers for a specific time.
Transfer the call to: Defines a recording text, the number key to press to transfer, and either a phone
number or a contact, or indicates that the call should transfer directly to voice mail.
Leave a voice message: Directly transfers the caller to voicemail.

Lab: Implementing Unified Messaging
Lab Setup
2. Ensure that the 10135B-VAN-DC1, 10135B-VAN-EX1, and 10135B-VAN-EX2 virtual machines are
running:

Lab Scenario
You are a messaging administrator for A. Datum Corporation. Your organization has deployed Exchange
Server 2010. Your users expect to have voice access to their mailboxes, so you must enable this feature
and configure Unified Messaging.
Additionally, many native German speakers work at A. Datum, so you need to install the German language
pack so that they also can use Unified Messaging.
Exercise 1: Installing and Configuring Unified Messaging Features

1. Install the Exchange Server Unified Messaging prerequisites.
2. Install the Unified Messaging role.

3. Create a dial plan.
4. Create a Unified Messaging IP gateway and hunt group.
5. Change the default Unified Messaging mailbox policy.
X Lab preparation
1. On the host computer, open Hyper-V Manager.
2. Right-click 10135B-VAN-EX2, and then click Settings.

then click Open.
5. Click OK.
X Task 1: Install the Exchange Server Unified Messaging prerequisites

1. On VAN-EX2, close the AutoPlay dialog box.
2. In Server Manager, add the Desktop Experience feature and other required features.
3. When prompted, restart the computer.
4. After the computer restarts, log on as Adatum\Administrator.
5. Connect to \\VAN-EX1\D$\Labfiles.
6. Install UcmaRuntimeSetup.exe and SpeechPlatformRuntime.msi.
X Task 2: Install the Unified Messaging role

1. Use Programs and Features in Control Panel to open Microsoft Exchange Server 2010 Setup.
2. Install the Unified Message server role.
X Task 3: Create a dial plan

1. On VAN-EX2, create a new dial plan using the Exchange Management Console.
2. Configure the dial plan with following settings:

Name: DP-VAN-5digit
VoIP security: Unsecured
Country/Region code: 1604
UM Server: VAN-EX2
X Task 4: Create a Unified Messaging IP gateway and hunt group

1. Create a Unified Messaging IP gateway named IPTestPhone using Exchange Management Console,
and then configure an IP address of 10.10.0.10, and use DP-VAN-5digit as the dial plan.
2. Create a Unified Messaging hunt group named HG-VAN-5digits for the IP gateway, and then
configure a Pilot identifier of 90000.
X Task 5: Change the default Unified Messaging mailbox policy

1. Configure message text for the Unified Messaging mailbox policy that reads Welcome to the Unified
Messaging Server VAN-EX2 to be sent to users when their mailboxes are enabled for Unified
Messaging.
2. Configure the PIN policies for the mailbox policy so that they never expire.
Results: After this exercise, you should have installed the Unified Messaging role and configured the basic
server-side settings for Unified Messaging, namely a dial plan, an IP gateway, a hunt group, and a mailbox
policy. You also will have assigned the dial plan to a Unified Messaging server.
X To revert the virtual machines

following steps:


Review Questions
1. If your company already implemented Lync Server 2010 and connected Lync Server to the PSTN, do
you need an additional IP PBX for Exchange Server 2010 Unified Messaging?
2. Users want to ensure that private voice mails are protected. Does Exchange Server 2010 Unified
Messaging have a feature to do this?
Common Issues Related to Unified Messaging

Identify the causes for the following common issues related to implementing Unified Messaging, and
You are unable to enable Unified

Messaging in mailbox properties
on the Mailbox Features tab. It is
unavailable.
Best Practices Related to Implementing Unified Messaging

Once you install the Unified Messaging server role, check the event log to make sure the service is
operational and no error messages appear.
After installing the Unified Messaging server role, configure a dial plan, and Unified Messaging IP
gateway, hunt group, and Unified Messaging mailbox policy, and then associate it to the Unified
Messaging server. Then use the Exchange Unified Messaging Test Phone to see if the configuration is
working, before you configure your IP PBX or PBX to communicate with the Exchange server.
Tools
Exchange Server Connect to your Unified Messaging

Unified Messaging server via voice access to your mailbox.
Test Phone
L1-1
Module 1: Deploying Microsoft Exchange Server 2010

Lab A: Installing Exchange Server 2010
Exercise 1: Evaluating Requirements for an Exchange Server Installation
X Task 1: Evaluate the Active Directory 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, and 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.
X Task 2: Evaluate the DNS requirements

1. On NYC-SVR1, click Start, and, 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 Domain Name
System (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
a service (SRV) record is returned.
7. Close the command prompt.

L1-2 Module 1: Deploying Microsoft Exchange Server 2010
X 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 then point to Administrative Tools.

5. Verify that Internet Information Services (IIS) Management is not listed.
6. Click Start, click All Programs, click Accessories, click Windows PowerShell, and then click
Windows PowerShell.
7. At the PS 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 v2.
8. Close Windows PowerShell.
9. Click Start, and then click Control Panel.
10. In the Control Panel, click Programs.
11. In the Programs window, click Programs and Features. Verify that Microsoft Filter Pack 2.0 is
installed. Close the Programs and Features window.
Results: After this exercise, you should have evaluated the requirements for AD DS, DNS, and servers.
Exercise 2: Preparing for an Exchange Server 2010 Installation

X 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. Select the .NET Framework 3.5.1 check box, and then click Add Required Role Services.
4. Select the RPC over HTTP Proxy check box, and then click Add Required Role Services.
5. 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.

Lab A: Installing Exchange Server 2010 L1-3
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, click OK, and then close the Services console.
X Task 2: Prepare AD DS for Exchange Server 2010 installation

This task requires that the Exchange Server 2010 Service Pack 2 (SP2) is attached to the NYC-SVR1 virtual
machine as a DVD drive. Complete the following steps to attach it:
1. In the 10135B-NYC-SVR1 on localhost Virtual Machine Connection window, in the File menu, click
Settings.
2. Click DVD Drive, and then click Image File.
3. Click Browse, and then browse to C:\Program Files\Microsoft Learning\10135\Drives. Click

Exchange2010SP2.iso, and then click Open. Click OK.
4. On NYC-SVR1, click Close to close the AutoPlay dialog box.
5. On NYC-SVR1, open a Command Prompt.

6. Type D:\setup.com /PrepareAD /OrganizationName:Contoso, and then press Enter. These tasks
will take about 10 minutes to complete. Make sure that no errors appear.
7. Close the command prompt window when the tasks are complete.
Results: After this exercise, you should have installed the Windows Server 2008 server roles and features,
and prepared AD DS for an Exchange Server 2010 installation.
Exercise 3: Installing Exchange Server 2010

X Task 1: Install Microsoft Exchange Server 2010
1. Click Start, click Run, type D:\setup.exe, and then click OK.
2. Steps 1, 2, and 3 are unavailable because they are complete. If the components were not installed,
Exchange Server provides links to download the necessary software.
3. Click Step 4: Install Microsoft Exchange. The installation begins copying files.
4. On the Introduction page, click Next to begin Exchange Server 2010 Setup.
5. On the License Agreement page, click I accept the terms in the license agreement, and then
click Next.
6. On the Error Reporting page, click No to disable error reporting, and then click Next. You are
disabling error reporting because your virtual machine does not have access to the Internet.
7. On the Installation Type page, click Typical Exchange Server Installation, select Automatically
install Windows Server roles and features required for Exchange, and then click Next. Note that
this is specific to Exchange Server 2010 SP2.
8. On the Client Settings page, click Yes to configure Exchange Server for Microsoft Outlook 2003 or
Entourage clients, and then click Next.
9. On the Configure Client Access server external domain page, click Next.
10. On the Customer Experience Improvement Program page, click I dont wish to join the program
at this time, and then click Next.
11. Click Install. A readiness check takes place to ensure that Exchange is ready to install on the server.
This check takes several minutes to complete.
12. Click Install again. The installation begins, and takes approximately 15 to 20 minutes to complete.
13. Clear the option Finalize this installation using the Exchange Management Console, and then
click Finish.
14. If prompted to reboot server, click OK.

15. Click Close and Yes to exit Exchange Server 2010 Setup. You are not obtaining the critical updates for
Exchange Server 2010 because the virtual machine does not have Internet connectivity.
16. Restart NYC-SVR1 server. After it restarts, log on as Contoso\Administrator with the password
Pa$$w0rd.
Results: After this exercise, you should have installed Exchange Server 2010.
L1-5
Lab B: Verifying an Exchange Server 2010

Installation
Exercise 1: Verifying an Exchange Server 2010 Installation
X Task 1: View the Exchange Server services
1. On NYC-SVR1, click Start, point to Administrative Tools, and then click Services.
2. Scroll down the list of services, and click the Microsoft Exchange Active Directory Topology
service. Review the service description.
3. Review the status of the remaining Exchange Server services. Ensure that all services that are set for
automatic startup are running.
4. Close Services.
X Task 2: View the Exchange Server folders

1. Click Start, and then click Computer.
2. Browse to C:\Program Files\Microsoft\Exchange Server\V14. This list of folders includes
ClientAccess, Mailbox, and TransportRoles. These three roles were installed as part of the typical
setup.
3. Open TransportRoles. The Hub Transport server role uses these folders.
4. Close Windows Explorer.
X Task 3: Create a new user, and send a test message

1. If necessary, click Start, point to All Programs, click Microsoft Exchange Server 2010, and then
click Exchange Management Console.
2. In the left pane, click Microsoft Exchange On-Premises(nyc-svr1.contoso.com). Wait for the
initialization to finish, and then click OK to acknowledge that the server is unlicensed.
3. Expand Microsoft Exchange On-Premises and click Recipient Configuration. Notice that a
mailbox for the Administrator and a Discovery Search Mailbox are the only mailboxes created by
default.
4. Right-click Recipient Configuration, and then click New Mailbox. Wait for the New Mailbox Wizard
to start.
5. Click Next to accept the User Mailbox option.
6. Click Next to accept the New user option.
7. In the First name box, type TestUser.
8. In the User logon name box, type TestUser.
9. In the Password and Confirm password boxes, type Pa$$w0rd.
10. Click Next.
11. On the Mailbox Settings page, in the Alias box, verify that TestUser is displayed, and then click
Next to accept the mailbox settings.
12. On the Archive Settings page, click Next.

13. Click New to create the new mailbox.
14. Click Finish.
15. Click Start, point to All Programs, and then click Internet Explorer.
16. In the Address bar, type https://NYC-SVR1/owa, and then press Enter.
17. Click Continue to this website (not recommended) to proceed. It might take some time for
Outlook Web App to appear for the first time.
18. Log on as Contoso\TestUser with a password of Pa$$w0rd.
19. Click OK to accept the default Outlook Web App settings.
20. Click New to create a new message.
21. If warning page appears, click Continue to this website (not recommended).
22. In the To box, type Administrator.
23. In the Subject box, type Test Message, and then click Send.
24. Close Windows Internet Explorer.
26. In the Address bar, type https://NYC-SVR1/owa, and then press Enter.
27. Click Continue to the website (not recommended) to proceed.
28. Log on as Contoso\Administrator with a password of Pa$$w0rd.
30. Double-click the message from TestUser to read it.
31. Close the message from TestUser.
32. Close Internet Explorer.
X Task 4: Run the Exchange Server Best Practices Analyzer tool

1. In Exchange Management Console, in the left pane, click Toolbox.
2. In the center pane, double-click Best Practices Analyzer.
3. Click Do not check for updates on startup. You do this because your virtual machine does not have
Internet access.
4. Click I dont want to join the program at this time.
5. Click Go to the Welcome screen.
6. Click Select options for a new scan.
7. Click Connect to the Active Directory server.
8. In the Enter an identifying label from this scan box, type Post-Installation Test.
9. Review the options, and then click Start scanning.
10. When the scan is complete, click the View a report of this Best Practices scan link.
11. On the Critical Issues tab, click Offline address book replica not found. This gives you the option
to get information about how to fix the problem or hide the message.
Lab B: Verifying an Exchange Server 2010 Installation L1-7
12. Click Tell me more about this issue and how to resolve it. This opens the Microsoft Exchange
Server Best Practices Analyzer Help, and provides specific information about the warning and
troubleshooting it.
13. Close Exchange Server Best Practices Analyzer Help.
14. Close the Exchange Server Best Practices Analyzer Tool.
Results: After this exercise, you should have verified the successful installation of Exchange Server 2010 by
viewing the Exchange Server services and folders. You should also have created a new user and sent a test
message to that user. Finally, you should have used the Exchange Server Best Practices Analyzer tool to
view information about any installation issues.

following steps:
L2-8
Module 2: Configuring Mailbox Servers

Lab: Configuring Mailbox Servers
Exercise 1: Configuring Mailbox Databases
X Task 1: Create a new database for the Executive mailboxes
2. In the Console Tree, expand Microsoft Exchange, expand Microsoft Exchange On-Premises,
expand Organization Configuration, and then click Mailbox.
3. In the Content pane, select the Database Management tab.
4. In the Actions pane, click New Mailbox Database.
5. In the New Mailbox Database Wizard, type Executive in the Mailbox database name field, and then
click Browse.
6. In the Select Mailbox Server dialog box, select VAN-EX1, and then click OK.
7. Click Next.
8. In the Database file path field, type C:\Mailbox\Executive\Executive.edb.
9. In the Log folder path field type C:\Mailbox\Executive.
10. Click Next.
11. Click New.

12. Click Finish.
X Task 2: Configure the Executive mailbox database with appropriate limits

1. In the Content pane, select the Database Management tab, right-click on the Executive database,
and then click Properties.
2. Click the Limits tab.

3. Type 850 for Issue warning at (MB).
4. Uncheck Prohibit send at (MB).
5. Type 1024 for Prohibit send and receive at (KB).
6. Click OK.
X Task 3: Move the existing Accounting database to a new location

1. In the Content pane, select the Database Management tab, and then select the Accounting
database.
2. In the Actions pane, click Move Database Path.
3. In the Move Database Path Wizard, in the Database file path field, type
C:\Mailbox\Accounting\Accounting.edb.
Lab: Configuring Mailbox Servers L2-9
4. In the Log folder path field type C:\Mailbox\Accounting\.
5. Click Move.
6. Click Yes.
7. Click Finish.
Results: After this exercise, you should have created a new database, set the specified limits, and moved
the existing Accounting database to a new folder.
Exercise 2: Configuring Public Folders

X Task 1: Check Executives public folder statistics
2. In the Console Tree, expand Microsoft Exchange, expand Microsoft Exchange On-Premises, and
then click Toolbox.
3. In the Content pane, double-click Public Folder Management Console.
4. If you are not connected, then in the Actions pane, click Connect to a Server, and then in the
Connect to Server dialog box, click Browse.
5. In the Select Public Folder dialog box, select VAN-EX1, click OK, and then click Connect.
6. In the Console Tree, expand Public Folders, and then select Default Public Folders.
7. In the Content pane, right-click Executives, and then choose Properties.
8. On the General tab, note the Total Items and Size of the items in the public folder.
9. Click OK.
10. Leave the Public Folder Management Console running.
X Task 2: Create a public folder database on VAN-EX3

1. On VAN-EX3, in the Exchange Management Console, expand Organization Configuration, and then
click Mailbox.
2. In the Content pane, select the Database Management tab.
3. In the Actions pane, click New Public Folder Database.
4. On the New Public Folder Database page, type PF-VAN-EX3 in the Public Folder database name
field, and then click Browse.
5. In the Select Mailbox Server dialog box, select VAN-EX3, and then click OK.
6. Click Next.
7. In the Database file path field, type C:\Mailbox\PF-VAN-EX3\PF-VAN-EX3.edb.
8. In the Log folder path field, type C:\Mailbox\PF-VAN-EX3\.

L2-10 Module 2: Configuring Mailbox Servers
9. Click Next.
10. Click New.
11. Click Finish.
X Task 3: Add a replica of the Executives public folder on VAN-EX3

1. In the Console Tree for the Public Folder Management Console, expand Public Folders, and then
select Default Public Folders.
3. Click the Replication tab.
4. Under Replicate content to these public folder databases, click Add.
5. Select PF-VAN-EX3, and then click OK.

6. Click OK to close the Executives Properties dialog box. If an error occurs, wait 5 minutes and try
again.
Note It can take as much as 15 minutes for replication to complete.
X Task 4: Verify replication between VAN-EX1 and VAN-EX3

1. Click Public Folders, in the Actions pane, click Connect to a Server, and then in the Connect to
Server dialog box, click Browse.
2. In the Select Public Folder Servers dialog box, select VAN-EX3, click OK, and then click Connect.
3. In the Console Tree, expand Public Folders, and then select Default Public Folders.
Note If the Executives folder is not visible, you may need to wait for the hierarchy
replication to finish. Wait five minutes, and refresh the view. If the folder is still not visible,
shut down the Public Folder Management Console, and open it again. Use the steps above
to connect to VAN-EX3.
5. On the General tab, note the Total Items and Size of the items in the public folder.
6. Click OK.
7. Close the Public Folder Management Console.
Results: After this exercise, you should have created a new public folder database on VAN-EX3 and added
replicas for each public folder.
Lab: Configuring Mailbox Servers L2-11

following steps:

L3-12
Module 3: Managing Exchange Recipients

Lab: Managing Exchange Recipients
Exercise 1: Managing Recipients
X Task 1: Create and configure a mailbox called Adventure Works Questions
and then click Mailbox.
3. In the Actions pane, click New Mailbox.
4. Choose User Mailbox, and then click Next.
5. Choose New user, and then click Next.
6. Complete the following information:

Name: Adventure Works Questions
User logon name (User Principal Name): AdventureWksQ
Password: Pa$$w0rd
Confirm password: Pa$$w0rd
7. Click Next.
8. Type AdventureWksQ as the Alias. Select the Specify the mailbox database rather than using a
database automatically selected check box, and click Browse.
9. Click Mailbox Database 1, click OK, and then click Next.
10. Click Next.

11. Click New.
12. Click Finish.
13. In the Results pane, select the Adventure Works Questions mailbox, and then in the Actions pane,
click Properties. On the Organization tab, in the Company field, type Adventure Works, and then
click OK.
14. In the Results pane, select the Adventure Works Questions mailbox, and then in the Actions pane,
click Manage Full Access Permission.
15. In the Manage Full Access Permission Wizard, click Add.
16. In the Select User or Group dialog box, choose George Schaller, and then click OK.
17. Click Manage.
18. Click Finish.

Lab: Managing Exchange Recipients L3-13
X Task 2: Create a resource mailbox, and configure auto-accept settings for the
ProjectRoom
1. In the Console Tree, under Recipient Configuration, click Mailbox.
3. In the New Mailbox Wizard, select Room Mailbox, and then click Next.
4. Verify New user is selected, and then click Next.
Name: ProjectRoom
User logon name (User Principal Name): ProjectRoom
6. Click Next.
7. Type ProjectRoom as the Alias. Select the Specify the mailbox database rather than using a
database automatically selected check box, and then click Browse.
8. Click Mailbox Database 1, click OK, and then click Next.

9. Click New, and then click Finish.
10. In the Results pane, click ProjectRoom, and in the Actions pane, click Properties.
11. Click the Resource General tab.
12. Select the Enable the Resource Booking Attendant check box. If you do not enable this option, the
resource will not process meeting requests, even if you configure other settings.
13. On the Organization tab, configure the Company name as Adventure Works.
14. Click OK.
X Task 3: Move George Schallers mailbox to the VAN-EX1\Mailbox Database 1

1. In the console tree, under Recipient Configuration, click Mailbox.
2. Click the George Schaller mailbox, and then in the Actions pane, click New Local Move Request.
3. In the New Local Move Request Wizard, click Browse.
4. Click Mailbox Database 1, and then click OK.
5. Click Next.
6. Verify that Skip the mailbox is selected, and then click Next.
7. Click New.
8. Click Finish.
9. In the console tree, click Move Request to verify the move request is complete.
Note If the mailbox move fails, and the error indicates that no Mailbox Replication Service
is available, start the Microsoft Exchange Mailbox Replication service, and try the mailbox
move again.
L3-14 Module 3: Managing Exchange Recipients
X Task 4: Create and configure a mail-enabled contact for Ian Palangio at

Woodgrove Bank
1. In the Console Tree, under Recipient Configuration, click Mail Contact.
2. In the Actions pane, click New Mail Contact.
3. Verify that New contact is selected.
4. Click Next.
First Name: Ian
Last name: Palangio
Alias: IanPalangioWB
6. To set the e-mail address, click Edit.
7. In the E-mail address box, type ian.palangio@woodgrovebank.com, and then click OK.
8. Click Next.
9. Click New.
10. Click Finish.
X Task 5: Create a moderated distribution list for the Adventure Works Project, and
delegate an administrator
1. In the console tree, under Recipient Configuration, click Distribution Group.
2. In the Actions pane, click New Distribution Group.

3. Verify New group is selected.
4. Click Next.
5. Under Group Type, verify that Distribution is selected.

Name: Adventure Works Project
Alias: AdventureWorksProject
7. Click Next.
8. Click New.
9. Click Finish.
10. In the Work pane, select the Adventure Works Project group.
11. In the Actions pane, click Properties.
12. Click the Members tab.
13. Click Add, and then select the following users by holding down CTRL:
George Schaller
Ian Palangio
Wei Yu
Paul West
14. Click OK.
15. Click the Mail Flow Settings tab.
16. Select Message Moderation, and then click Properties.
17. Select the Messages sent to this group have to be approved by a moderator check box.
18. In the Specify group moderators section, click Add.
19. Select George Schaller, and then click OK.

20. Click OK.
21. Click OK.
X Task 6: Create a room list distribution group for the Adventure Works
meeting rooms
2. At the command prompt, type $Members=Get-User -Filter {(RecipientTypeDetails -eq

"RoomMailbox") -and (Company -eq "Adventure Works")} and press Enter.
3. At the command prompt, type New-DistributionGroup -Name "Adventure Works Conference

Rooms" -RoomList -Members $Members and press Enter.
X Task 7: Verify that changes were completed successfully

1. On VAN-CL1, verify that you are logged in as Administrator.
2. Open Microsoft Outlook 2010.
3. In the toolbar, click the down arrow next to New Items, and then click Meeting.
4. Choose a meeting Start time for tomorrow at 1:00 PM.
5. Click the To button.
Note If you receive an error message when you click To, click Cancel. Start or restart the
Microsoft Exchange Address Book Service on VAN-EX1, and then try this step again.
6. Select the Adventure Works Project group, and then click Required. Click OK.
7. In the Room Finder pane, under Show a room list, click Adventure Works Conference Rooms.
Note If the room list is not available, close the meeting request, and close Outlook. Wait a
few minutes, and then try this task again.
8. Under Choose an available room, click ProjectRoom.
9. Type Project Kickoff as the subject.

10. Click Send.
11. Close Outlook.
12. Log off from VAN-CL1.
13. On VAN-EX1, click Start, click All Programs, and then click Internet Explorer.
14. Type https://VAN-EX1.Adatum.com/OWA in the Address bar.
15. Log on to Microsoft Outlook Web App as Adatum\George with a password of Pa$$w0rd. Click OK.
16. Double-click the message with the subject of Project Kickoff.
17. Click the Accept check mark. Choose to send the response now.
Results: At the end of this exercise, you should have completed all of the assigned tasks, including
creating a mailbox, creating a resource mailbox, moving a mailbox, creating a contact, and creating a
moderated distribution group.
Exercise 2: Configuring E-Mail Address Policies

X Task 1: Create an e-mail address policy for Adventure Works users
select Hub Transport.
2. In the Actions pane, click New E-mail Address Policy.
3. In the New E-Mail Address Policy Wizard, type Adventure Works as the policy name.
4. Click Browse.
5. Click Adatum.com in the Select Organizational Unit dialog box, and then click OK.
6. Verify that All recipient types is selected, and then click Next.
7. In the Step 1 box, select the Recipient is in a Company check box.
8. In the Step 2 box, click specified.
9. In the Specify Company dialog box, type Adventure Works, and then click Add.
10. Click OK.
11. In the New E-Mail Address Policy dialog box, click Next.
12. Click Add. In the SMTP E-mail Address dialog box, click First name.last name (john.smith).
13. Click Select the accepted domain for the e-mail address, click Browse, click Adventure-
works.com, and then click OK.
14. Click OK.

15. Click Next.
16. Verify Immediately is selected, and then click Next.
17. Click New.
18. Click Finish.

X Task 2: Verify that addresses are applied correctly

1. In the Console Tree, under Recipient Configuration, click Mailbox.
2. In the Results pane, double-click George Schaller.
3. In the Properties dialog box for George Schaller, click the E-Mail Addresses tab, and view the
current email addresses that are assigned.
4. Click the Organization tab.

5. Type Adventure Works for the Company, and then click Apply.
6. Click the E-Mail Addresses tab, and view the current email addresses that are assigned. Microsoft
Exchange should have assigned the new adventure-works.com email address when the company
change was made.
7. Click OK.
Results: At the end of this exercise, you should have created an email address policy for Adventure Works
users.
Exercise 3: Configuring Address Lists

X Task 1: Create an empty-container address list named Companies
1. On VAN-EX1, in Exchange Management Console, under Organization Configuration, click Mailbox.
2. In the Results pane, click the Address lists tab.
3. In the Actions pane, click New Address List.
4. In the Name box, type Companies.
5. Click Next.
6. Select None under Include these recipient types.
7. Click Next.
8. Click New.
9. Click Finish.
X Task 2: Create a new address list for Adventure Works recipients

1. In the console tree, under Organization Configuration, click Mailbox.
2. In the Results pane, click the Address Lists tab.
4. In the Name box, type Adventure Works.
5. Click Browse.
6. In the Select Address List dialog box, select Companies, and then click OK.
7. Click Next.
9. In the Step 1 box, select the Recipient is in a Company option.
11. In the Specify Company dialog box, type Adventure Works, and then click Add.
12. Click OK.
13. Click Preview, and then click OK.
14. Click Next.

16. Click New.
17. Click Finish.
X Task 3: Create a new address list for A. Datum Corporation recipients

1. In the console tree, under Organization Configuration, click Mailbox.
2. In the Results pane, click the Address lists tab.
4. In the Name box, type A. Datum.
5. In the Display name box, type A. Datum.
6. Click Browse.
7. In the Select Address dialog box, click Companies, and then click OK.
8. Click Next.
10. In the Step 1 box, check Recipient is in a Company.
12. In the Specify Company dialog box, type A. Datum, and then click Add.
13. Click OK.
14. Click Preview, and then click OK.
15. Click Next.
17. Click New.
18. Click Finish.
X Task 4: Verify the new address list is available in Microsoft Office Outlook
1. On VAN-CL1, log on as Administrator with a password of Pa$$w0rd.
2. Open Outlook 2010.
3. On the Home tab, click Address Book.

4. Under Address Book, click the down arrow to display the options. You can see that under All
Address Lists, the Companies container is listed and includes the address lists Adventure Works and
A. Datum.
5. Close all open windows, and close Outlook.
X Task 5: Create a new offline address book for the Adventure Works address list
1. On VAN-EX1, in Exchange Management Console, under Organization Configuration, click Mailbox,
and then click the Offline Address Book tab.
2. In the Actions pane, click New Offline Address Book.
3. In the Name box, type Adventure Works.
4. Click Browse, select VAN-EX1, and then click OK.
5. Clear the Include the default Global Address List check box.
6. Select the Include the following address lists check box.
7. Click Add, expand Companies, click Adventure Works, and then click OK.
8. Click Next.
9. Select Enable Web-based Distribution and Enable public folder distribution.
10. Click Add, and in the Microsoft Exchange dialog box, click OK.
11. Click OAB (Default Web Site), click OK, and then click Next.
X Task 6: Create a global address list for Adventure Works users

2. At the command prompt, type New-GlobalAddressList Name Adventure Works GAL
IncludedRecipients AllRecipients ConditionalCompany Adventure Works and press Enter.
X Task 7: Create the address book policy for the Adventure Works users
1. In the Actions pane of the Exchange Management Console, click New Address Book Policy.
2. In the Name field, type Adventure Works ABP.
3. Beside Global address list, click Browse, click Adventure Works GAL and click OK.
4. Beside Offline address book, click Browse, click Adventure Works and click OK.
5. Beside Room list, click Browse, click Adventure Works and click OK.
6. Under Address Lists, click Add.
7. Expand Companies, click Adventure Works, and click OK.
8. Click New, and click Finish.
Results: At the end of this exercise, you should have created an address list for the A. Datum and
Adventure Works users, and an offline address book for each organization.
Exercise 4: Performing Bulk Recipient Management Tasks

X Task 1: Add a header to the .csv file exported from the Human Resources (HR)
system
1. On VAN-EX1, click Start, point to All Programs, click Accessories, and then click Notepad.
2. Click the File menu, click Open.
3. Change the Files of Type to All Files.

4. Browse to D:\Labfiles\Users.csv, and then click Open.
5. At the top of the file, replace Add Header Here with FirstName,LastName,Password. The
Import-CSV cmdlet uses this header to name each column of imported information. You then can
reference these names to view and manipulate information.
Note Ensure that you replace the entire top line in the file, including the commas. After
your edits, the first line should be FirstName,LastName,Password.
6. Click the File menu, and then click Save.
7. Close Notepad.
X Task 2: Modify the CreateUsersLab.ps1 script to import Adventure Works users from
a .csv file
1. Click Start, point to All Programs, click Accessories, and then click Notepad.
2. Click the File menu, click Open.
3. Change the Files of Type to All Files.
4. Select D:\Labfiles\CreateUsersLab.ps1, and then click Open.

5. In Section 1, define $db as Mailbox Database 1.
6. In Section 1, define $upndom as adatum.com.
7. In Section 1, define $ou as Adventureworks.
8. In Section 1, define $csvFile as D:\Labfiles\Users.csv.
9. In Section 4, replace all instances of property1 with firstname.
10. In Section 4, replace all instances of property2 with lastname.

11. In Section 4, replace property3 with password.
12. Click the File menu, and then click Save.
13. Close Notepad.
X Task 3: Create the AdventureWorks Organizational Unit

1. On VAN-EX1, click Start, click All Programs, click Administrative Tools, and then click Active
Directory Users and Computers.
2. In the Console Tree right-click Adatum.com, expand New and click Organizational Unit.
3. In the New Object Organizational Unit dialog in the Name box type AdventureWorks.
4. Click OK.
X Task 4: Run CreateUsersLab.ps1 to import the Adventure Works Users

1. On VAN-EX1, if required, start the Exchange Management Shell.
2. Type D:\Labfiles\CreateUsersLab.ps1 and press Enter.
X Task 5: Configure the Settings for the Adventure Works users

1. In the Exchange Management Shell, run Get-User OrganizationalUnit AdventureWorks |
Set-User Company Adventure Works
2. Run Get-Mailbox OrganizationalUnit Adventureworks.
3. Run: Get-Mailbox OrganizationalUnit Adventureworks | Set-Mailbox

IssueWarningQuota 4GB ProhibitSendQuota 5GB.
4. Run Get-Mailbox OrganizationalUnit Adventureworks | Set-Mailbox

AddressBookPolicy Adventure Works ABP.
Results: After this exercise, you should have created all of the additional Adventure Works users with an
Exchange Management Shell script and configure the mailbox properties.

following steps:

L4-22
Module 4: Managing Client Access

Lab A: Configuring Client Access Servers for
Outlook Anywhere Access
Exercise 1: Configuring Client Access Servers
X Task 1: Configure an external client access domain for VAN-EX2
2. Expand Microsoft Exchange On-Premises. In the left pane, expand Server Configuration, and
3. In the Actions pane, click Configure External Client Access Domain.
4. On the Configure External Client Access Domain page, type mail.Adatum.com as the domain
name, and then click Add.
5. In the Select Client Access Server dialog box, click VAN-EX2, and then click OK.
6. Click Configure. In the Microsoft Exchange dialog box, click Yes, and then click Finish.
7. In the results pane, click VAN-EX2, and then in the work pane, double-click owa (Default Web Site).
8. On the General tab, verify that the External URL field has been changed to
https://mail.adatum.com/owa, and then click OK.
X Task 2: Prepare a Server Certificate request for VAN-EX2

1. In the left pane, click Server Configuration. In the results pane, click VAN-EX2.
3. On the Introduction page, type Adatum Mail Certificate as the friendly name for the certificate,
and then click Next.
4. On the Domain Scope page, click Next.
5. On the Exchange Configuration page, expand Client Access server (Outlook Web App), and then
select both the Outlook Web App is on the Intranet and Outlook Web App is on the Internet
check boxes. Verify that Mail.adatum.com is displayed in the second text box.
6. Expand Client Access server (Exchange ActiveSync), and then verify that Exchange Active Sync is
enabled check box is selected.
7. Expand Client Access server (Web Services, Outlook Anywhere, and Autodiscover). Enter
mail.adatum.com as the external host name.
8. Ensure that both the Autodiscover used on the Internet check box and the Long URL option are
selected. In the Autodiscover URL to use field, delete all entries except for autodiscover.adatum.com,
9. On the Certificate Domains page, click Next.

Lab A: Configuring Client Access Servers for Outlook Anywhere Access L4-23
10. On the Organization and Location page, enter the following information:
Organization Unit: Messaging
State/province: BC
11. Click Browse, type CertRequest as the File name, and then click Save.
12. Click Next, click New, and then click Finish.
X Task 3: Request the certificate from the CA

1. Click the Folder icon in the task bar, and click Documents.
2. Right-click CertRequest.req, and then click Open.
3. In the Windows dialog box, click Select a program from a list of installed programs, and then
click OK.
4. In the Open with dialog box, click Notepad, and then click OK.
5. In the CertRequest.req Notepad window, click Ctrl+A to select all the text, and then click Ctrl+C to
copy and save the text to the clipboard. Close Notepad.
6. Click Start, click All Programs, and then click Internet Explorer.
7. Connect to https://van-dc1.adatum.com/certsrv.
8. Log on as Administrator using a password of Pa$$w0rd.
9. On the Welcome page, click Request a certificate.
10. On the Request a Certificate page, click advanced certificate request.

11. On the Advanced Certificate Request page, click Submit a certificate request by using
a base-64-encoded CMC or PKCS#10 file, or submit a renewal request by using a
base-64-encoded PKCS#7 file.
12. On the Submit a Certificate Request or Renewal Request page, click in the Saved Request field,
and then press Ctrl+V to paste the certificate request information into the field.
13. In the Certificate Template drop-down list box, click Web Server, and then click Submit. Click Yes.
14. On the Certificate Issued page, click Download certificate.
15. In the File Download dialog box, click Save.
16. In the Download complete dialog box, click Open.
17. In the Certificate dialog box, on the Details tab, click Subject Alternative Name. Verify that the
certificate includes several Subject Alternative Names, and then click OK.
L4-24 Module 4: Managing Client Access
X Task 4: Import and assign the Internet Information Services (IIS) Exchange Service to
the New Certificate
1. In the Exchange Management console, click Server Configuration.
2. Click ADatum Mail Certificate, and in the Actions pane, click Complete Pending Request.
3. On the Complete Pending Request page, click Browse.
4. Under Favorites, click Downloads.
5. Click certnew.cer and click Open.
6. Click Complete, and then click Finish.
7. In the Exchange Management console, click Server Configuration.
8. In the results pane, click VAN-EX2. In the bottom pane, click Adatum Mail Certificate.
9. In the Actions pane, click Assign Services to Certificate.
10. On the Select Servers page, verify that VAN-EX2 is listed, and then click Next.
11. On the Select Services page, select the Internet Information Services check box, click Next, click
Assign, and then click Finish.
X Task 5: Verify Microsoft Office Outlook connectivity to the Microsoft Exchange

Server
1. On VAN-CL1, log on as Molly using the password Pa$$w0rd.
2. Click Start, click All Programs, click Microsoft Office, and then click Microsoft Outlook 2010.
3. On the Microsoft Outlook 2010 Startup page, click Next.
4. On the E-Mail Accounts page, click Next.
5. On the Auto Account Setup page, click Next.
6. On the Configuring page, click Finish.
Note If Outlook cannot connect to the server, ensure that all of the Microsoft Exchange
Server services on VAN-EX2 do indeed start if they are set to Automatic start. Start all
services that have not started, and try connecting again.
7. In the User Name dialog box, click OK.
8. On the Help Protect and Improve Microsoft Office page, click Dont make changes, and then
click OK.
9. In Microsoft Outlook, click File.
10. Click Account Settings, and then click Account Settings.
11. Click Molly@adatum.com and then click Change.

12. Verify that the user mailbox is located on VAN-EX2, click Cancel, and then click Close.
13. Close Outlook.

Lab A: Configuring Client Access Servers for Outlook Anywhere Access L4-25
Exercise 2: Configuring Outlook Anywhere

X Task 1: Configure a Domain Name System (DNS) record for Mail.Adatum.com
1. On VAN-DC1, click Start, point to Administrative Tools, and then click DNS.
2. In DNS Manager, in the left pane, expand Forward Lookup Zones, and then expand Adatum.com.
3. Right-click Adatum.com, and then click New Host (A or AAAA).

4. In the New Host dialog box, in the Name box, type mail. In the IP Address box, type 10.10.0.21,
and then click Add Host.
5. Click OK to close the prompt, and then click Done. Close DNS Manager.
X Task 2: Configure Outlook Anywhere on VAN-EX2

1. On VAN-EX2, click Start, point to Administrative Tools, and then click Server Manager.
2. Click Features. In the Features list, verify that the RPC over HTTP Proxy feature is listed.
3. On VAN-EX2, if required, open the Exchange Management Console.
4. In the Exchange Management Console, expand Server Configuration, and then click Client Access.
5. Click VAN-EX2, and in the Actions pane, click Enable Outlook Anywhere.
6. On the Enable Outlook Anywhere page, in the External host name field, type Mail.adatum.com.
Under Client authentication method, click NTLM authentication, and then click Enable.
8. Close all open windows, and then restart VAN-EX2.
X Task 3: Configure the Outlook profile to use Outlook Anywhere

1. On VAN-CL1, ensure that you are logged on as Adatum\Molly.
2. Click Start, and then click Control Panel. In the Search field, type Mail. Right-click Mail, and then
click Open.
3. In the Mail Setup - Outlook dialog box, click E-mail Accounts.
4. In the E-mail Accounts dialog box, click Molly@adatum.com, and then click Change.
5. On the Server Settings page, click More Settings.
6. In the Microsoft Exchange dialog box, on the Connection tab, select Connect to Microsoft
Exchange using HTTP, and then click Exchange Proxy Settings.
7. In the Microsoft Exchange Proxy Settings dialog box, complete the following information:
Use this URL (https://): mail.adatum.com
8. Click OK, and then click OK again to close the Microsoft Exchange dialog box.
9. On the Server Settings page, click Next.
10. On the Congratulations! page, click Finish.
11. On the E-mail Accounts page, click Close, and then click Close again to close the Mail Setup -
Outlook dialog box.
X Task 4: Verify the Outlook Anywhere connectivity

1. Wait until VAN-EX2 finishes restarting, and then log on as Administrator using the password
Pa$$w0rd.
2. On VAN-CL1, open Microsoft Outlook 2010.
3. Verify that the Outlook connection indicator states Connected to Microsoft Exchange.
Note If Outlook cannot connect to the server, and you get an error message, first ensure
that all of the Exchange Server services on VAN-EX2 that are set to Automatic start are
started. Start all services that have not started, and then click Retry in Outlook window.
4. Press and hold Ctrl, and then right-click the Office Outlook icon in the Windows 7 operating
system notification area. You may need to click the up arrow in the Windows 7 notification area to
view the Office Outlook icon.
5. Click Connection Status. Confirm that the Conn column lists HTTPS as the connection method.
6. Click Close.
7. Press and hold Ctrl, and then click the Outlook icon in the Windows task bar notification area. Click
Test E-mail AutoConfiguration.
8. In the Password field, type Pa$$w0rd.
9. Clear the Use Guessmart and Secure Guessmart Authentication check boxes.
10. Click Test. View the information displayed on the Results tab.
11. Click the Log tab to view how the client completed Autodiscover.
12. Close the Test E-mail AutoConfiguration dialog box.
13. Close Microsoft Outlook, and then log off VAN-CL1.

Do not shut down the virtual machines or revert them to their initial state when you finish this lab.
The virtual machines are required to complete the last lab in this module.
L4-27
Lab B: Configuring Client Access Servers for

Outlook Web App and Exchange
ActiveSync
Exercise 1: Configuring Outlook Web App
X Task 1: Configure IIS to use the Internal CA certificate
1. On VAN-EX2, click Start, point to Administrative Tools, and then click Internet Information
Services (IIS) Manager.
2. Expand VAN-EX2 (ADATUM\Administrator), expand Sites, expand Default Web Site, and then
click owa.
3. In the center pane, and under IIS, double-click SSL Settings. Notice that secure sockets layer (SSL) is
required by default.
4. Under Sites, click Default Web Site, and in the Actions pane, click Bindings.
5. In the Site Bindings dialog box, click https, and then click Edit.
Note In Site Bindings dialog box you will see two instances of https. You should click on
instance that has asterisk (*) in the IP Address field.
6. In the SSL Certificate drop-down list, verify that Adatum Mail Certificate is selected
7. Click OK, click Close, and then close the IIS Manager.
X Task 2: Configure Outlook Web App settings for all users

1. Click Start, point to All Programs, click Microsoft Exchange Server 2010, and then click Exchange
Management Console.
2. In the console tree, expand Microsoft Exchange On-Premises, expand Server Configuration, and
3. In the work pane, select VAN-EX2, and in the result pane, right-click owa (Default Web Site), and
then click Properties.
4. Click the Authentication tab, and verify that Use forms-based authentication is selected.
5. Under Logon Format, click User name only, and then click Browse.
6. Click Adatum.com, and then click OK.
7. Click the Segmentation tab, click Tasks, and then click Disable. Click Rules, and then click Disable.
Click OK twice.
8. Open the Exchange Management Shell. At the PS prompt, type set-owavirtualdirectory owa
(Default Web Site) ForceSaveFileTypes .doc, and then press Enter.
9. Type set-owavirtualdirectory owa (Default Web Site) GzipLevel Off, and then press Enter.
10. Type Set-OwaVirtualDirectory -identity Owa (Default Web Site) -

FilterWebBeaconsAndHtmlForms ForceFilter, and then press Enter.
11. Type IISReset /noforce, and then press Enter. If you get a message that the service did not start,
open the Services Microsoft Management Console (MMC), and start the World Wide Web Publishing
Service.
X Task 3: Configure an Outlook Web App Mailbox Policy for the Branch Managers
1. On VAN-EX2, in Exchange Management Console, expand Organization Configuration, and then
click Client Access.
2. In the Actions pane, click New Outlook Web App Mailbox Policy.
3. In the New Outlook Web App Mailbox Policy page, type Branch Managers Policy as the policy
name.
4. In the list of features, click Change Password, and then click Disable.
6. Right-click Branch Managers Policy, and then click Properties.

7. On the Public Computer File Access tab, clear all check boxes.
8. On the Private Computer File Access tab, clear all check boxes, and then click OK.
9. Under Recipient Configuration, click Mailbox.

10. Click the Organization Unit column heading to sort the view by organization units (OU).
11. Select all the users in the Branch Managers OU, right-click, and then click Properties.
12. On the Mailbox Features tab, click Outlook Web App, and then click Properties.
13. Select the Outlook Web App mailbox policy check box, and then click Browse.
14. Click Branch Managers Policy, and then click OK four times.
X Task 4: Verify the Outlook Web App configuration

1. On VAN-EX1, open Windows Internet Explorer.
2. In the address field, type https://mail.Adatum.com/owa, and then press Enter.
3. Log on to Outlook Web App as Adatum\Sharon using the password Pa$$w0rd. Sharon is not in the
Branch Managers OU. Click OK.
4. Verify that the Tasks folder is not displayed in the user mailbox.
5. On the Outlook Web App page, click Options. Click the See All Options link.
6. On the Organize E-Mail tab, verify that you cannot create a new Inbox rule. Close Internet Explorer.
7. Open Internet Explorer.
8. In the address field, type https://mail.Adatum.com/owa, and then press Enter.
9. Log on to Outlook Web App as Adatum\Johnson using the password Pa$$w0rd. Johnson is in the
Branch Managers OU. Click OK.
10. Verify that the Tasks folder is listed in the user mailbox.
Lab B: Configuring Client Access Servers for Outlook Web App and Exchange ActiveSync L4-29
11. On the Outlook Web App page, click Options. Click the See All Options link.
12. In the left pane, click Settings. Notice that you do not have an option to change passwords. Close
Internet Explorer.
Exercise 2: Configuring Exchange ActiveSync

X Task 1: Verify the Exchange ActiveSync virtual directory configuration
1. On VAN-EX2, in the Exchange Management Console, expand Server Configuration, and then click
Client Access.
2. In the result pane, click VAN-EX2, and in the work pane, click the Exchange ActiveSync tab.
3. Right-click Microsoft-Server-ActiveSync, and then click Properties.
4. Review the information on the General tab.
5. Click the Authentication tab. Notice that Basic authentication is enabled. This is acceptable, because
you typically would use SSL to secure the credentials in transit.
6. Click OK.
X Task 2: Create a new Exchange ActiveSync mailbox policy

1. On VAN-EX2, if required, open the Exchange Management Console.
2. In the console tree, expand Organization Configuration, and then click Client Access.
3. In the Actions pane, click New Exchange ActiveSync Mailbox Policy.
4. In the Mailbox policy name box, type EAS Policy 1.
5. Select the Allow non-provisionable devices check box. Confirm that the Allow attachments to be
downloaded to device option is selected.
6. Select the Require password check box.
7. Select the Enable password recovery check box. This will enable users to recover their Windows
Mobile password through the Exchange Control Panel (ECP).
8. Click New to create the mobile mailbox policy.
9. Read the completion summary, and then click Finish. Notice the Exchange Management Shell
command that was used to create the new mobile mailbox policy.
10. Right-click EAS Policy 1, and then click Properties. Notice that the General tab has additional
options.
11. Click the Password tab. Notice the additional password-option list that was not available when
creating the mobile mailbox policy.
12. On the Sync Settings tab, review the configuration options.
13. On the Device tab, review the configuration options.
14. On the Device Applications tab, review the configuration options. To implement these settings, you
must have an Enterprise Client Access License for each mailbox.
15. On the Other tab, review the options for allowing or blocking specific applications, and then click OK.
16. In the console tree, expand Recipient Configuration, and then click Mailbox.
17. In the result pane, right-click Scott MacDonald, and then click Properties.
18. Click the Mailbox Features tab, click Exchange ActiveSync, and then click Properties.
19. In the Exchange ActiveSync Properties dialog box, click Browse.
20. Select EAS Policy 1, and then click OK.
21. Click OK twice to save and apply the changes.

following steps:
Important: Start the VAN-DC1 virtual machine first, and ensure that it is fully started before
L5-31
Module 5: Managing Message Transport

Lab: Managing Message Transport
Exercise 1: Configuring Internet Message Transport
X To prepare for this lab
1. On VAN-EX2, click Start, right-click Network, and then click Properties.
3. Right-click Local Area Connection, and then click Properties.
5. Change the IP address to 10.10.11.21, and then click OK. Click Close.
6. Click the Start button, and then click Restart. In the Comment field, type Lab restart, and then click
OK.
7. After the system is restarted, log on to VAN-EX2 as Adatum\Administrator, using the password
Pa$$w0rd.
Note These preparation steps move VAN-EX2 to a second site defined in Active
Directory Domain Services (AD DS).
X Task 1: Configure a Send connector to the Internet


3. In the Hub Transport pane, click the Send Connectors tab.
5. In the New Send Connector window, in the Name box, type Internet Send Connector.
6. In the Select the intended use for this Send connector list, click Internet, and then click Next.
8. In the Address space(for example,contoso.com) field, type *, click OK, and then click Next.
9. On the Network settings page, click Route mail through the following smart hosts, click Add,
and then click Fully qualified domain name (FQDN).
10. In the Fully qualified domain name (FQDN) box, type van-dc1.adatum.com, click OK, and then
click Next.
12. On the Source Server page, ensure that VAN-EX1 is listed, and then click Next.
13. On the New Connector page, click New, and then click Finish.
L5-32 Module 5: Managing Message Transport
X Task 2: Configure a Receive connector to accept Internet messages

1. In the Microsoft Exchange Server Exchange Management Console, expand Server Configuration,
click Hub Transport, and then in the Hub Transport pane, click VAN-EX1.
2. In the Actions pane, click New Receive Connector.
3. In the New Receive Connector window, in the Name box, type Internet Receive Connector.
4. In the Select the intended use for this Receive connector list, click Custom, and then click Next.
5. On the Local Network settings page, click Next.
6. On the Remote Network settings page, click the red X to delete the entry, and then click Add.
7. In the Address or address range box, type 10.10.0.10, click OK, and then click Next.
9. In the VAN-EX1 pane, double-click Internet Receive Connector.
10. In the Internet Receive Connector window, on the General tab, in the Protocol logging level list,
click Verbose.
11. On the Permission Groups tab, select the Anonymous users check box, and then click OK.
X Task 3: Enable anti-spam functionality on the Hub Transport server

1. In Exchange Management Console, expand Server Configuration, click Hub Transport, and then
click VAN-EX1 in the Hub Transport pane.
2. In the VAN-EX1 pane, verify that only the Receive Connectors tab is available.
3. Click Start, point to All Programs, point to Microsoft Exchange Server 2010, and then click
4. At the PS prompt, type cd c:\Program Files\Microsoft\Exchange Server\v14\scripts, and then
press Enter.
5. At the PS prompt, type .\install-AntispamAgents.ps1, and then press Enter.

6. Type Restart-Service MSExchangeTransport, and then press Enter. Wait for the Transport Service to
finish restarting.
7. In Exchange Management Console, expand Server Configuration, click Hub Transport, click
Refresh in Hub Transport Actions pane, and then click VAN-EX1 in the Hub Transport pane.
8. In the VAN-EX1 pane, click the Anti-Spam tab.
9. Expand Organization Configuration, click Hub Transport, and then click the Anti-spam tab.

1. On VAN-EX1, start Windows Internet Explorer, and connect to https://VAN-EX1.Adatum.com
/OWA.
2. Log on as Adatum\Wei with the password Pa$$w0rd.
3. On the Microsoft Outlook Web App page, click OK.

Lab: Managing Message Transport L5-33
4. Create and send a new email to Info@Internet.com with the subject Test Mail to Internet. Close
Internet Explorer.
5. Switch to Exchange Management Console.
6. On the left pane, expand Microsoft Exchange On-Premises, and then click Toolbox.
7. In the Toolbox pane, double-click Queue Viewer.

8. On the Queues tab, verify that the VAN-DC1.adatum.com queue has a Message Count of 0.
Note If the VAN-DC1.adatum.com message queue is not empty, verify that the Simple
Mail Transfer Protocol (SMTP) service is running on VAN-DC1.
9. On VAN-DC1, click Start, point to All Programs, point to Accessories, and then click Command
Prompt.
10. At the command prompt, type telnet van-ex1 smtp, and then press Enter.
11. Type helo, and then press Enter.
12. Type mail from: info@internet.com, and then press Enter.
Response: 250 2.1.0 Sender OK
13. Type rcpt to:Wei@adatum.com, and then press Enter.
Response: 250 2.1.5 Recipient OK

14. Type data, and then press Enter.
Response: 354 Start mail input; end with <CRLF>.<CRLF>
15. Type Subject: Test from Internet, and then press Enter.
16. Press the PERIOD key, and then press Enter.
17. Type Quit, and then press Enter.
18. On VAN-EX1, start Internet Explorer, and connect to https://VAN-EX1.adatum.com/OWA.
20. Verify that the mail with the subject Test from Internet mail has arrived in the Junk Email folder.
Close Internet Explorer.
Results: After this exercise, you should have configured Internet message transport by configuring Send
and Receive connectors, enabling anti-spam functionality, and verifying Internet message delivery.
Exercise 2: Troubleshooting Message Transport

X Task 1: Check the routing log, and verify that mail delivery works correctly
1. On VAN-EX1, in Exchange Management Console, click Toolbox.
2. In the Toolbox pane, under Mail flow tools, double-click Routing Log Viewer.
3. In the Routing Log Viewer window, select the File menu, and then click Open log file.
4. In the Open Routing Table Log File dialog box, click Browse server files.
5. In the Open dialog box, select the latest RoutingConfig#... file, and then click Open.
6. On the Active Directory Sites & Routing Groups tab, expand the Active Directory sites until you see
the Exchange Servers in their respective sites.
7. Start Internet Explorer, and connect to https://VAN-EX1.adatum.com/OWA.

9. Create and send a new email to Anna, with the subject Test Mail to VAN-EX2.
11. Log on as Adatum\Anna with the password Pa$$w0rd.
13. Reply to the mail Test Mail to VAN-EX2 from Wei.
14. Switch back to VAN-EX1, and check the Inbox in Microsoft Outlook Web App to see if the mail has
arrived.
X Task 2: Troubleshoot message transport

1. On VAN-EX1, in Exchange Management Shell, type d:\labfiles\Lab05Prep1.ps1, and then
press Enter.
2. On VAN-EX1, in Internet Explorer, create and send a new email to Anna with the subject Another
Test Mail to VAN-EX2. Close Internet Explorer.
3. Switch to VAN-EX2, and in Outlook Web App, check the Inbox to see if the mail has arrived.
4. Switch to VAN-EX1, and in Exchange Management Console, click Toolbox.
5. In the Toolbox pane, under Mail flow tools, double-click Queue Viewer.
6. On the Queues tab, double-click site2 to open the queue.

7. Verify that the message that Wei sent to Anna is listed in the queue. Then click the Queues tab.
8. On the Queues tab, click Site2, and scroll to the right to view the Last Error column.
9. Read the Last Error message of that Queue.
10. Click Start, point to All Programs, point to Accessories, and then click Command Prompt.
11. At the command prompt, type telnet van-ex2 smtp, and then press Enter. Verify that you receive a
Connect failed error.
12. On VAN-EX2, open the Exchange Management Console. Expand Microsoft Exchange On-Premises,
expand Server Configuration, click Hub Transport, and then click VAN-EX2 in the Hub Transport
pane.
13. On the Receive Connectors tab, notice that only the Client VAN-EX2 connector exists. This is the
reason the server does not accept a port 25 connection.
14. In the Actions pane, click New Receive Connector.
15. In the New Receive Connector window, in the Name box, type Internal VAN-EX2.
16. In the Select the intended use for this Receive connector list, click Internal, and then click Next.
17. On the Remote Network settings page, click Next.

19. Switch to VAN-EX1, and in Exchange Management Console, click Toolbox.
21. Right-click site2, and then click Retry to force an immediate retry of the message delivery. Verify that
the queue now has a message count of 0.
22. Switch to VAN-EX2, and check Annas Inbox in Outlook Web App to see that the message is now
delivered.
Results: After this exercise, you should have verified routing logs, and used the other troubleshooting
tools in Exchange Server to troubleshoot message transport.
Exercise 3: Troubleshooting Internet Message Delivery

X Task 1: Send a message to the Internet, and track it
On VAN-EX2, open Outlook Web App, and from Annas mailbox, create and send a new email to
Info@Internet.com with the subject Test Mail to Internet from VAN-EX2.
X Task 2: Implement user-based message tracking to verify mail delivery

1. On VAN-EX2, in Outlook Web App, click Options, then click See All Options to open the Exchange
Control Panel.
2. On the left pane, click Organize E-Mail, and then click the Delivery Reports tab.
3. Click Search.
4. In the Search Results pane, select the message you sent to Info@Internet.com, and then click Details.
5. Verify that is the message was sent to a server outside the organization. Close Internet Explorer.
X Task 3: Troubleshoot Internet message delivery

1. On VAN-EX1, in Exchange Management Shell, type d:\labfiles\Lab05Prep2.ps1, and then
press Enter.
2. On VAN-EX2, start Internet Explorer, and connect to https://VAN-EX2.adatum.com/owa.
3. Log on as Adatum\Anna with the password Pa$$w0rd.
4. Create and send a new email to Info@Internet.com with the subject Another Mail to Internet
from VAN-EX2.
5. On VAN-EX1, in Exchange Management Console, click Toolbox.
6. In the Toolbox pane, under Mail flow tools, double-click Message Tracking. An Internet Explorer
window opens with Outlook Web App running.
7. Log on as adatum\administrator with the password Pa$$w0rd. If the Choose the language you
want to use page appears, click OK.
8. In the Select what to manage drop down list, click My Organization. Click Reporting.
9. On the Delivery Reports tab, in the Mailbox to search field, click Browse, select Anna Lidman in
the Select Mailboxes to Search window, and then click OK.
10. Click Search.
11. In the Search Results window, select the message with the subject Another Mail to Internet from
VAN-EX2, and then click Details.
12. In the middle pane of the Delivery Report window, notice that the Status of the message is Pending.
13. Review the Delivery Report pane as it lists every route the message has taken in the Exchange
Organization. At the end of the list, you will see the reason why the message is pending.
14. Click Close in the Delivery Report pane.
15. In Exchange Management Console, click Toolbox.
16. In the Toolbox pane, under Mail flow tools, double-click Mail Flow Troubleshooter.
17. On the Updates and Customer Feedback page, click Do not check for updates on startup and
I dont want to join the program at this time. Click Go to Welcome Screen.
18. On the Exchange Mail Flow Troubleshooter page, in the Enter an identifying label for this
analysis text box, type Internet Message Delivery Failure.
19. Under What symptoms are you seeing?, click Messages are backing up in one or more queues
on a server. Click Next.
20. On the Enter Server and User Information page, enter the following information, and then click
Next:
Exchange Server Name: VAN-EX1

Global Catalog Server Name: VAN-DC1
21. On the Basic Server Information page, review the information, and then click Next.
22. On the Initial Queue Analysis Results page, click the displayed item, review the information, and
then click Next.
23. On the Remote Delivery Queue(s) Initial Analysis Results page, review the information, scroll
down, and then click Next.
24. On the DNS Availability Check Results, review the information, and then click Next.
25. On the DNS Record Analysis Results, review the information, and then click Next.
26. On the Remote Delivery Queue(s) DNS Records Analysis Results, notice that the wizard has
identified a possible root cause, and then click Next.
27. On the Remote Delivery Queue(s) Connectivity Test Results page, review the information, and
then click Next.
28. On the Remote Delivery SMTP Instance Configuration Analysis Results page, click Next.
29. On the Remote SMTP Service Diagnosis Results page, click Next.
30. On the Remote Delivery Queue(s) Message Tracking Log Analysis Results page, click Next.
31. On the Remote Delivery Queue(s) SMTP Commands Analysis Results page, click Next.
32. On the Third-Party Application Analysis Results, click Next.

33. On the View results page, click the Root Causes tab, review the displayed information, and then
close the Troubleshooting Assistant.
34. Switch to VAN-DC1, click Start, point to All Programs, point to Accessories, and then click
Command Prompt.
35. At the command prompt, type nslookup, and then press Enter.
36. Type set querytype=MX, and then press Enter.
37. Type internet.com, and then press Enter. The query will timeout, which indicates that the domain
name cannot be resolved. This means that the host cannot directly resolve a Domain Name System
(DNS) domain and has to use a smart host to send a message to the internet.
click Hub Transport.
39. On the Send Connectors tab, double-click Internet Send Connector.
40. Click the Network tab, select Route mail through the following smart hosts, and then click Add.
41. In the Add smart host dialog box, in the Fully qualified domain name (FQDN) box, type
van-dc1.adatum.com, click OK, and then click OK again.
42. In Exchange Management Console, click Toolbox.
44. Right-click internet.com, and then click Retry to force message delivery retry. Make sure that
message is not in queue anymore.
Results: After this exercise, you should have identified and resolved issues in Internet message delivery by
using the Exchange Server troubleshooting tools such as Message Tracking and Mail Flow Troubleshooter.

following steps:
L6-38
Module 6: Implementing Messaging Security

Lab A: Configuring Edge Transport Servers
and Forefront Protection 2010 for Exchange
Server
Exercise 1: Configuring Edge Transport Servers
X Task 1: Install the Edge Transport Server role
1. On VAN-SVR1, click Start, point to All Programs, point to Accessories, and then click Command
Prompt.
2. At the command prompt, type d:\Setup /mode:install /role:EdgeTransport, and then press Enter.
Wait for the installation to finish. The installation will take approximately eight to 10 minutes.
3. At the command prompt, type Exit, and then press Enter.
4. Restart VAN-SVR1 and logon as Administrator, using the password Pa$$w0rd.
6. In the Microsoft Exchange window, click OK.
7. In Exchange Management Console, in the left pane, click Edge Transport.
X Task 2: Configure Edge Synchronization

1. On VAN-SVR1, click Start, point to All Programs, point to Microsoft Exchange Server 2010, and
then click Exchange Management Shell.
2. In Exchange Management Shell, at the command prompt, type New-EdgeSubscription -FileName

c:\VAN-SVR1.xml, and then press Enter. In the Confirm text, enter Y, and then press Enter.
3. Click Start, and in the search box, type \\van-ex1\c$, and then press Enter.
4. Copy c:\VAN-SVR1.xml to the VAN-EX1\c$. Remember, that in real-world scenarios, it would be a

security violation if you are able to copy the EdgeSubscription file directly from the Edge Transport
server to the Hub Transport server. Normally, you would use a universal serial bus (USB) device or
other means to copy the file.
6. In Exchange Management Console, click Microsoft Exchange On-Premises, expand Organization

Configuration, and then click Hub Transport.
7. In the Hub Transport pane, click the Edge Subscriptions tab.
8. In the Actions pane, click New Edge Subscription.
9. In the New Edge Subscription window, beside Active Directory Site, click Browse. Select Default-
First-Site-Name as Active Directory Domain Services site, and then click OK.
Lab A: Configuring Edge Transport Servers and Forefront Protection 2010 L6-39
10. Beside Subscription file, click Browse. Browse to the C:\ click VAN-SVR1.XML click Open, make
sure Automatically create a Send connector for this Edge Subscription is checked, and then
click New.
X Task 3: Verify that EdgeSync is working and that Active Directory Lightweight
Directory Services contains data
2. In Exchange Management Shell, at the command prompt, type Start-EdgeSynchronization, and

then press Enter.
3. At the command prompt, type Test-EdgeSynchronization -FullCompareMode, and then

press Enter.
4. Ensure that the result displayed includes SyncStatus: Normal, otherwise you need to wait for another
minute and run Test-EdgeSynchronization again.
5. At the command prompt, type Get-User -Identity Wei | ft Name, GUID, and then press Enter.
6. Write down the first eight characters of the globally unique identifier (GUID) in your notes.
7. Switch to VAN-SVR1, click Start, point to All Programs, point to Accessories, and then click
Command Prompt.
8. At the command prompt, type LDP, and then press Enter.
9. In the LDP window, click Connection on the menu bar, and then click Connect.
10. In the Connect window, type VAN-SVR1 in the Server box, type 50389 in the Port box, and then
click OK.
11. Click Connection on the menu bar, and then click Bind.
12. In the Bind window, in the Bind type pane, click Bind as currently logged on user, and then
click OK.
13. Click View on the menu bar, and then click Tree.
14. In the Tree View dialog box, clear any entry in the BaseDN field, and then click OK.
15. In the LDP window, in the left pane, double-click OU=MSExchangeGateway to expand it.
16. Double-click CN=Recipients,OU=MSExchangeGateway.
17. By using the GUID you entered in previous steps, you can locate the recipient. It starts with
CN=<GUID>. After you find it, double-click the recipient GUID, and review the data that is available
for this recipient. Close LDP.

click Hub Transport.
2. Click the Send Connectors tab.

L6-40 Module 6: Implementing Messaging Security
3. Double-click EdgeSync - Default-First-Site-Name to Internet.
4. Click the Network tab, click Route mail through the following smart hosts, and then click Add.
5. In the IP address field, type 10.10.0.10, and then click OK twice.
6. In Exchange Management Shell, type Start-EdgeSynchronization, and then press Enter.
7. At the command prompt, type Exit, and then press Enter.
8. Start Windows Internet Explorer, and connect to https://VAN-EX1.adatum.com/owa.
9. Log on as Adatum\Wei using the password Pa$$w0rd.

11. Create and send a new e-mail to Info@Internet.com with the subject Test Mail to Internet.
12. Verify that you do not get a non-delivery report message.
Results: After this exercise, you should have installed an Edge Transport server role, and configured Edge
Synchronization between a Hub Transport and an Edge Transport server.
Exercise 2: Configuring Forefront Protection 2010 for Exchange Server

X Task 1: Install Forefront Protection 2010 for Exchange Server
1. On the host computer, in the Hyper-V Manager Microsoft Management Console (MMC), right-click
the 10135B-VAN-SVR1 virtual machine, and then click Settings.
2. In the Settings for 10135B-VAN-SVR1 dialog box, in the Hardware section, expand IDE
Controller 1, and then click DVD Drive.
3. In the details pane, click Image file, and type C:\Program Files\Microsoft Learning\10135
\Drives\ForeFrontInstall.iso in the field, and then click OK.
4. On VAN-SVR1, close the Autoplay dialog box. Click Start, in the Search field, type D:\, and then
press Enter.
5. In Windows Explorer, double-click forefrontexchangesetup.exe.
6. In the Setup Wizard window, on the License Agreement page, click I agree to the terms of the
license agreement and privacy statement, and then click Next.
7. On the Service Restart page, click Next.
8. On the Installation Folders page, click Next.
9. On the Proxy Information page, click Next.
10. On the Antispam Configuration page, click Enable antispam later, and then click Next.
11. On the Microsoft Update page, click I dont want to use Microsoft Update, and then click Next.
12. On the Customer Experience Improvement Program page, click Next.
13. On the Confirm Settings page, click Next. Wait for the installation to finish. It will take about five
minutes.
14. On the Installation Results page, click Finish. Close Windows Explorer.
Lab A: Configuring Edge Transport Servers and Forefront Protection 2010 L6-41
X Task 2: Configure Forefront Protection 2010 for Exchange Server

1. On VAN-SVR1, click Start, point to All Programs, point to Microsoft Forefront Server Protection,
and then click Forefront Protection for Exchange Server Console.
2. In the Evaluation License Notice window, click OK.
3. In the Forefront Protection 2010 for Exchange Server Administrator Console window, in the left pane,
click Policy Management.
4. In the Policy Management pane, under Antimalware, click Edge Transport.
5. On the Antimalware - Edge Transport page, in the Engines and Performance pane, select the Scan
with all engines option.
6. In the Scan Actions pane, in the Action list in the Virus row, select Delete.
7. On the Antimalware - Edge Transport page, click Save.
8. In the Policy Management pane, expand Global Settings, and then click Advanced Options.
9. On the Global Settings - Advanced Options page, in the Threshold Levels pane, increase the value
of Maximum nested depth compressed files to 10 and Maximum nested attachments to 50.
10. Under Intelligent Engine Management, in the Engine management list, select Manual.
11. In the Update scheduling table, click Norman Virus Control, and then click Edit Selected Engines
button.
12. In the Edit Selected Engine dialog box, in the Update frequency pane, verify that the Check for
updates every check box is selected, type 00:30 in the box, and then click Apply and Close.
13. On the Global Settings - Advanced Options page, click Save.
14. In the Policy Management pane, expand Global Settings, and then click Scan Options.
15. On the Global Settings - Scan Options page, in the Scan Targets Transport pane, under Target
types, clear Internal, and then click Save.
16. Close the Microsoft Forefront Protection 2010 for Exchange Server Administrator Console.
Results: After this exercise, you should have installed and configured Forefront Protection 2010 for
Exchange Server on the Edge Transport server.

L6-42
Lab B: Implementing Anti-Spam Solutions

Exercise 1: Configuring an Anti-Spam Solution on Edge Transport Servers
X Task 1: Configure Domain Name System (DNS) for Internet message delivery
1. On VAN-DC1, click Start, point to All Programs, point to Administrative Tools, and click DNS.
2. Expand Forward Lookup Zones, and then click Adatum.com.
3. Right-click Adatum.com, and then click New Mail Exchanger (MX).

4. In the New Resource Record dialog box, in the Fully qualified domain name (FQDN) of mail
server box, type VAN-SVR1.Adatum.com.
5. Click OK, and close DNS Manager.
X Task 2: Configure global SCL for junk mail delivery

2. In Exchange Management Console, click Edge Transport.
3. In the Edge Transport pane, select VAN-SVR1, and then click the Anti-spam tab.
4. In the Anti-spam pane, double-click Content Filtering.
5. In the Content Filtering Properties window, click the Action tab.
6. In the Action tab, clear the Reject messages that have an SCL rating greater than or equal to
check box, and then click OK.
8. In Exchange Management Shell, type Set-OrganizationConfig -SCLJunkThreshold 6, and then
press Enter.
9. At the PS prompt, type D:\labfiles\Lab6Prep.ps1, and then press Enter. This will send 11 messages
with the following spam confidence level (SCL) ratings:
Mail sender SCL level
Msg1@contoso.com 7
Msg2@contoso.com 8
Msg3@contoso.com 7
Msg4@contoso.com 7
Msg5@contoso.com 8
Msg6@contoso.com 6
Msg7@contoso.com 8
Lab B: Implementing Anti-Spam Solutions L6-43
(continued)
Mail sender SCL level
Msg8@contoso.com 7
Msg9@contoso.com 6
Msg10@contoso.com 6
Msg11@contoso.com 8
12. In the Mail pane, click Inbox. You should see three new messages in the Inbox. If not, wait for another
minute until they arrive. You see the mails because their SCL rating is 6, and not above.
13. In the Inbox pane, double-click the message from Msg10@contoso.com.
14. In the message window, click Message Details on the toolbar.
15. In the Message details window, identify the SCL level of this message by looking for
X-MS-Exchange-Organization-SCL in the Internet Mail Headers box. You should find
X-MS-Exchange_Organization-SCL:6 which indicates an SCL rating of 6. Then click Close to close
Message Details. Close the message window.
16. In the Mail pane, click Junk E-Mail. You should see eight new messages in the Junk E-Mail folder that
have been identified as junk mail as their SCL level was more than six. You can verify this by looking
at the Message Details of the messages.
17. Delete all messages in the Inbox and Junk E-Mail folders.
X Task 3: Configure content filtering to reject junk messages

2. In Exchange Management Console, click Edge Transport.

3. In the Edge Transport pane, select VAN-SVR1, and then click the Anti-spam tab.
4. In the Anti-spam pane, double-click Content Filtering.
5. In the Content Filtering Properties window, click the Action tab.
6. In the Action tab, select the Reject messages that have an SCL rating greater than or equal to
check box, configure it to 7, and then click OK.
7. On VAN-EX1, in Exchange Management Shell, type: D:\labfiles\Lab6Prep.ps1 and then press Enter.
This will send the 11 messages again, but notice that the Content Filter agent rejects all messages as
spam if they have a SCL level of 7 or more. Thus, only three messages will reach Weis Inbox, and the
other messages should not be delivered to the users Junk E-Mail folder.

L6-44 Module 6: Implementing Messaging Security
10. In the Mail pane, click Inbox. Notice the three new messages in the Inbox.
11. To delete all messages in the Inbox, select them, and then click Delete.
X Task 4: Configure an IP Allow List

1. On VAN-SVR1, in Exchange Management Console, click the Anti-spam tab.
2. In the Anti-spam pane, double-click IP Allow List.
3. In the IP Allow List Properties window, click the Allowed Addresses tab.
4. On the Allowed Addresses tab, click Add.
5. In the Add Allowed IP Address window, type 10.10.0.10 in the Address or address range box, and
then click OK.
6. On the Allowed Address tab, click OK.
7. On VAN-EX1, in Exchange Management Shell, type: D:\ labfiles\Lab6Prep.ps1, and then press Enter.

10. In the Mail pane, click Inbox. You should see 11 new messages in the Inbox.
11. Double-click one message, and review the Message Detail. The SCL rating should be -1. When the
sending SMTP server is added to the IP Allow List, content filtering is not applied to the messages.
12. To delete all messages in the Inbox, select them, and then click Delete.
X Task 5: Configure a Block List Provider

1. On VAN-SVR1, in Exchange Management Console, click the Anti-spam tab.
2. In the Anti-spam pane, double-click IP Block List Providers.
3. In the IP Block List Properties window, click the Providers tab.
4. On the Providers tab, click Add.
5. In the Add IP Block List Provider window, type Spamhaus in the Provider name box, type
zen.spamhaus.org in the Lookup domain box, and then click OK twice.
Results: After this exercise, you should have configured different SCL levels, and verified the behavior of
junk mail in user mailboxes. You should also have configured a Block List Provider.
Lab B: Implementing Anti-Spam Solutions L6-45

following steps:

L7-46
Module 7: Implementing High Availability

Lab: Implementing High Availability
Exercise 1: Deploying a DAG
X Task 1: Create a DAG named DAG1 by using the Microsoft Exchange
Management Shell
2. At the PS prompt, type New-DatabaseAvailabilityGroup Name DAG1 WitnessServer VAN-DC1

-WitnessDirectory C:\FSWDAG1 -DatabaseAvailabilityGroupIPAddress 10.10.0.80, and then
press Enter. You can ignore the warning message.
3. At the PS prompt, type Add-DatabaseAvailabilityGroupServer DAG1 MailboxServer VAN-EX1,


6. In the Results pane, click the Database Availability Groups tab.
7. In the Work pane, on the Database Availability Groups tab, right-click DAG1, and then click
Manage Database Availability Group Membership from the context menu.
8. In the Manage Database Availability Group Membership Wizard, click Add.
9. In the Select Mailbox Server dialog box, click VAN-EX2, and then click OK.
10. In the Manage Database Availability Group Membership Wizard, click Manage to complete the
changes, wait for the installation to finish, and then click Finish to close the wizard.
X Task 2: Create a mailbox database copy of the Accounting database


3. In the Results pane, click the Database Management tab.
4. In the Results pane, click Accounting, and then in the Actions pane, click Add Mailbox
Database Copy.
5. In the Add Mailbox Database Copy Wizard, click Browse to select the server to which to add
the copy.
6. In the Select Mailbox Server dialog box, click VAN-EX2, and then click OK.
Lab: Implementing High Availability L7-47
7. In the Add Mailbox Database Copy Wizard, click Add to create the copy of the Accounting
mailbox database.
8. Review the results, and then click Finish.
X Task 3: Verify successful completion of database copying

1. In the Results pane, click the Database Management tab, and then click Accounting.
2. In the bottom Work pane, view the Copy Status column for each database copy.
3. Click the Accounting entry that has a Healthy copy status, right-click it, and then choose Properties
from the context menu.
4. View the Status, Copy queue length, and Replay queue length on the General tab, and then click
on the Status tab.
5. On the Status tab, view the Seeding, Latest available log time, Last inspected log time, Last
copied log time, and Last replayed log time properties, and then click OK.
X Task 4: Suspend the Accounting database copy on VAN-EX2

1. In the Results pane, on the Database Management tab, click Accounting.
2. In the bottom Work pane, view the Copy Status column for each database copy.
3. Click the Accounting entry that has a Healthy copy status, right-click on it, and then choose
Suspend Database Copy from the context menu.
4. In the Suspend Mailbox Database Copy dialog box, type Software Updates being applied, and
then click Yes.
5. In the bottom Work pane, view the Copy Status column for each database copy. The copy status will
turn to Suspended.
Results: After this exercise, you should have created a DAG and a mailbox database copy of the
Accounting database. The Accounting database copy on VAN-EX2 should remain in a suspended state.
Exercise 2: Deploying Highly Available Hub Transport and Client Access

Servers
X Task 1: Create and configure a client access array for CASArray.adatum.com
On VAN-EX1, in the Exchange Management Shell, at the PS prompt, type New-ClientAccessArray
Fqdn casarray.adatum.com Name CASArray.adatum.com Site Default-First-Site-Name, and
then press Enter.
X Task 2: Assign the client access array to the databases

1. At the PS prompt, type Get-MailboxDatabase | ft Name, Server, RPC*, and then press Enter.
2. At the Exchange Management Shell prompt, type Get-MailboxDatabase |Set-MailboxDatabase
RpcClientAccessServer casarray.adatum.com, and then press Enter.
3. At the PS prompt, type Get-MailboxDatabase | ft Name, Server, RPC*, and then press Enter.
Results: At the end of this exercise, you should have created a client access array and assigned it to the
databases.
L7-48 Module 7: Implementing High Availability
Exercise 3: Testing the High Availability Configuration

X Task 1: Create a SMTP connector associated with VAN-EX1 and VAN-EX2

Configuration, and then click on Hub Transport.
3. Click the Send Connectors tab, and then in the Actions pane, click New Send Connector.
4. In the Name box, type Internet Mail.

5. In the Select the intended use for this Send connector drop-down menu, select Internet, and then
click Next.
7. In the SMTP Address space dialog box, in the Address space box, type *, click OK, and then click
Next on the Address space page.
8. On the Network Settings page, click Route mail through the following smart hosts, and then
click Add.
9. In the Add smart host dialog box, click Fully qualified domain name (FQDN).
10. In the Fully qualified domain name (FQDN) box, type van-dc1.adatum.com, and then click OK.
11. On the Network settings page, click Next.
12. On the Configure smart host authentication settings page, ensure None is selected, and then
click Next.
13. On the Source server page, click Add.
14. On the Select Hub Transport or Subscribed Edge Transport Server dialog box, hold the Ctrl key,
click VAN-EX1 and VAN-EX2, and then click OK.
15. On the Source server page, click Next.
16. Click New to create the connector, and then click Finish to close the wizard.
X Task 2: Stop the SMTP server on VAN-DC1

1. On VAN-DC1, click Server Manager from the quick launch bar.
2. In the Console Tree, expand Configuration, and then click Services.

3. In the Results pane, click Simple Mail Transfer Protocol (SMTP), and then in the Actions pane,
under Simple Mail Transfer Protocol (SMTP) click More Actions, and then click Stop.
X Task 3: Send an email to an internal user and an external SMTP address

1. On VAN-EX1, open Windows Internet Explorer, and connect to https://VAN-EX1.adatum.com
/owa.
2. Log on as Adatum\Jason with a password of Pa$$w0rd. Jasons mailbox is on VAN-EX3.
3. On the Microsoft Outlook Web Access (OWA) language and time zone settings page, click OK.
4. Click New to create a new email message.
5. In the To box, type terry@contoso.com; jane@adatum.com;.
6. In the Subject box, type Shadow Redundancy.
7. In the message body, type Test email, and then click Send.
X Task 4: Use Queue Viewer to locate the message in the queue

1. On VAN-EX2, in the Exchange Management Console, click Toolbox.
2. In the Results pane, double-click Queue Viewer.
3. On the Queues tab, locate the entry with van-dc1.adatum.com as the next hop domain. If the
message is not visible, then complete the following steps:
a. Click Connect to Server in the Actions pane.
b. On the Connect to Server dialog box, click Browse.
c. On the Select Exchange Server dialog box, click VAN-EX1, click OK, and then click Connect.
d. On the Queues tab, locate the entry with the van-dc1.adatum.com as the next hop domain.
4. In the Actions pane, click Connect to Server.
5. On the Connect to Server dialog box, click Browse.

6. On the Select Exchange Server dialog box, click VAN-EX3, click OK, and then click Connect.
7. Click the Queues tab, and then click Create Filter.
8. In the first drop-down menu, select Delivery Type.
9. In the second drop-down menu, select Equals.
10. In the third drop-down menu, select Shadow Redundancy.
11. Click Apply Filter.

12. Examine the shadow-redundancy queue contents.
13. Click on the Messages tab, and then click Create Filter.
14. In the first drop-down menu, select From Address.
15. In the second drop-down menu, select Equals.
16. In the third drop-down menu, type Jason@adatum.com.
17. Click Apply Filter.
18. Examine the message in the VAN-EX3\Shadow queue.
X Task 5: Start SMTP service on VAN-DC1 to allow delivery of the queued message
1. On VAN-DC1, in Server Manager, expand Configuration, and then click on Services.
2. In the Results pane, click Simple Mail Transport Protocol (SMTP), and then in the Actions pane,
under Simple Mail Transfer Protocol (SMTP), click More Actions, and then click Start.
L7-50 Module 7: Implementing High Availability
X Task 6: Verify that the messages were removed from the shadow redundancy queue
1. On VAN-EX2, in the Queue Viewer, verify that you are connected to VAN-EX3.
2. Click the Queues tab, and verify that the Shadow Redundancy filter is still being applied.
3. Examine the contents of the shadow redundancy queue.
Note You may need to wait a few minutes for the message to be removed from the
Shadow redundancy queue.
X Task 7: Verify the copy status of the Accounting database, and resume the database
copy
1. On VAN-EX1, in the Exchange Management Console, locate the Console Tree, expand Organization
2. In the Results pane, click the Database Management tab, and then click Accounting.
3. In the bottom Work pane, view the Copy Status column for each database copy, click the Accounting
entry that has a Suspended copy status, right-click on it, and then choose Properties from the
context menu.
4. View the Status, Copy queue length, and Replay queue length on the General tab, and then click
on the Status tab.
5. On the Status tab, view the Seeding, Latest available log time, Last inspected log time, Last
copied log time, and Last replayed log time properties, and then click OK.
6. Click the Accounting entry that has a Suspended copy status, right-click on it, and then choose
Resume Database Copy from the context menu.
7. On the Resume Mailbox Database Copy dialog box, click Yes.
8. Wait until the copy status of the Accounting database copy on VAN-EX2 is Healthy. You may need to
refresh the display.
X Task 8: Perform a switchover on the Accounting database to make the VAN-EX2

copy active
1. In the bottom Work pane, view the Copy Status column for each database copy, click the Accounting
entry that has a Healthy copy status, right-click on it, and then choose Activate Database Copy
from the context menu.
2. In the Activate Database Copy dialog box, verify None is selected, and then click OK.
X Task 9: Simulate a server failure

1. On VAN-EX1, in the Results pane, click the Database Management tab. Wait until the Accounting
database copy status for VAN-EX1 is Healthy.
2. In Hyper-V Manager, select 10135B-VAN-EX2, and then click Revert in the Actions pane. In the
Revert Virtual Machine dialog box, click Revert.
3. View the status of the Accounting database in the Results pane. The database copy on VAN-EX1 will
change to a Mounted status, and the database copy on VAN-EX2 will have a ServiceDown status.
Results: After this exercise, you should have verified that the mailbox databases could fail over and switch
between DAG servers, and that Hub Transport shadow redundancy is working properly.

following steps:

L8-52
Module 8: Implementing Backup and Recovery

Lab: Implementing Backup and Recovery
Exercise 1: Backing Up Exchange Server 2010
X Task 1: Populate a mailbox
1. On VAN-EX1, click Start, point to All Programs, and then click Internet Explorer.
2. In the Address bar, type https://VAN-EX1.adatum.com/owa, and then press Enter.
3. Log on as Adatum\Parna with the password Pa$$w0rd.
4. Click OK to accept the default Microsoft Outlook Web App settings.
5. Click New to create a new message.
6. In the To box, type George; Parna.
7. In the Subject box, type Message before Backup, and then click Send.

10. At the PS prompt, type Restart-Service MSExchangeIS, and then press Enter.
X Task 2: Perform a backup of the mailbox database by using Windows Server Backup
1. On VAN-EX1, click Start, click Administrative Tools, and then click Server Manager.
2. In Server Manager, click Features, and then on the Features Summary pane, click Add Features.
3. In the Add Features Wizard, expand Windows Server Backup Features, click Windows Server
Backup, and then click Next.
4. On the Confirm Installation Selections page, click Install. When the installation finishes, click Close.
5. Click Start, click Administrative Tools, and then click Windows Server Backup.
6. In Windows Server Backup, on the Actions pane, click Backup Once.
7. In the Backup Once Wizard, on the Backup Options page, select Different options, and then click
Next.
8. On the Select Backup Configuration page, select Custom, and then click Next.
9. On the Select Items for Backup page, click Add items, check Local disk (C:) in the Select Items
window, and then click OK.
10. On the Select Items for Backup page, click Advanced Settings, click on the VSS Settings tab, select
VSS full Backup, click OK, and then click Next.
11. On the Specify Destination Type page, select Remote shared folder, and then click Next.
12. On the Specify Remote Folder page, in the Location field, type \\VAN-DC1\Backup, and then click
Next.
Lab: Implementing Backup and Recovery L8-53
13. On the Confirmation page, click Backup. The backup will take approximately 15 to 20 minutes.
14. On the Backup Progress page, click Close.
X Task 3: Delete messages in mailboxes

3. Log on as Adatum\George with the password Pa$$w0rd.
5. Right-click the message with the subject Message before Backup, and then click Delete.
6. In the left pane, right-click Deleted Items, and then click Empty Deleted Items.
7. In the Empty Deleted Items box, click Yes.
9. Open Internet Explorer and connect to https://VAN-EX1.adatum.com/owa, and then press Enter.

11. Click Sent Items, and delete all messages in the folder.
12. In the left pane, right-click Deleted Items, and then click Empty Deleted Items.
13. In the Empty Deleted Items box, click Yes.

Results: After this exercise, you should have created a backup of an Exchange Server database, and
deleted messages.
Exercise 2: Restoring Exchange Server Data

X Task 1: Restore the database using Windows Backup
1. On VAN-EX1, click Start, click Administrative Tools, and then click Windows Server Backup.
2. In Windows Server Backup, on the Actions pane, click Recover.
3. In the Recovery Wizard, on the Getting Started page, select This server (VAN-EX1), and then click
Next.
4. On the Select Backup Date page, click Next.
5. On the Select Recovery Type page, select Applications, and then click Next.
6. On the Select Application page, select Exchange, and then click Next.
7. On the Specify Recovery Options page, click Recover to another location, click Browse, expand
Computer, click Local Disk (C:), click Make New Folder, enter DBBackup, click OK, and then click
Next.
L8-54 Module 8: Implementing Backup and Recovery
8. On the Confirmation page, click Recover.
9. On the Recovery Progress page, wait until the restore is completed, and then click Close. Close
Windows Server Backup.
X Task 2: Create a recovery database by using the backup files

1. On VAN-EX1, at the Exchange Management Shell prompt, type New-MailboxDatabase
-Name RecoverDB -Server VAN-EX1 -EDBFilePath c:\DBBackup\C_\Program Files
\Microsoft\Exchange Server\V14\Mailbox\Accounting\Accounting.edb -Logfolderpath
c:\DBBackup\C_\Program Files\Microsoft\Exchange Server\V14\Mailbox\Accounting
-Recovery, and then press Enter.
2. At the Exchange Management Shell prompt, type cd c:\dbbackup\c_\Program Files

\Microsoft\Exchange Server\v14\Mailbox\Accounting, and then press Enter.
3. At the Exchange Management Shell prompt, type eseutil /R E02 /i /d, and then press Enter.
4. At the Exchange Management Shell prompt, type Mount-Database RecoverDB, and then
press Enter.
5. At the Exchange Management Shell prompt, type Get-MailboxStatistics-Database RecoverDB,

X Task 3: Recover a mailbox from the recovery database

1. At the Exchange Management Shell prompt, type Restore-Mailbox -Identity Parna
-RecoveryDatabase RecoverDB, and then press Enter.
2. At the Confirm prompt, type Y, and then press Enter.
6. Verify that the deleted message is available in the Sent Items folder.
8. At the Exchange Management Shell prompt, type Remove-Mailboxdatabase -Identity RecoverDB,

and then press Enter. Type Y, and then press Enter.
Results: After this exercise, you should have created a recovery database, and restored a complete
mailbox from the recovery database to their original locations.
Exercise 3: Restoring Exchange Servers (optional)

X Task 1: Shutdown VAN-EX1, and reset the computer account
1. On the host computer, open Microsoft Hyper-V Manager, right-click 10135B-VAN-EX1, and then
click Revert.

3. On VAN-DC1, click Start, point to Administrative Tools, and then click Active Directory Users and
Computers.
4. Click Adatum.com, in results pane click Computers.
5. In the right pane, right-click VAN-EX1, click Reset Account, and then in the Active Directory
Domain Services dialog box, click Yes, and then click OK.
6. Close Active Directory Users and Computers.
X Task 2: Prepare VAN-SVR1 as VAN-EX1

1. On VAN-SVR1, click Start, right-click Computer, and then click Properties.
2. In the System window, in the Computer name, domain, and workgroup settings pane, click Change
settings.
3. On the Computer Name tab, click Change.
4. In the Computer Name/Domain Changes dialog box, in the Computer name field, type VAN-EX1,
and then click OK.
5. In the System Properties dialog box, click OK, click Close, and then click Restart Now to restart the
computer.
6. After the computer restarts, log on as Administrator using the password Pa$$w0rd.
7. Click Start, right-click Computer, and then click Properties.
8. In the System window, in the Computer name, domain, and workgroup settings pane, click Change
settings.
9. On the Computer Name tab, click Change.
10. Under Member of, click Domain, type Adatum.com, and then click OK.
11. In the Computer Name/Domain Changes dialog box, in the User name field, type Administrator.
12. In the Password field, type Pa$$w0rd, and then click OK.
13. In the Computer Name/Domain Changes dialog box, click OK, and then click OK again.
14. In the System Properties dialog box, click OK, click Close, and then click Restart Now to restart the
computer.
15. After the computer restarts, log on as adatum\Administrator using the password Pa$$w0rd.
X Task 3: Install Exchange Server 2010 with the RecoverServer mode

1. On VAN-SRV1, click Start, click Run, and then in the Open box, type d:\setup /m:RecoverServer,
and then press Enter. The installation takes approximately 15 minutes.
3. In Exchange Management Console, click Microsoft Exchange On-Premises (van-ex1.adatum.com),

expand Organization Configuration, and then click Mailbox.
4. In the Mailbox pane, on the Database Management tab, right-click Accounting, and then click
Properties.
L8-56 Module 8: Implementing Backup and Recovery
5. In Accounting Properties, click on the Maintenance tab, click This database can be overwritten by
a restore, and then click OK.
6. Repeat steps 4 and 5 for Mailbox Database 1.
7. In the Mailbox pane, on the Database Management tab, right-click Public Folder Database 1, and
then click Properties.
8. In Public Folder Database 1 Properties, on the General tab, click This database can be overwritten
by a restore, and then click OK.
X Task 4: Recover the mailbox databases from backup

1. On VAN-SVR1, click Start, click All Programs, click Administrative Tools, and then click Windows
Server Backup.
2. In Windows Server Backup, on the Actions pane, click Recover.
3. In the Recovery Wizard, on the Getting Started page, select A backup stored on another location,
4. On the Specify Location Type page, click Remote shared folder, and then click Next.
5. On the Specify Remote Folder page, type \\van-dc1\backup, and then click Next.
6. On the Select Backup Date page, click Next.

7. On the Select Recovery Type page, select Applications, and then click Next.
8. On the Select Application page, select Exchange, and then click Next.
9. On the Specify Recovery Options page, click Recover to original location, and then click Next.
10. On the Confirmation page, click Recover.
11. On the Recovery Progress page, click Close.
X Task 5: Test the recovery

1. On VAN-SVR1, in Exchange Management Console, under Organization Configuration, click
Mailbox.
2. In the Mailbox pane, on the Database Management tab, check if the Accounting database is
mounted. If it is not mounted, right-click Accounting, and then click Mount Database.
3. If required, mount Mailbox Database 1 and Public Folder Database 1.
4. On VAN-DC1, click Start, point to All Programs, and then click Internet Explorer.
6. Click Continue to this website (not recommended).

7. Log on as Adatum\Parna with a password of Pa$$w0rd, and then click OK.
8. Verify that the mailbox is accessible.
Results: After this exercise, you should have recovered a complete Exchange server by using a different
Windows Server, renaming it, installing Exchange Server in /m:RecoverServer mode, and recovering the
Exchange Server database from a backup. You have also tested the recovery.

following steps:
1. On the host computer, start Microsoft Hyper-V Manager.

L9-58
Module 9: Configuring Messaging Policy and Compliance

Lab A: Configuring Transport Rules, Journal
Rules, and Multi-Mailbox Search
Exercise 1: Configuring Transport Rules
X To start the lab, complete the following steps
2. Expand Microsoft Exchange On-Premises, expand Organization Configuration, and then click
Hub Transport.
4. On the Introduction page, type Internet Connector as the connector name. In the Select the
intended use for this Send connector drop-down list, click Internet, and then click Next.

6. In the Address field, type *, click OK, and then click Next.
7. On the Network settings page, click Route mail through the following smart hosts, and then
click Add.
8. In the IP address field, type 10.10.0.10, click OK, and then click Next.
10. On the Source Server page, click Next, click New, and then click Finish.
X Task 1: Create a transport rule that adds a disclaimer to all messages sent to
the Internet
1. On VAN-EX1, in the Exchange Management Console, expand Organization Configuration, click
Hub Transport, and then click New Transport Rule.
2. On the Introduction page, in the Name box, type Internet E-Mail Disclaimer, and then click Next.
3. On the Conditions page, in the Step 1: Select condition(s) area, select the sent to users that are
inside or outside the organization, or partners check box.
4. In the Step 2: Edit the rule description by clicking an underlined value area, click Inside the
organization.
5. In the Select scope dialog box, under Scope, click Outside the organization, and then click OK.
6. On the Conditions page, click Next.
7. On the Actions page, in the Step 1: Select Action(s) area, select append disclaimer text and
fallback to Action if unable to apply.
8. In the Step 2: Edit the rule description by clicking an underlined value area, click disclaimer text.
9. In the Specify disclaimer text box, type This e-mail is intended solely for the use of the
individual to whom it is addressed. and then click OK.
Lab A: Configuring Transport Rules, Journal Rules, and Multi-Mailbox Search L9-59
10. On the Actions page, click Next.
11. On the Exceptions page, click Next, review the rule description, click New, and then click Finish.
X Task 2: Create a transport rule for the CustomerService distribution group

1. On VAN-EX1, in the Exchange Management Console, in the Actions pane, click New Transport Rule.
2. On the Introduction page, in the Name box, type Customer Service Tracking, and then click Next.
3. On the Conditions page, in the Step 1: Select condition(s) area, select the sent to users that are
inside or outside the organization, or partners check box.
4. In the Step 2: Edit the rule description by clicking an underlined value area, click Inside the
organization.
5. In the Select scope dialog box, under Scope, click Outside the organization, and then click OK.
6. On the Conditions page, in the Step 1: Select condition(s) area, select the when the Subject field
or message body contains specific words check box.
7. In the Step 2: Edit the rule description by clicking an underlined value area, click specific words.
8. In the Specify words dialog box, type Customer, click Add, and then click OK.
9. On the Conditions page, click Next.
10. On the Actions page, in the Step 1: Select Action(s) area, select the copy the message to
addresses check box.
11. In the Step 2: Edit the rule description by clicking an underlined value area, click addresses.
12. In the Specify recipients dialog box, click Add, click CustomerService, and then click OK.
13. On the Exceptions page, select the except when the message is from a member of distribution
list.
14. In the Step 2: Edit the rule description by clicking an underlined value area, click distribution
list.
15. In the Select Mail-Enabled Group dialog box, click CustomerService, and then click OK twice.
16. On the Exceptions page, click Next, review the rule description, click New, and then click Finish.
X Task 3: Enable AD RMS integration for the organization

1. On VAN-DC1, open Windows Explorer, browse to C:\inetpub\wwwroot\_wmcs\certification,
right-click servercertification.asmx, and then click Properties.
2. In the Server Certification.asmx Properties dialog box, on the Security tab, click Edit.
3. In the Permissions for Server Certification.asmx dialog box, click Add.
4. In the Select Users, Computers, Service Accounts, or Groups dialog box, click Object Types, select
the Computers check box, and then click OK.
5. In the Enter the object names to select field, type Exchange Servers , and then click OK.
6. Click Add. In the Enter the object names to select field, type IIS_IUSRS, and then click OK three
times.
L9-60 Module 9: Configuring Messaging Policy and Compliance
7. On VAN-DC1, open a command prompt, type IISReset, and then press Enter. Wait for the service to
restart, and then close the command prompt.
8. On VAN-EX1, in the Exchange Management Shell, at the PS prompt, type

set-irmconfiguration InternalLicensingEnabled $true, and then press Enter. This cmdlet enables
AD RMS encryption for messages sent inside the organization.
X Task 4: Configure a transport rule that applies the Do Not Forward AD RMS template
to all messages with the words confidential or private in the subject
1. On VAN-EX1, in the Exchange Management Console, under Organization Configuration, click Hub
Transport.
2. In the Actions pane, click New Transport Rule.
3. On the Introduction page, in the Name field, type Confidential E-Mail Rule.
4. Verify that Enable Rule is selected, and then click Next.
5. On the Conditions page, under Step 1, select the when the Subject field contains specific words
check box.
6. Under Step 2, click the specific words link.
7. In the Specify words dialog box, type Confidential, click Add, type Private, click Add, and then
click OK.
8. Click Next.
9. On the Actions page, under Step 1, select rights protect message with RMS template.
10. Under Step 2, click the RMS Template link.
11. In the Select RMS template dialog box, click Do not Forward, and then click OK.
12. Click Next twice, click New, and then click Finish.
X Task 5: Configure a moderated group

1. On VAN-EX1, in the Exchange Management Console, under Recipient Configuration, click
Distribution Group.
2. In the middle pane, right-click All Company, and then click Properties.
3. On the Mail Flow Settings tab, double-click Message Moderation.
4. In the Message Moderation dialog box, select the Messages sent to this group have to be
approved by a moderator check box.
5. Under Specify group moderators, click Add.
6. In the Select Recipient Entire Forest dialog box, click Andreas Herbinger, and then click OK
three times.
X Task 6: Test the transport rule configuration

1. On VAN-CL1, open Microsoft Outlook 2010.
2. Create a new message, and then send it to Carol@contoso.com.

3. Create another message to Carol, with a subject of Customer Information and then send the
message.
4. On VAN-DC1, open Windows Explorer. Browse to C:\inetpub\mailroot\queue folder. Double-click
the first EML file in the folder.
click OK. Click Notepad, and then click OK.
6. Scroll to the middle of the message, and verify that the disclaimer has been added to the message.
7. On VAN-CL1, open Windows Internet Explorer and connect to https://van-ex1.adatum.com/owa.
Log on as Adatum\Anna, using the password Pa$$w0rd. Anna is a member of the CustomerService
distribution group. Click OK.
8. Verify that a copy of second message sent by Luca is in the Inbox. Close Internet Explorer.
9. In Outlook, create a new message, and then send it to the All Company distribution group.
10. Open Windows Internet Explorer, and connect to https://van-ex1.adatum.com/owa. Log on as
Adatum\Andreas using the password Pa$$w0rd. Click OK.
11. Double-click the email message to open it, and then click Approve.
12. In Outlook, verify that the message to the All Company distribution list has arrived.
13. In Outlook Web App, create a new message with a subject of Private. Send the message to Luca.
15. In Outlook, verify that Luca received the message with the subject Private. If prompted for
credentials, enter Luca as the user name and Pa$$w0rd as the password. Double-click the message
and wait for AD RMS to be configured on the computer. Verify that the message has the Do Not
Forward template applied. Verify that the Forward option is not available on the message.
Results: After this exercise, you should have configured a transport rule that ensures that all messages
sent to users on the Internet include a disclaimer of which the legal department approves. Additionally,
you should have configured a transport rule that sends a copy of all messages with customer information
to the CustomerService group, and you should have configured a transport rule that applies the Do Not
Forward AD RMS template to all messages with the words confidential or private in the subject. Lastly,
you should have configured a moderated group using the All Company distribution group.
Exercise 2: Configuring Journal Rules and Multi-Mailbox Search

X Task 1: Create a mailbox for the Executives department journaling messages
1. On VAN-EX1, in the Exchange Management Console, click Recipient Configuration.
2. In the Actions pane, click New Mailbox to start the New Mailbox Wizard.
3. On the Introduction page, ensure that User Mailbox is selected, and then click Next.
4. On the User Type page, click Next.
5. On the User Information page, type the following information:
First name: Executives Journal Mailbox
User Logon name (User Principal Name): ExecutivesJournal
Password: Pa$$w0rd
6. Click Next.
7. On the Mailbox Settings page, type ExecutivesJournal as the Alias.
8. Select the Specify the mailbox database rather than using a database automatically accepted
check box, click Browse, click Mailbox Database 1, click OK, and then click Next.

10. On the New Mailbox page, click New, and then click Finish.
X Task 2: Create a journal rule that saves a copy of all messages sent to and from
Executives department members
1. In the Exchange Management Console, in the Organization Configuration work area, click
Hub Transport.
2. In the Actions pane, click New Journal Rule to start the New Journal Rule Wizard.
3. On the New Journal Rule page, in the Rule name box, type Executives Department Message
Journaling.
4. Beside Send Journal reports to e-mail address, click Browse, click Executives Journal Mailbox,
and then click OK.
5. Under Scope, ensure Global all messages is selected.
6. Select the Journal messages for recipient check box, and then click Browse.
7. In the Select Recipient dialog box, click Executives, and then click OK.
8. On the New Journal Rule page, click New, and then click Finish.
X Task 3: Create and configure the MailboxAuditor account

1. On VAN-EX1, in the Exchange Management Console, click Recipient Configuration.
2. In the Actions pane, click New Mailbox to start the New Mailbox Wizard.
3. On the Introduction page, ensure that User Mailbox is selected, and then click Next.
5. On the User Information page, type the following information:

First name: Mailbox Auditor
User Logon name (User Principal Name): MailboxAuditor
Password: Pa$$w0rd
6. Click Next.
7. On the Mailbox Settings page, type MailboxAuditor as the Alias.
8. Select the Specify the mailbox database rather than using a database automatically accepted
check box, click Browse, click Mailbox Database 1, click OK, and then click Next.

10. On the New Mailbox page, click New, and then click Finish.
11. In the recipient list, click Executives Journal Mailbox, and then click Manage Full Access
Permission.
12. On the Manage Full Access Permission page, click Add, click Mailbox Auditor, and then click OK.
13. Click Manage, and then click Finish.

14. On VAN-DC1, open Active Directory Users and Computers, and then in the Microsoft Exchange
Security Groups OU, double-click the Discovery Management group.
15. In the Discovery Management Properties dialog box, on the Members tab, click Add.
16. Type Mailbox Auditor, and then click OK twice.
X Task 4: Configure legal hold on a mailbox

1. Double-click George Schaller. On the Mailbox Settings tab, double-click Messaging Records
Management.
2. Select the Enable Litigation Hold check box, and then click OK three times.
X Task 5: Test the journal rule and Multi-Mailbox Search configuration

1. On VAN-CL1, if required, open Outlook.
2. Create a new message, and then send it to Marcel Truempy. Marcel is a member of the Executives
group.
3. Open Internet Explorer, and then connect to https://VAN-EX1.adatum.com/owa. Log on as

Adatum\Marcel with the password Pa$$w0rd. Confirm that the message from Luca arrived. Reply to
the message, and then close Internet Explorer.
4. Open a new instance of Internet Explorer, and then connect to https://VAN-EX1.adatum.com/owa.

Log on as Adatum\MailboxAuditor with the password Pa$$w0rd.
5. In the left pane, right-click Mailbox Auditor, and then click Open Other Users Inbox.
6. Type Executives Journal Mailbox, and then click OK twice. Under Executives Journal Mailbox,
click Inbox. Verify that the two journaled messages are in the mailbox. Close Internet Explorer.
7. In Outlook, create and send a new message with the following configuration:
To: George; Carol@contoso.com
Subject: Customer Order
Message body: Here is the order for Carol at Contoso. Her customer number is 1111-1111.
8. Open Internet Explorer, and then connect to https://VAN-EX1.adatum.com/owa. Log on to
Outlook Web App as Adatum\George, with the password, Pa$$w0rd.
9. Click the message from Luca, and then click Delete.
10. Click the Deleted Items folder, and then click Empty.
11. Under George Schaller, right-click the Deleted Items folder, and then click Recover Deleted Items.
12. Click the message, and then click the Delete button. Click OK to permanently delete the message,
and close all Internet Explorer Windows.
13. Open Internet Explorer, and connect to Outlook Web App. Log on as MailboxAuditor. Click
Options, and then click See All Options.
14. In the Select what to manage drop-down list, ensure that My Organization is listed.
15. In the left pane, click Mail Control, and then under Multi-Mailbox Search, click New.
16. In the Keywords box, type Customer Number.

17. Expand Mailboxes to Search.
18. Under Select the mailboxes to search, click Add. In the Select Mailbox window, click Luca
Dellamore, and then click Add. Click George Schaller, click Add, and then click OK.
19. Expand Search Name and Storage Location.
20. In the Search name field, type Customer Number Discovery.
21. Click Copy the search results to the destination mailbox.

22. Next to Select a mailbox in which to store the search results, click Browse.
23. In the Select Mailbox window, click Discovery Search Mailbox, and then click OK.
24. Select the Send me an e-mail when the search is done check box, and then click Save.
25. Wait until the search finishes, and then in the bottom right pane, click the Open link.
26. In the Outlook Web App window, click OK.
27. In the Navigation pane, notice the new discovery folder named Customer Number Discovery.
Expand the folder.
28. Note the two folders created that correspond to the mailboxes added to the search criteria.
29. Expand Luca Dellamore, expand Primary Mailbox, expand Sent Items, and then verify that the
email was discovered using the search criteria.
30. Expand George Schaller, expand Primary Mailbox, expand Inbox, and then verify that the email
was discovered using the search criteria.
Results: After this exercise, you should have created a mailbox for the Executives department journaling
messages, and then created a journal rule that saves a copy of all messages sent to and from Executives
department members. You also should have created and configured the MailboxAuditor account.

L9-65
Lab B: Configuring Messaging Records

Management and Personal Archives
Exercise 1: Configuring Personal Archives
X Task 1: Create an archive mailbox for all members of the Marketing group
1. On VAN-EX1, in the Exchange Management Console, click Recipient Management, and then
click Mailbox.
2. In the Results pane, click the Organization Unit heading to sort the mailbox list by OU.
3. Select all of the mailboxes in the Executives and Marketing OUs, right-click, click Enable Archive,
and then click OK.
X Task 2: Verify that the archive mailbox was created for members of the Marketing
group
Open Internet Explorer, and then connect to https://VAN-EX1.adatum.com/owa. Log on as
Adatum\Manoj with the password Pa$$w0rd. Click OK. Verify that the archive mailbox is visible
through Outlook Web App.
Results: After this exercise, you should have configured archive mailboxes for all members of the
Marketing group.
Exercise 2: Configuring Retention Policies

X Task 1: Create and configure retention tags
click Mailbox.
2. In the Actions pane, click New Retention Policy Tag.

3. In the Tag name field, type Adatum - Deleted Items.
4. In the Tag Type drop-down list, select Deleted Items.
5. In the Age limit for retention (days) field, type 30.
6. In Action to take when the age limit is reached, select Permanently Delete.
7. In the Comments field, type Deleted Items are purged after 30 days.
10. In the Tag name field, type Adatum DefaultMoveToArchive.
11. In the Tag Type drop-down list, select All other folders in the mailbox.
13. In Action to take when the age limit is reached, select Move To Archive.
14. In the Comments field, type Messages are moved to the archive after one year.
17. In the Tag name field, type Adatum Business Critical.
18. In the Tag Type drop-down list, select Personal Tag.
20. In Action to take when the age limit is reached, select Move To Archive.
21. In the Comments field, type Business critical messages are moved to the archive after
three years.
X Task 2: Create and configure retention policies for the Marketing group
click Mailbox.
2. In the Actions pane, click New Retention Policy.

3. In the Name field, type Marketing Group Retention, and then click Add.
4. Select both the Adatum DefaultMoveToArchive and Adatum - Deleted Items tags, click OK, and
then click Next.
5. On the Select Mailboxes page, click Add.
6. In Select Mailbox Entire Forest, click Scope menu, and then click Modify Recipient Picker
Scope.
7. Click View all recipients in specified organizational unit, and then click Browse.
8. Click Marketing, and then click OK twice.
9. After the scope changes, select all users in the list, and then click OK.
X Task 3: Create and configure retention policies for the Executives group
click Mailbox.
2. In the Actions pane, click New Retention Policy.
3. In the Name field, type Executive Group Retention, and then click Add.
4. Select the Adatum DefaultMoveToArchive, Adatum Business Critical and Adatum - Deleted
Items tags, click OK, and then click Next.
5. On the Select Mailboxes page, click Add.
6. In Select Mailbox Entire Forest, click Scope menu, and then click Modify Recipient Picker
Scope.
7. Click View all recipients in specified organizational unit, and then click Browse.
Lab B: Configuring Messaging Records Management and Personal Archives L9-67
8. Click Marketing, and then click OK twice.
9. After the scope changes, select all users in the list, and then click OK.
Results: After this exercise, you will have configured Retention Tags and retention policies for the

following steps:

L10-68
Module 10: Securing Microsoft Exchange Server 2010

Lab 10: Securing Exchange Server 2010
Exercise 1: Configuring Exchange Server Permissions
X Task 1: Configure permissions for the ITAdmins group
1. On VAN-EX1, open Active Directory Users and Computers.
2. Expand Adatum.com, click Microsoft Exchange Security Groups, and then double-click Server
Management.
3. On the Members tab, click Add.
4. In the Enter the object names to select field, type ITAdmins, and then click OK twice.
X Task 2: Configure permissions for HRAdmins and Support Desk groups

1. On VAN-EX1, open the Exchange Management Shell. In the Exchange Management Shell, at the PS
prompt, type the following command, and then press Enter:
New-RoleGroup Name HRAdmins roles Mail Recipients
2. At the PS prompt, type the following command, and then press Enter:
New-RoleGroup Name SupportDesk roles Mail Recipients, Mail Recipient Creation,
Distribution Groups

4. Expand Microsoft Exchange On-Premises, and then click Toolbox.
5. Double-click Role Based Access Control (RBAC) User Editor.
6. Log on as Adatum\administrator using the password Pa$$w0rd.
7. Click SupportDesk, and then click Details.
8. Under Members, click Add.
9. On the Select Member page, select Anna Lidman, click Add, and then click OK.
10. Click Save.
11. Click HRAdmins, and then click Details.
12. Under Members, click Add.
13. On the Select Member page, select Paul West, click Add, click OK, and then click Save.
14. Close Windows Internet Explorer
X Task 3: Verify the permissions

1. On VAN-EX2, log on as Shane using the password Pa$$w0rd.
2. Open the Exchange Management Console, and then click Yes.

Lab: Securing Exchange Server 2010 L10-69
3. In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand

Organization Configuration, click Mailbox, and in the Results pane, double-click the Accounting
mailbox database.
4. On the Limits tab, clear the Issue warning at (MB) check box, and then click OK.
5. Under Organization Configuration, click Hub Transport. Verify that many of the tabs normally
shown in this view are not available. On the Accepted Domains tab, double-click Adatum.com.
Verify that you cannot modify the settings, and then click Cancel.
6. Expand Recipient Configuration, click Mailbox, double-click one of the mailboxes, verify that you
cannot modify the mailbox properties, and then click Cancel.
7. Log off on VAN-EX2.
8. On VAN-EX1, open Internet Explorer, and connect to https://van-ex1.adatum.com/ecp.

9. Log on as Adatum\Anna using a password of Pa$$w0rd, and then click OK.
10. On the Mailboxes tab, click Andreas Herbinger, and then click Details.
11. Click Organization, in the Department field, type IT, and then click Save.
12. Click Distribution Groups. Click Accounting, and then click Details. Verify that you can modify the
group properties by typing a group description, and then clicking Save. Close Internet Explorer.
Note You cannot create or delete user accounts and mailboxes in Exchange Control Panel.
If you want to test whether Anna can create user accounts and mailboxes, add Anna to the
local Administrators account on VAN-EX2, and log on to VAN-EX2 as Anna. Then open
Exchange Management Console and verify that you can create a mailbox. In a production
environment, you could install the Exchange Management tools on a Windows 7 client
computer.
13. On VAN-EX1, open Internet Explorer, and connect to https://van-ex1.adatum.com/ecp.

14. Log on as Adatum\Paul using the password Pa$$w0rd, and then click OK.
15. On the Mailboxes tab, click Franz Kohl, and then click Details.
16. Click Organization, in the Department field, type Customer Service, and then click Save.
17. Verify that the Distribution Groups tab is not visible. Close Internet Explorer.
Results: After this exercise, you should have configured and verified permissions in the Exchange Server
deployment.
Exercise 2: Configuring Audit Logging

X Task 1: Create and configure an Info@Adatum.com mailbox
1. On VAN-EX1, in the Exchange Management Console, expand Microsoft Exchange On-Premises,
expand Recipient Configuration, and then click Mailbox.
3. On the Introduction page, click Next.

L10-70 Module 10: Securing Microsoft Exchange Server 2010
5. On the User Information page, fill in the following information, and then click Next.
Select the Specify the organizational unit rather than using the default one, click Browse,
click CustomerService, and then click OK.
Name: Info
User logon name (User Principal Name): Info

Password and confirm password: Pa$$w0rd
6. On the Mailbox Settings page, click Next.
7. Click Next twice, click New, and then click Finish.
8. Right-click Info, and then click Manage Full Access Permission.
9. Click Add, click Adatum\CustomerService, click OK, and then click Manage, and then click Finish.
10. Repeat the above steps for the Manage Send As Permission.
X Task 2: Enable audit logging on the Info@Adatum.com mailbox

2. In the Exchange Management Shell, run the following cmdlet:
Set-Mailbox -Identity "Info" -AuditDelegate SendAs,SendOnBehalf

-AuditEnabled $true
3. Minimize the Exchange Management Shell.
X Task 3: Perform SendAs activity on the Info@Adatum.com mailbox

1. On VAN-EX1, open Internet Explorer, and then connect to https://van-ex1.adatum.com/owa.
2. Log on as Adatum\Anna using the password Pa$$w0rd. If the Regional Settings page appears,
click OK.
3. Click New, and then in the Untitled Message window, click Options.
4. Click Show From, and then click OK.
5. In the From field, delete Anna Lidman, and then type Info@Adatum.com.
6. In the To field, type administrator.
7. In the Subject field, type test message.
8. In the message body, write some text, and then click Send.
9. Close Microsoft Outlook Web App.
Note If you get an error message that Anna does not have permission to send as the Info
mailbox, stop and restart the Microsoft Exchange Information Store service on VAN-EX2,
and repeat this task.
X Task 4: Verify that the activity is logged

1. On VAN-EX1, open Internet Explorer, and then connect to https://VAN-EX1.adatum.com/ecp.
2. Log on as Adatum\Administrator using the password Pa$$w0rd.Click Roles and Auditing.
3. Click Auditing.
4. Click Run a non-owner mailbox access report.
5. In the Start date field, enter yesterdays date.
6. In the End date field, enter tomorrows date.
7. Click Select Mailboxes.
8. Find the Info mailbox, click Add, and then click OK.
9. In the Search for access by drop-down list, select All non-owners, and then click Search.
10. Verify that in the Search Results box, the Info mailbox appears, and that in the Details box, there is a
description of the activity that you performed in Task 3.
11. Click Close
12. Exit the Exchange Control Panel.
X Task 5: Verify the administrator audit logging configuration

1. On VAN-EX1, restore the Exchange Management Shell, and run the following cmdlet:
Get-AdminAuditLogConfig
2. In the results list, verify that AdminAuditLogEnabled is set to True. Review the other values in
the list.
3. Minimize the Exchange Management Shell.
X Task 6: Make a change to Michiyo Satos mailbox

2. Expand Recipient Configuration, click Mailbox, find Michiyo Sato on the list in the central pane,
right-click Michiyo Sato, and then select Properties.
3. Click the Mailbox Settings tab, click Storage Quotas, and then click Properties.
4. In the Deleted Item retention section, clear the Use mailbox database defaults check box, and
then in the Keep deleted items for (days) field, type 20.
5. Click OK twice.
6. Minimize the Exchange Management Console.
X Task 7: Verify that the change was logged

1. On VAN-EX1, restore the Exchange Management Shell, and run the following cmdlet:
Search-AdminAuditLog -Cmdlets Set-Mailbox -StartDate 01/01/2011 -EndDate (Tomorrows

date using the mm/dd/yyyy format)
2. Review the results, and ensure they contain the action performed in Task 6. You might also see logs
about other actions on this account.
Note If no results are returned when you search the administrator audit log, wait a few
minutes and repeat this task. It can take up to five minutes for the change to appear in the
audit log.
X To prepare for the next exercise

1. On the host computer, in Hyper-V Manager, right-click 10135B-VAN-EX2, click Revert.

3. Start the VAN-TMG and VAN-CL1 virtual machines.
4. Log on to VAN-TMG as Adatum\Administrator, using the password Pa$$w0rd. Do not log on to

VAN-CL1 at this point.
Results: After this exercise, you should have configured audit logging.
Exercise 3: Configuring a Reverse Proxy for Exchange Server Access

X Task 1: Request a server certificate with multiple storage area networks (SANs) on
the Client Access server
1. On VAN-EX1, in the Exchange Management Console, click Server Configuration.
3. On the Introduction page, type Adatum Mail Certificate as the friendly name for the certificate,
4. On the Domain Scope page, click Next.
5. On the Exchange Configuration page, expand Client Access server (Outlook Web App), select the
Outlook Web App is on the Intranet check box, and then type VAN-EX1.adatum.com in the
domain name box.
6. Select the Outlook Web App is on the Internet check box, and then type Mail.adatum.com in the
second text box.
7. Expand Client Access server (Exchange ActiveSync), and then verify that the Exchange Active
Sync is enabled check box is selected. Type mail.adatum.com as the domain name.
8. Expand Client Access server, (Web Services, Outlook Anywhere, and Autodiscover), and then
enter mail.adatum.com as the external host name.
9. Ensure that both the Autodiscover used on the Internet check box and the Long URL options are
selected. In the Autodiscover URL to use field, delete all entries except for
autodiscover.adatum.com, and then click Next.
10. On the Certificate Domains page, click Next.
11. On the Organization and Location page, enter the following information:
Organizational Unit: Messaging
State/province: BC
12. Click Browse, type CertRequest as the File name, and then click Save.
14. Click the Folder icon in the task bar, and then click Documents.
15. Right-click CertRequest.req, and then click Open.
click OK.
17. In the Open with dialog box, click Notepad, and then click OK.
18. In the CertRequest.req Notepad window, select Ctrl+A to select all of the text, select Ctrl+C to save
the text to the clipboard, and then close Notepad.
19. Click Start, click All Programs, and then click Internet Explorer.
20. Connect to https://van-dc1.adatum.com/certsrv.
21. Log on as Adatum\administrator using the password Pa$$word.
22. On the Welcome page, click Request a certificate.
23. On the Request a Certificate page, click advanced certificate request.
24. On the Advanced Certificate Request page, click Submit a certificate request by using a base-
64-encoded CMC or PKCS#10 file, or submit a renewal request by using a base-64-encoded
CMC or PKCS#7 file.
25. On the Submit a Certificate Request or Renewal Request page, click in the Saved Request field,
and then press Ctrl+V to paste the certificate request information into the field.
26. In the Certificate Template drop-down list, click Web Server, and then click Submit.
27. In the Web Access Confirmation dialog box, click Yes.
28. On the Certificate Issued page, click Download certificate.
29. In the File Download dialog box, click Save as.
30. In the Save As dialog box, browse to the C: drive, and then click Save.

32. In the Exchange Management Console, click Adatum Mail Certificate, and then click Complete
Pending Request.
33. On the Complete Pending Request page, click Browse.
34. Browse to the C: drive, click certnew.cer, click Open, click Complete, and then click Finish.
35. On the Exchange Certificates tab, click Adatum Mail Certificate, and then click Assign Services
to Certificate.
36. On the Select Servers page, click Next.
37. On the Select Services page, select the Internet Information Services check box, click Next, click
Assign, and then click Finish.
X Task 2: Export the certificate from the Client Access server

1. On VAN-EX1, right-click Adatum Mail Certificate, and then click Export Exchange Certificate.
2. On the Introduction page, click Browse, and then browse to drive C.
3. Type CertExport.pfx as the file name, and then click Save.

4. In the Password field, type Pa$$w0rd, click Export, and then click Finish.
X Task 3: Import the certificate on the Microsoft Forefront Threat Management

Gateway (TMG) server
1. On VAN-TMG, click Start. In the Search box, type MMC, and then press Enter.
2. On the File menu, click Add/Remove Snap-in.
3. On the Add or Remove Snap-ins page, click Certificates, and then click Add.
4. Click Computer account, click Next, click Finish, and then click OK.
5. Expand Certificates, right-click Personal, point to All Tasks, and then click Import.
6. On the Certificate Import Wizard page, click Next.
7. On the File to Import page, type \\VAN-EX1\C$\CertExport.pfx, and then click Next.
8. On the Password page, type Pa$$w0rd in the Password field, and then click Next.
9. On the Certificate Store page, click Next, and then click Finish.
10. Click OK, and then close Console1 without saving changes.
X Task 4: Configure an Outlook Web Access publishing rule

1. On VAN-TMG, click Start, point to All Programs, click Microsoft Forefront TMG, and then click
Forefront TMG Management.
2. Expand Forefront TMG (VAN-TMG), and then click Firewall Policy.
3. On the Firewall Policy Tasks pane, on the Tasks tab, click Publish Exchange Web Client Access.
4. On the Welcome to the New Exchange Publishing Rule Wizard page, type OWA Rule, and then
click Next.
5. On the Select Services page, in the Exchange version list, click Exchange Server 2010, select the
Outlook Web Access check box, and then click Next.
6. On the Publishing Type page, click Next.
7. On the Server Connection Security page, ensure that Use SSL to connect the published Web
server or server farm is configured, and then click Next.
8. On the Internal Publishing Details page, in the Internal site name text box, type
VAN-EX1.Adatum.com, and then click Next.
9. On the Public Name Details page, ensure that This domain name (type below) is configured in the
Accept requests for drop-down list. In the Public name box, type mail.Adatum.com, and then click
Next.
10. On the Select Web Listener page, click New.
11. On the Welcome to the New Web Listener Wizard page, type HTTPS Listener, and then click
Next.
12. On the Client Connection Security page, ensure that Require SSL secured connections with
clients is selected, and then click Next.
13. On the Web Listener IP Addresses page, select the External check box, and then click Next.
14. On the Listener SSL Certificates page, click Select Certificate.

15. In the Select Certificate dialog box, click mail.adatum.com, click Select, and then click Next.
16. On the Authentication Settings page, accept the default of HTML Form Authentication, and then
click Next.
17. On the Single Sign On Settings page, type Adatum.com as the single sign-on (SSO) domain name,
click Next, and then click Finish.
18. On the Select Web Listener page, click Next.

19. On the Authentication Delegation page, accept the default of Basic authentication, and then
click Next.
20. On the User Sets page, accept the default, and then click Next.
21. On the Completing the New Exchange Publishing Rule Wizard page, click Finish.
22. Click Apply twice to apply the changes, and then click OK when the changes have been applied.
X Task 5: Configure the Client Access server

1. On VAN-EX1, in the Exchange Management Console, expand Server Configuration, and then click
Client Access.
accessible.
2. On the Outlook Web App tab, double-click owa (Default Web Site).
3. In the External URL box, type https://mail.adatum.com/owa.

4. On the Authentication tab, click Use one or more standard authentication methods, select the
Basic Authentication (password is sent in clear text) check box, and then click OK twice.
5. On the Exchange Control Panel tab, double-click ecp (Default Web Site).
6. In the External URL box, type https://mail.adatum.com/ecp.
7. On the Authentication tab, click Use one or more standard authentication methods, select the
Basic Authentication (password is sent in clear text) check box, and then click OK twice.
8. Open the Exchange Management Shell. At the PS prompt, type IISReset, and then press Enter.
Note If you receive a message stating that the service did not start, start the World Wide
Web service in the Services console.
X Task 6: Test the Outlook Web App publishing rule

1. On the host computer, in Hyper-V Manager, right-click 10135B-VAN-CL1, and then click Settings.
2. Click Legacy Network Adapter, and in the Network drop-down list, click Private Network 2, and
then click OK.
3. On VAN-CL1, log on as Adatum\Administrator using the password Pa$$w0rd.

4. Open the Control Panel, and then click View network status and tasks.
6. Right-click Local Area Connection 3, and then click Properties.
8. Change the IP address to 131.107.0.50, change the Default Gateway to 131.107.0.1, click OK, and
then click Close. Close the Control Panel.
9. Click Start, and in the search field, type notepad c:\windows\system32\drivers\etc\hosts, and
then press Enter.
10. At the bottom of the hosts file, type 131.107.1.1 mail.adatum.com, and then save and close the file.
11. Open Internet Explorer, and then connect to https://mail.adatum.com/owa.
12. Log on as adatum\administrator using the password Pa$$w0rd, and then verify that you access the
user mailbox.
13. In the Microsoft Outlook Web App window, click Options. Verify that you can connect to the
Exchange Control Panel.
Results: After this exercise, you should have configured a Forefront Threat Management Gateway server
to enable access to Outlook Web App on the Client Access server. You also will have verified that the
access is configured correctly.

following steps:

L11-78
Module 11: Maintaining Microsoft Exchange Server 2010

Lab: Maintaining Exchange Server 2010
Exercise 1: Monitoring Exchange Server 2010
X Task 1: Create a new data collector set named Exchange Monitoring
1. On VAN-EX1, click Start, click Administrative Tools, and then click Performance Monitor.
2. In the Navigation pane, expand Data Collector Sets, and then click User Defined.
3. Click on the Action menu, click New, and then click Data Collector Set.
4. In the Create new Data Collector Set Wizard, in the Name box, type Exchange Monitoring, select
Create manually (Advanced), and then click Next.
5. Select the Performance Counter check box, and then click Finish.
X Task 2: Create a new performance counter data collector set for monitoring basic
Exchange Server performance
1. In the Performance Monitor, in the Navigation pane, expand Data Collector Sets, expand User
Defined, click Exchange Monitoring, click the Action menu, click New, and then click Data
Collector.
2. In the Create New Data Collector Wizard, in the Name box, type Base Exchange Monitoring, select
Performance counter data collector, and then click Next.
3. Click Add.
4. In the Available counters object list, expand Processor, and then click % Processor Time. Press and
hold Ctrl, click % User Time, click % Privileged Time, and then click Add.
5. In the Available counters object list, expand Memory, and then click Available Mbytes. Press and
hold Ctrl, click Page Reads/sec, click Pages Input/sec, click Pages/sec, click Pages Output/sec,
click Pool Paged Bytes, click Transition Pages Repurposed/sec, and then click Add.
6. In the Available counters object list, expand MSExchange ADAccess Domain Controllers, and
then click LDAP Read Time. Press and hold Ctrl, click LDAP Search Time, click LDAP Searches
timed out per minute, click Long running LDAP operations/Min, and then click Add.
7. In the Available counters object list, expand System, click Processor Queue Length, and then
click Add.
8. Click OK.
9. In the Create New Data Collector Wizard, in the Sample interval box, type 1, and then in the Units
dropdown menu, select Minutes, and then click Finish to create the data collector set.
Lab: Maintaining Exchange Server 2010 L11-79
X Task 3: Create a new performance counter data collector set for monitoring Mailbox
server role performance
1. In the Reliability and Performance Monitor, in the Navigation pane, click Exchange Monitoring, click
the Action menu, click New, and then click Data Collector.
2. In the Create New Data Collector Wizard, in the Name box, type Mailbox Role Monitoring, select
Performance counter data collector, and then click Next.
3. Click Add.
4. In the Available counters object list, expand LogicalDisk, and then click Avg.Disk sec/Read. Press
and hold Ctrl, click Avg.Disk sec/Transfer, click Avg.Disk sec/Write, and then click Add.
5. In the Available counters object list, expand MSExchangeIS, and then click RPC Averaged Latency.
Press and hold Ctrl, click RPC Num. of Slow Packets, click RPC Operations/sec, click RPC Requests,
and then click Add.
6. In the Available counters object list, expand MSExchangeIS Mailbox, click Messages Queued for
Submission, and then click Add.
7. In the Available counters object list, expand MSExchangeIS Public, click Messages Queued for
Submission, and then click Add.
8. Click OK.
9. In the Create New Data Collector Wizard, in the Sample interval box, type 1, and in the Units drop-
down menu, select Minutes, and then click Finish to create the data collector set.
X Task 4: Verify that the data collector set works properly

1. In the Reliability and Performance Monitor, in the Navigation pane, click Exchange Monitoring, click
the Action menu, and then click Start.
2. After at least five minutes, click the Action menu, and then click Stop.
3. In the Navigation pane, expand Reports, expand User Defined, expand Exchange Monitoring, click
VAN-EX1_DateTime, and then review the report.
4. Close the Performance Monitor.
Results: After this exercise, you should have created a data collector set for monitoring VAN-EX1 that
uses the performance counters that this module recommends.
Exercise 2: Troubleshooting Database Availability

X Preparation
1. On VAN-EX1, open an Exchange Management Shell. At the prompt, type

d:\ Labfiles\Lab11Prep2.ps1, and then press Enter.
2. When prompted, type N, and then press Enter.

L11-80 Module 11: Maintaining Microsoft Exchange Server 2010
X Task 1: Identify the scope of the problem


3. In the Work pane, click the Database Management tab, and then view the list of databases, noting
that MailboxDB100 is dismounted.

1. In the Work pane, right-click MailboxDB100, and then click Mount database. Review the warning
message, and then click No.
2. On VAN-EX1, click Start, click All Programs, click Administrative Tools, and then click Event
Viewer.
3. In Event Viewer, in the Navigation pane, expand Windows Logs, click on Application, and then in
the Content pane, review recent events. Click recent events that have a source from one of the
MSExchange services, and then review the details of the error in the lower half of the Content pane.
4. In the Navigation pane, click on System, and then in the Content pane, review recent events. No
notable events are present.
5. Close Event Viewer.
X Task 3: Run the Best Practices Analyzer

2. In the Console Tree, expand Microsoft Exchange On-Premises, and then expand Toolbox.
3. In the Work pane, double-click Best Practices Analyzer.
4. In the Microsoft Exchange Best Practice Analyzer, if prompted, select Do not check for updates on
startup, select I dont want to join the program at this time, and then click Go to the Welcome
screen.
5. On the Welcome to the Exchange Best Practices Analyzer page, click Select options for a new
scan.
6. On the Connect to Active Directory page, click Connect to the Active Directory server.
7. On the Start a new Best Practices scan page, in the Enter an indentifying label for this scan box,
type VAN-EX1 Scan, and then click Unselect all.
8. In the Specify the scope for this scan box, select VAN-EX1, verify that Health Check is selected,
and then click Start scanning to start the best practices scan process.
9. On the Scanning completed page, click View a report of this Best Practices scan. Verify that there
are no errors listed that may have caused this issue.
X Task 4: List the probable causes of the problem, and rank the possible solutions, if
1. List the problems and possible solutions:

Disk errors are preventing access to the Replace disks and restore from backup.
database.
Database path is incorrect because of storage Change storage or database configuration.

changes.
X Task 5: Review the database configuration

1. On VAN-EX1, in Exchange Management Console, under Organization Configuration, click Mailbox.
2. In the Work pane, click the Database Management tab, and then right-click on MailboxDB100, and
select Properties.
3. Identify the database file location, by examining value of Database path on General tab. Click
Cancel.
4. Click Start, click All Programs, click Accessories, and then click Windows Explorer.
5. In the Navigation pane, expand Computer, expand Local Disk (C:), expand Program Files, expand
Microsoft, expand Exchange Server, expand V14, expand Mailbox. Verify that the MailboxDB100-
NewPath folder does not exist.
6. In the Navigation pane, click MailboxDB100 and locate the database files. This is the actual location
of the database files. The configuration is pointing to the wrong path.
7. Close Windows Explorer.
X Task 6: Reconfigure and mount the database

2. In the Exchange Management Shell, type the follow cmdlet, and then press Enter.
Move-DatabasePath MailboxDB100 LogFolderPath C:\Program Files\Microsoft\Exchange

Server\V14\Mailbox\MailboxDB100 EdbFilePath C:\Program Files\Microsoft\Exchange
Server\V14\Mailbox\MailboxDB100\MailboxDB100.edb ConfigurationOnly force
3. Type Y, and then press Enter.
4. In the Exchange Management Shell, type Mount-Database MailboxDB100, and then press Enter.
5. Close Exchange Management Shell.
Results: After this exercise, you should have used a troubleshooting technique to identify and fix a
Mailbox server problem.
Exercise 3: Troubleshooting Client Access Servers

X Preparation
1. On VAN-EX1, open Exchange Management Shell. At the prompt, type d:\ Labfiles\Lab11Prep3.ps1,
X Task 1: Verify the problem by attempting to reproduce the problem

1. On VAN-EX1, open Windows Internet Explorer, and connect to
https://VAN-EX1.adatum.com/owa.
2. Note the error displayed in the browser: HTTP Error 401.2 Unauthorized.

1. On VAN-EX1, click Start, click All Programs, click Administrative Tools, and then click Event
Viewer.
2. In Event Viewer, in the Navigation pane, expand Windows Logs, click Application, and then in the
Content pane, review recent events. There is nothing substantial to point to the problem.
3. In the Navigation pane, click System, and then in the Content pane, review recent events.
4. Close Event Viewer.
X Task 3: Use the Test cmdlets to verify server health

2. In the Exchange Management Shell, type Test-ServiceHealth, and then press Enter. Verify that the
output does not return any errors.
3. In the Exchange Management Shell, type

Test-OwaConnectivity URL https://VAN-EX1.adatum.com/OWA -TrustAnySSLCertificate, and
then press Enter.
4. In the Windows PowerShell Credential Request dialog box, in the User name box, type
Adatum\Administrator, and in the Password box, type Pa$$w0rd, and then click OK.
5. Note the authentication errors.
6. Close Exchange Management Shell.

1. List the problems and possible solutions:

Internet Information Server (IIS) Configuration is not Modify the IIS configuration.
configured correctly.
Microsoft Outlook Web App authentication is not Modify Outlook Web App authentication
configured correctly. configuration.
X Task 5: Check the Outlook Web App configuration

2. In the Console Tree, expand Microsoft Exchange On-Premises, expand Server Configuration, and
accessible.
3. In the upper portion of the Work pane, click VAN-EX1, and then in the lower portion of the Work
pane, select the Outlook Web App tab. Right-click owa (Default Web Site), and then click
Properties.
4. In the owa (Default Web Site) Properties dialog box, click the Authentication tab, select Use
forms-based authentication, and then click OK.
5. Review the Microsoft Exchange Warning, and then click OK.
6. Click Start, click All Programs, click Accessories, and then click Command Prompt.
7. At the command prompt, type iisreset, and then press Enter.
Note If you receive an error indicating that the service did not start, start the World Wide
Web Service in Services management console.
8. Close the command prompt.
X Task 6: Verify that you resolved the problem

1. Open Internet Explorer, and connect to https://VAN-EX1.adatum.com/owa.
2. Log on to Outlook Web App as Adatum\Administrator using the password Pa$$w0rd.
3. Confirm that Administrator can now access Outlook Web App, and then close Internet Explorer.
Results: After this exercise, you should have used a troubleshooting technique to identify and fix a Client
Access server problem.

following steps:
1. On the host computer, start Hyper-VManager.

LA-85
Appendix A: Implementing Unified Messaging

Lab: Implementing Unified Messaging
Exercise 1: Installing and Configuring Unified Messaging Features
X Lab preparation
1. On the host computer, open Hyper-V Manager.
2. Right-click 10135B-VAN-EX2, and then click Settings.

then click Open.
5. Click OK.
X Task 1: Install the Exchange Server Unified Messaging prerequisites

1. On VAN-EX2, close the AutoPlay dialog box.
2. Open Server Manager, click Features, and then click Add Features.
3. On the Select Features page, select the Desktop Experience check box, click Add required
features, click Next, and then click Install.
4. Click Close, and then when prompted, click Yes to restart the computer.
5. After the computer restarts, log on as Adatum\Administrator. Wait for the installation to finish, and
then click Close.
6. Click Start, and in the search box, type \\VAN-EX1\D$\Labfiles, and then press Enter.
7. Double-click UcmaRuntimeSetup.exe, and then click Yes.

8. Click Install, accept the license agreement, click OK, and then click Exit.
9. In the Labfiles window, double-click SpeechPlatformRuntime.msi.
X Task 2: Install the Unified Messaging role

1. On VAN-EX2, click Start, and then click Control Panel.
2. In Control Panel, click Programs, and then click Programs and Features.
3. In Control Panel, on the Programs and Features page, select Microsoft Exchange Server 2010, and
then click Change.
4. In Exchange Server 2010 Setup, click Next.
5. On the Server Role Selection page, click Unified Messaging Role, and then click Next.
6. On the Readiness Checks page, click Install.

LA-86 Appendix A: Implementing Unified Messaging
X Task 3: Create a dial plan


Configuration, and then click Unified Messaging.
3. In the Actions pane, click New UM Dial Plan.
4. In the New UM Dial Plan Wizard, on the New UM Dial Plan page, in the Name field, type
DP-VAN-5digit.
5. Select Telephone Extension from the URI type drop-down list, and then select Unsecured from the
VoIP security drop-down list.
6. In the Country/Region code field, type 1604, and then click Next.
7. On the Set UM Servers page, click Add. Click VAN-EX2, and click OK. Click Next, and then
click New.
X Task 4: Create an Unified Messaging IP gateway and hunt group

1. In the Exchange Management Console, in the Actions pane, click New UM IP Gateway.
2. In the New UM IP Gateway Wizard, on the New UM IP Gateway page, type IP Test Phone in the
Name field.
3. In the IP address field, type 10.10.0.10 so that VAN-DC1 runs the UM Test Phone tool, and then
click Browse, select DP-VAN-5digit in the Select Dial Plan window, click OK, and then click New.
5. In the Exchange Management Console, on the UM IP Gateways tab, in the IP Test Phone Actions
pane, click New UM Hunt Group.
6. In the New UM Hunt Group Wizard, type HG-VAN-5digits in the Name field, click Browse, select
DP-VAN-5digit in the Select Dial Plan window, and then click OK.
7. In the Pilot identifier field, enter 90000, and then click New.
X Task 5: Change the default Unified Messaging mailbox policy

1. In the Exchange Management Console, click the UM Mailbox Policies tab.
2. In the Details pane, double-click DP-VAN-5digit Default Policy.
3. On the DP-VAN-5digit Default Policy Properties page, click the Message Text tab, and then type
Welcome to the Unified Messaging Server VAN-EX2 in the Text sent when a UM mailbox is
enabled field.
Lab: Implementing Unified Messaging LA-87
4. On the DP-VAN-5digit Default Policy Properties page, click the PIN Policies tab, uncheck PIN
lifetime (days), and then click OK.
Results: After this exercise, you should have installed the Unified Messaging role and configured the basic
server-side settings for Unified Messaging, namely, a dial plan, an IP gateway, a hunt group, and a
mailbox policy. You also will have assigned the dial plan to a Unified Messaging server.
X To revert the virtual machines

following steps:

10135B ENU TrainerHandbook

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

10135B ENU TrainerHandbook

Caricato da

Copyright:

Formati disponibili

MCT USE ONLY.

STUDENT USE PROHIBITED

Microsoft and the trademarks listed at http://www.microsoft.com/about/legal/en/us/IntellectualProperty

Product Number: 10135B

Part Number: X18-30632

a. If you are a Authorized Learning Center:

b. If you are a MPN Member.

c. If you are an End User:

2.3 Reproduction/Redistribution Licensed Content. Except as expressly provided in the applicable

13. APPLICABLE LAW.

This limitation applies to

LIMITATION DES DOMMAGES-INTRTS ET EXCLUSION DE RESPONSABILIT POUR LES DOMMAGES. Vous

Revised December 2011

Siegfried Jagott Content Developer

Stan Reimer Content Developer

Joel Stidley Content Developer

Damir Dizdarevic Technical Reviewer

Module 2: Configuring Mailbox Servers

Module 3: Managing Recipient Objects

Module 4: Managing Client Access

Module 5: Managing Message Transport

Module 6: Implementing Messaging Security

Module 7: Implementing High Availability

Module 8: Implementing Backup and Recovery

Module 9: Configuring Messaging Policy and Compliance

Module 10: Securing Microsoft Exchange Server 2010

Module 11: Maintaining Microsoft Exchange Server 2010

Module 12: Upgrading from Exchange Server 2003 or

Module 13: Implementing Microsoft Exchange Online with

Appendix A: Implementing Unified Messaging

Appendix: Lab Answer Keys

About This Course

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

To provide additional comments or feedback on the course, send email to

Virtual Machine Environment

Virtual Machine Configuration

Virtual machine Role

10135B-NYC-SVR1 Member server in the Contoso.com domain

10135B-VAN-DC1 Domain controller in the Adatum.com domain

10135B-VAN-EX1 Exchange 2010 server in the Adatum.com domain

10135B-VAN-EX2 Exchange 2010 server in the Adatum.com domain

10135B-VAN-EX3 Exchange 2010 server in the Adatum.com domain

10135B-VAN-EDG Exchange 2010 Edge Transport server

10135B-VAN-CL1 Client computer in the Adatum.com domain

10135B-VAN-TMG Microsoft Forefront Threat Management Gateway server in the

10135B-VAN-SVR1 Standalone server

Windows Server 2008 R2, SP1

Microsoft Office 2010 SP1

Microsoft Forefront Threat Management Gateway SP1

Course Hardware Level

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

Lesson 2: Installing Exchange Server 2010 Server Roles 1-18

Lab A: Installing Exchange Server 2010 1-38

Lab B: Verifying an Exchange Server 2010 Installation 1-51

After completing this module, you will be able to:

Describe the infrastructure requirements to install Exchange Server 2010.

Install Exchange Server 2010 server roles.

Complete an Exchange Server 2010 installation.

After completing this lesson, you will be able to:

Describe the Active Directory components.

Describe the Active Directory partitions.

Describe the DNS requirements for Exchange Server 2010.

Prepare AD DS for Exchange Server 2010.