20341B ENU TrainerHandbook PDF

M I C R O S O F T
20341B
L E A R N I N G
P R O D U C T
Core Solutions of Microsoft Exchange

Server 2013
MCT USE ONLY. STUDENT USE PROHIBITED
O F F I C I A L
ii Core Solutions of Microsoft Exchange Server 2013
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.
2013 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: 20341B

Part Number: X18-52906
Released: 05/2013
MICROSOFT LICENSE TERMS

OFFICIAL MICROSOFT LEARNING PRODUCTS
MICROSOFT OFFICIAL COURSE Pre-Release and Final Release Versions
These license terms are an agreement between Microsoft Corporation and you. Please read them. They apply to
the Licensed Content named above, which includes the media on which you received it, if any. These license
terms also apply to any updates, supplements, internet based services and support services for the Licensed
Content, unless other terms accompany those items. If so, those terms apply.
BY DOWNLOADING OR USING THE LICENSED CONTENT, YOU ACCEPT THESE TERMS. IF YOU DO NOT ACCEPT
THEM, DO NOT DOWNLOAD OR USE THE LICENSED CONTENT.
If you comply with these license terms, you have the rights below.
1.
DEFINITIONS.
a. Authorized Learning Center means a Microsoft Learning Competency Member, Microsoft IT Academy
Program Member, or such other entity as Microsoft may designate from time to time.
b. Authorized Training Session means the Microsoft-authorized instructor-led training class using only
MOC Courses that are conducted by a MCT at or through an Authorized Learning Center.
c. Classroom Device means one (1) dedicated, secure computer that you own or control that meets or
exceeds the hardware level specified for the particular MOC Course located at your training facilities or
primary business location.
d. End User means an individual who is (i) duly enrolled for an Authorized Training Session or Private
Training Session, (ii) an employee of a MPN Member, or (iii) a Microsoft full-time employee.
e. Licensed Content means the MOC Course and any other content accompanying this agreement.
Licensed Content may include (i) Trainer Content, (ii) software, and (iii) associated media.
f.
Microsoft Certified Trainer or MCT means an individual who is (i) engaged to teach a training session
to End Users on behalf of an Authorized Learning Center or MPN Member, (ii) currently certified as a
Microsoft Certified Trainer under the Microsoft Certification Program, and (iii) holds a Microsoft
Certification in the technology that is the subject of the training session.
g. Microsoft IT Academy Member means a current, active member of the Microsoft IT Academy
Program.
h. Microsoft Learning Competency Member means a Microsoft Partner Network Program Member in
good standing that currently holds the Learning Competency status.
i.
Microsoft Official Course or MOC Course means the Official Microsoft Learning Product instructorled courseware that educates IT professionals or developers on Microsoft technologies.
j.
Microsoft Partner Network Member or MPN Member means a silver or gold-level Microsoft Partner
Network program member in good standing.
k. Personal Device means one (1) device, workstation or other digital electronic device that you
personally own or control that meets or exceeds the hardware level specified for the particular MOC
Course.
l. Private Training Session means the instructor-led training classes provided by MPN Members for
corporate customers to teach a predefined learning objective. These classes are not advertised or
promoted to the general public and class attendance is restricted to individuals employed by or
contracted by the corporate customer.
m. Trainer Content means the trainer version of the MOC Course and additional content designated
solely for trainers to use to teach a training session using a MOC Course. Trainer Content may include
Microsoft PowerPoint presentations, instructor notes, lab setup guide, demonstration guides, beta
feedback form and trainer preparation guide for the MOC Course. To clarify, Trainer Content does not
include virtual hard disks or virtual machines.
2.
INSTALLATION AND USE RIGHTS. The Licensed Content is licensed not sold. The Licensed Content is
licensed on a one copy per user basis, such that you must acquire a license for each individual that
accesses or uses the Licensed Content.
2.1
Below are four separate sets of installation and use rights. Only one set of rights apply to you.
a. If you are a Authorized Learning Center:

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

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

i. For each license you acquire, you may use the Licensed Content solely to prepare and deliver an
Authorized Training Session or Private Training Session. For each license you acquire, you may
install and use one (1) copy of the Licensed Content in the form provided to you on one (1) Personal
Device and install one (1) additional copy on another Personal Device as a backup copy, which may
be used only to reinstall the Licensed Content. You may not install or use a copy of the Licensed
Content on a device you do not own or control.
ii.
Use of Instructional Components in Trainer Content. You may customize, in accordance with the
most recent version of the MCT Agreement, those portions of the Trainer Content that are logically
associated with instruction of a training session. If you elect to exercise the foregoing rights, you
agree: (a) that any of these customizations will only be used for providing a training session, (b) any
customizations will comply with the terms and conditions for Modified Training Sessions and
Supplemental Materials in the most recent version of the MCT agreement and with this agreement.
For clarity, any use of customize refers only to changing the order of slides and content, and/or
not using all the slides or content, it does not mean changing or modifying any slide or content.
2.2 Separation of Components. The Licensed Content components are licensed as a single unit and you
may not separate the components and install them on different devices.
2.3 Reproduction/Redistribution Licensed Content. Except as expressly provided in the applicable

installation and use rights above, you may not reproduce or distribute the Licensed Content or any portion
thereof (including any permitted modifications) to any third parties without the express written permission
of Microsoft.
2.4 Third Party Programs. The Licensed Content may contain third party programs or services. These
license terms will apply to your use of those third party programs or services, unless other terms accompany
those programs and services.
2.5 Additional Terms. Some Licensed Content may contain components with additional terms,
conditions, and licenses regarding its use. Any non-conflicting terms in those conditions and licenses also
apply to that respective component and supplements the terms described in this Agreement.
3.
PRE-RELEASE VERSIONS. If the Licensed Content is a pre-release (beta) version, in addition to the other
provisions in this agreement, then these terms also apply:
a. Pre-Release Licensed Content. This Licensed Content is a pre-release version. It may not contain the
same information and/or work the way a final version of the Licensed Content will. We may change it
for the final version. We also may not release a final version. Microsoft is under no obligation to
provide you with any further content, including the final release version of the Licensed Content.
b. Feedback. If you agree to give feedback about the Licensed Content to Microsoft, either directly or
through its third party designee, you give to Microsoft without charge, the right to use, share and
commercialize your feedback in any way and for any purpose. You also give to third parties, without
charge, any patent rights needed for their products, technologies and services to use or interface with
any specific parts of a Microsoft software, Microsoft product, or service that includes the feedback. You
will not give feedback that is subject to a license that requires Microsoft to license its software,
technologies, or products to third parties because we include your feedback in them. These rights
survive this agreement.
c. Term. If you are an Authorized Training Center, MCT or MPN, you agree to cease using all copies of the
beta version of the Licensed Content upon (i) the date which Microsoft informs you is the end date for
using the beta version, or (ii) sixty (60) days after the commercial release of the Licensed Content,
whichever is earliest (beta term). Upon expiration or termination of the beta term, you will
irretrievably delete and destroy all copies of same in the possession or under your control.
4.
INTERNET-BASED SERVICES. Microsoft may provide Internet-based services with the Licensed Content,
which may change or be canceled at any time.
a. Consent for Internet-Based Services. The Licensed Content may connect to computer systems over an
Internet-based wireless network. In some cases, you will not receive a separate notice when they
connect. Using the Licensed Content operates as your consent to the transmission of standard device
information (including but not limited to technical information about your device, system and
application software, and peripherals) for internet-based services.
b. Misuse of Internet-based Services. You may not use any Internet-based service in any way that could
harm it or impair anyone elses use of it. You may not use the service to try to gain unauthorized access
to any service, data, account or network by any means.
5.
SCOPE OF LICENSE. The Licensed Content is licensed, not sold. This agreement only gives you some rights
to use the Licensed Content. Microsoft reserves all other rights. Unless applicable law gives you more
rights despite this limitation, you may use the Licensed Content only as expressly permitted in this
agreement. In doing so, you must comply with any technical limitations in the Licensed Content that only
allows you to use it in certain ways. Except as expressly permitted in this agreement, you may not:
install more copies of the Licensed Content on devices than the number of licenses you acquired;
allow more individuals to access the Licensed Content than the number of licenses you acquired;
publicly display, or make the Licensed Content available for others to access or use;
install, sell, publish, transmit, encumber, pledge, lend, copy, adapt, link to, post, rent, lease or lend,
make available or distribute the Licensed Content to any third party, except as expressly permitted
by this Agreement.
reverse engineer, decompile, remove or otherwise thwart any protections or disassemble the
Licensed Content except and only to the extent that applicable law expressly permits, despite this
limitation;
access or use any Licensed Content for which you are not providing a training session to End Users
using the Licensed Content;
access or use any Licensed Content that you have not been authorized by Microsoft to access and
use; or
transfer the Licensed Content, in whole or in part, or assign this agreement to any third party.
6.
RESERVATION OF RIGHTS AND OWNERSHIP. Microsoft reserves all rights not expressly granted to you in
this agreement. The Licensed Content is protected by copyright and other intellectual property laws and
treaties. Microsoft or its suppliers own the title, copyright, and other intellectual property rights in the
Licensed Content. You may not remove or obscure any copyright, trademark or patent notices that
appear on the Licensed Content or any components thereof, as delivered to you.
7.
EXPORT RESTRICTIONS. The Licensed Content is subject to United States export laws and regulations. You
must comply with all domestic and international export laws and regulations that apply to the Licensed
Content. These laws include restrictions on destinations, End Users and end use. For additional
information, see www.microsoft.com/exporting.
8.
LIMITATIONS ON SALE, RENTAL, ETC. AND CERTAIN ASSIGNMENTS. You may not sell, rent, lease, lend or
sublicense the Licensed Content or any portion thereof, or transfer or assign this agreement.
9.
SUPPORT SERVICES. Because the Licensed Content is as is, we may not provide support services for it.
10.
TERMINATION. Without prejudice to any other rights, Microsoft may terminate this agreement if you fail
to comply with the terms and conditions of this agreement. Upon any termination of this agreement, you
agree to immediately stop all use of and to irretrievable delete and destroy all copies of the Licensed
Content in your possession or under your control.
11.
LINKS TO THIRD PARTY SITES. You may link to third party sites through the use of the Licensed Content.
The third party sites are not under the control of Microsoft, and Microsoft is not responsible for the
contents of any third party sites, any links contained in third party sites, or any changes or updates to third
party sites. Microsoft is not responsible for webcasting or any other form of transmission received from
any third party sites. Microsoft is providing these links to third party sites to you only as a convenience,
and the inclusion of any link does not imply an endorsement by Microsoft of the third party site.
12.
ENTIRE AGREEMENT. This agreement, and the terms for supplements, updates and support services are
the entire agreement for the Licensed Content.
13.
APPLICABLE LAW.
a. United States. If you acquired the Licensed Content in the United States, Washington state law governs
the interpretation of this agreement and applies to claims for breach of it, regardless of conflict of laws
principles. The laws of the state where you live govern all other claims, including claims under state
consumer protection laws, unfair competition laws, and in tort.
b. Outside the United States. If you acquired the Licensed Content in any other country, the laws of that
country apply.
14.
LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the laws of
your country. You may also have rights with respect to the party from whom you acquired the Licensed
Content. This agreement does not change your rights under the laws of your country if the laws of your
country do not permit it to do so.
15.
DISCLAIMER OF WARRANTY. THE LICENSED CONTENT IS LICENSED "AS-IS," "WITH ALL FAULTS," AND "AS
AVAILABLE." YOU BEAR THE RISK OF USING IT. MICROSOFT CORPORATION AND ITS RESPECTIVE
AFFILIATES GIVE NO EXPRESS WARRANTIES, GUARANTEES, OR CONDITIONS UNDER OR IN RELATION TO
THE LICENSED CONTENT. YOU MAY HAVE ADDITIONAL CONSUMER RIGHTS UNDER YOUR LOCAL LAWS
WHICH THIS AGREEMENT CANNOT CHANGE. TO THE EXTENT PERMITTED UNDER YOUR LOCAL LAWS,
MICROSOFT CORPORATION AND ITS RESPECTIVE AFFILIATES EXCLUDE ANY IMPLIED WARRANTIES OR
CONDITIONS, INCLUDING THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT.
16.
LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. TO THE EXTENT NOT PROHIBITED BY
LAW, YOU CAN RECOVER FROM MICROSOFT CORPORATION AND ITS SUPPLIERS ONLY DIRECT
DAMAGES UP TO USD$5.00. YOU AGREE NOT TO SEEK TO RECOVER ANY OTHER DAMAGES, INCLUDING
CONSEQUENTIAL, LOST PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES FROM MICROSOFT
CORPORATION AND ITS RESPECTIVE SUPPLIERS.
This limitation applies to

o
anything related to the Licensed Content, services made available through the Licensed Content, or
content (including code) on third party Internet sites or third-party programs; and
o
claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence,
or other tort to the extent permitted by applicable law.
It also applies even if Microsoft knew or should have known about the possibility of the damages. The
above limitation or exclusion may not apply to you because your country may not allow the exclusion or
limitation of incidental, consequential or other damages.
Please note: As this Licensed Content is distributed in Quebec, Canada, some of the clauses in this agreement
are provided below in French.
Remarque : Ce le contenu sous licence tant distribu au Qubec, Canada, certaines des clauses dans ce
contrat sont fournies ci-dessous en franais.
EXONRATION DE GARANTIE. Le contenu sous licence vis par une licence est offert tel quel . Toute
utilisation de ce contenu sous licence est votre seule risque et pril. Microsoft naccorde aucune autre garantie
expresse. Vous pouvez bnficier de droits additionnels en vertu du droit local sur la protection dues
consommateurs, que ce contrat ne peut modifier. La ou elles sont permises par le droit locale, les garanties
implicites de qualit marchande, dadquation un usage particulier et dabsence de contrefaon sont exclues.
LIMITATION DES DOMMAGES-INTRTS ET EXCLUSION DE RESPONSABILIT POUR LES DOMMAGES. Vous
pouvez obtenir de Microsoft et de ses fournisseurs une indemnisation en cas de dommages directs uniquement
hauteur de 5,00 $ US. Vous ne pouvez prtendre aucune indemnisation pour les autres dommages, y
compris les dommages spciaux, indirects ou accessoires et pertes de bnfices.
Cette limitation concerne:
tout ce qui est reli au le contenu sous licence , aux services ou au contenu (y compris le code)
figurant sur des sites Internet tiers ou dans des programmes tiers ; et
les rclamations au titre de violation de contrat ou de garantie, ou au titre de responsabilit
stricte, de ngligence ou dune autre faute dans la limite autorise par la loi en vigueur.
Elle sapplique galement, mme si Microsoft connaissait ou devrait connatre lventualit dun tel dommage.
Si votre pays nautorise pas lexclusion ou la limitation de responsabilit pour les dommages indirects,
accessoires ou de quelque nature que ce soit, il se peut que la limitation ou lexclusion ci-dessus ne sappliquera
pas votre gard.
EFFET JURIDIQUE. Le prsent contrat dcrit certains droits juridiques. Vous pourriez avoir dautres droits prvus
par les lois de votre pays. Le prsent contrat ne modifie pas les droits que vous confrent les lois de votre pays
si celles-ci ne le permettent pas.
Revised December 2011
x Core Solutions of Microsoft Exchange Server 2013
Core Solutions of Microsoft Exchange Server 2013 xi
Acknowledgments
Microsoft Learning wants to acknowledge and thank the following for their contribution toward
developing this title. Their effort at various stages in the development has ensured that you have a good
classroom experience.
Stan Reimer Content Developer
Stan Reimer is president of S. R. Technical Services Inc., and he works as a consultant, trainer, and author.
Stan has extensive experience consulting on Active Directory and Exchange Server deployments for some
of the largest companies in Canada. Stan is the lead author for two Active Directory books for Microsoft
Press. For the last ten 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 14
years.
Damir Dizdarevic Course Designer/Content Developer
Damir Dizdarevic is an MCT, Microsoft Certified Solutions Expert (MCSE), Microsoft Certified Technology
Specialist (MCTS), and a Microsoft Certified Information Technology Professional (MCITP). He is a manager
and trainer of the Learning Center at Logosoft d.o.o., in Sarajevo, Bosnia and Herzegovina. Damir has
more than 17 years of experience on Microsoft platforms and he specializes in Microsoft Windows
Server , Exchange Server, security, and virtualization. He has worked as a subject matter expert and
author on many Microsoft Official Courses (MOC) courses, mostly on Exchange and Windows Server
topics, and has published more than 400 articles in various IT magazines, such as Windows ITPro. He's also
a frequent and highly rated speaker on most of Microsoft conferences in South and Eastern Europe.
Additionally, he is a Microsoft Most Valuable Professional and a president of MSCommunity user group in
Bosnia. His blog about MS technologies can be found at: http://dizdarevic.ba/ddamirblog.
Siegfried Jagott Content Developer
Siegfried Jagott is a Principal Consultant and Team Lead for the Messaging and Collaboration team at
Atos Germany. He is an award-winning author of Microsoft Exchange Server 2010 Best Practices (Microsoft
Press), and has authored and technically reviewed several Microsoft Official Curriculum (MOC) courses
on various topics such as MOC 10165: Updating Your Skills from Microsoft Exchange Server 2003 or
Exchange Server 2007 to Exchange Server 2010 SP1. He has coauthored various books on Windows,
Microsoft System Center Virtual Machine Manager, and Exchange, and is a frequent presenter on these
topics at international conferences such as IT & Dev Connections Spring 2012 in Las Vegas. Siegfried
has planned, designed, and implemented some of the worlds largest Windows and Exchange Server
infrastructures for international customers. He received an MBA from Open University in England, and has
been an MCSE since 1997.
Vladimir Meloski Content Developer
Vladimir is a Microsoft Certified Trainer, an MVP on Exchange Server, and consultant, providing unified
communications and infrastructure solutions based on Microsoft Exchange Server, Lync Server, and
System Center. Vladimir has 16 years of professional IT experience, and has been involved in Microsoft
conferences in Europe and the United States as a speaker, moderator, proctor for hands-on labs, and
technical expert. He has also been involved as a subject matter expert and technical reviewer for several
Microsoft Official Curriculum courses.
Robert Genes Content Developer
xii Core Solutions of Microsoft Exchange Server 2013
Robert Genes is a messaging architect and a Microsoft Certified Master for Exchange Server 2010. As the
manager of genes messaging solutions he has worked in different Exchange Server projects in south
Germany. Robert is specialized in Exchange Server and has more than 10 years of experience.
Chris Crandall Tech Reviewer
Chris Crandall is the Principal Architect for the Messaging Practice at CB5 Solutions, where he leads,
overseas, and manages all engagements related to messaging infrastructure for enterprise customers in
each the Public and Private Sector. Chris is a Microsoft Certified Master (MCM), Microsoft Certified Trainer
(MCT), Microsoft Certified IT Professional (MCITP), and Microsoft Certified Technology Specialist (MCTS).
He is currently writing an Exchange 2013 book as a contributing Subject Matter Expert (SME). Chris served
as a SME and mentor in his role as Senior Premier Field Engineer at Microsoft where he served more than
30 enterprise organizations; earning numerous awards for customer satisfaction and performance.
Core Solutions of Microsoft Exchange Server 2013 xiii
Contents
Module 1: Deploying and Managing Microsoft Exchange Server 2013
Lesson 1: Exchange Server 2013 Prerequisites and Requirements
1-2
Lesson 2: Exchange Server 2013 Deployment
1-11
Lesson 3: Managing Exchange Server 2013
1-23
Lab: Deploying and Managing Exchange Server 2013
1-31
Module 2: Planning and Configuring Mailbox Servers

Lesson 1: Overview of the Mailbox Server Role
2-2
Lesson 2: Planning the Mailbox Server Deployment
2-11
Lesson 3: Configuring the Mailbox Servers
2-22
Lab: Configuring Mailbox Servers
2-28
Module 3: Managing Recipient Objects

Lesson 1: Managing Exchange Server 2013 Mailboxes
3-2
Lesson 2: Managing Other Exchange Recipients
3-12
Lesson 3: Planning and Implementing Public Folder Mailboxes
3-17
Lesson 4: Managing Address Lists and Policies
3-23
Lab: Managing Recipient Objects
3-30
Module 4: Planning and Deploying Client Access Servers

Lesson 1: Planning Client Access Server Deployment
4-2
Lesson 2: Configuring the Client Access Server Role
4-9
Lesson 3: Managing Client Access Services
4-18
Lab: Deploying and Configuring a Client Access Server Role
4-26
Module 5: Planning and Configuring Messaging Client Connectivity

Lesson 1: Client Connectivity to the Client Access Server
5-2
Lesson 2: Configuring Outlook Web App
5-7
Lesson 3: Planning and Configuring Mobile Messaging
5-14
Lesson 4: Configuring Secure Internet Access for Client Access Server
5-23
Lab: Planning and Configuring Messaging Client Connectivity
5-32
Module 6: Planning and Implementing High Availability

Lesson 1: High Availability on Exchange Server 2013
6-2
Lesson 2: Configuring Highly Available Mailbox Databases
6-10
Lesson 3: Configuring Highly Available Client Access Servers
6-22
Lab: Implementing High Availability
6-25
Module 7: Planning and Implementing Disaster Recovery

Lesson 1: Planning for Disaster Mitigation
7-2
Lesson 2: Planning and Implementing Exchange Server 2013 Backup
7-8
Lesson 3: Planning and Implementing Exchange Server 2013 Recovery
7-13
Lab: Implementing Disaster Recovery for Exchange Server 2013
7-21
Module 8: Planning and Configuring Message Transport

Lesson 1: Overview of Message Transport and Routing
8-2
Lesson 2: Planning and Configuring Message Transport
8-18
Lesson 3: Managing Transport Rules
8-25
Lab: Planning and Configuring Message Transport
8-31
Module 9: Planning and Configuring Message Hygiene

Lesson 1: Planning Messaging Security
9-2
Lesson 2: Implementing an Antivirus Solution for Exchange Server 2013
9-9
Lesson 3: Implementing an Anti-Spam Solution for Exchange

Server 2013
9-15
Lab: Planning and Configuring Message Security
9-27
Module 10: Planning and Configuring Administrative Security and Auditing

Lesson 1: Configuring Role-Based Access Control
10-2
Lesson 2: Configuring Audit Logging
10-13
Lab: Configuring Administrative Security and Auditing
10-17
Module 11: Monitoring and Troubleshooting Microsoft Exchange Server 2013

Lesson 1: Monitoring Exchange Server 2013
11-2
Lesson 2: Maintaining Exchange Server 2013
11-15
Lesson 3: Troubleshooting Exchange Server 2013
11-21
Lab: Monitoring and Troubleshooting Exchange Server 2013
11-29
Lab Answer Keys

Module 1 Lab: Deploying and Managing Exchange Server 2013
L1-1
Module 2 Lab: Configuring Mailbox Servers
L2-7
Module 3 Lab: Managing Recipient Objects
L3-15
Module 4 Lab: Deploying and Configuring a Client Access Server Role
L4-23
Module 5 Lab: Planning and Configuring Messaging Client Connectivity
L5-29
Module 6 Lab: Implementing High Availability
L6-39
Module 7 Lab: Implementing Disaster Recovery for Exchange

Server 2013
L7-45
xiv Core Solutions of Microsoft Exchange Server 2013
Core Solutions of Microsoft Exchange Server 2013 xv
Module 8 Lab: Planning and Configuring Message Transport
L8-51
Module 9 Lab: Planning and Configuring Message Security
L9-57
Module 10 Lab: Configuring Administrative Security and Auditing
L10-63
Module 11 Lab: Monitoring and Troubleshooting Exchange

Server 2013
L11-69
About This Course

This section provides a brief description of the course, audience, suggested prerequisites, and course
objectives.
Course Description
About This Course
xvii
This course will provide you with the knowledge and skills to plan, deploy, manage, secure, and support
Microsoft Exchange Server 2013. This course will teach you how to configure Exchange Server 2013
and supply you with the information you will need to monitor, maintain, and troubleshoot Exchange
Server 2013. This course will also provide guidelines, best practices, and considerations that will help you
optimize performance and minimize errors and security threats in Exchange Server 2013.
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 2013. People coming into the course are expected to have at least 3 years of experience working in
the IT fieldtypically in the areas of network administration, help desk, or system administration. They are
not expected to have experience with previous Exchange Server versions.
The secondary audience for this course will be candidates that are IT professionals who are looking to take
the exam 70-341: Core Solutions of Microsoft Exchange Server 2013 as a standalone, or as part of the
requirement for the Microsoft Certified Solutions Expert (MCSE) certification.
Student Prerequisites
This course requires that you meet the following prerequisites:
Understanding of TCP/IP and networking concepts.
Understanding of Windows Server 2008 or 2012 and AD DS, including planning, designing and
deploying.
Understanding of security concepts such as authentication and authorization.
Working in a team or a virtual team.
Working knowledge of Public Key Infrastructure (PKI) technologies Active Directory Certificate
Services (AD CS).
Working knowledge of Domain Name System (DNS).
Course Objectives
After completing this course, students will be able to:
Perform an Exchange Server 2013 deployment and manage Exchange Server 2013
Plan for a Mailbox server role deployment and configure the Mailbox servers and mailbox databases
Manage Exchange Server 2013 recipients
Plan Client Access server deployment and configure the Client Access server roles
Plan and configure mobile messaging and secure Internet access for Client Access server
Configure highly available mailbox databases and Client Access servers
Plan and implement Exchange Server 2013 disaster recovery
About This Course
xviii
Plan and configure message transport and manage transport rules
Plan message hygiene and implement an antivirus and anti-spam solution for Exchange Server 2013
Manage Role Based Access Control (RBAC) permissions and split permissions
Monitor, maintain, and troubleshoot Exchange Server 2013
Course Outline
The course outline is as follows:
Module 1, Deploying and Managing Microsoft Exchange Server 2013
Module 2, Planning and Configuring Mailbox Servers"
Module 3, Managing Recipient Objects"
Module 4, Planning and Deploying Client Access Servers"
Module 5, Planning and Configuring Messaging Client Connectivity
Module 6, Planning and Implementing High Availability
Module 7, Planning and Implementing Disaster Recovery
Module 8, Planning and Configuring Message Transport
Module 9, Planning and Configuring Message Hygiene
Module 10, Planning and Configuring Administrative Security and Auditing
Module 11, Monitoring and Troubleshooting Exchange Server 2013
Course Materials
The following materials are included with your kit:
Course Handbook: a succinct classroom learning guide that provides the critical technical
information in a crisp, tightly-focused format, which is essential for an effective in-class learning
experience.
About This Course
xix
Lessons: guide you through the learning objectives and provide the key points that are critical to
the success of the in-class learning experience.
Labs: provide a real-world, hands-on platform for you to apply the knowledge and skills learned
in the module.
Module Reviews and Takeaways: provide on-the-job reference material to boost knowledge
and skills retention.
Lab Answer Keys: provide step-by-step lab solution guidance.
Course Companion Content on the http://www.microsoft.com/learning/companionmoc Site:

searchable, easy-to-browse digital content with integrated premium online resources that
supplement the Course Handbook.
Modules: include companion content, such as questions and answers, detailed demo steps and
additional reading links, for each lesson. Additionally, they include Lab Review questions and
answers and Module Reviews and Takeaways sections, which contain the review questions and
answers, best practices, common issues and troubleshooting tips with answers, and real-world
issues and scenarios with answers.
Resources: include well-categorized additional resources that give you immediate access to the
most current premium content on TechNet, MSDN, or Microsoft Press.
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 an email to

support@mscourseware.com. To inquire about the Microsoft Certification Program, send an
email to mcphelp@microsoft.com.
Virtual Machine Environment
About This Course
xx
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 Hyper-V to perform the labs.
Important: At the end of each lab, you must revert the virtual machines to a snapshot. You can
find the instructions for this procedure at the end of each lab.
The following table shows the role of each virtual machine that is used in this course:
Virtual machine
Role
20341B-LON-DC1
Domain controller running Windows Server 2012 in the Adatum.com

domain
20341B-LON-DC1-B
Domain controller running Windows Server 2012 in the Adatum.com

domain (used the for installation lab)
20341B-LON-EX1-B
Windows Server 2013 member server for Exchange Server 2013

installation lab
20341B-LON-CAS1
Windows Server 2012 server, with Exchange Server 2013 Client Access
Server role installed
20341B-LON-CAS2
Windows Server 2012 server, with Exchange Server 2013 Client Access
20341B-LON-MBX1
Windows Server 2012 server, with Exchange Server 2013 Mailbox

20341B-LON-MBX2
Windows Server 2012 server, with Exchange Server 2013 Mailbox

20341B-LON-SVR1
Windows Server 2012 server, member of Adatum.com domain
20341B-LON-TMG
Threat Management Gateway server in Adatum.com domain
20341B-LON-CL1
Client computer running Windows 8 and Office 2013 in the

Adatum.com domain
Software Configuration
The following software is installed on each VM:
Windows Server 2012
Windows 8
Microsoft Office 2013
Exchange Server 2013, Cumulative Update 1
Windows Server 2008 R2 and Microsoft Forefront Threat Management Gateway
Classroom Setup
Each classroom computer will have the same virtual machines configured in the same way.
Course Hardware Level
About This Course
xxi
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 is taught.
Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) processor
Dual 120 gigabyte (GB) hard disks 7200 RM Serial ATA (SATA) or better. The hard disks should be
configured with a separate volume (Drive C: and Drive D:) on each hard disk.
16 GB RAM
DVD drive
Network adapter
Super VGA (SVGA) 17-inch monitor
Microsoft Mouse or compatible pointing device
Sound card with amplified speakers
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 and Managing Microsoft Exchange Server 2013

Contents:
Module Overview
1-1
Lesson 1: Exchange Server 2013 Prerequisites and Requirements
1-2
Lesson 2: Exchange Server 2013 Deployment
1-11
Lesson 3: Managing Exchange Server 2013
1-23
1-31
Module Review and Takeaways
1-36
Module Overview
Exchange Server 2013 is the new version of Microsofts email and collaboration suite. It is a successor to
Microsoft Exchange Server 2010. Exchange Server 2013 offers many enhancements in architecture,
functionality, and features for both administrators and end users. To successfully implement Exchange
Server 2013, you should know its prerequisites, as well as how to deploy it in your existing infrastructure.
This module examines how to deploy and manage Exchange Server 2013.
Objectives
After completing this module, you will be able to:
Describe Exchange Server 2013 prerequisites and requirements.
Perform an Exchange Server 2013 deployment.
Manage Exchange Server 2013.
Lesson 1
Exchange Server 2013 Prerequisites and Requirements
1-2 Deploying and Managing Microsoft Exchange Server 2013
Before you start the of Exchange Server 2013 deployment process, you must make sure that your current
Active Directory Domain Services (AD DS) and network infrastructure components satisfy requirements
for an Exchange Server deployment. In addition, you should plan hardware resources for Exchange Server
installation. Because Exchange Server 2013 integrates intensively with AD DS, you must extend the AD DS
schema before starting the installation process. In this lesson, we will review the requirements for installing
Exchange Server 2013.
Lesson Objectives
After completing this lesson, you will be able to:
Describe Active Directory components and Exchange Server integration.
Describe Domain Name System (DNS) server requirements for Exchange Server 2013.
Describe software requirements for Exchange Server 2013.
Describe hardware requirements for Exchange Server 2013.
Describe infrastructure requirements for Exchange Server 2013.
Prepare AD DS for an Exchange Server 2013 deployment.
Active Directory Components and Exchange Server Integration

Active Directory information is divided into four
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 the 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 contains 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. In addition, some distributed applications and services store
information in the configuration partition. This information replicates through the entire forest, so that
each domain controller retains 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 organizational unit (OU) that is used to organize other objects.
Core Solutions of Microsoft Exchange Server 2013 1-3
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 can create application partitions manually, and an application can automatically create
partitions during its installation process. 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 2013 does not use
application partitions to store information.
Exchange Server 2013 and AD DS Partitions Integration
To ensure proper placement of Active Directory components in relation to computers that are running
Exchange Server, you must understand how Exchange Server 2013 communicates with AD DS and uses
Active Directory information to function. AD DS stores most Exchange Server 2013 configuration
information.
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 2013, you can also add Office 365 domain to the Exchange
Administration Center (EAC) console. This enables you to manage multiple organizations from
a single management console.
Schema Partition
The Exchange Server 2013 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 2013 organization.
Because AD DS replicates the configuration partition among all domain controllers in the forest,
configuration of the Exchange Server 2013 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 2013, the email attributes for mail-enabled and mailbox-enabled
objects replicate to the global catalog. In the context of Exchange Server, global catalog is used for
the following: The global address list (GAL) is generated from the recipients list in an Active Directory
forests global catalog.
Exchange Server 2013 transport service access the global catalog to find the location of a recipient
mailbox when delivering messages.
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 server in each Active Directory site that contains
an Exchange 2013 server. You must deploy enough global catalog servers to ensure adequate
performance. Exchange Server 2013 does not use Read-Only Domain Controllers (RODCs) or
RODCs that you configure as global catalog servers (ROGC). This means that you should not
deploy an Exchange 2013 server in any site that contains only RODCs or ROGCs.
DNS Server Requirements for Exchange Server 2013

Each computer that is running Exchange Server
must use DNS to locate AD DS and the global
catalog servers. As a site-aware application,
Exchange Server 2013 prefers to communicate
with domain controllers that are located in the
same site as the computer that is running
Exchange Server.
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 Domain Name System (DNS)
with service (SRV) records that describe the server
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 that 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 that contain information
that AD DS uses to map a service back to the computer that provides the service. The SRV records for
domain controllers and global catalog servers are registered with 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.
SRV resource records use the following format:
_Service_.Protocol.Name Ttl Class SRV Priority Weight Port Target
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 that have
the same site attribute as the Exchange Server.
Host Records
Host records provide 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 Internet Protocol version 4 (IPv4), which are A records; or Internet Protocol version 6
(IPv6) records, which are 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 might need to configure
Sender Policy Framework (SPF) records to support Sender ID spam filtering. In addition, 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.
Software Requirements for Exchange Server 2013

Exchange Server 2013 requires that some software
be preinstalled before you start the deployment
process. First, you should plan for the operating
system platforms that will be used for Exchange
Server 2013. The following operating systems are
supported for installation of Exchange Server 2013
roles:
Windows Server 2012 Standard or

Datacenter
Windows Server 2008 R2 Standard with

Service Pack 1 (SP1)
Windows Server 2008 R2 Enterprise with SP1
Windows Server 2008 R2 Datacenter RTM or newer
Note: Server Core installation option is not a supported operating system option for
Exchange Server 2013 installation. In addition, Windows Server 2008 R2 Standard does not
support failover clustering and cannot use database availability groups (DAGs) in Exchange Server
for high availability. You cannot upgrade Windows Server after you have installed Exchange.
Depending on which Exchange Server role is installed, different Windows components can be installed on
a server. However, you do not need to install these roles and features prior to Exchange Server installation
because the installation process can install the necessary roles and features automatically.
Note: If you choose to install Windows Server roles and features during Exchange Server
setup, you might be required to restart the server before Exchange server starts installation. This
is expected behavior.
However, there are additional components that you should install manually. These components, freely
available to download from Microsoft, include:
Microsoft .NET Framework 4.5 (only for Windows Server 2008 and 2008 R2).
Windows Management Framework 3.0 (already included with Windows Server 2012).
Remote Server Administration Tools (RSAT) for AD DS (can be installed with Server Manager).
Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit.
Microsoft Office 2010 Filter Pack SP1 64-bit or Microsoft Office 2013 Filter Pack.
Exchange Server Updates for Knowledge Base articles KB974405, KB2619234, and KB2533623 when
installing Exchange Server 2013 on Windows Server 2008 R2.
You also should ensure that the Task Scheduler service is enabled and running on the server where you
plan to install Exchange Server 2013.
Hardware Requirements for Exchange Server 2013

Determining the hardware requirements for
Exchange Server 2013 is more complex than
simply reading the specifications provided by
Microsoft. Many other factors can influence the
Exchange Server hardware design, aside from the
general specifications that provide information
about minimum supported hardware
configuration.
First, the server role that is installed has a
significant influence on hardware specifications.
For example, the Mailbox server likely requires
more powerful hardware than the Client Access
server does. Second, many organizations install all Exchange Server roles on a single computer, which
means that you must merge hardware requirements for each of the roles.
The processor for an Exchange Server computer must be a 64-bit architecture-based Intel processor that
supports Intel 64 architecture (formerly known as Intel EM64T), or an AMD processor that supports the
AMD64 platform. Intel Itanium IA64 processors are not supported.
Memory
We recommend that you consider using the maximum server memory configuration when deciding on
the amount of RAM memory that you need for Exchange Server 2013. Different server architectures have
different memory limits. Check the following technical specifications for the server to determine the most
cost-efficient maximum memory configuration:
Memory speed. Some server architectures require slower memory modules to scale to the maximum
supported amount of memory for a specific server. For example, the maximum server memory might
be limited to 32 gigabytes (GB) with PC3 10666 (DDR3 1333), or 128 GB using PC2 6400 (DDR2 800).
Check with the manufacturer to ensure that the memory configuration target for Exchange Server
2013 is compatible in terms of speed.
Memory module size. Consider choosing the largest memory module size that the server supports.
Generally, the larger the memory module, the more expensive it is. Make sure that the maximum
memory module size allows you to meet your target memory requirements for Exchange Server 2013.
Total number of memory slots. Consider how many memory modules a specific server will support.
The total number of slots, multiplied by the maximum memory module size, provides the maximum
memory configuration for the server. Keep in mind that memory modules sometimes must be
installed in pairs.
When you plan the amount of memory to be installed in Exchange servers, you should follow these
guidelines:
Mailbox: 8 GB minimum
Client Access: 4 GB minimum
Mailbox and Client Access combined: 8 GB minimum
Some servers experience a performance improvement when more memory slots are filled, while others
experience a reduction in performance. Check with your hardware vendor to understand this effect on
your server architecture.
Disk Drive Space
You have to consider several requirements when choosing and configuring disk drives for an Exchange
Server 2013 installation. You must have:
At least 30 GB on the drive on which you install Exchange.
An additional 500 MB of available disk space for each Unified Messaging (UM) language pack that
you plan to install.
200 MB of available disk space on the system drive.
A hard disk that stores the message queue database on with at least 500 MB of free space.
All partitions that Exchange Server 2013 will use must be formatted with the NTFS file system.
The space required for the Mailbox server role cannot be determined without knowing the number of
mailboxes, mailbox sizes, and high-availability requirements, among other parameters. We recommend
that you use the Mailbox server role calculator to determine optimal hardware requirements for the
Mailbox server role.
Hardware Configuration for Servers with Multiple Server Roles

When you design the hardware configuration for servers on which you install multiple server roles,
consider the following recommendations:
Plan for a minimum of two processor cores. The recommended number of processor cores is eight,
while 24 is the maximum recommended number.
Design a server with multiple server roles to use half of the available processor cores for the Mailbox
server role, and the other half for the Client Access server role.
Plan for the following memory configuration for a server with multiple server roles: 8 GB, and
between 2 MB and 10 MB per mailbox. This can vary based on the user profile and the number of
mailbox databases. We recommend 64 GB as the maximum amount of memory that you need.
Reduce by 20 percent the number of mailboxes per core calculation, based on the average client
profile, to accommodate the Client Access server role on the same server as the Mailbox server role.
Deploy multiple Exchange Server roles on a Mailbox server that is a DAG member, if desired. This
scenario provides full redundancy for the Mailbox and the Client Access server roles on just two
Exchange 2013 servers.
Infrastructure Requirements for Exchange Server 2013

Before you deploy Exchange Server 2013 in
your organization, you need to ensure that your
organization meets AD DS and DNS requirements.
AD DS Requirements
You must meet the following AD DS requirements
before you can install Exchange Server 2013:
The domain controller that is the schema

master must have Windows Server 2012,
Windows Server 2008 R2, Windows Server
2008, or Windows Server 2003 with Service
Pack 2 (SP2). 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 2013, at least one global catalog server must
be installed and must run Windows Server 2012, Windows Server 2008, Windows Server 2008 R2, or
Windows Server 2003 SP2.
In each site where you plan to install Exchange Server 2013, you must have at least one writable
domain controller running Windows Server 2012, Windows Server 2008, or Windows Server 2008 R2.
The Active Directory domain and forest functional levels must run Windows Server 2003, at the
minimum, or newer versions.
DNS Requirements
Before you install Exchange Server 2013, you must configure DNS correctly in your Active Directory forest.
All servers that run Exchange Server 2013 must be able to locate Active Directory domain controllers,
global catalog servers, and other Exchange Servers.
Preparing AD DS for Exchange Server 2013 Deployment

Before implementing Exchange Server 2013 in
your environment, you must prepare AD DS.
AD DS, by default, does not have necessary
classes, objects, and attributes defined for the
Exchange Server. By preparing AD DS, you
extend the AD DS schema, and also modify
configuration and domain partitions of AD DS.
In addition, Exchange Server requires several
groups and special permissions in AD DS; these
are also configured during AD DS preparation.
You can prepare your AD DS by running the

Exchange Sever 2013 Setup Wizard with a user
account that has the permissions required to prepare Active Directory and the domain. To prepare the
AD DS schema and configuration partition, you must use an account that is a member of the Schema
Admins and Enterprise Admins groups. By using this type of account, the wizard automatically prepares
Active Directory and the domain.
Alternatively, you can also prepare AD DS for Exchange Server by running the Exchange Server 2013
setup utility from the command line. If you want to prepare the AD DS schema, and upgrade it to a
version supported by Exchange Server 2013, you should run either of the following setup commands:
setup /PrepareSchema or setup /ps. To execute this command, you must also be a member in the
Enterprise Admins or Schema Admins groups.
This command performs the following tasks:
Connect the Exchange Server to the schema master domain controller.
Import LDAP Data Interchange Format (LDIF) files to update the schema with Exchange Server 2013
specific attributes.
Set the schema version (ms-Exch-Schema-Version-Pt) to 15132.
Note: You can also prepare the schema as a part of the PrepareAD procedure, which is
described below.
To prepare AD DS objects and the AD DS configuration partition for Exchange Server 2013, you should
run setup with the /PrepareAD switch, by executing the following command:
Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms /OrganizationName:Name of
Organization
Creates the Microsoft Exchange container if it does not exist; the container is created under
CN=Services,CN=Configuration,DC=<root domain>.
Verifies that the schema has been updated, and that the organization is up to date, by checking
the objectVersion property in Active Directory. The objectVersion property is in the CN=<your
organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain> container.
The objectVersion value for Exchange Server 2013 is 15448.
Creates all necessary objects and containers needed for Exchange Server 2013, under
CN=<Organization Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<root
domain>.
Creates the default Accepted Domains entry if it does not exist, based on the forest root
namespace, under CN=Transport Settings,CN=<Organization Name>,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=<root domain>.
Assigns specific permissions throughout the configuration partition.
Imports the Rights.ldf file. This adds the extended rights required for Exchange to install into
Active Directory.
Creates the Microsoft Exchange Security Groups OU in the root domain of the forest, and assigns
specific permissions to this OU.
Creates the management role groups within the Microsoft Exchange Security Groups OU.
Adds the new universal security groups (USGs) that are within the Microsoft Exchange
Security Groups OU to the otherWellKnownObjects attribute stored on the CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=<root domain> container.
Creates the Unified Messaging Voice Originator contact in the Microsoft Exchange System Objects
container of the root domain.
Prepares the local domain for Exchange Server 2013.
To perform this command, you must be a member of Enterprise Admins security group, and you must
run this command on the computer that is in the same domain as the schema master domain controller.
If you have more than one domain, you should wait for a period of time after running this command, so
that changes performed to AD DS are replicated to all other domains and domain controllers.
At the end of this process, you should execute the setup /PrepareDomain command in each domain
where Exchange recipients will be located. You do not need to run this command in a domain where you
ran setup /PrepareAD.
Alternatively, you can also run setup /PrepareDomain:<FQDN of domain you want to prepare> to
prepare a specific domain, or you can run setup /PrepareAllDomains or setup /pad to prepare all
domains in your organization.
Creates the Microsoft Exchange System Objects container in the root domain partition in AD DS, and
sets permissions on this container for the Exchange Servers, Exchange Organization Administrators,
and Authenticated Users groups.
Sets the objectVersion property in the Microsoft Exchange System Objects container under DC=<root
domain>. This objectVersion property contains the version of domain preparation. The version for
Exchange Server 2013 is 13236.
Creates a domain global group called Exchange Install Domain Servers in the current domain.
Assigns permissions at the domain level for the Exchange Servers USG and the Organization
Management USG.
After all of these commands are successfully completed, your AD DS is ready for Exchange Server
2013 installation. You can check if preparation went well, by performing the following tasks: In the
Schema naming context, verify that the rangeUpper property on ms-Exch-Schema-Version-Pt is set
to 15132.
In the Configuration naming context, verify that the objectVersion property in the CN=<your
organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain> container is
set to 15448.
In the Default naming context, verify that the objectVersion property in the Microsoft Exchange
System Objects container under DC=<root domain is set to 13236.
Lesson 2
Exchange Server 2013 Deployment
Deploying Exchange Server 2013 requires that you complete all of the prerequisite planning steps, install
the software, and then complete the post-installation tasks. When preparing for your installation, you
must determine the type of deployment that you are going to perform, and how will you design server
role placement. This lesson examines the server role architecture in Exchange Server 2013, in addition to
various deployment scenarios.
Lesson Objectives
Describe server role architecture in Exchange Server 2013.
Describe deployment options for Exchange Server 2013.
Describe hybrid-deployment considerations with Microsoft Office 365.
Describe upgrade and migration options.
Deploy Exchange Server 2013 as a virtual machine.
Describe how to install Exchange Server 2013 using the setup wizard.
Describe how to Install Exchange Server 2013 in Unattended Mode.
Install Exchange Server 2013 in Unattended Mode.
Describe and perform the Post Installation Tasks.
Troubleshoot Exchange Server installation.
Exchange Server Role Architecture in Exchange Server 2013

In Exchange Server 2013, Microsoft made
major changes in the server role architecture. In
Exchange Server 2007 and Exchange Server 2010,
there were five server roles hosting various
functionalities, including:
Mailbox Server role
Client Access role
Hub Transport role
Edge Transport role
Unified Messaging role
In Exchange Server 2013, the number of server roles is greatly reduced, to only these two roles:
Mailbox Server role
Client Access server role
All other roles, except the Edge Transport role (which does not exist in Exchange Server 2013), are
integrated within these two roles.
Server Roles in Exchange Server 2013
Unlike Microsoft Exchange Server 2010, in which the Mailbox Server role hosted only mailbox and public
folder databases and provided email storage, in Exchange Server 2013, the Mailbox Server role also
includes Client Access protocols, Hub Transport service, mailbox databases, and Unified Messaging
components. This means that the functionality of three roles in Exchange Server 2010 (Mailbox, Hub
Transport, and Unified Messaging) is now integrated in only one role in Exchange Server 2013.
The Client Access Server role has changed in Exchange Server 2013. The Client Access server is now
basically a proxy server that handles all client connections, by admitting all client requests and routing
them to the correct active Mailbox database. It provides authentication, redirection, and proxy services,
and offers support for the following client access protocols: HTTP, POP and IMAP, and SMTP.
Also unchanged is the fact that the Client Access server does not store any user data on itself; nor does
it do any message queuing. The Client Access server role also provides some security functionality, by
enforcing SSL in communication with clients. In some scenarios where the Exchange Server is deployed in
multiple sites within one organization, the Client Access server also can redirect the request to a more
suitable Client Access server or proxies the connection to the right Mailbox server.
Note: The Edge Transport role is not included in Exchange Server 2013. However, you can
use the Exchange Server 2010 Edge Transport server with Exchange Server 2013 servers.
Client Access Server

The Client Access Server in Exchange Server 2013 provides the following features:
Stateless server. In Exchange Server 2007 and 2010, most of the protocols on the Client Access server
required session affinity in scenarios where the Client Access server was in a load-balancing cluster.
That meant that all requests from a single Outlook Web App client had to be handled during an
entire session by a specific Client Access server within a load-balanced array of Client Access servers.
In Exchange Server 2013, this is no longer the case, and the Client Access server is now stateless.
All processing for the mailbox now happens on the Mailbox server, so it does not matter which
Client Access server in an array of Client Access servers receives each individual client request. By
implementing this, you can use Layer 4 load balancing instead of the more expensive Layer 7 load
balancing. This allows hardware load balancing devices to support significantly more concurrent
connections.
Connection pooling. As in previous releases of Exchange, the Client Access Server manages
client authentication for client connections and sends AuthN data to the Mailbox server role. The
connection between the Client Access Server and Mailbox server is established by using a privileged
account that is a member of the Exchange Servers group. This allows the Client Access servers to
effectively pool connections to the Mailbox servers. With this technology, a Client Access array can
handle millions of client connections from the Internet or internal network, but uses many fewer
connections to proxy the requests to the Mailbox servers than in previous versions of Exchange.
Mailbox Server
In Exchange Server 2013, the Mailbox Server role provides much more functionality than in previous
Exchange Server versions. This includes integration of the Hub Transport service (previously known as the
Hub Transport server role) and Unified Messaging service (previously known as the Unified Messaging
server role). This is the key role for storing mailbox and public folders data, as well as for Unified
Messaging functionality and message queuing.
The Mailbox Server role also interacts with the Client Access server, as well as with AD DS domain
controllers and global catalogs. The Mailbox Server role never communicates with clients directly, as it did
in previous versions of Exchange Server. All client-based communication is performed through the Client
Access server role.
Client and Server Communication in Exchange Server 2013
Because of the modifications that were made to the Exchange Server 2013 architecture, changes were also
made to the way in which clients communicate with the Exchange Server, and how Exchange Server 2013
roles communicate with each other and with AD DS components.
From the client perspective, the most important connectivity change is that remote procedure call (RPC)
is no longer supported as a direct client access protocol. In previous Exchange versions, Outlook clients
from an internal network were connecting to Exchange Server by using RPC (or MAPI). In Exchange Server
2013, all client connections are established by using RPC over HTTPS. This means that all clients are
connecting by using the Outlook Anywhere service. This eliminates the need to have the RPC service
running on the Client Access server. In addition, you will have one fewer FQDN to manage, because all
clients will be using a new connection point made up of the users mailbox GUID + @ + UPN suffix. As
a result of these changes, only Outlook 2007 and newer clients support connection to Exchange Server
2013.
Deployment Options for Exchange Server 2013

When you plan an Exchange Server 2013
installation, you must decide how you will
organize server roles, and you must choose
the appropriate Exchange Server 2013 version.
Exchange Server 2013 is available in both the

Standard Edition and Enterprise Edition. The
Standard Edition should meet the messaging
needs of most small and medium corporations,
but it also may be suitable for specific server roles
or branch offices. The Enterprise Edition, designed
for large enterprise corporations, enables you to
create additional databases, and includes other
advanced features. The main difference between Standard and Enterprise versions is that Enterprise
version supports up to 50 mailbox databases while with Standard version you can create up to five
databases. The version used is determined by product key that you enter when activating your Exchange
installation. You should also make sure that you select the appropriate version of client access license
(CAL) from the following options:
Exchange Server Standard CAL. This license provides access to email, shared calendaring, Outlook
Web App, and ActiveSync.
Exchange Server Enterprise CAL. This license 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.
In general, there are three deployment scenarios that you can choose from, including:
Single server deployment. In this scenario, you deploy both Exchange Server roles on a single server.
This scenario is appropriate for small organizations with limited resources. Deploying all Exchange
Server services on a single server has several drawbacks. These include having a single point of failure
for your whole messaging system, and not having any high-availability options. If you choose to have
a single-server Exchange deployment, it is recommended that you deploy Exchange Server inside
a virtual machine, and that you keep that virtual machine highly available or at least replicated to
another Hyper-V in Windows Server 2012 host. This will provide you with high availability and
redundancy for critical Exchange services.
Multiple server deployment. In the multiple-server deployment scenario, you usually install the Client
Access Server role and the Mailbox server role on separate servers, or you install more than one server
with both roles installed. This requires that you provide at least two virtual or physical machines for
the Exchange Server deployment. In scenarios where you also want to provide high availability, you
should add more machines to build the Client Access load balancing cluster and DAGs. You cannot
use DAGs and network load balancing (NLB) on the same set of machines. To achieve full redundancy
for Exchange Server, you need at least four servers for Exchange, and at least two domain controllers.
Hybrid deployment. A hybrid deployment provides the ability to extend on-premises Exchange Server
functionality to the cloud. In this scenario, you connect your AD DS and Exchange Server with
Microsoft Office 365. This allows you to move some of your Exchange resources to Office 365. A
hybrid deployment also can serve as an intermediate step prior to moving completely to an Exchange
Online organization.
Exchange Server 2013 Hybrid Deployment with Office 365

Office 365 is a suite of four Microsoft services that
are now available in an online version: Exchange
Online, Lync Online, SharePoint Online, and
Office Professional Plus. It is a subscription-based
service that features various pricing options.
Exchange Online provides Exchange Server

with email, calendar, and contacts in addition
to antivirus and anti-spam protection. You can
connect your existing Exchange Server 2013
organization to Exchange Online to provide rich
coexistence for users. In Exchange Server 2013, it
is possible to create a hybrid deployment between
on-premises Exchange Server and Exchange Online from Microsoft Office 365. A hybrid deployment offers
organizations the ability to extend the user experience and administrative control that 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 @adatum.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 onpremises 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.
Cloud-based message archiving for on-premises Exchange mailboxes. Exchange Online Archiving can
be used with a hybrid deployment.
If you want to implement Exchange Server 2013 in a hybrid deployment scenario, you must configure
two very important components to connect your on-premises AD DS and Exchange infrastructure and
Office 365. These include:
Microsoft Federation Gateway. The Microsoft Federation Gateway is a free service that provides a
trust connection between your Exchange Server (installed on premises) and Exchange Online (as a
part of Office 365). It is mandatory that your on-premises Exchange organization trusts Microsoft
Federation Gateway. You can configure this trust relationship manually, or it can be created
automatically as part of configuring a hybrid deployment with the Hybrid Configuration Wizard. A
federation trust with the Microsoft Federation Gateway for your Office 365 tenant is automatically
configured when you activate your Office 365 service account.
Active Directory synchronization. If you want to provide services from Exchange Online to your local
users, you must synchronize information from your AD DS to Exchange Online. Active Directory
synchronization replicates on-premises AD DS information for mail-enabled objects to the Office 365
organization, to support the unified GAL. Organizations that configure a hybrid deployment must
deploy Active Directory synchronization on a separate on-premises server.
Upgrade and Migration Options

To upgrade your existing Exchange organization
to Exchange Server 2013, you cannot directly
upgrade your current Exchange Server by
installing Exchange Server 2013 over a previous
version. This procedure, which is known as an inplace upgrade, is not supported for Exchange
Server 2013. Instead, you can only upgrade your
existing Exchange organization Exchange Server
by installing Exchange Server 2013 on a new
server, and then you can migrate all resources
from your previous Exchange Server to Exchange
Server 2013. Once the migration is complete, you
can decommission your old Exchange Server.
Coexistence of Exchange Server 2013 and earlier versions of Exchange Server is described in following
table:
Exchange version
Exchange organization coexistence
Exchange Server 2003 and earlier versions
Not supported
Exchange 2007
Supported
Exchange 2010
Supported
Deploying Exchange Server 2013 as Virtual Machines

Exchange Server 2013 allows you to deploy
all server roles as virtual machines. Using
virtualization for deploying servers greatly
improves resource usage, and also simplifies
deployment and management. In addition to
evaluating the potential benefits of an upgrade,
you also should consider the issues for deploying
virtual machines in your current Exchange Server
environment.
Benefits of Using Virtual Machines
Deploying Exchange 2013 servers as virtual

machines provides the same advantages and
disadvantages as deploying other servers as virtual machines. Many organizations are virtualizing physical
servers as a way to reduce costs and to ensure that all server hardware is properly utilized.
Following are the benefits of deploying Exchange Servers as virtual machines:
Increases hardware utilization and decreases the number of physical servers. In many organizations,
the servers deployed in data centers have low hardware utilization. By deploying multiple virtual
machines on a single physical server, you can increase hardware utilization while decreasing the
number of deployed physical servers. This can result in significant cost savings.
Provides server-management options that are not available for physical servers. Because virtual
machines are essentially only a set of files, you may have additional management options with virtual
machines. For example, to increase the hardware level of a virtual machine, you can assign more of
the host resources to the virtual machine, or move the virtual machine files to a more powerful host
server.
Although running Exchange Servers as virtual machines can provide significant benefits, you also need
to verify that your organization has the resources and management capability to provide a critical service
like messaging in a virtual environment. Implementing virtualization does introduce an additional level of
complexity because it requires you to manage both the virtual Exchange Servers and the host servers. In
addition, hosting multiple virtual machines on a single host can increase the risk of a single physical server
failure, resulting in the failure of multiple virtual machines.
Considerations for Deploying Exchange Server 2013 Servers as Virtual Machines
Although running Exchange Server 2013 as a virtual machine provides certain benefits, you should also
consider the following issues:
You can design Exchange Servers to ensure 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 benefit of running virtual machines is that you can configure high availability within the virtual
machine environment. In Exchange Server 2013 you can run both DAGs and a virtual machine-based,
high-availability solution. DAGs provide failover features that are not available in virtual machinebased, high-availability solutions. DAG features include multiple copies of the database, database
backup on the passive node, and application-aware failovers. You can combine DAGs with host-based
failover clustering and migration technology, as long as the virtual machines are configured in a way
that they do not save and restore state on disk when moved or taken offline. All failover activity
occurring at the hypervisor level must result in a full reboot when the virtual machine is activated on
the target node. All planned migration must either result in shutdown and full reboot, or an online
migration that makes use of a technology like Hyper-V Live Migration.
The storage used by the Exchange Server guest machine can be a virtual storage of a fixed size, a
small computer system interface (SCSI) pass-through storage, or Internet SCSI (iSCSI) storage. Passthrough 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 fixedsize virtual disks. You can also use the virtual SAN feature in Hyper-V 3.0 to present storage from
Fibre Channel SAN to a virtual machine.
You must allocate sufficient storage space for each Exchange Server guest machine on the host
machine. Storage is needed for the fixed disk that contains the guests operating system, any
temporary memory storage files in use, and related virtual machine files that are hosted on the host
machine. In addition, for each Exchange Server guest machine, you must allocate sufficient storage
for the message queues, and sufficient storage for the databases and log files on Mailbox servers. You
should host the storage that Exchange Server uses in disk spindles that are separate from the storage
that hosts the guest virtual machines operating system. The operating system for an Exchange guest
machine must use a disk that has a size equal to at least 15 GB in addition to the size of the virtual
memory that is allocated to the guest machine. This requirement is necessary to account for the
operating system and paging file disk requirements. For example, if the guest machine is allocated
16 GB of memory, the minimum disk space needed for the guest operating system disk is 31 GB.
You can deploy only management softwaresuch as antivirus software, backup software, and virtual
machine management softwareon the physical root machine. You should not install any other
server-based applications, such as Exchange Server, Microsoft SQL Server, or AD DS, 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 must share 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 2013 as a virtual machine, make sure that you plan
the virtual hardware requirements carefully. Running Exchange Server 2013 as a virtual machine does
not change the hardware requirements for the Exchange Server. You must assign the same hardware
resources to the Exchange Server virtual machine that you would assign to a physical server running
the same workload.
Note: Do not use virtual machine snapshots with Exchange Server deployed inside a virtual
machine in a production environment. Doing so can result in unexpected behavior and it is not
supported.
Discussion: Implementing Exchange Infrastructure in a Virtual Environment

Discuss virtualization of Exchange and other
services with the students. Lead the discussion
with the following questions:
Do you use virtualization in your

environment? If yes, which virtualization
platform do you use?
Are you aware of the new features available

in Hyper-V 3.0 in Windows Server 2012,
such as the new virtual disk format, network
virtualization, clusterless migration, Hyper-V
replica, and others?
If you are using Exchange Server, is it virtualized or not? Explain your answer.
If you plan to implement Exchange Server 2013, will you virtualize it? Explain your answer.
How to Install Exchange Server 2013 Using the Setup Wizard

Exchange Server 2013 can be installed by using
the graphical interface-based setup wizard or by
using command line utilities. If you decide to use
the graphical interface, you have to run the setup
program from the installation media. However,
before doing so, ensure that you installed all of
the prerequisites required by Exchange Server
2013.
You will perform the following steps when you
install Exchange Server 2013 with the setup
wizard:
1.
On the Check for Updates page, you can

choose to update the setup process with the latest files from Microsoft Update. It is recommended
that you do this if your Exchange Server is connected to the Internet.
2.
On the License Agreement page, you should read your license agreement with Microsoft.
3.
On the Recommended Settings page, you can choose if you will configure your server to report
errors to Microsoft. It is recommended that you leave this setting on by default.
4.
On the Server Role Selection page, you should select the server roles that you want to install. You
can choose to install the Mailbox Server role, the Client Access server role, or both. You can also
choose to install only Management Tools. On this same page, you can select to install all necessary
Windows roles and features that are needed for the Exchange installation that you want to perform.
5.
On the Installation Space and Location page, you can change the path where you want to install
the Exchange Server.
6.
On the Exchange Organization page, you can choose the name for your Exchange organization, if
you are deploying a new one. If you are joining to an existing Exchange organization, the name value
will be pre-populated. On this same page, you also can choose to apply the Active Directory splitpermission model to your Exchange organization.
7.
On the Malware Protection Settings page, you can choose to disable built-in malware protection
functionality. We recommend that you do not disable this malware protection, unless you have
another solution for antivirus protection already implemented.
8.
On the Readiness Checks page, the setup procedure will inform you if there are any obstacles to the
Exchange Server installation, and if your hardware and software prerequisites are met. If everything is
in order, you should click Install and wait for Exchange Server to be installed. If you did not prepare
your AD DS environment before starting the Exchange Server installation, the setup procedure will
complete this task during installation.
Installing Exchange Server 2013 can take between 20 and 50 minutes, depending on the components that
are installed and your server performance. After installation finishes, you can begin to configure your
deployment.
How to Install Exchange Server 2013 in Unattended Mode

Exchange Server 2013 installation can also be
performed without using the GUI setup wizard.
By using the command line to run the setup.exe
program, you can install Exchange Server 2013 in
unattended mode. This installation method allows
you to provide all of the answers for the setup
wizard in advance, and it supports installing
multiple Exchange Servers with the same settings.
To initiate an unattended installation, you should
run the setup.exe program from the command
line, and provide the appropriate switches to
specify your Exchange installation options.
Following is the syntax for an unattended installation with all available switches for setup.exe:
Setup.exe [/Mode:<setup mode>] [/IAcceptExchangeServerLicenseTerms]
[/Roles:<server roles to install>] [/InstallWindowsComponents]
[/OrganizationName:<name for the new Exchange organization>]
[/TargetDir:<target directory>] [/SourceDir:<source directory>]
[/UpdatesDir:<directory from which to install updates>]
[/DomainController:<FQDN of domain controller>]
[/AnswerFile:<filename>] [/DoNotStartTransport] [/LegacyRoutingServer]
[/EnableErrorReporting] [/NoSelfSignedCertificates]
[/AddUmLanguagePack:<UM language pack name>]
[/RemoveUmLanguagePack:<UM language pack name>] [/NewProvisionedServer:<server>]
[/RemoveProvisionedServer:<server>] [/ExternalCASServerDomain:<domain>]
[/MdbName:<mailbox database name>] [/DbFilePath:<Edb file path>]
[/LogFolderPath:<log folder path>] [/Upgrade]
You do not have to provide a value for each of these switches. You only need to include the switches that
pertain to your installation scenario and the level of detail that you want to provide.
The following is a list of the most commonly used switches:
/Mode. Controls what the setup program does. It can have the following values: Install, Uninstall,
RecoverServer.
/roles. Specifies which roles you want to install. If you specify multiple roles, you must separate them
with commas. You can provide values CA (for Client Access role) or MB (for Mailbox role).
/OrganizationName. Specifies the name you want to give to the new Exchange Server organization.
This parameter is required if you are installing the first server in an organization.
/TargetDir. Specifies the folder in which Exchange Server 2013 will be installed. Default:
%%programfiles%%\ Microsoft\Exchange Server.
/DomainController. Specifies which domain controller that the setup program will be read and write
from during installation.
The following are examples of commands that can be used for unattended installations:
Setup.exe /mode:Install /role:ClientAccess,Mailbox /OrganizationName:MyOrg
/IAcceptExchangeServerLicenseTerms
This command installs the Client Access server role, the Mailbox server role, and the management tools to
the default installation location, and provides the organization name of MyOrg.
Setup.exe /r:CA,MB /IAcceptExchangeServerLicenseTerms
This command installs the Client Access server role, the Mailbox server role, and the management tools to
the default installation location.
Setup.exe /role:ClientAccess,Mailbox /UpdatesDir:"C:\ExchangeServer\New Patches"
This command updates ExchangeServer.msi with updates from the specified directory, and then installs
the Client Access server role, Mailbox server role, and the management tools. If a language pack bundle is
included in this directory, the language pack is also installed.
Setup.exe /mode:Install /role:ClientAccess /AnswerFile:c:\ExchangeConfig.txt
This command installs the Client Access server role by using the settings in the ExchangeConfig.txt file.
Demonstration: Installing Exchange Server 2013

Demonstration Steps
1.
On LON-DC1, attach D:\Program Files\Microsoft Learning\20341\Drives

\ExchangeServer2013CU1.iso as a DVD drive.
2.
Open Windows PowerShell.
3.
Navigate to D: drive. Type .\Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms

/OrganizationName:Adatum, and press Enter. Wait until process finishes.
4.
Switch to LON-EX1.
5.
Map D:\Program Files\Microsoft Learning\20341\Drives\ExchangeServer2013CU1.iso as a

DVD drive.
6.
Open Windows Explorer and navigate to D:\.

o
Run setup.exe
Dont check for updates
Select to install both Mailbox and Client Access roles
Dont disable malware scanning
Start the prerequisite check.
Restart the computer and rerun setup.exe.
Post-Installation Tasks
After finishing the Exchange Server installation,
you may need to perform additional steps to
finalize the server deployment.
Configuring Exchange Server Security
Security is important for all of the servers in

your deployment. 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,
and sensitive and private information is often
sent through and stored in the messaging system.
Computers that are running Exchange Server all communicate with the Internet in some way, which is not
the case with many other servers. 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 2013:
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 can be easily compromised.
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 (if
deployed) or other SMTP gateway 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, if you deploy Edge Transport servers,
these 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 they can manage all
Exchange Server recipients and computers that are running Exchange Server in that domain. Reduce
delegated AD DS 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
2013. Failure to verify certification for Exchange Server 2013 could result in data or availability loss.
Products specifically designed for use with Exchange Server 2013 take advantage of new features.
Some of the additional software you might want to install or configure includes:
Antivirus software. You can choose to use Forefront Online Protection or a third-party antivirus
solution. You can also use built in antimalware protection.
Anti-spam software. Anti-spam software can significantly reduce unsolicited commercial email
messages that your users receive and have to manage. Many organizations choose to deploy thirdparty anti-spam solutions. You can also use the anti-spam solution built into Exchange Server 2013.
Backup software. To back up Exchange Server 2013 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). Operations Manager allows you to proactively monitor
and manage your Exchange Servers by installing monitoring agents on them.
Troubleshooting Exchange Server Installation
Although the Exchange Server setup process

rarely fails, if you fulfill all prerequisites, there are
some situations when you need to troubleshoot
the Exchange installation. During setup process,
Exchange Server installation performs very
detailed logging. Exchange setup logs are
located in C:\ExchangeSetupLogs folder. File
ExchangeSetup.log log file contains information
about the status of prerequisite and systemreadiness checks that Exchange Server performs
before the installation begins. This log also
contains information about every task that occurs
during the Exchange Server setup, and is the most complete log available for troubleshooting installation
errors. Other .msilog or .ps1 files may exist in this folder, depending on which roles are installed on this
server.
Some common installation problems and solutions are:
Insufficient disk space. Your server might not have the necessary disk space to install Exchange Server
2013. 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 2013 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 2013 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 2013, 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 2013 into an existing organization, you
must be a member of the Exchange Admins group for the older version of Exchange Server.
Lesson 3
Managing Exchange Server 2013
After Exchange Server 2013 is installed, you need to manage your Exchange deployment. Exchange
administrators can manage Exchange Server by using a new web-based graphical interface called the EAC,
or by using Exchange Management Shell. Exchange users can manage a set of available options by using
the Outlook Web App interface. This lesson examines each of these Exchange Server 2013 management
techniques.
Lesson Objectives
Manage Exchange Server 2013.
Describe EAC.
Manage User Mailbox properties with Outlook Web App.
Describe Windows PowerShell.
Describe Windows PowerShell Syntax.
Describe how to access help in Windows PowerShell.
Describe Exchange Management Shell.
Perform Management Shell Administration Examples.
Use Exchange Administration Tools to Manage Exchange.
Managing Exchange Server 2013

Exchange Server 2013 supports several methods
for managing your server and client settings.
Unlike Exchange Server 2010 and older versions,
in which management was primarily performed
by using the MMC-based Exchange Management
console, Exchange Server 2013 does not provide
an MMC-based console for configuration
management. Instead, Exchange Server 2013
uses a new web-based console called EAC.
Full management of Exchange Server 2013

can also be performed by using Exchange
Management Shell, a Windows PowerShell-based
console that provides all available options for managing your Exchange Server. Because several
management options are not available in the EAC, some advanced tasks must be performed using the
Exchange Management Shell.
Users also can manage some of their mailbox settings through Outlook Web App. This is also a webbased interface that enables users to configure available options for their mailboxes and connected
devices. Users are allowed to configure only a subset of available options.
It is important that you follow appropriate management techniques when performing specific
administrative tasks. For example, if you want to create mailboxes for several users at the same time,
it will be much more efficient to do that through Exchange Management Shell than by using EAC.
What Is EAC?
The EAC is the new, web-based console that is
used for managing your Exchange Server 2013
deployment. It is graphical console that allows you
to manage both an on-premises Exchange Server
and an Exchange Online or hybrid Exchange
deployment. This console is a replacement for the
Exchange Management console (which exists in
Exchange Server 2007 and 2010) and for the
Exchange Control Panel (ECP).
The EAC has several advantages over the MMCbased console that was used in previous versions
of Exchange. Because the EAC is a web-based
console, it is much faster and more responsive than the Exchange Management console. The EAC
allows you to administer both Exchange on-premises and Exchange Online deployments from the
same place. EAC can be accessed from a web-browser interface from both an internal network and the
Internet. However, if you want to disable Exchange management from outside your network, you can
partition access from the Internet/Intranet from within the ECP IIS virtual directory to allow or disallow
management features. This enables you to permit or deny access to users trying to access the EAC from
the Internet outside of your organizational environment, while still allowing access to an end-users
Outlook Web App Options.
You can access EAC by using the same URL syntax as used in older versions. It is located in the ECP
virtual directory. When you sign-in to EAC, you are provided with the ability to manage the following
components of your Exchange infrastructure:
Recipients. In this node, you manage mailboxes, groups, resource mailboxes, contacts, shared
mailboxes, and mailbox migrations and moves.
Permissions. This node contains options for managing administrator roles, user roles, and Outlook
Web App policies.
Compliance Management. The Compliance Management Center is used for managing In-Place
eDiscovery, In-Place Hold, Auditing, Data Loss Prevention, Retention Policies, Retention Tags, and
Journaling.
Organization. This node includes tasks related to the Exchange Organization, including Federated
sharing, Outlook Apps, and address lists.
Protection. Exchange Server 2013 includes built-in antimalware functionality, and the Protection
Center is the place where you to manage it, if you choose to implement Exchanges antimalware
protection rather than third-party software.
Mail Flow. In this node, you manage rules, delivery reports, accepted domains, and email address
policies, and send and receive connectors.
Mobile. On this place in EAC console, you can manage mobile devices that you allow to connect to
your organization. You can manage mobile device access and policies.
Public Folders. Unlike previous Exchange Server versions, in which public folder administration was not
possible from within the Exchange Management console, in Exchange 2013, public folders can be
managed from the Public Folders center.
Unified Messaging. The Unified Messaging center is where you manage UM dial plans and UM IP
gateways.
Servers. The Servers Center is where you will manage your Mailbox and Client Access servers,
databases, DAGs, virtual directories, and certificates.
Hybrid. The Hybrid Center is where you will access Hybrid setup and configuration.
Because the EAC is now a web-based management console, you will need to access it through your web
browser using the ECP virtual directory URL. To find the ECP virtual directory URL that provides access to
the EAC, run the following command:
Get-ECPVirtualDirectory | Format-List InternalURL,ExternalURL
Use the InternalURL or ExternalURL value in your web browser to launch the EAC.
Managing User Mailbox Properties with Outlook Web App

In Exchange Server 2013, users can manage their
accounts and mailboxes by using the Outlook
Web App interface. When users Sign in to Outlook
Web App they can see email and related items,
and they can also choose to manage their mailbox
settings.
This 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.
Manage inbox rules for automatic message

management.
Perform message tracking of messages sent or received from their mailbox.
Manage site mailboxes where they are members.
View and manage mobile devices that have connected to their mailboxes.
Manage text-messaging notifications.
View group memberships and request to join public groups.
Recover deleted messages.
Manage block and allow lists.
Change their password.
Manage applications for Outlook Web App.
This enables users to perform some of the tasks that were previously dedicated only to administrators,
thus giving users greater control over the appearance and performance of their mail system.
What Is Windows PowerShell?

Windows PowerShell is a command-line
management interface that can be used to
configure Windows Server 2012 and products
such as System Center 2012, Exchange Server
2013, and Microsoft SharePoint Server 2013.
This management interface, which provides an
alternative to the GUI management tool, enables
administrators to:
Create automation scripts.
Perform batch modifications.
Access settings that might be unavailable or

more difficult to configure in the GUI.
GUI can be inefficient for tasks that you have to perform repeatedly, such as creating new user accounts.
By building administrative functionality in the form of Windows PowerShell commands, you can select the
right method for a given task.
As you become more comfortable with Windows PowerShell, you may use it in place of other low-level
administrative tools that you may have used in the past. For example, Windows PowerShell has access to
the same features that can be accessed by VBScript, but in many cases, Windows PowerShell provides
easier ways to perform the same tasks.
Windows PowerShell also may change the way you use Windows Management Instrumentation (WMI).
Windows PowerShell can wrap task-specific commands around the underlying WMI functionality. When
you use Windows PowerShell with WMI, your work is simplified because Windows PowerShell provides
easy-to-use, task-based commands.
Although Windows PowerShell is an excellent command-line tool for performing specific tasks, it also
offers additional functionality. Windows PowerShell can manage Windows Server roles and features, and
it can be used to provision, manage, and report on various objects, directories, and components.
Windows PowerShell Syntax

Windows PowerShell uses commands, known as
cmdlets, to perform specific tasks. The naming
convention for a cmdlet includes a verb or action,
followed by a hyphen, and then a noun or subject.
For example, to retrieve a list of users, you would
use the cmdlet Get-User. This standardized
naming convention is designed to enable users
to more easily remember how to perform
administrative tasks. For example, to change the
settings of a mailbox, you would use the cmdlet
Set-Mailbox.
Optionally, one or more parameters can be used

with a cmdlet to modify its behavior or specify settings. When you type a cmdlet on a command line, the
parameters are entered after the cmdlet name. Each parameter that is used must begin with a hyphen,
and if multiple parameters are entered, they must be separated by a space.
Not all cmdlets use the same parameters. Some cmdlets have parameters that are unique to their
functionality. For example, the Move-Item cmdlet includes the -Destination parameter to specify the
location where the object will be moved; whereas the Get-ChildItem cmdlet has the Recurse parameter.
There are several kinds of parameters, including the following:
Named. Named parameters are the most commonly used parameters, and they can require a value
or modifier. For example, by using the Move-Item cmdlet, you would specify both the Destination
parameter and the exact destination where the item will be moved.
Switch. Switch parameters modify the behavior of the cmdlet, but they do not require any additional
modifiers or values. For example, you can specify the Recurse parameter without specifying a value
of $True.
Positional. Positional parameters are parameters that can be omitted and can still accept values based
on where the information is specified in the command. For example, you could run Get-EventLog
EventLog System to retrieve information from the System event log. However, because the
EventLog positional parameter accepts values for the first position, you also can run Get-EventLog
System to obtain the same results. When the EventLog parameter is not present, the cmdlet still
accepts the value of System because it is the first item after the cmdlet name.
Parameters that are common to many cmdlets include options to test the actions of the cmdlet or to
generate verbose information about the execution of the cmdlet. Common parameters include:
-Verbose. This parameter displays detailed information about the performed command. You should
use this parameter to obtain more information about the execution of the command.
-WhatIf. This parameter displays the outcome of running the command without actually running it.
This is helpful when you are testing a new cmdlet or script, and you do not want the cmdlet to run.
-Confirm. This parameter displays a confirmation prompt before executing the command. This is
helpful when you are running scripts and you want to prompt the user before executing a specific
step in the script.
Additional Reading: For additional information on cmdlet verbs, see the following
location: http://go.microsoft.com/fwlink/?LinkId=290957.
Accessing Help in Windows PowerShell

Whether you are an experienced professional
or are new to Windows PowerShell, the cmdlet
Help documentation provides a rich source of
information. To access the Help documentation,
use the Get-Help cmdlet (or its alias, help)
followed by the cmdlet name, or enter the cmdlet
name followed by the help parameter. Get-Help
includes the following parameters to adjust the
Help content that is displayed:
-Detailed. Displays more detailed help than

the default option displays.
-Examples. Displays only the examples for

using the cmdlet.
-Full. Displays advanced help and usage examples.
-Online. Opens a web browser to the cmdlet documentation on the Microsoft website.
Windows PowerShell 3.0 includes the ability to download the latest help document from Microsoft.
To view help documentation locally, you must use the Update-Help cmdlet. Also new in Windows
PowerShell 3.0 is the Show-Command cmdlet. This cmdlet helps users who are new to PowerShell to
interact with the input and output options for a cmdlet by using a graphical interface.
The Get-Command cmdlet returns a list of all locally available cmdlets, functions, and aliases. You can use
it to discover new cmdlets by using wildcard searches. For example, to return a list of all cmdlets that
include VM in the cmdlet name, you could run Get-Command *VM*.
What Is Exchange Management Shell?

The Exchange Management Shell and the
Exchange Management Console run on top of the
Windows PowerShell version 3.0 command-line
interface. These tools also 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 more
than 700 cmdlets that perform Exchange Server
management tasks, and even more non-Exchange
Server cmdlets exist 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 2013. 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 quickly create comprehensive administrative scripts.
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, as well as scope of objects that can be modified, 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 2013 administration tools run Exchange Management Shell
cmdlets to make changes to the Exchange environment, RBAC permissions are consistently applied across
all administration tools.
Exchange Management Shell Administration Examples

In Exchange Management Shell, you can also use
the get-help command to access Help for any
cmdlet. For example, if you want to learn about
the available options for Set-Mailbox cmdlet, you
will type get-help Set-Mailbox. If you want to
access extended help, you can type get-help SetMailbox detailed. And if you want to view a list
of examples of usage for the Set-Mailbox cmdlet,
you can type get-help Set-Mailbox examples.
When you type a cmdlet, it is very useful to use the
TAB key. Exchange Management Shell supports
command completion by using the TAB key. All
you must do is type the first few letters of a cmdlet, and then press the TAB key to complete the
command. If several cmdlets begin with the same letters, you can continue pressing the TAB key to
browse through all cmdlets.
Each command that makes a change in Exchange Management Shell can be ended with the WhatIf
parameter, which instructs the cmdlet to simulate the actions that it would take on the object. By using
the -WhatIf parameter, you can view the changes that would occur without actually making those
changes.
You can also use the Confirm parameter if you are about to run a command that affects multiple objects.
The -Confirm parameter forces the cmdlet to pause processing and requires the administrator to
acknowledge what the cmdlet will do before processing continues.
If you expect that output of your cmdlet will be too long, you can direct the output to a text file. For
example, you can type Get-Mailbox | Format-List > file.txt.
Examples of Exchange Management Shell commands include:
Enable-Mailbox -Identity adatum\Bart -Database MailboxDatabase. This command enables

a mailbox for an existing Active Directory user (Bart) with the domain and alias combination
adatum\Bart by creating a mailbox in the mailbox database named MailboxDatabase.
New-MailboxExportRequest -Mailbox Bart -FilePath \\LON-EX1\PSTFileShare

\Bart_Mailbox.pst. This command retrieves the contents of the mailbox with the alias Bart, and
stores the PST file in \\LON-EX1\PSTFileShare\Bart_Mailbox.pst.
Get-MailboxStatistics -Database MailboxDatabase. This command retrieves the mailbox statistics

for all mailboxes that are located in the mailbox database named MailboxDatabase.
New-MailboxDatabase -Name MailboxDatabase -Server LON-Ex1. This command creates a

mailbox database named MailboxDatabase on the server LON-EX1.
Get-ExchangeServer -Status | Format-List. This command retrieves a detailed list of all existing
servers, and forces a call to update the server's current status. Without the Status parameter, some
fields that change in real time will not be populated.
New-DynamicDistributionGroup -Name DDG -Alias DDGAlias -OrganizationalUnit OU

-IncludedRecipients MailboxUsers. This command creates a query-based dynamic distribution
group named DDG that is located in the OU and has the alias DDGAlias.
New-MoveRequest -Identity 'user1'-TargetDatabase Executives. This command creates a move

request for the mailbox associated with the alias user1 to the mailbox database named Executives.
Demonstration: Using Exchange Administration Tools to Manage Exchange

Demonstration Steps
1.
On LON-EX1, review the options in the Exchange Admin Center.
2.
Create the mailbox for the user Aidan.
3.
Sign in to Outlook Web App as Aidan.
4.
Review the options in Outlook Web App for a non-administrative user.
5.
From the Exchange Management Shell execute following cmdlets:

o
Get-Command *mailbox*
Get-Mailbox Aidan | Format-List alias,*quota
Enable-MailContact -Identity "John Woods" -Alias woods -ExternalEmailAddress

woods@adatum.com
Get-MailboxStatistics -Server LON-EX1
Get-Recipient -RecipientType UserMailbox
New-MailboxDatabase -Name AdatumExec -Server LON-EX1

Scenario
You are working as a messaging administrator in the A. Datum corporation. Your organization is
preparing to install its first Exchange Server 2013 server. As an initial task, you will deploy Exchange Server
2013 in a test environment. Before installing Exchange Server 2013 in the test environment, you must first
verify that the AD DS is ready for the installation. You also must verify that all computers that will run
Exchange Server 2013 meet the prerequisites for installing Exchange. Once the environment is prepared,
you will deploy Exchange Server 2013.
Objectives
Evaluation of requirements and prerequisites for Exchange Server 2013 deployment.
Exchange Server 2013 deployment.
Exchange Server 2013 management.
Lab Setup
Estimated time: 60 minutes
Virtual machines
20341B-LON-DC1-B
20341B-LON-EX1-B
User Name
Adatum\Administrator
Password
Pa$$w0rd
For this lab, you will use the available virtual machine environment. Before you begin the lab, you must
complete the following steps:
1.
On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.
2.
In Hyper-V Manager, click 20341B-LON-DC1-B, and in the Actions pane, click Start.
3.
In the Actions pane, click Connect. Wait until the virtual machine starts.
4.
Sign in using the following credentials:
5.
a.
User name: Adatum\Administrator
b.
Password: Pa$$w0rd
Repeat steps 2 to 4 for 20341B-LON-EX1-B.
Exercise 1: Evaluating Requirements and Prerequisites for an Exchange

Server 2013 Installation
Scenario
The Active Directory administrators at A. Datum have prepared a test AD DS environment for the
Exchange Server 2013 deployment. The server administration team has deployed a Windows Server 2012
server that you can use to deploy the first Exchange Server 2013 server in the test organization. You must
verify that the Active Directory environment and the server meet all prerequisites for installing Exchange
Server 2013.
The main tasks for this exercise are as follows:

1.
Evaluate the Active Directory requirements.
2.
Evaluate the DNS requirements.
Task 1: Evaluate the Active Directory requirements
On LON-DC1, evaluate whether the domain controller requirements are met:
Use Active Directory Users and Computers to evaluate whether the domain and forest functional
level requirements are met. (Note: It should be at least Windows Server 2003.)
Use Adsiedit.msc to evaluate whether the Exchange schema changes are applied.
Task 2: Evaluate the DNS requirements

1.
On LON-EX1, verify that the DNS settings are configured appropriately.
2.
Ping the domain controller LON-DC1.adatum.com to verify network connectivity.
3.
Start the Nslookup utility from Windows PowerShell.
4.
Type set type=all.
5.
Perform an nslookup search for the _ldap._tcp.dc._msdcs.adatum.com SRV record.
6.
Verify that an SRV record for lon-dc1.adatum.com is returned.
7.
Close Window PowerShell.
Results: After completing this exercise, the students will have evaluated the AD DS requirements.
Exercise 2: Deploying Exchange Server 2013

Scenario
After evaluating the Exchange Server 2013 requirements, you are ready to begin the deployment process.
You must first prepare AD DS, and then perform a single server Exchange installation. For evaluation
purposes, all roles will be installed on a single server. At the end, you will verify whether the core
Exchange services and components are installed correctly.
1.
Preparing AD DS for Exchange Server 2013 deployment.
2.
Performing Exchange Server 2013 installation on a single server.
3.
Verify Exchange Server installation.
Task 1: Preparing AD DS for Exchange Server 2013 deployment

1.
On LON-DC1, attach C:\Program Files\Microsoft Learning\20341B\Drives

\ExchangeServer2013CU1.iso to the virtual machine.
2.
On LON-DC1 open a Windows PowerShell window. Switch to D:\.
3.
Execute the proper command to prepare AD DS for your Exchange Server installation.
.\Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms /OrganizationName:Adatum
4.
Wait until the process completes.
5.
Close Windows PowerShell.
Task 2: Performing Exchange Server 2013 installation on a single server

1.
On LON-EX1, attach C:\Program Files\Microsoft Learning\20341\Drives

\ExchangeServer2013CU1.iso to the virtual machine.
2.
Install the Windows features for Exchange server, by typing:
Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSATClustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model,
Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing,
Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-HttpTracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, WebMgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server,
Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, WindowsIdentity-Foundation, and press Enter. (If you do not want to type this command you can copy the
content of the file cmdlet.txt from C:\ drive.)
3.
After roles are installed, restart the server.
4.
Sign in to LON-EX1 as Adatum\Administrator with the password Pa$$w0rd, and start Exchange
Server setup from D:\.
o
Do not check for updates.
Select the options to install both Client Access and Mailbox Server roles.
Do not disable malware protection.
Ensure that prerequisites are met.
Install the Exchange server. Wait until the installation completes. It can take 30 to 40 minutes
to finish.
On the Setup Completed page click finish.
Restart LON-EX1 and sign in as Adatum\Administrator with the password Pa$$word.
Task 3: Verify Exchange Server installation

1.
On LON-EX1, from Server Manager, open the Services console.
2.
Review the status for each Exchange Server service. Ensure that all services that are set for automatic
startup are running.
3.
Using File Explorer, browse to C:\Program Files\Microsoft\Exchange Server\v15. This list of folders
includes ClientAccess, Mailbox, and TransportRoles. These three roles were installed as part of the
typical setup.
4.
Using Internet Explorer, open https://lon-ex1.adatum.com/owa.
5.
Sign in to Outlook Web App as Adatum\Administrator with the password Pa$$w0rd. Send a new
message to Administrator, and verify that the message was delivered to the inbox.
6.
Close Outlook Web App.
Results: After completing this exercise, the students will have deployed Exchange Server 2013.
Exercise 3: Managing Exchange Server 2013

Scenario
You have Exchange Server 2013 deployed in the test environment, and you want to explore the Exchange
Server 2013 management tools. You are interested in exploring the functionality that exists in the new
EAC, and also in Outlook Web App and Exchange Management Shell.
1.
Explore Exchange Server 2013 Administration Center.
2.
Manage Exchange Server with Exchange Management Shell.
3.
Explore Outlook Web App.
4.
To prepare for the next module.
Task 1: Explore Exchange Server 2013 Administration Center

1.
On LON-EX1, open Windows Internet Explorer.
2.
Sign in to https://lon-ex1.adatum.com/ecp as Adatum\Administrator with the password

Pa$$w0rd.
3.
Create a new mailbox for the existing user Aidan Delaney.
4.
Create a new open distribution group called Adatum News.
5.
Sign out of the EAC.
Task 2: Manage Exchange Server with Exchange Management Shell
On LON-EX1, use Exchange Management Shell to perform the following tasks:

a.
List all of the users from the Adatum.com domain.
b.
Enable the mailbox for the user Robert.
c.
List all mailboxes in Adatum.com.
d.
Set the warning quota to 200 MB, and configure the prohibit send quota to 250 MB for all
mailboxes.
e.
Enable mailboxes for all users in the IT organizational unit.
Task 3: Explore Outlook Web App

1.
On LON-EX1, open Internet Explorer and sign in to Outlook Web App at

https://lon-ex1.adatum.com/owa as Adatum\Aidan with the password Pa$$w0rd.
2.
Send a test email to the administrator.
3.
Join the Adatum News group.
4.
Create a signature for Aidan Delaney.
5.
Change the theme for the Outlook Web App interface.
Task 4: 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.
In the Virtual Machines list, right-click 20341B-LON-DC1-B, and then click Revert.
3.
In the Revert Virtual Machine dialog box, click Revert.
4.
5.
In Hyper-V Manager, click 20341B-LON-DC1, and in the Actions pane, click Start.
6.
7.
8.
Password: Pa$$w0rd
Repeat steps 5 to 7 for 20341B-LON-MBX1. When you have successfully signed in to LON-MBX1,
repeat steps 5 to 7 for 20341B-LON-CAS1 and 20341B-LON-CL1.
Results: After completing this exercise, the students will have explored Exchange management tools.

Best Practice
Always plan for Exchange server resources before starting an installation process.
Consider deploying Client Access Server role and Mailbox server role on separate servers.
Monitor Exchange services and logs with monitoring software such as SCOM 2012.
Learn how to use Exchange Management Shell.
Install Windows Server roles and features required for Exchange Server prior to installation of
Exchange to avoid restarts.
Common Issues and Troubleshooting Tips

Common Issue
Troubleshooting Tip
Setup.exe /PrepareAD fails
Review Questions
Question: Which server role in Exchange Server 2013 handles the message transport?
Question: How do Outlook clients from an internal network connect to Exchange Server
2013?
Question: On what is the EAC built?
Tools
EAC
Exchange Management Shell

2-1
Module 2
Planning and Configuring Mailbox Servers
Contents:
Module Overview
2-1
Lesson 1: Overview of the Mailbox Server Role
2-2
Lesson 2: Planning the Mailbox Server Deployment
2-11
Lesson 3: Configuring the Mailbox Servers
2-22
2-28
2-34
Module Overview
The key component of the Microsoft Exchange Server 2013 infrastructure is the Mailbox server, which
hosts mailbox databases and addresses books, handles message transport and routing, and provides
unified messaging services. When you plan an Exchange Server 2013 deployment, it is very important to
consider all aspects of your deployment that can affect the Mailbox server role design. In this module, we
will talk about planning and configuring of the Mailbox server role.
Objectives
Describe the Mailbox server role.
Plan for a Mailbox server role deployment.
Configure the Mailbox servers.
Lesson 1
Overview of the Mailbox Server Role

The Mailbox server role provides a storage solution for most of the data with which Exchange Server
works. It hosts user mailboxes, public folders, address lists, and other types of data. In Exchange 2013,
most functionality, such as message transport and unified messaging, is located on the Mailbox server
role; therefore, it is very important to properly plan and deploy this role.
Lesson Objectives
Describe the Mailbox server role in Exchange Server 2013.
Describe how the Mailbox server role interacts with client servers and the Client Access server role.
Describe the mailbox store in Exchange Server 2013.
Describe database log considerations.
Describe how the mailbox database is updated.
Describe storage options for the mailbox databases.
Describe how to import and export data from the mailbox database.
The Mailbox Server Role in Exchange Server 2013

In Exchange Server 2013, the Mailbox server does
much more than it did in Microsoft Exchange
Server 2010. In Exchange Server 2010, the Mailbox
server hosts databases and provides email storage.
In Exchange Server 2013, the Mailbox server also
hosts Client Access protocols, Transport service
components, mailbox databases, and Unified
Messaging components.
2-2 Planning and Configuring Mailbox Servers
Although clients never communicate directly

with the Mailbox server, this server interacts
actively with the Active Directory Domain
Services (AD DS) components and Client Access
server. It uses the Lightweight Directory Access Protocol (LDAP) to locate and access information about
recipients, servers, and organization configuration information that is stored in AD DS.
The Mailbox server also participates in high-availability configurations through Database Availability
Groups (DAGs). This concept provides high availability at a database level by implementing multiple
copies on the same database over different mailbox servers. A DAG is a group of up to 16 Mailbox servers
that hosts a set of databases and provides automatic database-level recovery from failures that affect
individual servers or databases.
Most of the functionality for internal message transport and routing, previously hosted on the Hub
Transport server, is now located on the Mailbox server role. The Hub Transport service, running on the
Mailbox server role, handles all internal Simple Mail Transfer Protocol (SMTP) mail flow, and performs
message categorization and content inspection. In addition to this service, there are two more transport
services that run on the Mailbox server role: Mailbox Transport Submission and Mailbox Transport
Delivery. These two services communicate with the Hub Transport service to send messages to other
servers, and also with the mailbox database to retrieve or submit data to the database.
The Unified Messaging server role, which previously existed as a separate server role, is now also
integrated with the Mailbox server role.
Note: The Mailbox server role in Exchange Server 2013 also hosts public folder mailboxes.
Unlike in Exchange Server 2010, public folders do not use separate databases or a separate
replication mechanism. For more details about public folders in Exchange Server 2013, see
Module 3.
The Mailbox server role in Exchange Server2013 includes the following new features:
In an evolution of the Exchange Server 2010 DAG, the transaction log code has been refactored for
fast failover, with deep checkpoints on passive database copies.
Servers can be in different locations to support enhanced site resiliency.
Exchange Server 2013 now hosts some Client Access components, including the transport
components and the Unified Messaging components.
The Exchange store has been rewritten in managed code to improve performance in additional I/O
reduction and reliability.
Each Exchange Server 2013 database now runs under its own process.
How the Mailbox Server Role Interacts with Clients and the Client Access
Server
In addition to its communication with AD DS,
the Mailbox server role communicates intensively
with the Client Access server. This communication
always takes the same paths, even when the Client
Access server role is installed on the same server
as the Mailbox server role.
Because the clients never communicate directly
with the Mailbox server, the Client Access server
accepts client requests and sends them to the
Mailbox server. The Front End Transport service,
which runs on the Client Access server, accepts
and sends messages from the Internet, and then
forwards them to the Hub Transport service running on the Mailbox server.
The Client Access server also returns the data (content of the client mailbox) from the Mailbox server to
the clients. In addition, the Client Access server uses NETBIOS file sharing to access the offline address
book (OAB) data from the Mailbox server role. This data is then served to the clients through the OAB
virtual directory on the Client Access server. The Client Access server also sends messages, free/busy data,
and client profile settings between the client server and the Mailbox server.
In previous Exchange Server versions, such as Microsoft Exchange Server 2007 and Exchange Server 2010,
internal clients had a direct Messaging Application Program Interface (MAPI) communication with the
Mailbox Server role in some scenarios. For example, when the client was accessing public folders in
Exchange Server 2010, it was communicating directly with the Mailbox server role. In Exchange Server
2007, the internal clients were directly communicating with the Mailbox server role, by using MAPI, for all
scenarios.
In Exchange Server 2013, clients no longer communicate directly with the Mailbox server role; therefore,
both internal and external client communication is proxied through the Client Access server. The Client
Access server uses LDAP or the Name Service Provider Interface (NSPI) to contact the Active Directory
server and retrieve the users Active Directory information.
The Mailbox Store in Exchange Server 2013

In Exchange Server 2013, the primary component
of the mailbox store is the mailbox database.
Unlike in previous Exchange server versions, in
which public folder databases were also present,
Exchange Server 2013 works only with the
mailbox databases.
Mailbox databases contain the data, data

definitions, indexes, checksums, flags, and other
information that constitute mailboxes in Exchange
Server 2013. Mailbox databases hold data that is
private to an individual user, and contain mailbox
folders generated when a mailbox is created for
that user. The mailbox database can be hosted on a single server, or it can be distributed across multiple
Mailbox servers if DAGs are deployed.
The mailbox database is stored in a database file, also known as an Exchange database (.edb) file.
However, this is not the only file that is related to the mailbox database. Exchange Server 2013 uses a set
of data files to host and maintain the mailbox database.
These files are:
Mailbox database (.edb file). This is the main repository for mailbox data. This file is directly accessed
by the Extensible Storage Engine (ESE). It has a B-tree structure that helps to provide quick access and
enables users to access data on any page within just one input-output cycle.
Transaction log (.log file). Each operation that should be performed on a database, such as sending or
receiving a message, is recorded in the transaction log file. These operations are called transactions.
Operations that are committed to the transaction log are later written to the database itself (in an
.edb file). Until the transaction is committed to the mailbox database, the only existence of this data is
in the RAM memory and in the transaction logs. All transactions, complete or incomplete, are logged
to maintain data integrity in case of a service interruption. Each database has its own set of
transaction logs.
Checkpoint file (.chk). Checkpoint files store data that indicate when a transaction is successfully
committed to the database. The purpose of the checkpoint file is to help the ESE to replay log files on
an inconsistent database in case of database recovery. By using information from the checkpoint file,
the ESE will start with the transaction that is present in the log file, but is not yet written to checkpoint
file. Each databases log prefix determines its checkpoint file name. For example, the checkpoint file
name for a database with the prefix E00 would be E00.chk. This checkpoint file is several kilobytes in
size and does not grow.
Temporary file (Tmp.edb). This is a temporary location used for processing transactions. Tmp.edb
contains temporary information that is deleted when all stores in the storage group are dismounted
or the Exchange Information Store service is stopped. This file does not exceed 1 MB.
Reserve log files (E##res0001.jrs - E##res000A.log per database, where ## is the log prefix). These
files are used to reserve space for additional log files if the disk that stores log files becomes full.
Exchange Server 2013 only uses these files as emergency storage when the disk becomes full, and it
cannot write new transactions to disk. When Exchange Server 2013 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 are always 1 MB each.
Although it is important to understand the purpose of each mailbox database file, you will interact directly
with these files only rarely. Exchange Server automatically manages these files, so they do not require
administrator intervention, except in cases of database backup and restore.
Database Log File Considerations

Each change that is performed on an Exchange
Server mailbox database must be logged in a
transaction log file prior to modification of the
database. After each transaction is logged to the
transaction log file, it can be written to the .edb
file. To enhance performance, changes performed
on the database are usually available to users right
after they are recorded to the transaction log file.
Exchange Server also caches transactions in RAM

memory. This is done for both redundancy and
performance reasons. If the database stops, or if
the server crashes or experiences any other system
outage, Exchange Server scans the log files and reconstructs and applies any changes not yet written to
the database file. This process is referred to as replaying log files.
The transaction log is not just one file, but instead is a series of log files. Each transaction log file is exactly
1,024 KB in size. After a transaction log file becomes full, ESE closes it, renames it, and opens a new
transaction log file.
The naming syntax for the transaction log file is Enn0000000x.log, where nn refers to a two-digit number
known as the base name or log prefix, and x is the sequential number of the log file. It is important to
know that log files are numbered in a hexadecimal system, not in a decimal system. For example, the log
file that comes after E0000000009.log is not E0000000010.log, but E000000000A.log.
Transaction log files are not deleted automatically. Usually, when a database is backed up, the backup
software deletes the transaction log files. Because a mailbox database cannot be backed up in the way
other files can, it is very important to have Exchange-aware backup software that will properly handle
transaction log files when performing backup and restore operations. If the transaction log files are not
deleted regularly, they can fill up the disk space, which can cause Exchange services to stop working. We
do not recommend manually deleting transaction log files, because that approach can interfere with your
regular backup procedure.
You can configure Exchange Server to perform circular logging. When the circular logging option is
enabled, transaction log files will be overwritten after the transactions from the log file are committed to
the mailbox database. However, this approach is not recommended in a production environment, because
it affects the ability to back up and restore to the mailbox database. For example, if you have circular
logging enabled, you can recover data only up to the time when you performed the last full backup of
your database. If you do not use circular logging, then you are able to use incremental backups, and you
also have the ability to restore the database from the incremental backup. By default, circular logging is
disabled.
To properly maintain transaction logs as well as the mailbox database, we recommend that you follow
these guidelines:
Regularly perform Exchange Server backups with Exchange-aware backup software.
Move transaction logs to a dedicated drive that supports heavy write load.
Place transaction log files on a redundant disk array, using redundant array of independent disks
(RAID) technology. We recommend that you use a RAID 1 volume. However, if you protect your
mailbox databases with a DAG, it might be unnecessary to use a dedicated storage for the transaction
log files. This option is discussed later in this module.
Ensure that the volume that hosts the transaction log files has enough free disk space to store all files
created between two backup cycles.
Do not use compression on drives that store transaction log files.
Do not use circular logging, except in a test environment.
How Are Mailbox Databases Updated?

Although database modification is an
automated process, it is not directly visible to
the administrator or the end user. It is important
that you understand how the database is being
modified during normal operations.
The following process takes place when a Mailbox
server receives a message:
1.
The Mailbox server receives the message.

This occurs when the Hub Transport service
on the Mailbox server accepts the message
from the Front End Transport service that is
running on the Client Access server. After the
Hub Transport service accepts the message, it is passed to the Mailbox Transport service.
2.
Before the message is written to the databases, the Mailbox server writes the message to the current
transaction log and the memory cache simultaneously.
3.
The Mailbox server writes the transaction from the 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.
Client servers can access and read the message in the database.
Storage Options for the Exchange Server 2013 Mailbox Server Role
Exchange Server 2013 supports various hardware
technologies for disk storage, including Serial
Advanced Technology Attachment (SATA),
Solid-state drive (SSD), and Serial Attached small
computer system interface (SCSI), known as SAS
(Serial Attached SCSI) or iSCSI drivers. When
selecting which storage solution to use, the goal
is to ensure that the storage will provide the
performance that your environment requires. In
Exchange Server 2013, disk I/O is further reduced
compared to previous versions of Exchange
Server. This enables you to use less expensive,
slower disks and storage systems without any significant decrease in performance. When choosing a
storage technology for Exchange Server, the most common choices are, DAS, SAN, or RAID.
DAS
Direct attached storage (DAS) is any disk system that is physically connected to your server. This includes
hard disks inside the server or those that are connected 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 appear to the server as a single large disk.
In general, DAS provides good performance, but it provides limited scalability because of the units
physical size. You must manage direct attached storage on a server-by-server basis. Exchange Server 2013
performs well with the scalability and performance characteristics of DAS.
DAS 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.
SAN
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 used 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 DAS options.
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 2013 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 backup 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.
RAID
To provide redundancy on any storage options, you have to use RAID technology. RAID can be used to
provide better disk performance or 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 with 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.
Just a bunch of disks (JBOD). JBOD is a collection of disks that have no redundancy or fault tolerance.
JBOD solutions are usually lower in cost than solutions that use RAID. JBOD adds fault tolerance by
using multiple copies of the databases on separate disks, which you can use when you protect your
databases with DAGs.
Importing and Exporting Data from a Mailbox Database

In some scenarios, you might want to export
data from the users database or import data
to the users database. For example, because of
compliance or legal reasons, you may be required
to export mailbox content from a specific user to
a personal storage file (.pst) file. For other
purposes, you might want to perform a snapshot
of a specific mailbox.
In yet another scenario, you might want to import

data from a .pst file from a legacy application to
a users mailbox on the Exchange Server. For
example, if a user was using a Windows Mail
application, all of the users data was being stored in a .pst file. It is common to import data from the
users .pst file to the users new mailbox on the Exchange Server, or to the users archive mailbox.
In Exchange Server 2013, you can use the New-MailboxImportRequest or NewMailboxExportRequest cmdlets to import or export data from the users mailbox. Requests for mailbox
import or export must be executed from the Exchange Management Shell. After you run one of these
cmdlets, the process is completed asynchronously by the Microsoft Exchange Mailbox Replication service.
This service takes advantage of the queuing and throttling frameworks to optimize Exchange performance
during import or export operations.
Note: To use the New-MailboxImportRequest or New-MailboxExportRequest cmdlets,
the Mailbox Import Export role must be assigned to you. By default, this role is unassigned.
Exchange Server 2013 includes a personal folders file (.pst) provider, so it can natively read and write .pst
files. The .pst files can be stored locally or they can reside on a shared folder. However, if you are using
share folders as a .pst location, you must ensure that you grant read/write permissions to the Exchange
Trusted Subsystem group for the specific shared folder.
Exchange Server 2013 supports only Unicode files created by Office Outlook 2007, Outlook 2010 and
newer versions. Data from a .pst file can be imported to a users mailbox or to an online archive if it is
enabled for a users mailbox. In addition, Exchange Server 2013 can import or export multiple .pst files at
the same time, which can speed up the process. However, the import or export process can take several
hours to complete, depending on the file size and network bandwidth.
Note: The maximum supported size for a .pst file is 50 gigabytes (GB). If a mailbox that
you want to export is larger than 50 GB, you can create multiple .pst files. You can use filters to
specify selected folders for export instead of the entire mailbox. You can also include or exclude
specific folders using the IncludeFolders or ExcludeFolders parameters.
When you import data from a .pst file, you must ensure that the mailbox exists prior to starting the import
process. You can import data to a different user account than the one from which it was exported.
Demonstration: Importing Data to a Users Mailbox

Demonstration Steps
1.
Log on to Outlook Web App (OWA) as Adatum\Aidan.
2.
Ensure that In-Place Archive mailbox is empty. Sign out of Outlook Web App.
3.
Open the Exchange Management Shell on LON-MBX1.
4.
Type New-ManagementRoleAssignment Role "Mailbox Import Export" User Administrator.
5.
Restart Exchange Management Shell.
6.
Type the following: New-MailboxImportRequest -Mailbox Aidan -IsArchive -FilePath

\\LON-DC1\MailboxExport\backup.pst.
7.
After the import completes, on LON-CAS1, sign in to Outlook Web App as Adatum\Aidan, and
ensure that content is imported in Personal Archive.
Lesson 2
Planning the Mailbox Server Deployment
Planning for the Mailbox Server role deployment is a key part of the Exchange Server infrastructure
planning. Before you deploy an Exchange Server 2013 Mailbox server, you should plan for hardware and
storage to accommodate the needs of your environment. You also should plan and design the mailbox
database layout and high-availability options. Some special considerations apply if you decide to virtualize
your Mailbox servers. In this lesson, we will discuss Mailbox server deployment.
Lesson Objectives
Plan hardware and storage for the mailbox servers.
Design mailbox databases.
Plan high availability for the mailbox servers.
Describe considerations for virtualizing mailbox servers.
Describe considerations for planning mailbox databases.
Describe the Exchange Mailbox Server Role Requirements Calculator.
Use the Exchange Mailbox Server Role Requirements Calculator.
Verify Mailbox server role performance.
Planning Hardware for the Mailbox Server Role

Unlike the Client Access server, which does not
have a large hardware footprint, the Mailbox
server can have fairly high hardware requirements
in scenarios in which it hosts large numbers
of mailboxes. On the other hand, you might
not need very powerful hardware if you are
implementing Exchange Server in small to
medium-sized companies. In either case, it is
very important to properly plan hardware
requirements for the Exchange Mailbox server
role.
CPU Requirements
Exchange Server 2013 requires a 64-bit processor and a 64-bit operating system. Exchange Server 2013
supports two specific processor architectures: AMD64 and Intel Extended Memory 64 Technology. It does
not support Itanium processors.
Exchange Server 2013 can take advantage of multicore processors, which can process multiple tasks at the
same time. A typical server processor has four or more cores.
The number of processor cores required for a Mailbox server varies, depending on the number of
mailboxes and how intensely the mailboxes are used. For average usage, a single processor core can
support approximately 1,000 active mailboxes. Average usage is defined as a user who sends 10 messages
a day and receives 40 messages a day. If the processor supports hyper-threading, we recommend that you
disable hyper-threading. Hyper-threading causes problems in capacity planning and offers little
performance improvement.
Memory Requirements
The memory requirements for Exchange Server 2013 vary, depending on the number of mailboxes and
how intensely the mailboxes are used. The minimum recommended RAM for a Mailbox server is 8 GB. A
server that combines multiple roles should have a minimum of 8 GB of RAM.
When calculating the memory required for your Mailbox server, take the minimum memory required, and
then add additional memory for each user based on their messaging volume. For each 50 messages per
day sent or received, you should allocate 3 megabytes (MB) per user. For example, if the average user in
your organization sends and receives 100 messages per day, then you should allocate 6 MB per user, in
addition to the minimum RAM for your Mailbox server configuration.
Planning Storage for the Mailbox Server Role

For many users, access to email is critical for them
to perform their jobs, because email is used both
for communication internally with colleagues,
and externally with partners and customers.
The amount of data that is kept in mailboxes
continues to grow, and all of this data must be
searchable.
New generations of hard disks are getting larger,

but spin rates and seek times are not improving.
Sequential read rates are increasing as a result of
greater data density, but random access read rates
are staying the same. Exchange Server 2013 takes
advantage of the increasing disk size, so that you can offer larger mailboxes to users without increasing
cost or decreasing performance.
With the I/O improvements in Exchange Server 2013, you can use larger and less expensive disks in many
scenarios. Disk I/O relates to the number of mailboxes that are stored on a disk, rather than the volume of
mailbox data that is stored on the disk. Large mailboxes reduce the disk I/O requirements for a Mailbox
server because they reduce the number of mailboxes that are stored on a disk. Fewer mailboxes on a disk
results in lower disk I/O.
As a result of lower disk I/O, you can consider using large 7,200 RPM disks rather than smaller, faster
15,000-RPM disks. A typical 7,200-RPM disk stores between 1 and 3 terabytes. A typical 15,000-RPM disk
stores less than 1 terabyte. The 7,200-RPM disks are significantly less expensive per GB.
In Exchange Server 2013 you can store personal archives and primary mailboxes in separate databases.
This is beneficial if you want to have different backup strategies for personal archives and primary
mailboxes. However, this can result in unbalanced disk I/O. The disks that are storing databases with
primary mailboxes will experience relatively high I/O, while the disks that are storing databases with
personal archives will have relatively low disk I/O. Keeping the primary mailboxes smaller allows you to
place a higher number of mailboxes on the same set of disks, which can also increase disk I/O. Keeping a
personal archive in the same database as the primary mailbox results in similar disk I/O because you have
only large mailboxes.
Because of the storage improvements that were introduced in Exchange Server 2010 and are also
supported in Exchange Server 2013, you can consider using less expensive and slower types of disk
storage, which you might not have been able to consider for previous versions of Exchange Server.
However, you still need to test the storage configuration that you select to ensure it meets your needs.
Consider the following:
Replicated database copies increase the amount of storage space required. If your organization uses
DAGs to replicate mailbox databases for high availability, consider the number of database copies
when you calculate how much disk space you need and what it costs.
Slower disks cost much less per GB than faster disks. The reduced disk I/O requirements of Exchange
Server 2013 mean that large-capacity 7,200-RPM disks are suitable for many organizations. You can
obtain 7,200-RPM disks of equal size with the SATA or SAS interface. SAS disks cost slightly more than
SATA disks, but in testing at Microsoft, SAS disks had a 50 percent lower failure rate than SATA disks.
Direct attached storage (DAS) is less expensive than a storage area network (SAN). As a result, DAS is
preferable if you use DAGs to create multiple replicated copies of data. You can purchase external
drive arrays and use them to connect a large number of disks to a single server. The lower reliability
of DAS is offset by the multiple database copies in the DAG. If you have a SAN with available space,
then you might prefer to use the SAN for the higher reliability it provides.
You can consider JBOD if you have three or more replicas of a database in a DAG. JBOD provides no
redundancy, but this is acceptable because the DAG has multiple database copies. JBOD is used with
DAS.
Some organizations have a significant investment in SANs for all server storage. If you use a SAN,
the increased reliability may mean that you choose to implement fewer database copies in a DAG.
You also can keep some database copies on a SAN and others on DAS. Even when a SAN is used, we
recommend having two database copies.
An Internet small computer system interface (iSCSI) SAN typically has lower performance than a
Fibre Channel SAN, but it also is much less expensive. If you use a SAN, the lower I/O requirements
in Exchange Server 2013 make iSCSI an option to Fibre Channel in a wide range of scenarios.
Use RAID to increase the redundancy of the disk system if there are less than three database copies
in a DAG. A variety of RAID types are available to increase the performance and redundancy of the
disk system. RAID 10 is the best-performing RAID option, because it has the speed of a striped set
and the redundancy of mirroring. However, it is fairly expensive, because 50% of the disk space is
used for redundant data. You can use the Exchange Server Mailbox Server Role Requirements
Calculator to help you plan the storage configuration of Mailbox servers. This spreadsheet contains
many calculations to help you accurately estimate the hardware requirements to support a specific
number of users with a specific storage configuration. You can download this tool, which is updated
regularly from the Microsoft website.
Additional Reading: More information about Storage Configuration Options for Exchange
Server 2013 can be found at: http://go.microsoft.com/fwlink/?LinkId=290958.
Database Design for Mailbox Databases

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

typically increases disk utilization.
Frequency of usage. Higher frequency usage typically increases disk utilization.
Size of mailboxes. Larger mailboxes combined with a higher number of users increases overall
database size.
Service level agreements (SLAs). To meet the recovery requirements, you may need to keep databases
small so that restore times are reduced.
In previous versions of Exchange Server, such as Exchange Server 2007, we recommended that log files
and databases be kept on separate disks. This meant that if the disk failed and the database was lost,
you still had the log files available after a restore. Therefore, you could replay them to recover messages
received since the last backup. In Exchange Server 2013, the same recommendation still applies in small
environments that do not use DAGs. However, if there are multiple replicated copies of a database, you
do not need to keep the transaction logs and databases separate because a different replica is used for
recovery instead of recovering from a backup.
In Exchange Server 2013, one best practice is to locate multiple databases on a single logical unit number
(LUN), because the disk I/O is random. You can separate transaction logs onto different physical disks to
increase performance, but this is not necessary typically. In most cases, because Exchange Server 2013 has
lower I/O requirements, you can keep transaction log files and database files on the same volume without
affecting performance.
You can separate log files from database files for recoverability when using backups. By storing database
files and log files on separate volumes or disks, you can replay transaction logs after a database restore
when the database was lost due to a failed volume or disk.
Disk-Space Considerations
When you calculate the disk-space requirements for a database on a Mailbox server, you need to consider
more than just the mailbox databases. In most cases, you may want to enable indexing on databases to
speed up searches. Each index uses approximately 5% of the mailbox database disk space. This index is
placed in the same location as the database.
Single-item recovery retains deleted messages in a database for a specified period of time. When you
enable single-item recovery, the database size increases.
You also should include personal archives when planning mailbox databases. A personal archive is
typically used for longer-term retention of mailbox content. If you enable personal archives, the database
size may increase.
You can use a recovery database in a variety of recovery scenarios to extract mailbox data. To use a
recovery database, you must have sufficient disk space available to restore the database and transaction
logs.
Planning Mailbox Servers for High Availability

Using a DAG is required to implement high
availability of mailbox databases. A DAG allows
you to replicate mailbox databases to multiple
servers. If the server that is servicing the clients
fails, a replica on another server in the DAG begins
to service the client requests.
Considerations for implementing DAGs include:
Mailbox database names must be unique in

the Exchange Server 2013 organization. This
may require developing a naming convention.
This naming convention should not include
the server name, because the database can
move between DAG members.
The storage path must be identical for all copies of a database. This means that all members of a DAG
should have the same disk configuration with the same drive letters. For increased flexibility, you can
use mount points instead of various drive letters, but this is not required.
DAG implementation uses the Windows Server operating system failover clustering feature. This is
available in the Windows Server 2012 Standard or Datacenter editions. If you are using Windows
Server 2008, you should install Windows Server 2008 Enterprise or Windows Server 2008 Datacenter
operating system editions to support failover clustering. However, DAGs are supported in both the
Exchange Server 2013 Standard and Enterprise editions.
DAGs can be managed from within Exchange Server 2013 management tools. This simplifies the
process of DAG configuration, and masks the complexity of failover clustering from administrators.
In Exchange Server 2013, DAGs can also be used to make public folders available. Because public
folders reside in the mailbox database, the same technology for high availability can be applied to
them.
A server that is a member of a DAG can have additional server roles installed. For example, a server
that is a member of a DAG can have the Client Access installed.
Virtualizing Mailbox Server Considerations

All Exchange Server 2013 server roles can be
virtualized. A virtualized implementation of
Exchange Server 2013 is supported when running
on one of the following virtualization platforms:
Windows Server 2008 R2 with Hyper-V

technology
Microsoft Hyper-V in Windows Server 2008 R2
Windows Server 2012
Microsoft Hyper-V in Windows Server 2012
Any third-party hypervisor that has been

validated under the Windows Server Virtualization Validation Program
When implementing Exchange Server 2013 on a virtual machine, you should consider the following:
When Exchange Server 2013 is running on a virtual machine, it has the same hardware performance
requirements as when it is not virtualized. The requirements for memory and processing power are
the same. For example, if planning indicates that a server running Exchange Server 2013 requires 16
GB of memory, then a virtualized version of that server also requires 16 GB of memory.
You should not install any additional software on the physical root partition of the server that hosts
virtual machines.
Do not use dynamic memory. Exchange Server 2013 uses caching in memory to improve
performance. If memory is dynamic, then Exchange Server 2013 does not have full control over
memory allocation in the virtual machine, and that can reduce performance.
Do not allocate virtual processors to virtual machines at a ratio higher than two virtual processors per
processor core. For example, if the physical host has two processors with six cores each, you should
not allocate more than 24 virtual processors.
Some considerations for storage are as follows:
Dynamically expanding virtual disks are not supported. This is because of performance concerns as
the disks expand.
Differencing or delta mechanisms such as snapshots are not supported. This is because the snapshot
mechanisms are not application aware and, as a consequence, recovery to the snapshot is
unpredictable.
An Exchange Server virtual machine must use a virtual hard disk that has a size at least 15 GB plus
the size of the virtual memory that is allocated to the guest machine. This requirement is necessary
to account for the operating system and paging file disk requirements. For example, if the guest
machine is allocated 8 GB of memory, the minimum disk space needed for the guest operating
system disk is 23 GB.
Test virtual disk performance to be sure that it meets your needs. Virtual disk performance is typically
slightly lower than physical disk performance.
Pass-through storage and iSCSI storage are both supported. However, iSCSI storage has reduced
performance if the network stack of the virtualization environment does not support jumbo frames.
Jumbo frames are supported in Hyper-V on Windows Server 2008 R2, but they must be enabled in
the parent partition and the virtual machine.
You can use the virtual machine high availability that is provided by your virtualization environment with
Exchange Server 2013. This is supported even for servers that are part of a DAG. Some considerations for
virtual machine high availability are:
The virtual machines must not save and then restore state when migrated between hosts. All
migration between hosts must be an online migration, such as the Hyper-V live migration technology
in Windows Server 2008 R2 and Windows Server 2012. Alternatively, the virtual machines can be shut
down, migrated, and then restarted.
Online migration methods must be supported by the hypervisor vendor.
If a virtual machine or host fails, the virtual machine must be restarted on an alternate host with a full
boot process.
Considerations for Planning Mailbox Databases

When planning a mailbox database deployment,
the first critical decision is whether organizations
will be deploying DAGs or whether they will
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.
Considerations for 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 deployment,
organizations need to be aware that in case of any type of failure, their messaging solution will face
downtime, and that they will have to restore their data and services 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 SLA for recovering databases. The Exchange Mailbox Server Role
Requirements Calculator recommends 200 GB limit for databases without DAGs.
Database and transaction log locations. With a single copy of the databases, 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 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
When organizations choose to implement DAGs, the planning process for the mailbox database
deployment changes. When databases are stored on multiple servers, users may not even be aware of
a server or database failure, as the databases can be automatically mounted on another server. These
companies might choose not to perform backup and instead use Exchange Native Data Protection 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 at 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 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 more likely might 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 JBOD.
Common Considerations for Planning Mailbox Database Deployments
When designing the mailbox database deployments, there are factors that apply regardless of whether or
not you deploy DAGs. These factors include:
Considerations for number of databases deployed. Consider deploying multiple databases, rather
than having only one large database. You may choose to place user mailboxes with common business
needs in one database, such as Executives, Human Resources, and Marketing, for example. Having
multiple databases gives more flexibility to Exchange Server administrators, as they can configure
mailbox limits, deletion settings, and backup/restore procedures for each database.
Considerations for naming databases. Beginning with Exchange Server 2010, databases are no longer
owned by server objects, and a database can replicate to multiple Mailbox servers if you configure
them for high availability. This means that database names must also be unique throughout the
organization, including databases on the legacy servers. Therefore, as a best practice, you should not
leverage the following in database-naming conventions:
o
Server name
Active Directory site name (for the site resilience case)
Physical data center name (for the site resilience case)
Exchange organization name
What Is an Exchange Mailbox Server Role Requirements Calculator?

To enable administrators and systems designers
to perform Exchange Server Mailbox role planning
as accurately as possible, Microsoft provides a
tool that helps you estimate requirements for
your mailbox server based on your current
environmental properties. This tool is the
Exchange Mailbox Server Role Requirements
Calculator. It is a macro-enabled Excel
spreadsheet that collects user inputs, and based
on those inputs, calculates various requirements
for Exchange Server Mailbox Server role
implementation.
Note: The Exchange Mailbox Server Role Requirements Calculator is a free download, and
is available here: http://go.microsoft.com/fwlink/?LinkId=290959
Currently, only the version for Exchange Server 2010 is available. However, it is also applicable to
To open and use the tool, you must have Microsoft Excel 2007, Microsoft Excel 2010, or Microsoft
Excel 2013 installed. The calculator is divided into the following sections (worksheets):
Input
Role Requirements
Activation Scenarios
Distribution
LUN Requirements
Backup Requirements
Log Replication Requirements
Storage Design
We recommend that you only fill out your data in the first (Input) worksheet. Based on that input, the tool
calculates the requirements for the Mailbox server role and presents them on the other sheets. On the
input sheet, you provide data in the following categories:
User profile: the message profile, the mailbox size, and the number of users.
High-availability architecture: the number of database copies you plan to deploy, whether the
solution will be site resilient, and the desired number of mailbox servers.
Server's CPU platform.
Storage architecture: the disk capacity/type and storage solution.
Backup architecture: choose whether to use the hardware or software Volume Shadow Copy Service
(VSS) and the frequency of the backups, or to leverage the Exchange native data protection features.
Network architecture: the utilization, throughput, and latency aspects.
Note: The tool comes with some pre-populated data in the Input sheet. This data is a
sample configuration, and any data points entered into the Input worksheet are specific to that
particular example and do not apply to other configurations. Make sure that you are using the
correct data points for your design.
Demonstration: Using the Exchange Mailbox Server Role Requirements

Calculator
This demonstration uses a modified version of the Exchange Server 2010 Exchange Mailbox Server Role
Requirements Calculator.
Note: Ensure that you download and use the Exchange Server 2013 version when
calculating hardware requirements for Exchange Server 2013 servers.
Demonstration Steps
1.
On LON-CL1, open File Explorer, navigate to C:\Files, and then double click E2013Calc.xlsm.
2.
In the E2013Calc, on the Input sheet, enter the following values for each section:
o
Exchange Environment Configuration
Server Multi-Role Configuration (MBX+CAS): Yes
Server Role Virtualization: Yes
High Availability Deployment: Yes
Number of Mailbox Servers Hosting Active Mailboxes / DAG: 4
Number of Database Availability Groups: 2
Mailbox Database Copy Configuration
Total Number of HA Database Copy Instances (Includes Active Copy) within DAG: 3
Total number of Lagged Database Copy Instances within DAG: 1
Exchange Data Configuration
Mailbox Moves/Week Percentage: 1%
LUN Free Space Percentage: 15%
Tier-1 User Mailbox Configuration
Total Number of Tier-1 User Mailboxes/Environment: 500
Projected Mailbox Number Growth Percentage: 5%
Total Send/Receive Capability/ Mailbox/Day: 50 messages
Average Message Size (KB): 50
Mailbox Size Limit (MB): 1024
Personal Archive Mailbox Size Limit (MB): 2048
Deleted Item Recovery Window (Days): 20
Single Item Recovery: Enabled
Calendar Version Storage: Enabled
Backup Configuration
Backup Methodology: Software VSS Backup/Restore
Backup Frequency: Weekly Full / Daily incremental
Database and Log Isolation Configured: Yes
Backup/Truncation Failure Tolerance: 3
Network Failure Tolerance (Days): 0
Primary Datacenter Disk Configuration
Database: 1000 GB, 7.2K RPM SAS 3.5
Log: 500 GB, 7.2K RPM SAS 3.5
Restore LUN: 1500 GB, 7.2K RPM SAS 3.5
3.
In the E2013Calc, click the Role Requirements tab.
4.
Review the calculated requirements provided on this sheet.
5.
Click the Distribution sheet.
6.
Click the Fail Server button for each server. Observe where the databases will be distributed.
7.
Click Export DAG Scripts button.
8.
In the Storage Calculator Export Scripts window, click OK twice.
9.
Click the LUN Requirements sheet. Review the calculated requirements provided on this sheet.
10. Click the Backup Requirements sheet. Review the calculated requirements provided on this sheet.
11. Click the Replication Requirements sheet. Review the calculated requirements provided on this
sheet.
12. Click the Storage Design sheet. Review the calculated requirements provided in this sheet.
Verifying Mailbox Server Role Performance

To design a test plan for Mailbox server
performance, you need to accurately understand
how the server will be used. This includes factors
such as the number of mailboxes, the number of
messages users will send, and the type of clients
that will be accessing the mailboxes. If you do not
accurately understand the load that will be placed
on the server, you cannot ensure that server
performance will meet your needs.
When you create your test environment, you

should ensure that it replicates the conditions
in your production environment as closely as
possible. This means that you should be using identical hardware, software, and drivers on the test system
and production system.
To test server performance, it is impossible to completely replicate the users in a production environment.
However, Microsoft provides two tools that you can use to generate simulated loads on the server:
Exchange Load Generator (LoadGen). You can use this tool to create a simulated load of MAPI,
Outlook Web App, the Microsoft Exchange ActiveSync technology, Internet Message Access
Protocol (IMAP), POP3, and Simple Mail Transfer Protocol (SMTP) clients on your Exchange servers.
You can configure this tool based on the usage data that you have gathered to determine whether
the performance is acceptable.
Jetstress. You can use this tool to verify disk performance by simulating the Exchange Server
database and the log file loads that a specific number of users produce. This tool is also capable of
simulating the load generated by database replication in a DAG.
Lesson 3
Configuring the Mailbox Servers
One of the most important tasks that you will perform after your initial Exchange Server 2013 deployment
is configuring the Mailbox servers. You should secure the Mailbox server as much as possible, plan and
configure the appropriate storage, and then create and configure the mailbox databases. In this lesson,
we will discuss configuration of the mailbox servers.
Lesson Objectives
Describe initial configuration tasks for the Mailbox servers.
Configure iSCSI storage.
Create and manage the mailbox databases.
Initial Mailbox Server Configuration Tasks

There are several tasks that you should complete
after you install Exchange Server 2013, and before
putting it into production.
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 by using Role-Based Access
control (RBAC). You can use built-in role
groups or create custom role groups to
delegate permissions. This reduces the
Exchange Servers attack surface.
Create and configure databases. Exchange Server 2013 uses mailbox databases to store messages and
public folders. Before creating mailboxes on the server, you need to create the required databases.
Configure high availability. Exchange Server 2013 uses DAGs to provide high availability for mailbox
databases. We recommend that the DAGs be configured before deploying mailboxes on the mailbox
databases.
Configure public folders. If you are migrating from a previous Exchange Server version, you should
consider migrating your public folders to Exchange Server 2013 before moving all of your mailboxes.
Configure recipients, including resource mailboxes. The Mailbox server role manages all user
mailboxes, so deploying the Mailbox server role includes configuring the recipients.
Configure the offline address book. Outlook 2007 (and newer) clients support retrieving offline address
books with HTTP, rather than only with public folders as in previous Microsoft Office Outlook
versions.
Implement an antivirus solution. We recommend highly that you implement and configure an
antivirus and antimalware solution before you put your Exchange server into production.
Configuring iSCSI Storage in Windows Server 2012

iSCSI is a protocol that supports access to remote,
SCSI-based storage devices over a TCP/IP network.
iSCSI carries standard SCSI commands over IP
networks to facilitate data transfers over intranets
and to manage storage over long distances. You
can use iSCSI to transmit data over LANs, WANs,
or even over the larger Internet.
iSCSI relies on standard Ethernet networking

architecture, and use of specialized hardware such
as a host bus adapter (HBA) or network switches
is optional. iSCSI uses TCP/IP (typically, TCP port
3260). This means that iSCSI enables two hosts to
negotiate (session establishment, flow control, and packet size, for example) and then exchange SCSI
commands by using an existing Ethernet network. By doing this, iSCSI takes a popular, high-performance,
local storage bus subsystem architecture and emulates it over LANs and WANs, creating a SAN.
Unlike some SAN protocols, iSCSI requires no specialized cabling; it can be run over existing switching and
IP infrastructure. However, the performance of an iSCSI SAN deployment can be severely decreased if it is
not operated on a dedicated network or subnet, which we recommend as a best practice.
Note: Although you can use a standard Ethernet network adapter to connect the server to
the iSCSI storage device, you can also use dedicated HBAs.
An iSCSI SAN deployment includes the following components:
IP network. You can use standard network interface adapters and standard Ethernet protocol network
switches to connect the servers to the storage device. To provide sufficient performance, the network
should provide speeds of at least 1 gigabit per second (Gbps), and should provide multiple paths to
the iSCSI target. We recommend that you use a dedicated physical and logical network to achieve
fast, reliable throughput.
iSCSI targets. ISCSI targets present or advertise storage, similar to controllers for hard disk drives of
locally attached storage. However, this storage is accessed over a network, instead of locally. Many
storage vendors implement hardware-level iSCSI targets as part of their storage devices hardware.
Other devices or appliances, such as Windows Storage Server devices, implement iSCSI targets by
using a software driver together with at least one Ethernet adapter. Windows Server 2012 provides
the iSCSI target serverwhich is effectively a driver for the iSCSI protocolas a role service.
iSCSI initiators. The iSCSI target displays storage to the iSCSI initiator (also known as the client), which
acts as a local disk controller for the remote disks. All versions of Windows Server starting from
Windows Server 2008 include the iSCSI initiator and can connect to iSCSI targets.
iSCSI Qualified Name (IQN). IQNs are unique identifiers that are used to address initiators and targets
on an iSCSI network. When you configure an iSCSI target, you must configure the IQN for the iSCSI
initiators that will be connecting to the target. iSCSI initiators also use IQNs to connect to the iSCSI
targets. However, if name resolution on the iSCSI network is a possible issue, iSCSI endpoints (both
target and initiator) can always be identified by their IP addresses.
The iSCSI initiator service has been a standard part of the operating system since Windows Server 2008.
Before Windows Server 2012, the iSCSI Software Target, however, needed to be downloaded and installed
optionally. Now, it is integrated as a role service into Windows Server 2012. The new features in Windows
Server 2012 include:
Authentication. You can enable Challenge-Handshake Authentication Protocol (CHAP) to authenticate

initiator connections or enable reverse CHAP to allow the initiator to authenticate the iSCSI target.
Query initiator computer for ID. This is only supported with Windows 8 and Windows Server 2012.
iSCSI Target Server
The iSCSI target server role service provides for software-based and hardware-independent iSCSI disk
subsystem. You can use the iSCSI target server to create iSCSI targets and iSCSI virtual disks. You can then
use the Server Manager to manage these iSCSI targets and virtual disks.
The iSCSI target server included in Windows Server 2012 provides the following functionality:
Network/diskless boot. By using boot-capable network adapters or a software loader, you can use
iSCSI targets to deploy diskless servers quickly. By using differencing virtual disks, you can save up
to 90% of the storage space for the operating system images. This is ideal for large deployments of
identical operating system images, such as a Hyper-V server farm or High Performance Computing
(HPC) clusters.
Server application storage. Some applications, such as Hyper-V and Exchange Server, require block
storage. The iSCSI target server can provide these applications with continuously available block
storage. Because the storage is remotely accessible, it can also combine block storage for central or
branch office locations.
Heterogeneous storage. An iSCSI target server supports iSCSI initiators that are not based on
Windows, so you can share storage on Windows Servers in mixed environments.
Lab environments. The iSCSI target server role enables your Windows Server 2012 computers to be a
network-accessible block storage device. This is useful in situations where you want to test
applications before deployment on SAN storage.
Enabling the iSCSI target server to provide block storage takes advantage of your existing Ethernet
network. No additional hardware is needed. If high availability is an important criterion, consider setting
up a high-availability cluster. With a high-availability cluster, you will need shared storage for the
clustereither hardware Fibre Channel storage or a serial attached SCSI (SAS) storage array. An iSCSI
target server is directly integrated into the failover cluster feature as a cluster role.
iSCSI Initiator
The iSCSI Initiator is included in Windows Server 2012 and Windows 8 as a service and installed by default.
To connect your computer to an iSCSI target, you only have to start the service and configure it.
Demonstration: Configuring iSCSI Storage for the Mailbox Server Role

Demonstration Steps
1.
On LON-DC1, start Server Manager, start the Add Roles and Features Wizard, install the following
roles and features to the local server, and accept the default values:
o
2.
File And Storage Services (Installed)\File and iSCSI Services (Installed)\iSCSI Target Server
On LON-DC1, in Server Manager, in the navigation pane, click File and Storage Services, and then
click iSCSI.
3.
Create a New iSCSI Virtual Disk with these settings:

o
Storage location: C:
Disk name: iSCSIDisk1
Size: 2 GB
iSCSI target: New
Target name: lon-mbx1
Access servers: LON-MBX1
4.
On the View results page, wait until the creation is completed, and then click Close.
5.
Create a New iSCSI Virtual Disk with these settings:

o
Size: 500 MB
iSCSI target: lon-mbx1
6.
Run iSCSI Initiator on LON-MBX1.
7.
Connect to the portal at address 172.16.0.10.
8.
Add the connection to the list of favorite targets.
Creating and Managing Mailbox Databases

One of the first things that you should do
after you deploy your Exchange Server 2013
infrastructure is create mailbox databases, or
configure settings on the existing mailbox
database. Exchange Server 2013 comes with one
mailbox database that is created by default. It is
located on a system drive, and it provides initial
storage for the administrator mailbox and system
mailboxes.
In most cases, you will not use the default mailbox

database unless you have a small and lowdemand environment. Otherwise, you will have to
create a new mailbox database on the supported storage. We recommend that you do not remove the
default mailbox database, because it contains system mailboxes. However, you can rename it so that it
follows your naming convention.
You can create a mailbox database from both the Exchange Administration Center (EAC) or from the
Exchange Management Shell. However, advanced management of existing databases can be done only
from the Exchange Management Shell.
When you create a mailbox database from the EAC, you need to specify the mailbox database name, the
server that will host the database, and paths for the database file and logs. By default, each database
location is within the Exchange Server installation directory, but we recommend that you change this
because you should host the databases on a dedicated volume.
If you want to create a mailbox database by using the Exchange Management Shell, you should use the
New-MailboxDatabase cmdlet. When creating a mailbox database, this cmdlet provides you with more
options and parameters than the Exchange Administration Center.
When you open properties of the mailbox database in the EAC, you can configure options on the
following tabs:
General: Use this tab to configure only the database name. All other settings and properties are readonly, but you can see when the last backup of the database was performed, on which server the
database is mounted, and who the master server is for the database. You can also see the last
modification date.
Maintenance: Use this tab to configure the journal recipient for the database and the maintenance
schedule. You can also enable background database maintenance, and configure circular logging. For
restore purposes, you can enable overwrite on the database, and configure the database so that it
does not mount on startup.
Limits: On this tab, you configure mailbox size and retention limits. You can configure limits where
clients will be warned to the size of their mailboxes and also limits when send and receive will be
prohibited. For retention, you can configure how many days the system will keep deleted items and
mailboxes.
Client Settings: This tab has only one configurable option, and that is the offline address book (OAB).
You can configure the OAB for the users on a mailbox database by database basis.
To view the full list of properties for the mailbox database, run following cmdlet:
Get-MailboxDatabase Identity MailboxName | FL
For advanced management and configuration of the mailbox database, use the Set-MailboxDatabase
cmdlet.
If you want to move the mailbox database files to another location, you must use the Exchange
Management Shell. You cannot use the Set-MailboxDatabase cmdlet to move the mailbox database;
you must use the Move-DatabasePath cmdlet. The following is an example of the Move-DatabasePath
cmdlet:
Move-DatabasePath Identity MailboxDatabaseName EdbFilePath E:\DB1\DB1.edb
LogFolderPath G:\Logs\DB1
This example shows the database with the name MailboxDatabaseName moving to the path
E:\DB1\DB1.edb, and the log files moving to G:\Logs\DB1.
Demonstration: Creating and Managing Mailbox Databases

Demonstration Steps
1.
Open Disk Management on LON-MBX1.
2.
Bring online and initialize the three new disks.
3.
Make a simple volume on each disk, and format it with NTFS.
4.
Name the volume on Disk 1 as DB2.
5.
Name the volume on Disk 2 as Logs.
6.
In the EAC window, create new mailbox database with following properties:
o
Database name: DB2
Database file path: E:\DB2\DB2.edb
Log folder path: F:\Logs\DB2
7.
Set the properties for the new database by executing the following cmdlet: Set-MailboxDatabase
identity DB2 DeletedItemRetention 20.00:00:00 CircularLoggingEnabled $true
ProhibitSendQuota 2.2GB.
8.
Dismount and remount the DB2 database.

Scenario
After performing a test deployment, A. Datum is now planning the deployment of Exchange Server 2013
in a production environment. First, they want to summarize all requirements and all available resources,
and then plan for the Mailbox server deployment. After the deployment, you need to configure the
storage attached to the servers, and then configure the mailbox databases. After the configuration tasks,
you need to export data from the users mailbox to the .pst file.
Objectives
Plan configuration for the mailbox servers.
Configure storage for the mailbox servers.
Create and configure the mailbox databases.
Lab Setup
Virtual machines
20341B-LON-DC1
20341B-LON-CAS1
20341B-LON-MBX1
20341B-LON-CL1
User Name
Password
Pa$$w0rd
1.
2.
3.
4.
5.
Password: Pa$$w0rd
Repeat steps 2 to 4 for 20341B-LON-MBX1, 20341B-LON-CAS1, and 20341B-LON-CL1.
Exercise 1: Planning Configuration for Mailbox Servers

Scenario
Use the Mailbox server role calculator to design the Exchange infrastructure for A. Datum. You must fulfill
the following requirements:
A. Datum has to provide mailboxes for 5,000 users. The number of mailboxes grows by a factor of 5%
per year.
All users must be provided with 1-GB mailboxes. In addition, each user must have an online archive of
2 GB.
The average message size is 75 KB, and the total number of sent/received messages per mailbox per
day is 150.
All deleted messages should have a retention period of 30 days, with single-item recovery enabled.
A. Datum plans to deploy four Mailbox servers.
Mailbox databases should be highly available.
Each database should have three total instances: 1 active instance, 1 passive instance, and 1 lagged
copy with 24 hours delay.
Approximately 2% of mailboxes are moved per week.
Databases and logs should be separated.
A. Datum plans to implement a third-party backup solution. Backups will be performed on a weekly
full/daily incremental schema.
Currently, A. Datum has only one datacenter, and at this time the company is not planning for a siteresilient solution. Servers for Exchange currently have 1,000-GB disks for databases, 500-GB disks for
transaction logs, and 1,500-GB disks for Restore LUN. A. Datum also plans to leverage virtualization as
much as possible.
Note: This lab uses a modified version of the Exchange Server 2010 Exchange Mailbox
Server Role Requirements Calculator. Ensure that you download and use the Exchange Server
2013 version when calculating hardware requirements for Exchange Server 2013 servers.
1.
Analyze requirements for the A. Datum Exchange Server deployment.
2.
Use the Exchange Mailbox Server Role Requirements Calculator.
3.
Analyze output from the Exchange Mailbox Server Role Requirements Calculator.
4.
Discuss the solution with the instructor and the class.
Task 1: Analyze requirements for the A. Datum Exchange Server deployment
Read the Lab and Exercise scenario. Summarize the requirements from the exercise scenario.
Task 2: Use the Exchange Mailbox Server Role Requirements Calculator

1.
On LON-CL1, open File Explorer, navigate to C:\Files and open the E2013Calc.xlsm file. On the
Security warning, click Enable Content.
2.
Based on requirements from lab and exercise scenario, fill in the appropriate fields on the Input sheet
in E2013Calc.
Task 3: Analyze output from the Exchange Mailbox Server Role Requirements
Calculator
1.
In the E2013Calc, click on Role Requirements tab.
2.
Review calculated requirements provided in this sheet.
3.
4.
Click the Fail Server button for each server. Observe where databases will be distributed.
5.
Click Export DAG Scripts.
6.
7.
Click the LUN Requirements sheet. Review the calculated requirements provided in this sheet.
8.
Click the Backup Requirements sheet. Review the calculated requirements provided in this sheet.
9.
Click the Replication Requirements sheet. Review the calculated requirements provided in this
sheet.
11. Open File Explorer, and navigate to C:\Files.
12. Right-click the CreateMBDatabases.ps1 file, and select Edit. Review the content of the script that is
generated.
13. Right click the CreateMBDatabaseCopies.ps1 file, and select Edit. Review the content of the script
that is generated.
14. Right-click the Diskpart.ps1 file, and select Edit. Review the content of the script that is generated.
15. Close the Windows PowerShell ISE window.
Task 4: Discuss the solution with the instructor and the class
1.
Discuss the solution provided by the Exchange Mailbox Server Role Requirements Calculator with
other students and with the instructor.
2.
Change the values on the Input tab of the Exchange Mailbox Server Role Requirements Calculator,
and see how that reflects on results that this tool provides.
Results: After completing this exercise, the students will have created a plan for their mailbox server
configuration.
Exercise 2: Configure Storage on the Mailbox Servers

Scenario
Currently, the Mailbox server has no locally attached storage for the mailbox database. You have available
iSCSI storage that should be used for the mailbox databases and logs. These drives will be sufficient for
the initial deployment at A. Datum, but the organization expects to add several additional iSCSI drives
during the deployment.
You need to configure Windows Server 2012 to connect to the iSCSI drives, and configure storage for the
mailbox databases and logs.

1.
Create and configure iSCSI target and drives.
2.
Connect Exchange Server to the storage.
3.
Configure storage.
Task 1: Create and configure iSCSI target and drives

1.
On LON-DC1, open Server Manager, start the Add Roles and Features Wizard, and install the
following roles and features to the local server, and accept the default values:
o
File And Storage Services (Installed)\File and iSCSI Services (Installed)\iSCSI Target Server
2.
On LON-DC1, in Server Manager, in the navigation pane, click File and Storage Services, and then
click iSCSI.
3.
Create a new iSCSI Virtual Disk with these settings:

o
Size: 2 GB
iSCSI target: New
Target name: lon-mbx1
Access servers: LON-MBX1
4.
On the View results page, wait until the creation is completed, and then click Close.
5.
6.
Size: 2 GB

o
Size: 500 MB
Task 2: Connect Exchange Server to the storage

1.
On LON-MBX1, open Server Manager, and then from the Tools menu start the iSCSI Initiator.
2.
Connect to the portal at address 172.16.0.10.
3.
Add the connection to the list of favorite targets.
Task 3: Configure storage

1.
On LON-MBX1, from Server Manager, open Disk Management.
2.
Bring online and initialize the three new disks.
3.
Make a simple volume on each disk, and format it with NTFS.
4.
5.
6.
Name the volume on Disk 3 as Logs.
Results: After completing this exercise, the students will have configured iSCSI storage for their mailbox
databases and logs.
Exercise 3: Creating and Configuring Mailbox Databases

Scenario
When installing the Mailbox server role, a default mailbox database is created on the server. You need to
modify the location and configuration of the default mailbox database to meet the corporate standards.
The database should have a warning limit set to 0.9 GB, prohibit send at 1.0 GB, and prohibit send and
receive at 2.2 GB.
In addition to the default mailbox database, you also need to create a new mailbox database to meet the
deployment requirements. The new mailbox database should be placed on the iSCSI drive, and it should
have circular logging enabled. You also need to set different limits and retention time periods from the
default database. After setting the limits and retentions, you need to export the mailbox of Aidan Delaney
to a .pst file.
1.
Configure mailbox settings for the existing mailbox database.
2.
Create and configure additional mailbox databases.
3.
Export mailbox data to the .pst file.
4.
Task 1: Configure mailbox settings for the existing mailbox database

1.
On LON-MBX1, open Internet Explorer and type https://lon-cas1.adatum.com/ecp, and press

Enter.
2.
Sign in as Adatum\Administrator with the password Pa$$w0rd.
3.
Set the properties for Mailbox Database 1 as follows:

o
Issue a warning at (GB): 0.9
Prohibit send at (GB): 1
Prohibit send and receive at (GB): 1.3
Keep deleted items for (days): 30
4.
Open the Exchange Management Shell.
5.
Note the database names by executing the Get-MailboxDatabase cmdlet.
6.
Move the database by executing the cmdlet: Move-DatabasePath Identity Mailbox Database 1
EdbFilePath E:\DB1\DB1.edb LogFolderPath G:\Logs\DB1.
7.
Verify that both the database file and logs are moved to the new location.
Task 2: Create and configure additional mailbox databases

1.
In the EAC window, create a new mailbox database with the following properties:
o
Database name: DB2
Database file path: F:\DB2\DB2.edb
Log folder path: G:\Logs\DB2
2.
Set the properties for the new database by executing the following cmdlet: Set-MailboxDatabase
identity DB2 DeletedItemRetention 20.00:00:00 CircularLoggingEnabled $true
ProhibitSendQuota 2.2GB.
3.
Dismount and remount the DB2 database.
Task 3: Export mailbox data to the .pst file

1.
On LON-MBX1, in the Exchange Management Shell window, execute the following cmdlet:
New-ManagementRoleAssignment Role "Mailbox Import Export" User Administrator.
2.
Restart the Exchange Management Shell.
3.
Export Aidans mailbox by executing the following cmdlet: New-MailboxExportRequest -Mailbox

aidan -FilePath \\lon-dc1\MailboxExport\aidan.pst.
4.
Make sure the status is complete by using the Get-MailboxExportrequest cmdlet.
5.
Verify that aidan.pst file exists in the shared folder.
following steps:
1.
2.
In the Virtual Machines list, right-click 20341B-LON-DC1, and then click Revert.
3.
4.
Repeat steps 2 to 3 for 20341B-LON-CAS1, 20341B-LON-MBX1, and 20341B-LON-CL1.
5.
6.
7.
8.
Password: Pa$$w0rd
Results: After completing this exercise, the students will have their mailbox databases created and
configured.
Question: What is the purpose of the Exchange Mailbox Server Role Requirements
Calculator?
Question: Can you move existing mailbox databases to a different path by using the EAC?
Question: What must you do before you can export the users mailbox to the .pst file?

Best Practice
Use the Exchange Server Mailbox Server Role Calculator when planning for Mailbox server
deployment.
Always provide high availability for Mailbox servers.
Do not use circular logging on mailboxes in production.
Consider using Exchange native data protection.
Review Questions
Question: Why would you choose to use SATA drives instead of a SAN or small computer
system interface (SCSI) drives for your Mailbox servers?
Question: Your organization needs to determine which storage solution to deploy for the
new Exchange Server 2013 messaging environment. What information should you consider
when selecting the hardware?
Tools
Exchange Mailbox Server Role Calculator
Exchange Administration Center

3-1
Module 3
Managing Recipient Objects
Contents:
Module Overview
3-1
Lesson 1: Managing Exchange Server 2013 Mailboxes
3-2
Lesson 2: Managing Other Exchange Recipients
3-12
Lesson 3: Planning and Implementing Public Folder Mailboxes
3-17
Lesson 4: Managing Address Lists and Policies
3-23
3-30
3-37
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 essential that you have a good understanding of recipient management.
This module describes how you can manage recipient objects, address policies, and address lists in
Microsoft Exchange Server 2013.
Objectives
After completing this module, students will be able to:
Manage Exchange Server 2013 mailboxes.
Manage other Exchange Server 2013 recipients.
Implement public folders.
Configure address lists and policies.
Lesson 1
Managing Exchange Server 2013 Mailboxes

Two of the most common tasks that Exchange Server administrators perform are creating and
configuring email recipients. As organizations hire new employees, or employees change positions
within the organization, the Exchange administrators need to make sure that the users have the
messaging functionality that they require. Most users in an organization will use Exchange Server
mailboxes, although Exchange Server 2013 also provides various other mailbox options that can be
configured.
3-2 Managing Recipient Objects
This lesson provides an overview of the different types of Exchange Server 2013 mailboxes, and describes
how to manage each type of mailbox.
Lesson Objectives
After completing this module, the students will be able to:
List the different recipient objects in Exchange Server 2013.
Describe user mailboxes.
Create and configure user mailboxes.
Move mailboxes.
Describe resource mailboxes.
Create and configure resource mailboxes.
Describe site mailboxes.
Describe shared mailboxes.
Configure shared mailboxes.
Describe linked mailboxes.
Types of Exchange Server Recipients

Exchange Server recipients are any objects within
the Active Directory Domain Services (AD DS)
forest that have been configured with an email
address. When AD DS objects are configured
with an email address, they appear in the Global
Address List (GAL). Exchange Server 2013 supports
the following recipient types:
User mailboxes. A mailbox that you assign

to an individual user in your Exchange Server
organization. This is the most common type
of recipient in Exchange Server 2013.
Mail contacts. Contacts that 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 e-mail address.
Mail users. Users who have an AD DS user account but 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 an AD DS user account with a security identifier (SID). This allows the user
account to access resources in the AD DS environment.
Resource mailboxes (room mailboxes and equipment mailboxes). A resource mailbox is configured for
objects such as meeting rooms, or resources 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.
Shared mailboxes. A mailbox that is used by multiple users rather than one primary user.
Organizations often use shared mailboxes to provide services such as sales, help desk, or general
information requests.
Mail-enabled security and distribution groups. You can use a mail-enabled AD DS security group
object to grant access permissions to AD DS resources, and you also can use it to distribute messages.
You can use a mail-enabled AD DS distribution group object to distribute messages to a group of
recipients.
Dynamic distribution groups. A distribution group that uses a Lightweight Directory Access Protocol
(LDAP) query with recipient filters and conditions to derive its membership at the time messages are
sent.
Linked mailboxes. Regular mailboxes that are associated with individual users in a separate, trusted
forest. When you create a linked mailbox, a disabled user account is created in the Exchange
organization, and a user account from a trusted forest is given access to the mailbox.
Remote mailboxes. Mailboxes that are located in the Exchange Online environment. In a hybrid
Exchange Server 2013 deployment, you can create and manage remote mailboxes in the Exchange
Online environment by using the Exchange Administration Center (EAC).
Site mailboxes. Mailboxes that include both an Exchange Server mailbox and a Microsoft SharePoint
site. With site mailboxes, messages are stored in the mailbox, whereas documents are stored on the
SharePoint site.
Managing Mailboxes
Creating Mailboxes
Most mailboxes in an Exchange Server

organization are regular mailboxes associated
with a user account in the AD DS forest. You
can create these mailboxes using the EAC or
using the Exchange Management Shell. When
creating a mailbox, you have the following
options: You can associate the mailbox with
an existing AD DS user account, or you can
create a new AD DS account when you create
the mailbox. To create a new mailbox and
user account in the Exchange Management Shell, use the New-Mailbox cmdlet. To configure an
existing user account with a mailbox, use the Enable-Mailbox cmdlet.
You can choose a specific mailbox database for the mailbox, or accept the default, which means that
Exchange will assign the mailbox to any mailbox database in the same AD DS site.
You can assign an address book view to the mailbox.
If you create or enable the user mailbox using the Exchange Management Shell, you can assign other
attributes to the mailbox.
Configuring Mailboxes
After creating the mailbox, you can configure all other settings on the mailbox using the EAC or the
Exchange Management Shell. The following table lists some of the mailbox configuration options
available:
Tab
Configuration settings
general
User names and custom attributes.
mailbox usage
Displays the last logon information.

Configure mailbox size limits and retention settings.
contact information
Configure information such as address and phone number.
organization
Configure the title, department, company, and manager settings.
email address
Configure the email addresses assigned to the mailbox.

Can include Single Mail Transfer Protocol (SMTP), Exchange
Unified Messaging addresses, or addresses associated with other
messaging systems.
mailbox features
Configure the policies that apply to the mailbox.

Configure the phone and voice features, including enabling and
disabling features, and configuring policies for enabled features.
Configure mail flow settings including delivery options, message
size, and delivery restrictions.
member of
View the groups to which the user account belongs.
MailTip
Configure MailTip for the mailbox to be displayed when users

add this recipient as a message recipient.
mailbox delegation
Configure Send As, Send on Behalf of, and Full Access

permissions to the user mailbox.
To change an existing mailbox, use the Set-Mailbox cmdlet.

Note: You can modify some attributes for multiple mailboxes at one time in the EAC. To do
this, select multiple mailboxes in the List view. The details pane will display the Bulk Edit options
that are available for the mailboxes. Note that not all settings can be modified using this process.
Demonstration: Creating and Configuring Mailboxes
In this demonstration, you will see how to create and configure user mailboxes using the EAC and the
Exchange Management Shell.
Demonstration Steps
1.
On LON-CAS1, in Windows Internet Explorer connect to https://lon-cas1.adatum.com/ecp. Sign in

as Adatum\administrator using the password Pa$$w0rd.
2.
In the Exchange Management Console, run the New Mailbox Wizard, and create a new user account
and mailbox for Alice Ciccu. Create the user account in the Research organizational unit (OU), and
create the mailbox in the Research mailbox database.
3.
Review the settings available on Alice Ciccus mailbox.
4.
Delete Alice Ciccus mailbox.
5.
Disable Anil Elsons mailbox.
6.
On LON-DC1, in Active Directory Users and Computers, verify that Alices account has been deleted
from the Research OU, but that Anils account has not been deleted.
Note: Deleting the mailbox deletes the specified user account and mailbox. Disabling the
mailbox removes the mailbox, but leaves the user account enabled.
7.
On LON-CAS1, open the Exchange Management Shell.
8.
Use the Enable-Mailbox cmdlet to assign a mailbox in the Research mailbox database to Anil Elsons
account.
9.
Use the Get-User and Enable-Mailbox cmdlets to create mailboxes for all users in the Development
OU. Place the mailboxes the Mailbox Database 1 mailbox database.
Demonstration: Moving Mailboxes
One common task Exchange administrators perform is moving mailboxes. You may need to move
mailboxes to another mailbox database on the same Exchange server, to a mailbox database on another
Exchange server, or to a mailbox database on an Exchange Server in another Exchange organization. In
Exchange Server 2013, you can move mailboxes one at a time or create migration batches to move
multiple mailboxes at one time.
In this demonstration, you will see how to move individual mailboxes, and how to configure and monitor
migration batches.
Demonstration Steps
1.
Move April Reagans mailbox from Mailbox Database 1 to the Research mailbox database using the
EAC. You could also move one mailbox at a time using the New-moverequest cmdlet.
2.
Move multiple mailboxes by creating a migration batch.
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 AD DS
user account that is associated with a resource
mailbox is disabled. You can create two different
types of resource mailboxes in Exchange Server
2013:
Room mailboxes. Resource mailboxes that

you can assign to meeting locations, such as
conference rooms, auditoriums, and training
rooms.
Equipment mailboxes. Resource mailboxes that you can assign to resources that are not locationspecific, such as portable computer projectors, microphones, or company cars.
You can include both types of resource mailboxes as resources in meeting requests, which provides a
simple and efficient way for users to book these resources. After creating the resource mailbox, you must
configure properties such as location and size. These attributes are useful for enabling users to search for
meeting rooms that meet their requirements.
Configuring Resource Booking Settings
When you configure a resource mailbox, you can also configure settings that determine how the resource
mailbox will respond to meeting requests. You can configure resource mailboxes to automatically process
incoming meeting requests for all users, or you can restrict who can book the meeting room. You can
configure delegates who have to approve all meeting requests, and you can also configure the resource
mailbox to accept only certain types of meetings. For example, you can configure a conference room to
automatically accept incoming meeting requests but not accept recurring meeting requests.
When you create a resource mailbox using the EAC, you can configure the following settings that define
how the mailbox will accept meeting requests.
Tab
delegates
booking options
Settings
You can configure the resource mailbox to automatically process meeting

requests for all users, or you can select delegates who must accept or deny
meeting requests. You can assign only individual mailboxes and not
distribution lists as delegates to the mailbox.
You can configure:
Whether the mailbox will accept repeating or recurring meetings.
Whether the mailbox can only be booked for meetings during regular
working hours (8 a.m. to 5 p.m. Monday to Friday).
How many days in advance users can book meetings.
Whether to automatically decline meetings that extend beyond the
maximum booking time.
How long meetings can be booked for the mailbox.
Additional text that will be sent to the user when they book a meeting
with the mailbox.
In addition to the settings available in the EAC, you also can configure many additional settings for how
the resource mailbox will respond to meeting requests. These settings are configured by using the setcalendarprocessing cmdlet. Some of the options available are:
Configuration option
Sample command
Allow conflicting meetings.
Set-CalendarProcessing id MeetingRm1
AllowConflicts $true
Allow certain users to request meetings that do

not follow the policies regarding maximum lead
time or maximum meeting limits.
Set-CalendarProcessing id MeetingRm1
RequestOutOfPolicy adam
Prevent the meeting room from automatically

accepting meeting requests.
Set-CalendarProcessing -Identity MeetingRm1

-AutomateProcessing:None
Considerations for Planning Resource Mailboxes

When you design how meeting requests will be accepted, consider the following:
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 and to block conflicting requests. You can change
this so that all meeting requests are accepted as tentative, or to allow users to book the meeting
resource for the same time.
Demonstration: Creating and Managing Resource Mailboxes

In this demonstration, you will use the Exchange Management Console to:
Create and configure a resource mailbox.
Configure a delegate for a resource mailbox.
Demonstration Steps
1.
On LON-CAS1, in the EAC, create a new room mailbox with the following information:
o
Name: Conference Room 1
Email address: ConferenceRoom1
Organizational unit: Sales
Location: London
Capacity: 20
Mailbox database: Mailbox Database 1
2.
3.
After creating the room mailbox, modify the properties to:

o
Change the lead time for booking meetings to one year.
Send the text You have successfully booked Conference Room 1 to users who book the
meeting room.
On LON-CL1, signed in as Aidan, open Outlook 2013 and create a new Meeting Request. Invite the
Administrator and the Conference Room 1 resource mailbox to the meeting.
Note: If necessary, complete the Welcome to Microsoft Outlook 2013 Wizard.
4.
Send the meeting request and verify that the resource accepted the invitation.
5.
On LON-CAS1, in the EAC, access the Conference Room 1 properties.
6.
Add Amr Zaki as a delegate for the resource mailbox.
7.
Verify that the delegate has to accept the meeting request for the room mailbox.
What Are Site Mailboxes?

One issue that users face when they work
collaboratively is that information can be stored in
several different locations. Users who are working
on the same project might need to exchange
emails related to the project, and they might also
need to access shared documents stored on file
shares or on a SharePoint Server 2013 site.
Site mailboxes in Exchange Server 2013 provide a
more integrated experience for users who need to
collaborate. Site mailboxes enable users to access
both documents stored on SharePoint 2013 and
email stored in an Exchange Server 2013 mailbox
using the same client interface.
Understanding How Site Mailboxes Work
A site mailbox provides integration between a SharePoint site and an Exchange mailbox. For example, a
group of users may be working on a project that requires email communication as well as a document
review process. With site mailboxes, users can send and read email messages in the site mailbox. Users
can also post documents and review documents on the SharePoint site.
The benefit of site mailboxes is that users can access both types of content from a single interface.
Site mailboxes are available in Outlook 2013 and can be used to view both the email messages in the
mailbox and the documents stored in SharePoint. The same content can also be accessed directly from
the SharePoint site. With site mailboxes, Exchange stores the email, providing users with the same email
conversations that they use every day for their own mailboxes. SharePoint stores the documents and
provides advanced document management tools such as version control.
Configuring Site Mailboxes
Site mailboxes are managed through SharePoint. To implement site mailboxes, you must configure Secure
Sockets Layer (SSL) and configure OAuth authorization between the SharePoint 2013 server and the
Exchange Server 2013 server.
Once the integration is configured, administrators or users with delegated permissions can create site
mailboxes on the SharePoint server by using the Site Mailbox application. Outlook users can then add
the site mailbox to their Outlook 2013 profile.
Managing Site Mailboxes with Policies
You can manage site mailboxes using both Exchange Server 2013 policies and SharePoint 2013 policies.
In Exchange, you can configure site mailbox quotas by using the SiteMailboxProvisioningPolicy cmdlets
in the Exchange Management Shell. You can configure the maximum size for the site mailbox, and the
maximum message size that can be sent to the mailbox.
In SharePoint, you can configure policies for those who can create site mailboxes, and you can configure
SharePoint Lifecycle policies to manage the lifecycle of a site mailbox. For example, you can create a
lifecycle policy in SharePoint that automatically closes all site mailboxes after six months. When the
lifecycle application in SharePoint closes a site mailbox, the site mailbox is retained in SharePoint for a
defined period of time. The mailbox can then be reactivated by the mailbox user or by a SharePoint
administrator.
After the retention period, the Exchange site mailbox in the mailbox database will have the prefix MDEL:
added to the mailbox name to indicate that it has been marked for deletion. The mailboxes are not
automatically removed from Exchange; you must manually remove these site mailboxes.
Managing Compliance
Site mailboxes can be part of the In-Place eDiscovery scope in SharePoint 2013 when you perform
keyword searches against user mailboxes or site mailboxes. In addition, you can put a site mailbox on
legal hold.
Note: For detailed information on how to configure site mailboxes, see the Configure site
mailboxes in SharePoint Server 2013 page at http://go.microsoft.com/fwlink/?LinkId=290960.
What Is a Shared Mailbox?

Many organizations need to have multiple
users access the same mailbox. For example,
an organization may provide an email address
such as info@adatum.com on a public web site.
The organization may want to have several
users monitor the mailbox associated with this
email address to ensure prompt replies to
potential customers. In previous versions of
Exchange Server, you could create a mailbox for
this purpose, and then give multiple users access
to this mailbox.
Exchange Server 2013 simplifies the process of

creating this type of mailbox by providing shared mailboxes. A shared mailbox is a special type of user
mailbox in which the user account associated with the mailbox is a disabled account, and other users are
granted access to the mailbox. To gain access to the mailbox, users with the required permissions sign
into their own mailboxes, and then open the shared mailbox by adding the shared mailbox to their
Outlook profile or by accessing the mailbox through Outlook Web App.
Note: When a users Outlook profile is configured in cache mode, all mailboxes to which
the user has Full Access permissions will be downloaded and cached on the local machine. This
behavior can be modified so that only the primary mailboxes and non-mail folders such as the
Calendar, Contacts, and Tasks folders for the other mailboxes are cached. You can edit the
registry or use Group Policy Objects to configure this setting. For more information, see
http://go.microsoft.com/fwlink/?LinkId=290961 for details.
In Exchange Server 2013, creating a shared mailbox is a single-step process using the EAC or the Exchange
Management Shell. You can create a shared mailbox and grant users Full Access and Send As mailbox
permissions when you create the mailbox.
When you grant a user Full Access permission to the shared 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 also assign 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.
Note: You also can enable delegated users to access regular mailboxes rather than creating
shared mailboxes. When you configure delegate access to a regular mailbox, you also can grant
a Send on Behalf Of permission. This permission allows a delegated user to send messages from
the mailbox, but the From: address in any message sent by the delegate shows that the message
was sent by the delegate on behalf of the mailbox owner.
Demonstration: Creating a Shared Mailbox

In this demonstration, you will see how to configure a shared mailbox, and access the mailbox using
Outlook 2013 and Outlook Web App.
Demonstration Steps
1.
On LON-CAS1, in the EAC, create a new shared mailbox with the following information:
o
Display name: Sales Information
Email address: salesInfo
Assign Full Access permission to Aidan Delany and Amr Zaki.
Mailbox database: Mailbox Database 1
2.
On LON-CAS1, log on to Outlook Web App as Administrator, and send a message to the Sales
Information mailbox.
3.
On LON-CL1, logged in as Aidan, switch to Outlook 2013, and verify that the Sales Information folder
is displayed.
4.
Reply to the message sent to the Sales Information mailbox.
5.
Access Outlook Web App as Amr, and open the Sales Information mailbox.
What Are Linked Mailboxes?

Linked mailboxes provide mailboxes for users
whose primary accounts are located in a separate,
trusted forest. Users with a linked mailbox sign
in to their local AD DS domain using the local
credentials, and those credentials are then used
to access a mailbox in an Exchange organization
in a different forest.
Linked mailboxes can be useful in the following
two scenarios:
Organizations deploy Exchange in a resource

forest. When organizations deploy Exchange
in a resource forest scenario, they deploy
Exchange into one AD DS forest, while allowing access to the Exchange mailboxes to user accounts
that are located in one or more trusted forests (called account forests).
Organizations use linked mailboxes in a merger or acquisition scenario. In this scenario, both
organizations may have deployed Exchange server before the merger or acquisition. Linked
mailboxes provide the opportunity to remove the Exchange server deployment from one of the
organizations. The users from one of the organizations can be configured with linked mailboxes in
the other organization. This ensures that users from both organizations are listed in a single GAL,
and also makes availability information accessible for all users.
When configuring a linked mailbox, the user account that is used to access the linked mailbox does
not exist in the forest where Exchange is deployed. When you create the linked mailbox, a disabled user
account is created in the domain where Exchange is deployed and associated with the linked mailbox. The
user account from the account forest is granted full control of the mailbox.
To implement linked mailboxes, perform the following steps:
Configure a one-way trust in which the domain where Exchange is deployed trusts the domain where
the user account exists. This can be an external or forest trust. Note that the one-way trust is required.
Make sure that the user account exists in the account forest before you create a linked mailbox. You
cannot create the user account when you create the linked mailbox.
In addition to configuring the one-way trust, you also should consider creating a two-way trust
between the domains. The two-way trust is not required, but the account that creates the linked
mailbox must have permissions to modify the user object in the account forest. If you do not
implement a two-way trust, you will need to provide account forest administrator credentials when
you create the linked mailbox.
Lesson 2
Managing Other Exchange Recipients
Exchange Server 2013 provides several other types of recipients besides the various types of mailboxes.
These recipients include distribution groups, which are used to send mail to groups of recipients and
assign permissions in an Exchange Server organization, and mail contacts and mail users. This lesson
provides an overview of these recipient types and describes how to manage them.
Lesson Objectives
Describe distribution groups.
Create and configure distribution groups.
Configure self-service management of distribution groups.
Manage mail contacts and mail users.
Configure site mailboxes.
What Are Distribution Groups?

Distribution groups in Exchange Server are mailenabled groups. When you mail-enable a group,
Exchange Server 2013 assigns an email address
to the group, and the group by default is added
to the GAL. You can use mail-enabled groups to
allow users to send email to multiple recipients.
Mail-enabled security groups also allow you to
assign permissions simultaneously to multiple
users for Exchange Server objects, such as shared
mailboxes and public folders.
In Exchange Server 2013, you can create two
types of mail-enabled groups:
Universal security groups. Universal security groups in AD DS are used to assign permissions to
network resources, and are used as an Exchange Server 2013 distribution group.
Universal distribution groups. Universal distribution groups in AD DS can only be used to group email
recipients; they cannot be used to assign permissions to network resources.
Dynamic Distribution Groups
Exchange Server 2013 also supports dynamic distribution groups. Dynamic distribution groups are mailenabled group objects that do not have a pre-configured list of members. Instead, the membership list for
dynamic distribution groups is calculated each time a message is sent to the group.
When you configure a dynamic distribution list, you can define the group membership based on various
filters and conditions. For example, you might create a dynamic distribution list that includes all users
in a specific building, or that includes all users located in a specific organizational unit. When an email
message is sent to a dynamic distribution group, the Exchange Server queries a global catalog server for
all recipients in the organization that match the criteria defined for that group. The Exchange Server then
populates the group based on the query, and delivers the mail to the users.
Demonstration: Creating and Configuring Distribution Groups

In this demonstration, you will see how to configure various types of distribution groups.
Note: You cannot mail-enable an existing universal distribution or security group in the
EAC. To mail-enable an existing group, use the Enable-DistributionGroup cmdlet.
Demonstration Steps
1.
On LON-CAS1, connect to the EAC, and sign in as Adatum\administrator.
2.
Create a new distribution group with the following settings:
3.
Display name: Sales Managers
Alias: SalesManagers
Organizational unit: Sales
Members: Bonnie Kearney, Dennis Bye
Owner approval is required: Closed
Choose whether the group is open to leave: Closed
Create a new security distribution group with the following settings:

o
Display name: IT Managers
Alias: ITManagers
Organizational unit: IT
Members: April Reagan, Magnus Hedlund
Owner approval is required: Selected
4.
Configure the group to require message moderation, assign Amr Zaki as the moderator, and
configure the IT group with permission to send to the group without moderation.
5.
Create a dynamic distribution group with the following settings:

o
Display name: Developers
Alias: Developers
Organizational unit: Development
Owner: Administrator Members include everyone in the Development group
Implementing Self-Service Distribution Group Management

In some organizations, managing distribution
groups can be complex and time consuming.
Distribution groups membership lists might
need to be updated frequently, and it might
not be clear which users should be added to
the different distribution groups. Business-unit
administrators or project leaders are often the
best people to determine who should be added
to specific distribution groups. In some cases,
organizations may want to grant users the ability
to add themselves to certain distribution groups.
Exchange Server 2013 provides the following
options for enabling self-service distribution group management:
Assign non-Exchange administrators as distribution group owners. With this option, Exchange
administrators with the appropriate permissions create distribution groups, and then assign other
users or groups as the owners of the groups. The group owners can manage the group membership
by accessing the group properties in Outlook or through the Outlook Web App.
Note: In Exchange Server 2013, you can only add individual mailboxes as owners of a
distribution group. In Exchange Server 2013 Cumulative Update 1 (CU1), you can assign other
groups as owners of distribution groups.
Enable open distribution-group memberships. You can configure distribution groups to enable
users to either automatically join groups or request to join groups. The configuration options vary
depending on whether the distribution group is a security group or not.
o
For security distribution groups, you can configure the group to require owner approval to join
groups. Only owners can remove members from security groups.
For distribution groups that are not security groups, you can configure the group membership as
open, which means that anyone can automatically join or leave the group. You can also configure
the group to require owner approval to join the group. In this scenario, users can request to join
the group, and they will be joined to the group when the owner approves the request.
Enable users to create and manage their own distribution groups. You also can enable users to create
distribution groups using the Outlook Web App Options page. To enable users to create distribution
groups, you must change the Default Role Assignment Policy or create a new role assignment policy
and enable the MyDistributionGroups role. This option gives users permission to create mail-enabled
distribution groups and to manage the groups that they own.
Configuring Group Naming Policies
If you enable users to create their own groups, you may still want to maintain some control of the names
assigned to the distribution groups. You can configure a group naming policy to manage names assigned
to distribution groups created by users. In the group naming policy, you can configure a prefix and suffix
that will be added to the name for a distribution group when it is created. You also can block specific
words from being used. With a group naming policy configured, users provide the display name for the
group, and then the prefix or suffix that you have defined in the group naming policy is applied to the
group.
Demonstration: Configuring Self-Service Distribution Group Management
In this demonstration, you will see how to configure two different options for self-service group
management. You will examine how to create a group that has an open membership list, and validate that
users can join this group without owner approval. You will also see how to create a group naming policy,
and enable users to create and manage their own groups.
Note: In this demonstration, you are granting all users the right to create distribution
groups by editing the Default Role Assignment Policy. To limit which users can create distribution
groups, create a custom role assignment policy that grants permission to create distribution
groups, and then assign that role assignment policy to selected users.
Demonstration Steps
1.
On LON-CAS1, log on to EAC and create a new distribution group named TechDiscussion with
open membership requirements.
2.
In LON-CL1, connect to Outlook Web App and log on as Amr.
3.
Access the Outlook Web App Options page, and verify that Amr can join the TechDiscussion
distribution group.
4.
On LON-CAS1, in the EAC, create a new distribution group naming policy that assigns a suffix of
EmailDL_ and a suffix with the company attribute.
5.
Enable the MyDistributionGroups option for the Default Role Assignment Policy.
6.
In LON-CL1, connect to Outlook Web App, and log on as Aidan.
7.
Access the Outlook Web App Options page, and create a new distribution group named EXAdmins.
8.
Verify that the group naming policy is applied.
Managing Mail Contacts and Mail Users

Mail contacts are mail-enabled AD DS 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 that persons email address. This
allows Exchange Server users to select that person from the GAL for sending email.
Mail Users
Mail users are similar to mail contacts. Both have external email addresses; both contain information
about people outside your Exchange Server organization, and both can be displayed in the GAL and
other address lists. However, unlike mail contacts, mail users have AD DS logon credentials and a security
identifier (SID) that enable them to access network 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 that individual. For example, you might 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.
Lesson 3
Planning and Implementing Public Folder Mailboxes
One significant change in Exchange Server 2013 is the way that public folders are implemented. In
previous versions of Exchange Server, public folders were stored in a dedicated public folder database.
Public folder databases could not be replicated in a database availability group (DAG), so they used public
folder replication to provide high availability and redundancy. In Exchange Server 2013, public folders are
now stored in regular mailbox databases rather than being stored in dedicated databases.
This lesson provides an overview of how public folders are implemented in Exchange Server 2013 and
describes how to create and manage public folders.
Lesson Objectives
Describe public folders implementation in Exchange Server 2013.
Manage public folders.
Configure public folder mailboxes and public folders.
Describe considerations for implementing public folders.
Using Public Folders in Exchange Server 2013

Public folders were available in all previous
versions of Exchange Server. Many organizations
use public folders as a means of sharing
information between groups of users. With
public folders, multiple users can access a shared
folder in Outlook.
In Exchange Server 2013, the underlying
architecture for public folders has changed entirely
without significantly changing the user experience
with public folders. In Exchange Server 2013:
Public folders are stored in a special type

of mailbox called a public folder mailbox. In
previous versions of Exchange Server, public folders were stored in a separate public folder database.
In Exchange Server 2013, the public folder mailboxes are stored in regular mailbox databases. The
public folder mailbox stores the public folder hierarchy as well as the public folder contents.
Public folder mailboxes can be stored in mailbox databases that are part of a DAG. In previous
versions of Exchange Server, public folders used a public folder replication process to enable
redundancy. By storing the public folder mailboxes in a mailbox database that is part of a DAG, you
can provide high availability for the public folder deployment using the same mechanism as the one
used for providing high availability for mailboxes.
Public folders are spread across multiple public folder mailboxes. In previous versions of Exchange
Server, you could replicate public folder contents to public folder databases located in different
locations to enhance client access to public folder contents. In Exchange Server 2013, you can create
public folders and store the public folders in different mailboxes, which can be located on Mailbox
servers in different locations.
Note: An important difference between public folder replication in previous versions of

Exchange Server and distributing public folders across multiple mailboxes in Exchange Server
2013 is that in Exchange Server 2013 you can have only a single copy of the data. In previous
versions of Exchange Server, you can have multiple copies of the public folder contents, and
public folder replication is a multi-master process. In Exchange Server 2013, you can only store
the public folder contents in one mailbox, and all clients must access that mailbox to see the
public folder contents. If you put the public folder mailbox in a database that is part of a DAG,
the mailbox is highly available, but all clients still only access the mailbox in the active copy of the
database.
Public folders are accessed by clients only for Outlook 2007 or later. In Exchange Server 2013,
Outlook Web App clients cannot access the public folders. In Exchange Server 2013 CU1, you can add
public folders located on Exchange 2013 as Favorites in Outlook Web App.
To implement public folders in Exchange Server 2013, you first must create a primary public folder
hierarchy mailbox. The primary public folder mailbox contains the only writeable copy of the public
folder hierarchy. After creating the primary public folder mailbox, you can create additional public folder
mailboxes as secondary public folder mailboxes. The secondary public folders will contain read-only
versions of the public folder hierarchy.
After creating the primary public folder mailbox, you can begin creating public folders. By default, all
public folders are created in the primary public folder mailbox. If you create a secondary public folder
mailbox, you can create public folders in the secondary public folder mailbox only if you create the public
folder using the new-publicfolder cmdlet with the mailbox parameter.
Managing Public Folders

After you create the public folder mailboxes and
public folders, you might need to perform several
additional management tasks on the public
folders.
Configure Public Folder Permissions

In Exchange Server 2013, administrative
permissions to manage public folders are enabled
through Role Based Access Control (RBAC). To
grant users permission to manage public folders,
you must add them to the Public Folder
Management role group.
Many organizations also configure public folder client permissions or access rights for users. These
permissions are used to restrict the actions users can perform in the public folder. Client permissions
have not changed compared to previous versions of Exchange Server. You can assign permissions to users
by using roles such as Owner, Publishing Editor, or Author. These roles include multiple types of access.
For example, the Publishing Editor role has the Create items, Read items, Create subfolders, Folder visible,
Edit own, Edit all, Delete own, and Delete all permissions. You also can assign custom permissions by using
a variety of the access rights.
You can configure client permissions in the EAC by selecting the public folder and then clicking
Manage under Folder permissions. You can also configure client permissions by accessing the
public folder properties in Outlook, or by using the Add-PublicFolderClientPermission and
Remove-PublicFolderClientPermission cmdlets.
When you create a public folder, it automatically inherits the same client permissions as the parent
public folder. When you change the permissions on a parent folder, you have the option to enforce the
permission change for all subfolders. The default permissions assigned to new root folders are Author for
authenticated users and None for anonymous users.
Mail-enable Public Folders
Mail-enabling a public folder assigns an SMTP address to it and lists it in the GAL. Users can then post
messages to the public folder by sending email messages to it. When a public folder is mail-enabled, you
can configure additional settings on the public folder such as email addresses and mail quotas. You can
mail-enable a public folder in the EAC by selecting the public folder and then clicking Enable under Mail
settings. You can also use the Enable-MailPublicFolder cmdlet.
Manage Quota Limits and Retention Settings
You can manage the default quota limits and retention settings for all public folders in the organization
by using the Set-OrganizationConfig cmdlet. You also can configure these settings on individual public
folders by using the Set-PublicFolder cmdlet.
Monitor public folders
Exchange Server 2013 provides several cmdlets that can be used to monitor and manage public folders:
Get-PublicFolderItemStatistics. Displays information about items within a specified public folder.

The information includes the subject, last modification time, last access time, creation time,
attachments, message size, and type of item.
Get-PublicFolderStatistics. Displays statistical information about all public folders, such as folder size
and last logon time.
Get-PublicFolderMailboxDiagnostics. Displays event-level information about a public folder

mailbox. This information can be used to troubleshoot public folder issues.
Update-PublicFolderMailbox. Used to update the hierarchy for public folders.
Demonstration: Creating and Configuring Public Folders
In this demonstration, you will see how to create and configure public folders in Exchange Server 2013.
You will also see how to configure public folder permissions in the EAC.
Demonstration Steps
1.
On LON-CAS1, in the EAC, create two new public folder mailboxes, PFMBX1 and PFMBX2.
2.
Create a public folder named Departments.
3.
Create a child public folder to the Departments public folder named IT.
4.
Open the Exchange Management Shell and use the Get-PublicFolder cmdlet to view the properties
of the public folders.
5.
Use the New-PublicFolder cmdlet to create the Research public folder as a subfolder under the
Departments public folder, and place the public folder in the PFMBX2 mailbox.
6.
Configure the Administrator account as the Owner of the Departments folder and all subfolders.
Migrating Public Folders to Exchange Server 2013
Because of the entirely new architecture for

Exchange Server 2013 public folders, it is more
complicated to migrate public folders from
previous versions of Exchange Server than it was
in older versions. To complete the migration, you
must copy the contents of public folders from
Exchange Server 2007 Service Pack 3 (SP3) Update
Rollup 10 (RU10) or Exchange Server 2010 SP3 to
the Exchange Server 2013 public folder mailboxes,
and then switch all access to public folders to the
new environment. Exchange Server 2013 provides
several new *PublicFolderMigrationRequest
cmdlets, in addition to several PowerShell scripts, to help you complete the migration. These cmdlets use
the Microsoft Exchange Mailbox Replication Service to perform the migration.
The high-level steps to complete the public folder migration from Exchange Server 2010 are listed below.
You can use the same steps to migrate public folders from Exchange Server 2007.
1.
2.
Prepare the environment for the migration. To prepare the environment, perform the following steps:
a.
On the Exchange Server 2010 SP3 server, take a snapshot of the current public folder
deployment. This snapshot is used to verify that the migration includes all the same
folders, items, and permissions at the end of the migration. Use the Get-PublicFolder,
Get-PublicFolderStatistics, and Get-PublicFolderClientPermission cmdlets to take this
snapshot.
b.
On the Exchange Server 2010 SP3 server, verify that there is no previous record of a successful or
ongoing migration.
c.
On the Exchange Server 2013 server, verify that there are no existing public folder migration
requests. If any exist, clear them.
d.
Ensure that there are no existing public folders on the Exchange Server 2013 servers.
Prepare the public folder mapping file. This step includes:

a.
On the Exchange Server 2010 or Exchange Server 2007 server, generate the comma-separated
values (CSV) files that list all of the public folders on the previous Exchange Server versions. To
do this, run the Export-PublicFolderStatistics.ps1 script to create the mapping file that maps
the folder name to the folder size. The file will have two columns: FolderName and FolderSize.
b.
Create the Folder-to-Mailbox mapping file. This file will be used to create the correct
number of public folder mailboxes on the Exchange 2013 Mailbox server. Run the
PublicFolderToMailboxMapGenerator.ps1 script to create the public folder-to-mailbox
mapping file.
3.
Create the public folder mailboxes on the Exchange 2013 server. Verify that the public folder
mailboxes that you create match the name of the TargetMailbox in the mapping file. When you
create the public folder mailboxes, use the HoldForMigration option.
4.
Start the migration request. On an Exchange Server 2013 Mailbox server, run the
New-PublicFolderMigrationRequest cmdlet to start the migration. This command can take a long
time to complete if you have several gigabytes (GBs) or more of data in the public folders.
5.
Lock down the public folders on the previous versions of Exchange Server for final migration.
During the public folder migration, users have been able to access public folders. To finish the
migration, you must log users off of the public folders and lock them for a final synchronization. Run
the Set-OrganizationConfig -PublicFoldersLockedForMigration:$true command on an Exchange
Server 2010 SP3 server. If you have multiple public folder databases, wait until the public folder
replication has completed to make sure that all public folder databases are locked.
6.
Finalize the public folder migration. In the final step, run the Set-PublicFolderMigration cmdlet
and set the PreventCompletion flag to false. Then resume the public folder migration. Exchange
will now complete a final synchronization of the public folder contents and set the public folder
databases on the Exchange Server2013 servers as active. After you complete the migration, all clients
will need to access the public folders on the Exchange Server 2013 servers. If you experience issues
with the migration, you can roll back to the previous version of Exchange Server by unlocking the
public folders and setting the migration as not completed.
Note: This topic provides a high-level description for the process of migrating public
folders from a previous version of Exchange Server. For more detailed information, see
http://go.microsoft.com/fwlink/?LinkId=290962.
Considerations for Implementing Public Folders

Because of the entirely new architecture for public
folders in Exchange Server 2013, your planning
process for implementing public folders will differ
considerably from the process you used with
previous versions of Exchange Server. Some of the
factors that you should consider when planning
the public folder deployment include:
In previous versions of Exchange Server,

organizations with Exchange Servers in
multiple locations often configured public
folder replication to ensure that the public
folder contents were available in each
location. In Exchange Server 2013, the public folder contents can only exist in a single public folder
mailbox. If your organization has multiple locations, you will need to plan the location of the public
folder contents to optimize user access.
Planning the distribution of public folder contents may be complicated in organizations with a
very large amount of data in public folders. Exchange Server 2013 has a maximum mailbox size
of 100 GB, so if your organization has more than 100 GB of data in public folders, you will need to
create multiple public folder mailboxes and distribute the public folder contents across the mailboxes.
Even if you have less than 100 GB of data in public folders, you might want to either distribute the
public folder contents across geographic regions so that the contents are in the same location as the
users who access the public folder contents or decrease the mailbox size.
Generally, public folder access has not changed for users. Users will still use their Outlook clients to
access public folders. If they have the required permissions, they will still be able to create new public
folders and configure public folder permissions in their Outlook client. The only significant change for
public folder users is that they will not be able to access public folders using Outlook Web App. Public
folders in mailboxes are the same as public folders in older versions of Exchange Server. The storage
of the public folders is different from an administration point of view, but that change is transparent
to the users.
We recommend that you locate the primary hierarchy mailbox in a mailbox database with multiple
mailbox copies in a DAG. If the primary hierarchy mailbox is not available, users can still read public
folder contents, but they cannot make any changes to the public folders.
Lesson 4
Managing Address Lists and Policies
In many messaging systems, you might host multiple SMTP domains, and therefore you would need to
manage the email addresses assigned to the Exchange Server recipients. To make sure that recipients have
the appropriate email addresses, you can create and apply email address policies.
In large organizations, the GAL may contain thousands of recipients. Finding a specific recipient in that list
can be complicated. To simplify the process of finding recipients, you can configure address lists.
In this lesson, you will learn how to configure email address policies and address lists.
Lesson Objectives
Describe address lists.
Configure address lists.
Configure offline address books.
Describe address book policies.
Configure address book policies.
Describe email address policies.
Configure email address policies.
What Are Address Lists?

Address lists are used to group recipient objects
based on a LDAP query for specific AD DS
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.
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. Because of the different nature of each business, 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 employees search for
recipients in their division, these custom address lists allow them 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 that contains all recipients in both divisions.
Example 2
You can use subcategories of address lists, which are known as hierarchical address lists. For example, you
can create an address list that contains all recipients in Vancouver and another address list 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
1.
On LON-CAS1, in the EAC, create a new address list called AllDepartments that includes only users
with Exchange mailboxes.
2.
Create another child address list under AllDepartments named Research that contains only users
with Exchange mailboxes in the Research department.
3.
On LON-CL1, in Outlook 2013, force a download of the offline address book.
4.
Verify that the Research address list is listed and that it contains the correct users.
Configuring Offline Address Books

The offline address book is used by Outlook clients
when you configure the clients to use a cached
mode Outlook profile, or when the client is in
offline mode. The offline address book is cached
on the local client so that users can search the GAL
when sending messages.
The default offline address book contains the
entire GAL, which includes all recipients in the
Exchange organization. You can create additional
GALs and add them to a custom offline address
book.
By default, the offline address book is generated

on a Mailbox server only once each day at 5 a.m. This means that any additions, deletions, or changes
made to mail-enabled recipients are only committed to the offline address book once daily, unless you
modify the schedule to generate the offline address book more frequently.
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 Offline
Address Book (OABGen) service runs on the Mailbox server that hosts the Organizational mailbox.
The OABGen service identifies all recipients that should be members of the offline address book, and
then creates the offline address book files in the C:\Program Files\Microsoft\Exchange Server
\V15\ClientAccess\OAB folder.
Note: You can identify the Mailbox server that hosts the Organization mailbox by running
the Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} command. The
only way to move the offline address book generation to another Exchange 2013 server is to
move this mailbox to another mailbox server.
OAB virtual directory. The OAB virtual directory is the distribution point Microsoft Office Outlook
2007 and newer clients use to download the offline address book. When you install Exchange Server
2013, the OAB virtual directory is created under the Default Web Site on the Client Access server,
and under the Exchange Back End website on Mailbox servers. By default, the OAB virtual directory
is configured with an internal URL. If Outlook clients from outside the organization are accessing the
Exchange environment, you also should configure an external URL.
Autodiscover service. Autodiscover service was introduced in Exchange Server 2007 as a feature that
enabled Office Outlook 2007 or newer clients, as well as some mobile devices, to configure their
profile to access Exchange Server automatically. This service provides the correct OAB URL for
Outlook clients.
OAB distribution. When clients need to download the offline address book, the client sends a request
to the Client Access server configured through Autodiscover. The Client Access server then proxies
the request to the Mailbox server that is hosting the OAB files. The OAB files are then distributed
directly from the Mailbox server to the client.
Offline Address Book Size Considerations
The size of the offline address book may be a concern in large organizations that have large directories,
or in organizations that have deployed Office Outlook in cached mode. Offline address book sizes can
vary from a few megabytes to a few hundred megabytes. 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 one kilobyte
(KB) to three KBs. They are the single largest contributor to the offline address book size.
Number of AD DS mail recipients.
Number of AD DS 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.
Note: Previous versions of Exchange Server supported a variety of versions of the Offline
Address Book. Exchange Server 2013 only supports OAB version 4, which is supported by Outlook
2007, Outlook 2010, and Outlook 2013.
What Are Address Book Policies?

Address book policies can limit the information
that users see in their GAL. Some organizations
require that certain users be prohibited from
seeing all of the other users in the 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 that have extremely large
GALs 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 Server 2013, 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 then can 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, and 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 mailbox is located on an Exchange Server 2010
Service Pack 3 (SP3) or Exchange Server 2013 server. If you update the address book policy, the clients
must reconnect their mailboxes before the new policy is applied. If a client accesses the global address list
through other means, such as a direct LDAP query to a global catalog server, the address book policy
does not apply.
Demonstration: Configuring Address Book Policies

Address book policies contain the following lists:
One GAL
One offline address book
One room-address list
One or more address lists
In this demonstration, you will see the following steps that are required to configure an address book
policy for users in the Research department at A. Datum:
Create a global address list for the Research department.
Create a new offline address book for the Research department.
Create the address book policy.
Note: In this demonstration, you will use the default All Rooms address list rather than
create a custom address list.
Demonstration Steps
1.
On LON-CAS1, if required, open the Exchange Management Shell.
2.
Use the following commands to create the address book policy and assign the policy to all users in
the Research OU.
New-GlobalAddressList -Name ResearchGAL -RecipientFilter {(Department eq

Research)}
Update-GlobalAddressList -Name ResearchGAL
New-OfflineAddressBook -Name "ResearchOAB" -AddressLists "ResearchGAL"
New-AddressBookPolicy -Name ResearchABP -AddressLists \AllDepartments\Research OfflineAddressBook ResearchOAB -GlobalAddressList ResearchOAB -RoomList "\All Rooms"
Get-Mailbox -OrganizationalUnit Research | Set-Mailbox -AddressBookPolicy ResearchABP
3.
On LON-CL1, sign out, and then sign in as Allie using the password Pa$$w0rd.
4.
Open Outlook 2013 and configure Allies profile.
5.
Verify that Allie can only see other members of the Research department in the GAL.
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 recipients in an
Exchange organization so that 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 configure in the Exchange
organization so that the Exchange servers will
accept messages sent to that SMTP namespace.
By default, the Exchange Server contains an email address policy that assigns one or more email addresses
to 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 of recipients, 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 multiple recipients based upon an OPATH filter.
OPATH is a querying language designed to query object-data sources. The filter defines the search scope
in the AD DS forest and the attributes that are used to filter the GAL.
The new Email 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 2013, Exchange Server 2010, and Exchange Server 2007
mailboxes.
Mail users with external email 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 AD DS, but use email accounts that are external to the organization.
Resource mailboxes. Select this check box if you want your email address policy to apply to
Exchange Server resource mailboxes.
Mail contacts with external email addresses. Select this check box if you want your email address
policy to apply to contacts with external email addresses.
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.
You can also configure a rule that can filter the recipients to which the email address policy will apply.
Using this option, you can filter the recipients based on the following categories:
Recipient container. Use this to filter the recipient list based on the organization unit where the
recipient account exists.
State or province. Select this check box if you want the email address policy to include only
recipients from specific states or provinces.
Company. Select this check box if you want the email address policy to include only recipients in
specific companies.
Department. Select this check box if you want the email address policy to include only recipients in
specific departments.
Custom attributes. 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 that custom attribute.
When creating an email address policy, you can use the following email address types:
Default SMTP email address. Default SMTP email addresses are commonly used email address types
that Exchange Server provides for you.
Custom SMTP email address. If you do not want to use one of the default SMTP email 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
%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
Non-SMTP email address. Exchange Server 2013 supports a number of non-SMTP address types
including X.500, X.400, Lotus Notes, and Novel GroupWise.
Demonstration: Configuring Email Address Policies
In this demonstration, you will see how to modify the default email address policy and how to create a
new email address policy.
Demonstration Steps
1.
On LON-CAS1, in the EAC, modify the default email address policy to add the
firstname.lastname@adatum.com email to all A. Datum users.
2.
Create a new accepted domain for Sales.adatum.com.
3.
Create an email address policy that applies the email address first name first initial of last name
@sales.adatum.com email address to all users in the Sales OU.
4.
Examine the email addresses assigned to Adam Barr and Arlene Huff and verify that the email
addresses are assigned correctly.

Scenario
You are the messaging administrator for A. Datum Corporation. A. Datum has purchased a new company
named Trey Research. The Trey Research mailboxes will be hosted on your Exchange Server 2013
environment, but they must maintain a unique identity within the organization. All Trey Research users
should use the TreyResearch.net SMTP domain to send and receive email. Trey Research users should be
able to view only other users in the Trey Research business group.
You need to implement the messaging environment for the Trey Research users.
Lab Setup
Virtual machines
20341B-LON-DC1
20341B-LON-CAS1
20341B-LON-MBX1
20341B-LON-CL1
User Name
Password
Pa$$w0rd
1.
2.
3.
4.

o
Password: Pa$$w0rd
5.
Repeat steps 2 to 4 for 20341B-LON-MBX1 and 20341B-LON-CAS1.
6.
Repeat steps 2 and 3 for 20341B-LON-CL1. Do not log on until directed to do so.
Note: In some cases, messages sent in this lab may not be delivered immediately. You may
notice that when you send messages, the messages stay in the Drafts folder in Outlook Web App.
Use the following steps to troubleshoot mail flow if you experience this issue in this lab or in any
other labs:
1.
On LON-MBX1, open the Exchange Management Shell.
2.
Type Test-ServiceHealth, and press Enter. Verify that all required services are running. If the services
are not running, start them.
3.
Type Restart-Service MSExchangeSubmission, and press Enter.
4.
Type Restart-Service MSExchangeDelivery, and press Enter. Check to see if the message has been
delivered.
5.
If not, type Restart-Service MSExchangeTransport, and press Enter. Check to see if the message has
been delivered.
6.
If the messages are still not being delivered, restart the Microsoft Exchange Active Directory
Topology service from the Services console. Restart all dependent services. Verify that all services set
to automatic start are started. Check to see if the message has been delivered.
Exercise 1: Configure Trey Research Recipients

Scenario
You have received a script and a .csv file that you will use to create the recipients for the Trey Research
users. However, you also need to configure other recipient objects for the Trey Research users, such as
distribution groups and resource mailboxes. The project team has requested that you create the following
recipient objects:
Create AD DS user accounts and mailboxes using a script provided by the project team.
Create room mailboxes and configure the mailboxes so only Trey Research users can book meetings
in the rooms. All other meeting requests must be approved by a Trey Research administrator.
Configure a shared mailbox for the Sales department at Trey Research.
Configure distribution groups that include different departments at Trey Research.
Configure a dynamic distribution list that includes Trey Research and A. Datum users who are working
on the Trey Research integration project. You have been provided with a list of the current members
of this team, but the membership list is expected to change frequently.

1.
Create the Trey Research AD DS objects.
2.
Create the Trey Research mailboxes.
3.
Create the Trey Research distribution groups.
Task 1: Create the Trey Research AD DS objects

1.
On LON-CAS1, from Server Manager open the Active Directory Module for Windows PowerShell.
2.
Run the TreyResearchSetup.ps1 script from the e:\Labfiles\Mod03 folder.
3.
Verify that the Trey Research OUs, users, and groups are created.
Task 2: Create the Trey Research mailboxes

1.
On LON-CAS1, open the Exchange Management Shell and run the following commands:
To
Run
Create a mailbox database for

Trey Research users
New-MailboxDatabase Name TreyResearchDB

Server LON-MBX1
Restart the Microsoft Exchange

Information Store service on
LON-MBX1
Invoke-Command ComputerName LON-MBX1

ScriptBlock {Restart-Service msexchangeis}
Mount the database
Mount-Database id TreyResearchDB
To
Run
Create mailboxes for all Trey

Research users
Get-User OrganizationalUnit TreyResearch | EnableMailbox -Database TreyResearchDB
Mail-enable all Trey Research

groups
Get-Group OrganizationalUnit TreyResearch | EnableDistributionGroup
2.
On LON-CAS1, open Internet Explorer and connect to https://LON-CAS1.adatum.com/ecp.
3.
Sign in as Adatum\administrator using the password Pa$$w0rd.
4.
Create a room mailbox with the following settings:

o
Room name: TR_Room1
Email address: TR_Room1
Organizational unit: click Browse, click TreyResearch, and then click OK
Location: Harrow
Capacity: 20
Mailbox database: TreyResearchDB
Delegates: Charlotte Weiss
5.
Enable all TreyResearch users to book meetings without moderation by running the
Set-CalendarProcessing id TR_Room1 BookinPolicy AllTreyResearch command.
6.
Create a shared mailbox with the following settings:

o
Display name: TreyResearch Sales
Email address: TreyResearchSales
Full access permission: TR_Sales
Mailbox database: TreyResearchDB
Task 3: Create the Trey Research distribution groups

1.
On LON-CAS1, in the EAC, create a new distribution group with the following settings:
o
Display name: Trey_SalesMgrs
Alias: TreySalesMgrs
Organizational unit: TreyResearch\Sales
Members: Florence Flipo, Sidney Higa
2.
3.
Create another distribution group with the following settings:

o
Display name: TreyResearchNews
Alias: TreyResearchNews
Organizational unit: TreyResearch
Members: none
Owner approval is required: Open
Choose whether the group is open to leave: Open
4.
5.
On LON-CAS, in the Exchange Management Shell, change to the E:\Labfiles\Mod03 folder and then
run the following commands to configure all members of the TreyResearch integration team with a
custom attribute.
o
$users=import-csv .\TreyResearchIntegrationTeam.csv
foreach ($i in $users) {set-mailbox Identity $i.alias CustomAttribute1 TreyResearch

Integration Project Team}
On LON-CAS1, in the EAC, create a new dynamic distribution group with the following settings.
o
Display name: TreyIntegration
Alias: TreyIntegration
Owner: Administrator
Recipient container: Adatum.com
Custom attribute 1: TreyResearch Integration Project Team
Results: In this exercise, you created AD DS user and group accounts for Trey Research, created a room
mailbox with custom permissions, and configured a shared mailbox. You also configured distribution
groups for the Trey Research users.
Exercise 2: Configure Address Lists and Policies for Trey Research

Scenario
Your second step in integrating Trey Research users into the A. Datum Exchange server environment is
to create the address lists and policies required to ensure that the Trey Research users have the required
functionality and separation of user information. To do this, you need to:
Configure TreyResearch.net as an accepted domain.
Create an email address policy for Trey Research users.
Create an address list for Trey Research users.
Create an address book policy for Trey Research users.
Validate the Trey Research deployment.

1.
Configure TreyResearch.net as an accepted domain.
2.
Configure an email address policy for Trey Research users.
3.
Configure an address list for TreyResearch users.
4.
Configure an address book policy for Trey Research users.
5.
Validate the deployment.
Task 1: Configure TreyResearch.net as an accepted domain
On LON-CAS1, in the EAC, create a new accepted domain called TreyResearch using the domain
name TreyResearch.net.
Task 2: Configure an email address policy for Trey Research users
On LON-CAS1, in the EAC, create a new email address policy named TreyResearch Email that assigns
a primary email address in the form of FirstName.LastName@treyresearch.net to all TreyResearch
users.
Task 3: Configure an address list for TreyResearch users
On LON-CAS1, in the EAC, create a new address list named TreyResearch that includes all recipients
in the TreyResearch OU.
Task 4: Configure an address book policy for Trey Research users
On LON-CAS1, in the Exchange Management Shell, run the following commands:

To
Run
Create a global address

list that includes only
Trey Research users.
New-GlobalAddressList -Name TreyResearchGAL

-RecipientContainer TreyResearch
Update the Trey

Research GAL.
Update-GlobalAddressList -id TreyResearchGAL
Create a new offline

address book for the
Trey Research GAL.
New-OfflineAddressBook -Name "TreyResearchOAB"

-AddressLists "TreyResearchGAL"
Create a new room

address list for all
resource mailboxes in
the TreyResearch OU.
New-AddressList -Name TreyResearchRooms

RecipientContainer TreyResearch IncludedRecipients Resources
Update the
TreyResearchRooms
address list.
Update-AddressList TreyResearchRooms
Configure the
TreyResearchOAB to
be distributed through
the LON-CAS1 and
LON-MBX1 virtual
directories.
Set-OfflineAddressBook -id "TreyResearchOAB"

VirtualDirectories LON-CAS1\oab (Default Web Site),LONMBX1\oab (Exchange Back End)
Update the
TreyResearchOAB offline
address book.
Update-OfflineAddressBook -id "TreyResearchOAB"
Create a new address

book policy that groups
the Trey Research
components.
New-AddressBookPolicy -Name TreyResearchABP -AddressLists

\TreyResearch -OfflineAddressBook TreyResearchOAB
-GlobalAddressList TreyResearchGAL -RoomList
\TreyResearchRooms
Assign the
TreyResearchABP to
all mailboxes in the
TreyResearch OU.
Get-Mailbox -OrganizationalUnit TreyResearch | Set-Mailbox

-AddressBookPolicy TreyResearchABP
Task 5: Validate the deployment

1.
On LON-CAS1, in the EAC, verify that the TreyResearchABP has been assigned to Aaron Nicholls.
2.
On LON-CL1, sign in as Adatum\Aaron using the password Pa$$w0rd.
3.
Open Outlook 2013 and configure Aarons profile.
4.
Create a new email message.
5.
Review the recipients visible in the global address list. Verify that only Trey Research recipients are
available.
6.
Send a message to the Trey_SalesMgrs distribution group.
7.
Create and send a new meeting request and invite Cindy White and the TR_Room1 as a resource.
Verify that you can book the meeting room.
8.
Connect to OWA and verify that you cannot join the Trey_SalesMgrs distribution group but that you
can join the TreyResearchNews distribution group.
9.
In Outlook, send a message to the TreyIntegration group.
10. Log on to OWA as TreyResearch\Aidan using the password Pa$$w0rd. Verify that Aidan received
the message you sent to the TreyIntegration group.
Results: In this exercise, you created an email address policy and address list for Trey Research. You also
created an address book policy for Trey Research and validated the deployment.
Exercise 3: Configure Public Folders for Trey Research

Scenario
A. Datum has not implemented public folders, but Trey Research users have used public folders in the past
and would like to continue using them. You need to create a public folder infrastructure for Trey Research
users, and ensure that only Trey Research users have access to the public folders.
1.
Create the public folder mailbox.
2.
Create the public folders.
3.
Configure public folder permissions.
4.
Validate the public folder deployment.
5.
Task 1: Create the public folder mailbox
On LON-CAS1, in the EAC, create a new public folder mailbox named PFMBX1. Create the recipient
object in the TreyResearch OU and the mailbox in the TreyResearchDB mailbox database.
Task 2: Create the public folders

1.
On LON-CAS1, in the EAC, create a new public folder named TreyResearch.
2.
In the TreyResearch public folder, create a sub-folder named Research.
Task 3: Configure public folder permissions
1.
On LON-CAS1, in the EAC, assign the TR_IT group as the owner of the TreyResearch public folder and
all subfolders.
2.
Assign the AllTreyResearch author permission to the public folders.
Task 4: Validate the public folder deployment

1.
On LON-CL1, in Outlook 2013, verify that Aaron can access the public folders.

following steps:
1.
2.
3.
4.
5.
6.
7.
8.
Password: Pa$$w0rd
repeat steps 5 to 7 for 20341B-LON-CAS1.
Results: In this exercise, you will have created public folder mailboxes for Trey Research and verified that
users can access the mailboxes.
Question: How would you ensure that meeting requests to room mailboxes are validated
manually before being approved?
Question: How would you give access to allow a user to send messages from another
mailbox without giving the user access to the mailbox contents?

Best Practice
If you have a large number of users in your organization, spend some time learning how to manage
recipients using the Exchange Management Shell and scripts. This will save you a significant amount of
time once you are comfortable with using the commands.
Review Questions
Question: A company has two large divisions and one Exchange Server organization.
Employees in the two divisions 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?
Question: An organization has a large number of projects that leverage distribution groups.
Managing group members takes considerable time. You need to reduce the time that the
help desk staff spends managing groups so that they can work on other issues. What should
you do?
Question: You employ contractors who need an email address from your company. The
contractors should not be able to log onto your network, but you want the contractors to
appear in the GAL. The company needs to enable the contractors to receive these messages
in their current third-party mailboxes. What should you do?
Real-world Issues and Scenarios

Supplement or modify the following best practices for your own work situations:
Define clear naming conventions and adhere to them. Naming conventions help identify the location
and purpose of recipient objects, and also help both end users and administrators locate recipients
easily.
Test global changes prior to making them in a production environment. Changes to global settings,
such as email address policies, should be tested in a lab environment before you make changes in
production. This helps avoid configuration errors.

4-1
Module 4
Planning and Deploying Client Access Servers
Contents:
Module Overview
4-1
Lesson 1: Planning Client Access Server Deployment
4-2
Lesson 2: Configuring the Client Access Server Role
4-9
Lesson 3: Managing Client Access Services
4-18
Lab: Deploying and Configuring a Client Access Server Role
4-26
4-31
Module Overview
Microsoft Exchange Server 2013 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 plan, deploy, and configure it to support
various client types. This module provides details on how to plan and implement the Client Access server
role in Exchange Server 2013.
Objectives
Plan Client Access server deployment.
Configure the Client Access server roles.
Manage Client Access services.
Lesson 1
Planning Client Access Server Deployment
4-2 Planning and Deploying Client Access Servers
The first step in deploying client access to Exchange Server mailboxes is planning the Client Access server
deployment and configuration. You must consider several factors when designing deployment, including
the hardware configuration and how you will provide access to the services enabled on the Client Access
server. This lesson describes how to plan Client Access server deployment.
Lesson Objectives
Describe the Client Access server role in Exchange Server 2013.
Describe the hardware and software requirements for Client Access server.
Plan Client Access server deployment.
Describe how Client Access server works.
Describe how Outlook clients connect to their mailboxes.
Describe how Client Access server works with multiple sites.
Plan client connectivity for Client Access server.
What Is the Client Access Server Role?

The Client Access server role in Exchange Server
2013 is one of two key roles for the entire
messaging infrastructure. In fact, it is a mandatory
component for each Exchange Server deployment.
The primary purpose of the Client Access server
role is to accept and handle client connections
and server Simple Mail Transfer Protocol (SMTP)based connections, and proxy these connections
to the Mailbox server.
The Client Access server also authenticates client

connections, and provides content from the
Mailbox server role to the clients. In Exchange
Server 2013, clients cannot initiate a connection to the Mailbox server directly, in any scenario. All
connections are routed through the Client Access Server, which provides proxy services, and in Unified
Messaging (UM) scenario redirection, to the Mailbox server role. The Client Access server accepts SMTP
connections from other SMTP servers on the Internet, and also establishes SMTP connections to the other
SMTP servers on the Internet.
Unlike a Mailbox server, the Client Access server does not store any user data; nor does it perform any
kind of message queuing. The Client Access server sends and accepts messages to and from the Internet
by using its Front End Transport service, but it does not have the ability to accept and store messages for
later delivery. Front End Transport service should not be confused with, or mistakenly identified as a
replacement for Hub or Edge Transport server role from previous Exchange Server versions. It is simply a
proxy for both client and server connections; actual email processing, and sending and receiving, happens
on the Mailbox server role.
The Client Access server also provides services for messaging security. For clients, it provides Secure
Sockets Layer (SSL)-based communication and authentication. The Client Access server also provides antimalware and anti-spam functionality as SMTP traffic passes through it. The Client Access servers Front
End Transport service cannot inspect message content, but it has complete access to the SMTP protocol
conversation, so it can filter messages based on connections, domains, senders, and recipients. In addition,
unlike Exchange Server 2010, which did not have an integrated anti-malware solution, Exchange Server
2013 allows you to configure anti-malware options for virus scanning. You should note that the Client
Access server in Exchange Server 2013 does not have a transport agent for connection filtering that is
enabled by default. You can create a transport agent if you need one.
Hardware and Software Requirements for the Client Access Server

When you plan a Client Access server deployment,
you should consider general Exchange Server
hardware and software requirements. If you
choose to deploy a Client Access server together
with the Mailbox server role, you should follow
the hardware requirements for the Mailbox server,
as it is a more resource-intensive role. If you
choose to deploy the Client Access server on a
separate server, the same software requirements
that are discussed in this course will apply;
however, you should design the Client Access
server and Mailbox server hardware separately.
The Client Access server does not store any user data, so you do not have to provide separate storage
for it. However, because this role is critical in an Exchange Server infrastructure, you should make sure
that the Client Access servers hard drive is redundant (for example, in mirror configuration). We also
recommend that you deploy more than one Client Access server, if possible. If you deploy the Client
Access server on the virtual machine, ensure that the machine is highly available.
Consider the following guidelines when designing the Client Access server configuration:
There is no specific recommended processor configuration for Client Access servers. However, we
recommend that you use a minimum of two processor cores, and a maximum of 12 processor cores.
The recommended memory configuration depends on the number of client connections and the
transaction rate for a Client Access server. The recommended random access memory (RAM) for
Client Access servers is 2 gigabytes (GB) of RAM per processor core, with a minimum of 8 GB of RAM.
The Client Access server is not a hard disk-intensive application, so you do not have to implement fast
and expensive hard drives for it. You should make sure that the hard drives you select are reliable and
certified to work all day, all of the time.
The Client Access server requires a fast network connection to Mailbox servers and global-catalog
servers. If you have a large number of internal Microsoft Office Outlook clients, the network
connection may become a bottleneck. To reduce network bottleneck, configure the Client Access
server with multiple 1-gigabits-per-second (Gbps) network cards.
As a general guideline, you should deploy one Client Access server for every four Mailbox servers.
However, we recommend that you have more than one Client Access server, for redundancy and load
balancing purposes.
Planning Client Access Server Deployment

When you plan your Client Access server
deployment, you must meet certain requirements
to ensure a successful installation. In addition,
there are options for deploying Client Access
servers in scenarios where servers require high
availability, or when multiple sites are deployed.
Requirements for Client Access Server

Deployment
When you deploy Client Access servers, you must
meet the following requirements:
You must have one Client Access server in

each Active Directory site where you have Mailbox servers deployed.
If your Active Directory Domain Services (AD DS) 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.
Client Access servers should have a fast network connection to domain controllers and global-catalog
servers.
If users must access their mailboxes from the Internet through the Client Access server, then the
server must be accessible from the Internet using HTTPS, IMAP4, or POP3.
Note: 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, 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. The
following options are available when you deploy the Client Access server role:
You can deploy the Client Access server role on the same computer where the Mailbox server role
resides. Installing all server roles on a single server does not provide additional availability, and offers
only limited scalability.
You can deploy the Client Access server role on a dedicated server. This deployment provides
additional scalability and performance benefits.
You can deploy multiple servers running the Client Access server role. To provide high availability for
Client Access servers, you can deploy Windows Network Load Balancing (NLB) or a hardware network
load balancer to manage connections to the Client Access servers.
Note: You can install Client Access servers on Mailbox servers that are database availability
group (DAG) members. However, just adding the Client Access server to a DAG member does not
provide high availability for the Client Access server. This is because DAG uses failover clustering,
which does not work with Windows load balancing on the same machine. However, you can use
a hardware load balancer for the Client Access server in this scenario.
How Does a Client Access Server Work?

In Exchange Server 2013, all messaging clients
connect to a Client Access server when accessing
an Exchange Server mailbox. The main purpose of
the Client Access server is to accept, authenticate,
and proxy or redirect client connections, while
also handling SMTP message traffic with other
SMTP servers. However, the Client Access server
works differently in Exchange Server 2013
compared to the same role in Microsoft Exchange
Server 2007 and Exchange Server 2010.
One of the most significant changes is the way

that the Client Access array communicates with
clients and the Mailbox server. In previous versions of Exchange Server, internal clients used Messaging
Application Programming Interface (MAPI) remote procedure call (RPC) to connect to the Client Access
server or Mailbox server, while external clients used the RPC over HTTPS, HTTPS, POP3, or IMAP4 protocol.
In Exchange Server 2013, MAPI over RPC is still the protocol that Outlook uses, however it is now, by
default, packed inside HTTPS, regardless of how the client connects. The connection from the client to
the mailbox still goes through Client Access server. The Client Access server proxies the RPC over HTTPS
connection from the client to the Mailbox server.
The following image is a diagram that shows how a Client Access server works.
Note: To better understand how these connections work, you should understand the
following key components that participate in this process:
MAPI. This is the set of protocol commands that Outlook clients use to interact with the mailbox
server when it is accessing and managing mailboxes. MAPI is the language that all of the servers
talk, and it provides client access to mailboxes. MAPI commands are wrapped within RPC.
RPC. This is the transport through which MAPI commands are issued to the Mailbox server.
HTTPS. This is the transport protocol, and it securely wraps MAPI/RPC commands that are distributed
between clients and servers.
On the Client Access server in Exchange Server 2010, the RPC/HTTP proxy is the Internet Information
Services (IIS) component that terminates HTTP traffic. Once the HTTP traffic is terminated, the RPC
traffic on the rest of network path is allowed. However, when the Client Access server in Exchange Server
2013 terminates the HTTPS traffic, it decrypts it and inspects MAPI/RPC commands. Then the traffic is
reencrypted back with HTTPS, and sent to the Mailbox server. Next, the traffic hits the RPC proxy endpoint
on the Mailbox server IIS. This endpoint component strips off the HTTPS, and then MAPI commands are
executed on the Mailbox server with a RPC. The server, based on the parameters contained within RPC
request, should find and send the correct endpoint on the Mailbox server when the client RPC over the
HTTPS connection reaches the Clients Access server.
In a manner similar to the connections from Outlook clients, POP3 and IMAP are proxied to the
appropriate services on the Mailbox server role. SMTP connections from other SMTP servers are inspected
and the Client Access Server proxies them to the Transport component on the Mailbox server. The Client
Access server UM Call Router component redirects clients to the UM component on the Mailbox Server
role only for Unified Messaging communication.
How Does a Client Access Server Work 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.
However, in multiple-site scenario, things can work
differently. In previous Exchange Server versions,
such as the 2007 or 2010 versions, in a multiplesite scenario, Exchange Server directed clients to a
Client Access server located in the same site as the
Mailbox server, or a Client Access server in a remote site proxied a request to a Client Access server in the
same site as the Mailbox server.
Exchange Server 2013 no longer uses FQDNs of Client Access servers or arrays to locate user mailboxes.
Instead, Client Access server uses the GUID that is assigned to the user mailbox. When the client connects
to the Client Access server and requests the mailbox content, the Client Access server performs a query on
AD DS to determine the details of the client mailbox based on mailboxs GUID. These details include data
about the mailbox server that hosts the user mailbox.
The Client Access server then uses RPC over HTTPS to connect to the Mailbox server and then retrieves
the users data. Because of this approach, when configuring an Outlook profile for the user, the server
name will not be Client Access server (or Client Access server array) anymore. Instead, the connection
point is the string that is a unique identifier of the mailbox. It contains the mailbox GUID and domain
name part that is the primary domain name for the user.
A unique mailbox identifier is user specific. This information uniquely identifies the user and the mailbox.
This is effectively the target for the RPC requests that the user makes in Outlook. In addition, this
information is used to enable Client Access server to find the appropriate Mailbox server for the user at
any time. From the Outlook perspective, the unique mailbox identifier is actually the Mailbox server,
because that is the endpoint for the connection.
With this approach, a Client Access server is no longer so tightly connected to a specific Mailbox server,
as it was in prior Exchange Server versions that used the RpcClientAccessServer property. This change
provides greater flexibility in deployment and management.
By switching to RPC over HTTPS connections only for the clients, the Client Access server becomes more
lightweight. It no longer must have the RPC Client Access service installed. Benefits of this design can also
be applied to site-resilience scenarios, in that administrators no longer must handle different namespaces
when performing failover. Because the mailbox GUID and User Principal Name (UPN) is unique through
the forest, a client connection can be established without referring to a specific Client Access server.
How Does a Client Access Server Work 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.
However, in multiple-site scenario, things can
work differently. In previous Exchange Server
versions, such as the 2007 or 2010 versions, in a
multiple-site scenario, Exchange Server directed
clients to a Client Access server located in the
same site as the Mailbox server, or a Client Access server in a remote site proxied a request to a Client
Access server in the same site as the Mailbox server.
Exchange Server 2013 simplifies this process. When the client connects to the Client Access Server in one
site, and its Mailbox server is in another site, the Client Access Server will proxy the client connection to
the appropriate Mailbox server, without the need to first contact Client Access Server in the same site
where users Mailbox server is located.
This works the same way in scenarios where you have a single Internet access point, or each site has its
own Internet access point. The difference is that in scenarios where you have an Internet access point for
each site that hosts Exchange servers, you will have to maintain multiple public names, one for each Client
Access Server that is published to the Internet. In addition, you must configure an external URL for each
Client Access server. You must also make sure 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.
Note: In the case of a mixed Exchange Server environment, this connection path might not
always work the same way. For example, if you have multiple AD DS sites, where Exchange Server
2013 is deployed in Internet-facing site while a previous version of Exchange Server (such as 2007
or 2010) is deployed in another site, then Client Access Server 2013 will proxy the client
connection to the Client Access server in the site where the users Mailbox server resides.
In addition, using a proxy will not work for POP3 or IMAP4 messaging clients. These clients must connect
to a Client Access server in the same Active Directory site as the user's Mailbox server.
Planning Client Connectivity for Client Access Server

Exchange Server 2013 supports different types of
clients, although client support has changed from
the prior version. The most significant change is
that Microsoft Office Outlook 2003 is no longer
supported as Exchange client software. In
addition, email clients on the Mac operating
systems that require Distributed Authoring and
Versioning (DAV), such as Entourage 2008 for
Mac RTM and Entourage 2004, are not supported.
In Exchange Server 2013, the following clients are
supported natively:
Outlook 2013
Outlook 2010 SP1 with the April 2012 Cumulative Update
Outlook 2007 SP3 with the July 2012 Cumulative Update
Entourage 2008 for Mac, Web Services Edition
Outlook for Mac 2011
You also can connect to the Exchange Server 2013 Client Access server from email applications that are
using POP3 and IMAP4 protocols. These protocols are disabled by default, so you must enable and
configure them before connecting clients. However, you cannot achieve full Exchange Server functionality
with these protocols, so we recommend that you use the natively supported clients listed above.
Clients also can connect to the Exchange Server by using the Microsoft Exchange ActiveSync protocol.
Clients that are using ActiveSync are predominantly mobile platforms, such as Windows Phone 7 and
newer clients. ActiveSync clients also use HTTPS to connect to Client Access server, so no additional
configuration is needed on the Client Access server side, except for configuring ActiveSync policies, if
needed.
Note: Mail application in Windows 8 also uses ActiveSync protocol to connect to the
Exchange Server.
Lesson 2
Configuring the Client Access Server Role
After you deploy a Client Access server in your Exchange infrastructure, you must configure options to
optimize its settings to meet your needs. You should configure namespaces and certificates, as well as
security and authentication options. Because the Client Access server is communicating with servers and
clients on the Internet, you should pay special attention when configuring this aspect. In this lesson, you
will see how to configure the Client Access server role.
Lesson Objectives
Configure Client Access server options.
Configure Namespaces on the Client Access server.
Configure Certificates on the Client Access server.
Secure the Client Access server.
Configure Authentication on the Client Access server.
Configure the Client Access server for Internet access.
Configure POP3 and IMAP4 Client Access.
Configuring Client Access Server Options

After you initially deploy a Client Access server
role, there are several options that you should
configure before you place the Client Access
server in production. You can configure the Client
Access server from the Exchange Management
Shell, or by using the Exchange Administration
Center (EAC). In the EAC, you can configure
options in the following categories on the Client
Access server:
Virtual Directory settings. These setting are

used to configure each of virtual directories
that the Client Access server hosts on IIS. For
each virtual directory, you can configure general settings and authentication options.
Certificates. We recommend highly that organizations deploy a public or internally published

certificate to the Client Access server, and replace any self-signed certificates. The Certificates pane
in the EAC allows you to manage certificates and create new certificate requests.
Mobile device settings. The Client Access server also manages options for mobile devices. You can
configure device access rules and manage mobile devices in quarantine. You also can manage
mobile-device mailbox policies.
Mail flow. Administrators can use this node in the EAC to manage the transport component that
resides on the Client Access server. Managing the transport component includes configuring delivery
reports, accepted domains, and send/receive connectors.
Antimalware protection. Because the Client Access server includes malware filtering, the EAC allows
you to configure the options for malware filtering.
Outlook Anywhere options. You can configure options for external and internal host name and
authentication.
Configuring Namespaces on a Client Access Server

Before deploying Exchange Server 2013, you must
consider how you will implement your external
namespaces. A namespace is a logical structure
represented by a DNS domain name, such as
adatum.com. The decisions you make about your
DNS namespace affect the following:
DNS configurations
Digital certificates
Client configurations
Selecting a Namespace Model
Align your namespaces with your site configuration. In particular, consider implementing a separate
namespace for each site that contains an Internet-facing Client Access server. You can configure Exchange
Server 2013 according to one of the following organizational models:
Centralized data center. In this scenario, all Exchange servers are located within one physical site
with a single namespace, such as mail.adatum.com. With this model, there are few DNS records to
configure, fewer certificates to manage, and only one URL for client computers. However, this model
does not support site resilience through using multiple data centers.
Single namespace with proxy sites. Only one site contains an Internet-facing Client Access server.
Consequently, this model uses only one namespace. With this model, you must configure fewer DNS
records and manage fewer certificates, and client computers use only one external URL. However,
because many sites might not contain an Internet-facing Client Access server, many users will access
their mailboxes using a proxy.
Single namespace and multiple sites. Each site may have an Internet-facing Client Access server,
or only one site may contain Internet-facing Client Access servers. In this model, the sites use one
namespace. As a reminder, because there is a single namespace, DNS and certificates are easier to
manage, and client computers use a single external URL.
Regional namespaces. This model consists of multiple physical sites and multiple namespaces.
For example, a site located in Seattle might have the namespace mail.usa.adatum.com, while a
Vancouver, British Columbia, site might have the namespace mail.canada.adatum.com. This model
reduces proxying, but there are more DNS records and certificates to manage. In addition, you must
configure client computers with the appropriate external URL.
Multiple forests. This model consists of multiple forests that have multiple namespaces. An
organization that uses this model could be made up of two partner companies. Namespaces might
include mail.usa.adatum.com and mail.europe.contoso.com.
Configuring Certificates on the Client Access Server

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 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
Certificate Authority (CA).
Identifying the source of the certificates is one of the most important considerations when planning the
use of certificates. Exchange Server 2013 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, which are
described below.
Using a Public CA provides the following benefits:
Client computers internally and on the Internet 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.
The primary disadvantage of using a public CA is that certificates issued by public CAs are more expensive
than self-signed certificates or certificates issued by internal CAs.
Companies that choose to use an internal CA to deploy certificates to the Exchange Server will experience
the following benefits:
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.
Internally issued certificates also have some disadvantages, including:
Implementing an internal CA can be complicated, and the complexity can introduce security
problems if incorrectly managed.
Although certificates issued by internal CAs are free, the cost of implementing and managing a CA
implementation can be higher than buying certificates from a public CA.
Client computers that are not members of an internal Active Directory domain do not automatically
trust the root CA. Therefore, you must add certificates for the trusted root to the client machines,
where necessary.
Self-signed certificates can be deployed without any Public Key Infrastructure (PKI). When you install
Exchange 2013, a self-signed certificate is automatically created for each Exchange Server computer.
However, there is no centralized revocation list. 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.
In an Exchange Server 2013 environment, you can use the self-signed certificates for internal
communication. You also can use these certificates to secure client connections to Client Access servers
in test or evaluation scenarios. However, because none of the client computers trusts this certificate, we
do not recommend this solution for a production environment. Instead, 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 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 plan to enable Federated Sharing, you must obtain a certificate for your
Internet-accessible Client Access servers from a public trusted CA.
Certificates on Mailbox Server Role
In Exchange Server 2013, the Mailbox Server role also comes with self-signed certificates preinstalled. By
default, HTTP, Microsoft Exchange ActiveSync, POP3, and IMAP4 communication between and among the
Mailbox servers and Client Access server, domain controllers, and global catalog servers is encrypted by
using SSL. However, because clients are not connecting directly to the Mailbox server, it is not accessible
from the Internet, it is not necessary to replace these certificates with public certificate. You can choose to
replace a certificate on the Mailbox server role with internally issued certificates, but it is not mandatory.
Planning the Certificate Names
To make sure that clients can 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.adatum.com/owa, and they connect to the IMAP4 server using a name such as
IMAP.adatum.com, you must make sure that the certificates you use support both server names. In
addition, if you enable Autodiscover access from the Internet, your certificate also must support a name
such as Autodiscover.adatum.com. Autodiscover is used to configure Outlook and mobile device profile
settings automatically.
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 also may 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 *.contoso.com, and
use that certificate for client connections.
Not all clients support wildcard certificates. Deploying wildcard certificates is 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 host names for the organization also are compromised.
Demonstration: Creating a Certificate Request on a Client Access Server

Demonstration Steps
1.
Open Exchange Admin Center (EAC) on LON-CAS1, and sign in as Adatum\Administrator.
2.
Click certificates in the feature pane.
3.
Start the wizard to create a new Exchange certificate.
4.
Provide mail.adatum.com for the friendly name.
5.
Provide mail.adatum.com as the value for web services.
6.
Fill in the following fields as follows:
7.
a.
Organization name: A.Datum
b.
Department name: IT
c.
Country/Region name: United States
d.
City/Locality: Seattle
e.
State/Province: WA
Save the request to \\lon-cas1\C$\windows\temp\certreq.req.
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 make sure 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 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. Make sure that
Client Access server virtual directories in IIS are configured to require SSL.
2.
Secure the following virtual directories:

o
Autodiscover
Exchange Control Panel (ECP)
Exchange Web Services (EWS)
Microsoft-Server-ActiveSync
Offline Address Book (OAB)
Outlook Web App (OWA)
Windows PowerShell
By default, all of these virtual folders are configured to require SSL, after the Exchange Server Client
Access server role is installed. We recommend that you do not change this.
Configuring Secure Authentication
Exchange Server 2013 provides several authentication options for clients communicating with the Client
Access server. If the server has multiple authentication options enabled, Exchange Server 2013 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. This 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 logged-on users user name and
password. 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.
Digest authentication. Digest authentication secures the password by transmitting it as a hash value
over the network.
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 user credentials are never automatically passed over Basic authentication.
Forms-Based Authentication
Forms-based authentication is available only for Outlook Web App and EAC. 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 inactive session time-out is
valuable because it protects user accounts from unauthorized access if users leave their session logged on
while they are away from their computers.
The time that elapses 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.
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 the way that these credentials are transmitted in basic
authentication. However, forms-based authentication requires the use of SSL, which encrypts the user
credentials as they are transmitted over the network.
Forms-based authentication is enabled by default for both Outlook Web App and EAC.
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 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 that all connections on
your internal network be secure, you can configure the firewall to decrypt the SSL traffic, but not
re-encrypt it before sending the traffic to the Client Access server. This means that the Client Access
server resources are not used to perform SSL decryption and encryption.
If you use Forefront Threat Management Gateway 2010 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 in to the internal network.
Note: Threat Management Gateway 2010 is not fully supported for publishing Exchange
Server 2013 services. However, you can use the publishing wizard for Exchange Server 2010 to
publish Exchange Server 2013, but additional manual configuration is needed after that.
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 also should use the same name that is 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 must 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 hosts the Internet DNS
zone for your organization. If you are using different host names for each Client Access server, then
you must 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 Exchange Servers in specific sites accessible from the Internet, you should not
configure an external URL. All client requests to that server can be used as a proxy from an Internetaccessible 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.
o
Configure a unique external URL for the Client Access servers that are accessible from the
Internet.
Ensure that the host records for each site are added to the appropriate DNS zone.
Configure the firewalls and SSL certificates for each site.
Configuring POP3 and IMAP4 Client Access

By default, Exchange Server 2013 supports POP3
and IMAP4 client connections, but these 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.
You can use the services console to do this, or you
can use Exchange Management Shell.
To use Exchange Management Shell, on the
computer running the Client Access server role,
you should run the following cmdlets:
Set-service msExchangePOP3 -startuptype automatic

Start-service msExchangePOP3
On the computer running the Mailbox server role, you should run the following cmdlets:
Set-service msExchangePOP34BE -startuptype automatic
Start-service msExchangePOP3BE
Configuration Options
If you choose to enable POP3 or IMAP4 access, you can configure the following settings:
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

including basic authentication, Integrated Windows authentication, and secure logon requiring TLS.
The default setting is secure logon.
Connection. 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 backend server).
Retrieval. Enables the configuration of the message formats used for these protocols, and enables you
to configure how clients 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.
Lesson 3
Managing Client Access Services

The Client Access servers in Exchange Server 2013 provide several services for Office Outlook clients.
These services are usually enabled by default for Outlook clients on the internal network, but you may
need to modify some of the settings. In addition, you can make some of these services available to
Outlook clients that connect to the Exchange Servers from outside the deployment. In this case, you
must enable these features and make sure that they are configured correctly.
Lesson Objectives
Describe the services provided by the Client Access server.
Describe Autodiscover.
Configure and manage Autodiscover.
Describe the Availability service.
Describe MailTips.
Configure MailTips.
Services Provided by the Client Access Server

In Exchange 2013, the Client Access server role
provides critical services for all messaging clients,
including Office Outlook clients. The following is
a list of services that the Client Access server role
provides:
Autodiscover. This service configures client

computers that are running Outlook 2007 or
newer versions, or supported mobile devices.
The Autodiscover process configures the
Outlook client profile, including the Mailbox
server, Availability service, and offline address
book (OAB) download locations.
Availability. This service is used to make free/busy information available for Outlook 2007 (and newer)
versions, 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. This feature provides notifications for users regarding potential issues with sending a
message, before they send the message. MailTips are supported in Outlook 2010 or newer versions.
Offline Address Book download. The Client Access server makes OAB available through a Web service.
Only Microsoft Office Outlook 2007 or newer clients are capable of retrieving OABs from a web
service.
EAC. The EAC is a webbased management interface that can be used to manage Exchange Server.
Exchange Web Services. Exchange Web Services enables client applications to communicate with the
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 applications.
Outlook Anywhere. Outlook Anywhere enables Outlook 2007 or newer-version 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 Autodiscover?
The Autodiscover service in Exchange Server 2013
simplifies client configuration in Office Outlook
2007, 2010, and 2013. Autodiscover provides
configuration information that Outlook requires
to create a configuration profile for the client.
Outlook clients can also use the Autodiscover
service to repair Exchange Server connection
settings, or if the user mailbox is moved to a
different server. The Autodiscover service provides
profile settings to Outlook 2007, 2010, and 2013
clients and supported mobile devices based on
the users email address and password.
Note: Providing only an email address and the password for automatic configuration with
Autodiscover, will work only when the users email address is equal to users UPN. If that is not
the case, the user will have to provide correct user name and domain name.
As part of creating the profile, Autodiscover provides information for the client to locate various web
services, such as the Availability service, UM settings, and offline address books (OABs).
How Autodiscover Works

Outlook client connects to Exchange Server 2013 in the following manner:
1.
When you install the Client Access server role, a Service Connection Point (SCP) is configured
automatically in AD DS for the Client Access server. The SCP helps Outlook clients find the Client
Access server closest to their AD DS site. Each Client Access server registers its SCP in AD DS. This SCP
includes two pieces of information: the Autodiscover URI and the Autodiscover site scope parameter.
The Autodiscover uniform resource identifier (URI) and the Autodiscover site scope parameter. The
site scope parameter specifies one or more of the AD DS sites for which the specific Client Access
server is responsible. By leveraging site scope parameter, you can optimize Client Access server
coverage if you have multiple AD DS sites with Outlook clients. SCP is used only by clients that are
domain joined and connected to internal network. Clients perform a Lightweight Directory Access
Protocol (LDAP) request to AD DS to obtain the SCP information.
2.
When Outlook 2007 or a newer version start for the first time on a domain-joined computer, Outlook
retrieves the user name or the users email address and password, and then performs the query to
AD DS to locate the SCP. If computer is not domain joined, you have to manually type your email
address (or user name) and password.
3.
If Outlook is running on a domain-joined computer, Outlook then uses the information from SCP to
locate the Autodiscover service on an Exchange Server 2013 computer with the Client Access server
role installed. If you are accessing an 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 Client Access server, where the client
performs a request to download configuration information.
4.
The request that the client makes to the Client Access server is actually the HTTP POSTS command to
the Autodiscover server endpoint, which requests the configuration information for the SMTP address
that client sends in the request.
5.
The Client Access server provides the Autodiscover information to the client. The information includes
the locations for the Availability Web Service, the Offline Address Book, ECP, OWA, and UM.
6.
Outlook downloads and applies the required configuration information from the Autodiscover
service.
7.
Outlook then uses the appropriate configuration settings to connect to Exchange Server 2013.
The place where Autodiscover information is generated may differ depending on which Exchange Server
version is the client mailbox. When the client connects to the Client Access server 2013 with an Autodiscover
request, either because SCP directs it there or it is sent by using DNS, Client Access server will do one of
the following:
If the client mailbox is on Exchange Server 2007, Client Access Server 2013 will send the request to
the Mailbox Server 2013, which will generate Autodiscover information for the client.
If the client mailbox is on Exchange Server 2010, Client Access Server 2013 proxies the request to
Client Access Server 2010 and then returns the response back to the client.
Supported Clients and Protocols

Autodiscover supports the following clients and protocols:
Client
Protocol
Office Outlook
RPC over HTTP
Outlook Anywhere
RPC over HTTP
Exchange ActiveSync
Exchange ActiveSync over HTTP
Entourage 2008, Exchange Web Services Edition
Exchange Web Services (HTTPS)
Note: Exchange Server 2013 supports Autodiscover for Exchange ActiveSync Service clients.
However, the Exchange ActiveSync Service client must be running Windows Phone 7 or newer
versions to support this feature.
Configuring and Managing Autodiscover

By default, the Autodiscover settings for
internal clients are automatically configured, and
Outlook 2007 or newer clients are automatically
configured to use the appropriate services. In
some cases, you may want to modify the
default settings. For external clients, you must
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:
Set-ClientAccessServer. Configures the Autodiscover SCP.
New-AutodiscoverVirtualDirectory. Creates a new Autodiscover virtual directory.
Remove-AutodiscoverVirtualDirectory. Removes an Autodiscover virtual directory.
Set-OutlookProvider. Configures an Office Outlook provider.
Get-OutlookProvider. Locates an Office Outlook provider or providers in the virtual directory.
Generally, you should not modify Autodiscover settings in default Exchange configuration. However, there
are some scenarios where you might need to do this. For example, if you have a hardware load balancer
with a virtual IP pointing to an address such as mail.adatum.com, you can change the internal URI to use
mail.adatum.com rather than the Client Access server names.
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 where connectivity is poor between all of your sites and you would like
Outlook clients to utilize Autodiscover services on a Client Access server to which the clients have good
connectivity. In another scenario, if you have acceptable connectivity between your sites, you still may
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 the 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
To enable external clients 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 AD DS. 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://<e-maildomain/autodiscover/autodiscover.xml
https://autodiscover.e-maildomain/autodiscover/autodiscover.xml
To enable Autodiscover, you must configure a DNS record on the external 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 a reverse proxy server, such as Forefront TMG, that is used to publish
Using the Test E-mail AutoConfiguration Feature in Outlook 2007 and Newer
Versions
You can use the Test E-mail AutoConfiguration feature in Outlook to test whether Autodiscover is working
correctly. To perform this test, hold the Ctrl button and click on the Outlook icon in the notification area,
and then click Test E-mail AutoConfiguration.
You also can use the Exchange Management Shell cmdlet Test OutlookWebServices to test the
Autodiscover settings on a Client Access server. For a very useful tool for testing Autodiscover
functionality from outside, go to https://www.testexchangeconnectivity.com/. This is an official Microsoft
testing tool that you can use to test Autodiscover for ActiveSync and Outlook connectivity. It can be used for
an on-premises Exchange Server, and can also be used to test service availability in Microsoft Office 365.
What Is the Availability Service?

Exchange Server 2013 uses the Availability
service to make free/busy information available
to Outlook 2007 or newer clients, and to Outlook
Web App clients. The Availability service replaces
the public folder used to store free/busy
information in previous Exchange Server versions.
In Outlook, the component Scheduling Assistant
allows you to see attendees free time slots in their
calendars without attendees actually sharing their
calendars with you.
The Scheduling Assistant uses the Availability
service to:
Retrieve live free/busy information for Exchange Server 2007, Exchange Server 2010, or Exchange
Server 2013 mailboxes.
Retrieve live free/busy information from other Exchange Server 2007, Exchange Server 2010, or
Exchange Server 2013 organizations.
View the working hours of attendees.
Show meeting-time suggestions.
Note: Only Outlook 2007 or newer versions and the Outlook Web App use the Availability
service.
How the Availability Service Works

The Availability service provides free/busy information through the following process:
1.
When you start the Scheduling Assistant in Outlook 2007 or newer clients, or in the Outlook Web App
client, 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 servers 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 one where Client Access server is located, the request is
proxied to the Mailbox server in that site. If another site runs Exchange Server 2010, then the request
is sent by proxy to a Client Access server 2010 in the site where the user mailbox is located. The
Availability service combines the free/busy information for all invited users, and presents it to the
Outlook 2007 or Outlook Web App client.
You also can configure the Client Access server to query the Availability service in a different Exchange
Server 2013 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 require
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 or newer clients.
The Availability service is located at the following website: 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 2013 analyzes the message, including
the list of recipients to which it is addressed. If it
detects a potential problem, it notifies the user
through 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 nondelivery reports (NDRs).
Types of MailTips
Exchange Server 2013 provides several default MailTips, including:
Mailbox Full. This MailTip displays if the sender adds a recipient whose mailbox is full, and if the
recipients organization has implemented a prohibit-receive restriction for mailboxes over a specified
size.
Automatic Replies. This MailTip displays the first 250 characters of the automatic reply configured by
the recipient.
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 the senders organization. By default, Exchange Server displays this
MailTip for messages to distribution groups that have more than 25 members.
You also can configure custom MailTips in the Exchange Management Shell. You can assign a custom
MailTip 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 in which 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.
Note: MailTips are available only in Exchange Server 2010 and 2013 Outlook Web App, or
when using Microsoft Office Outlook 2010 or newer versions. MailTips are not available in
Outlook 2007.
How MailTips Work
MailTips are implemented as a Web service in Exchange Server 2013. When a sender composes a
message, the client software makes an Exchange Web service call to the Exchange Server 2013 server with
the Client Access server role installed, to get the MailTips list. The Exchange Server 2013 server responds
with the list of MailTips that apply to that message, and the client software displays the MailTips to the
sender.
The senders following actions 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, if that message 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:
3.
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.
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 structure of the offline address book (OAB) was redesigned in Exchange Server
2013 to include some of the information required by MailTips. 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. This MailTip 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: Configuring MailTips

Demonstration Steps
1.
In the EAC on LON-CAS1, click recipients in the feature pane.
2.
Select to manage Mailboxes.
3.
Open properties for April Reagan.
4.
Configure MailTip for this user with the text: This person is on extended leave.
5.
Log on to Outlook Web App as ADatum\Don.
6.
Create a new message to April, and ensure that MailTip appears.
Lab: Deploying and Configuring a Client Access Server

Role
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 make sure that the deployment is as secure as possible, you must secure the Client
Access server, and you also must configure a certificate on the server that will support the messaging
client connections. In addition, you have to verify options on the Client Access server, and configure
Mailtips for a few users.
Objectives
Configure certificates on the Client Access server.
Configure MailTips.
Lab Setup
Virtual machines
20341B-LON-DC1
20341B-LON-CAS1
20341B-LON-MBX1
User Name
Password
Pa$$w0rd
1.
2.
3.
4.
Log on using the following credentials:
5.
a.
b.
Password: Pa$$w0rd
Exercise 1: Configuring Certificates for the Client Access Server

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 must make sure that Outlook clients can still connect to the
server.

1.
Make a certificate request on Exchange Server.
2.
Issue a certificate from an internal CA.
3.
Assign a certificate to Exchange services.
Task 1: Make a certificate request on Exchange Server

1.
On LON-CAS1, open Windows Internet Explorer, type https://lon-cas1.adatum.com/ecp, and

press Enter.
2.
Sign in as Adatum\administrator with the password Pa$$w0rd.
3.
Click the servers node, click on Certificates and start the wizard for creating a certificate request.
4.
Provide mail.adatum.com as a friendly name for a certificate.
5.
Do not use wildcard certificates.
6.
Provide the name mail.adatum.com for all values that are not defined.
7.
Ensure that the certificate request contains the following domain names: mail.adatum.com, loncas1.adatum.com, autodiscover.adatum.com, LON-CAS1, and Adatum.com.
8.
Fill in additional data as follows:
9.
a.
b.
Department name: IT
c.
d.
e.
State/Province: WA
Save certificate request to \\lon-cas1\C$\windows\temp\certreq.req.
Task 2: Issue a certificate from an internal CA

1.
On LON-DC1, restart the certificate service.
2.
On LON-CAS1, open File Explorer and navigate to C:\windows\temp.
3.
Open the certificate request file with Notepad, and copy all content to the clipboard.
4.
Connect to http://lon-dc1.adatum.com/certsrv as Administrator with the password Pa$$w0rd.
5.
Choose to perform an advanced certificate request.
6.
Paste the certificate request content (from step 2) in to the appropriate field, and select Web Server
template.
7.
Save the certificate.
8.
Open File Explorer, and create a new folder called cert on the C:\ drive. Share the folder, and give
Read permission to Everyone.
9.
Copy the certificate file to the cert folder.
Task 3: Assign a certificate to Exchange services
1.
On LON-CAS1, open the EAC.
2.
Import the mail.adatum.com Exchange certificate that you issued in Task 2. Import the certificate to
LON-CAS1.Adatum.com.
3.
Assign the certificate to IIS service.
Results: After completing this exercise, the students will have a certificate installed on the Exchange
Server Client Access server.
Exercise 2: Configuring Client Access Services Options

Scenario
To prepare the Client Access server, you need to perform several configuration tasks, such as
configuring the external access domain and POP3 service. The external email domain name should be
mail.adatum.com. You need to make sure that POP3 users can connect securely, and that connection
limits should be applied as well as proper message formatting You also need to verify authentication
options for virtual directories on the Client Access server.
1.
2.
Verify authentication options on Client Access server.
Task 1: Configure Client Access server options

1.
In the EAC, set the external domain name to mail.adatum.com for LON-CAS1.
2.
Open LON-CAS1 settings, and set the following for POP3 users:
a.
Maximum connections: 100
b.
Maximum connections from a single IP address: 20
c.
Maximum connections from a single user: 2
Task 2: Verify authentication options on Client Access server

1.
On LON-CAS1 in EAC, navigate to servers, and then click virtual directories.
2.
Verify authentication options for the following virtual directories:
3.
a.
Autodiscover
b.
ecp
c.
PowerShell
d.
Microsoft-Server-ActiveSync
e.
OAB
Do not make any changes.
Results: After completing this exercise, the students will have configured Client Access server.
Exercise 3: Configuring Custom MailTips

Scenario
To reduce the number of users who require support, A. Datum is evaluating implementation of MailTips.
You have been asked to configure some test deployments that implement MailTips, and you must verify
that MailTips can be enabled in multiple languages.
1.
Configure MailTips.
2.
Test MailTips.
3.
Task 1: Configure MailTips

1.
On LON-CAS1, open EAC, and navigate to Mailboxes.
2.
Select April Reagan mailbox object.
3.
Set the MailTip text for April to be Test e-mail tip for April.
4.
Open Exchange Management Shell, and set an email tip for Aidan by executing the following:
Set-Mailbox Identity Aidan Mailtip this is english mail tip MailtipTranslation

(FR: Cest la lague francaise)
Task 2: Test MailTips

1.
Open Internet Explorer, and type https://lon-cas1.adatum.com/owa
2.
Sign in as Adatum\Don with the password Pa$$w0rd.
3.
Accept defaults for time and language.
4.
Open new mail window, and type April Reagan in the To text box.
5.
Verify that the email tip appears.
6.
Open new mail window and type Aidan Delaney in the To text box.
7.
Verify that email tip appears in English.
8.
Sign out from Outlook Web App, and sign in as Adatum\Amr.
9.
Select to Francais (France) as the OWA language.
10. Open a new mail window, and type Aidan Delaney in the To text box.
11. Verify that the e-mail tip appears in French.
following steps:
1.
2.
3.
4.
Repeat steps 2 to 3 for 20341B-LON-CAS1 and 20341B-LON-MBX1.
5.
6.
7.
8.
a.
b.
Password: Pa$$w0rd
repeat steps 5 to 7 for 20341B-LON-CAS1, 20341B-LON-TMG, and 20341B-LON-CL1.

Best Practice
If possible, make the Client Access server highly available or redundant.
Provide a public certificate for Client Access server that is exposed to the Internet to avoid trust issues.
Do not place Client Access server in the perimeter network. Use an application-layer firewall and
reverse proxy to publish it securely.
Make sure that the Client Access server has a fast and reliable connection to the Mailbox server and
the AD DS domain controllers.
Review Question
Question: What is the main difference between the Client Access server role in Exchange
Server 2010 and Exchange Server 2013?

5-1
Module 5
Planning and Configuring Messaging Client Connectivity
Contents:
Module Overview
5-1
Lesson 1: Client Connectivity to the Client Access Server
5-2
Lesson 2: Configuring Outlook Web App
5-7
Lesson 3: Planning and Configuring Mobile Messaging
5-14
Lesson 4: Configuring Secure Internet Access for Client Access Server
5-23
Lab: Planning and Configuring Messaging Client Connectivity
5-32
5-40
Module Overview
Planning and configuring client connections is one of the most important tasks that you must perform
when you implement a Microsoft Exchange Server implementation. Microsoft Exchange Server 2013
supports various types of clients and connections from desktop and laptop computers, and from mobile
devices; it also supports web-based access for many Internet browsers. In this module, we focus on
planning and configuring the services that provide access to Microsoft Exchange clients. Specifically, this
module describes Microsoft Outlook Web App and mobile messaging and how to securely access the
Internet from Client Access server.
Objectives
Describe the client services Exchange Server 2013 provides.
Configure Outlook Web App.
Plan and configure mobile messaging.
Configure secure Internet access for Client Access server.
Lesson 1
Client Connectivity to the Client Access Server
5-2 Planning and Configuring Messaging Client Connectivity
The primary function of the Client Access server role in Exchange Server 2013 is to accept, authenticate,
and proxy client connections from both an internal network and the Internet. The Client Access server is
able to accept, authenticate, and proxy client connections by providing several services to clients, such as
Outlook Web App, Outlook Anywhere, and Exchange ActiveSync. Familiarity with these technologies is
essential when you plan and configure client connectivity.
Lesson Objectives
Describe Outlook Web App.
Describe Outlook Anywhere.
Describe Exchange ActiveSync.
Describe Outlook Web App Light.
Describe how you can connect non-Outlook clients to Client Access server.
What Is Outlook Web App?

Outlook Web App is an Exchange Server 2013
service that enables users to access their
mailboxes through a web browser. The feature set
in Outlook Web App closely mimics the features
available in Microsoft Outlook 2013, and provides
features that are not available in previous Outlook
versions. In some cases, for example, when you do
not have a locally installed email client, it may be
possible to use Outlook Web App in place of
Outlook 2010 or Outlook 2013.
Features of Outlook Web App

Outlook Web App provides most of the features
that are available when using the full Outlook 2013 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 is redesigned in Exchange Server 2013 to include features such as chat, text messaging,
enhanced calendar and people parts, mobile phone integration, and enhanced conversation view.
Outlook Web App now also includes external applications such as Bing Maps, Suggested Appointments,
and Action Items. These applications integrate with Outlook 2013 and Outlook Web App, and they extend
the information and functionality of messages and calendar items. In addition, Outlook Web App now
provides offline access capability.
The most important new features in Outlook Web App, compared to Outlook Web App in Microsoft
Exchange Server 2010, include:
The integration of Web Apps in the Outlook Web App interface.
Enhancements to the People feature. It is now possible to link multiple entries for the same person
and view the information in a single contact card. You can also connect to a users LinkedIn account.
Improvements to the Calendar which that enable users to see multiple calendars in one or a merged
view.
Enhancements to the interface used on tablets and smartphones.
In Exchange Server 2013, these features are accessible from an expanded set of web browsers, including
Microsoft Internet Explorer 9.0 or newer, Firefox, Safari, and Google Chrome.
Benefits of Outlook Web App

Outlook Web App provides many important benefits for an organization, including:
All communication between the Outlook Web App client and the Client Access server is sent using
HTTP. You can easily secure this information by using the Secure Sockets Layer (SSL) protocol. This
means that you can easily configure firewalls or reverse proxies to enable Internet access to Outlook
Web App because only a single port is required.
Outlook Web App does not require you to 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 2013 also provides access to some features that are available
only through Outlook Web App or Outlook 2010 or later. For example, features such as the archive
mailbox or conversation view can be accessed through Outlook Web App without deploying Outlook
2010 or later.
What Is Outlook Anywhere?

Outlook Anywhere is a feature that has existed
in Exchange Server since Exchange Server 2003
Service Pack 2. In the older Exchange Server
versions, this feature was referred to as remote
procedure call (RPC) over HTTP(S).
By using Outlook Anywhere, an Office Outlook
2007 or newer client can use RPCs encapsulated
in an HTTPS packet to connect to a server that
is running Exchange Server 2013 Client Access
Server. The Windows RPC-over-HTTP proxy
component, which Outlook Anywhere clients use
to connect, wraps RPCs with an HTTP layer. This
enables traffic to pass through network firewalls without requiring RPC ports to be opened.
Configuring Outlook Anywhere in Exchange Server 2013
Outlook Anywhere functionality is enabled by default in Exchange Server 2013. This is a change from
previous versions of Exchange, which usually only external clients used Outlook Anywhere. In Exchange
Server 2013 internal clients also connect by using this method.
There is no need to enable or deploy Outlook Anywhere, but it must be properly configured. You should
install an appropriate SSL certificate on your Client Access server role, and configure the external domain
name system (DNS) name to be used when connecting from the Internet.
Outlook Anywhere has several benefits, including:
Users can access Exchange servers from the Internet, the same way they access it from an internal
network.
The same URL and namespace can be used for Outlook Anywhere, Outlook Web App, and
ActiveSync.
The same certificate is used for Outlook Anywhere, Outlook Web App, and ActiveSync.
The user is always authenticated within Outlook client and cannot access data if unauthenticated.
There is no need to use a virtual private network (VPN) to access Exchange servers across the Internet.
If Outlook Web App and Exchange ActiveSync are deployed with SSL, there is no need to open any
additional ports for Outlook Anywhere.
Although the configuration of Outlook Anywhere is a fairly simple process, you should validate its
functionality before placing it into production. You can test end-to-end client connectivity for Outlook
Anywhere and TCP-based connections by using the Test-OutlookConnectivity PowerShell cmdlet.
You also can use the Microsoft Exchange Connectivity Analyzer web-based application.
What Is Exchange ActiveSync?
Exchange ActiveSync is an XML-based protocol

that enables mobile devices to communicate over
HTTP (or HTTPS) with an Exchange Server. The
protocol is designed for the synchronization of
email, contacts, calendar, tasks, and notes from
an Exchange server to a mobile device with a
supported mobile platform (also known as mobile
operating system). ActiveSync protocol also
provides mobile-device management and policy
controls. The Exchange ActiveSync
communication process is optimized to function
over both high-latency and low-bandwidth
networks, such as General Packet Radio Service (GPRS) or EDGE, but it can also benefit from high speed
networks such as 3G or LTE.
By default, Exchange ActiveSync is available for all users after you install a Client Access server. ActiveSync
has evolved in many versions over the last 12 years. ActiveSync is implemented in Exchange Server 2013
and the Microsoft mobile operating systems Windows Phone 7 and Windows Phone 8.
The connection established by using the ActiveSync protocol is very similar to Outlook Anywhere. One
difference between Exchange ActiveSync and Outlook Anywhere, apart from the client connection type,
is the device that is used to view the email. With Outlook Anywhere, the end device is a mobile computer,
which can be a member of the internal Active Directory Domain Services (AD DS) and can be managed
as an AD DS member. With Exchange ActiveSync, the end device is a mobile client, which cannot be a
member of the local domain.
Note: Windows 8 is not only a mobile platform, but also a desktop operating system with a
built-in email application that uses ActiveSync to connect to the Exchange Server.
Microsoft has licensed the ActiveSync protocol to most mobile platform vendors, such as Google,
Apple, and Symbian. Because of this licensing arrangement, most of todays mobile platforms support
ActiveSync; however, not all platforms support every ActiveSync feature. Each mobile platform vendor
can choose the functionalities that it will implement in its mobile platform.
What Is Outlook Web App Light?

Outlook Web App Light is a smaller version of
Outlook Web App. You can use it for mobile
platforms that either do not support Exchange
ActiveSync, or on which ActiveSync is not enabled
on the Exchange Server side. This is a lightweight
web-based email client intended for use from
HTML-compatible mobile browsers on mobile
devices such as smart phones and tablets. It uses a
very simple HTML4 based UI which works in most
Internet browsers in existence.
Outlook Web App Light is fully based on the Outlook Web App architecture. Because it works within
Outlook Web App, it uses all of the segmentation flags that exist in Outlook Web App, and some subset
of Outlook Web App settings.
Outlook Web App Light enables users to:
Access email, calendar, contacts, tasks, and the global address list (GAL).
Access email subfolders.
Compose, reply to, and forward email messages.
Create calendar, contact, and task items.
Handle meeting requests.
Set the time zone and automatic-reply messages for when users are out of the office and not
available to respond to email.
Outlook Web App Light uses the same public session time-out values that Outlook Web App uses. It is
important to note that there is no logoff functionality in Mobile Outlook Web App, because the system
does not rely on the fact that the browser will forget the stored password after the default time-out value.
You can access the Outlook Web App light version by accessing the Outlook Web App URL with mobile
browser or browser that does not support the full version of Outlook Web App.
Connecting Non-Outlook Clients to the Client Access Server

In some scenarios, non-Outlook clients need to
be connected to the Exchange Server. This occurs
in organizations that employ an email client
other than Microsoft Office on client machines.
Exchange Server supports client connections from
non-Outlook clients. The functionality achieved is
not always comparable.
Companies that do not have Outlook deployed on

client machines can alternatively use Outlook Web
App instead of the locally installed client software.
This provides a consistent user experience that is
very similar to the Outlook user experience, but is
not quite as robust. Alternatively, you can connect existing email applications to Exchange using POP3 or
IMAP4 protocols. These protocols are set to be started manually, by default in Exchange installations, but
you can start them by setting corresponding services to automatic state. Be aware that Exchange Server
2013 requires that a POP3 connection be established over a secure channel, so it must be set in email
client software.
If client machines have Windows 8 deployed, you can use an integrated Mail application to connect to the
Exchange Server by using ActiveSync protocol. This also provides a good user experience, although the
Mail application is very simple and provides few options.
Lesson 2
Configuring Outlook Web App
Besides using the Outlook client software, the most common way to access a mailbox on an Exchange
Server is through Outlook Web App. Outlook Web App is a web-based application that provides a fullfeatured client experience for accessing mailbox content. You can access it from both internal and
external networks and have the same user experience. However, you can configure many options for
Outlook Web App to make it more secure and to provide a positive user experience.
Lesson Objectives
Describe configuration options for Outlook Web App.
Describe Outlook Web App policy.
Configure Outlook Web App options and policies.
Describe and use integrated applications in Outlook Web App.
Describe Office Web Apps Server integration.
Describe Outlook Web App offline access.
Enable and use Outlook Web App offline access.
Configuring 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 using the Exchange Administration Center
(EAC) to configure Outlook Web App, you can
perform the following tasks:
Install and configure a SSL server certificate

to enable SSL for all client connections.
Define internal and external URLs for accessing Outlook Web App from an internal network and from
the Internet, respectively.
Set authentication options. You can choose among basic, integrated, digest, and form-based
authentication for Outlook Web App.
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 Internet Information Services (IIS)
website on the Client Access server. In most cases, you will not have to modify the Outlook Web App
virtual directory settings, other than to configure the default website to use a certificate authority
(CA) certificate for SSL, and to set the authentication options.
Configure features available in Outlook Web App. You can enable or disable specific Outlook Web
App features for Exchange Server 2013 Outlook Web App users. You can do this on Outlook Web
App virtual directory level, in which case these settings apply to all users that use OWA. Optionally,
you can configure the same settings in Outlook Web App at the policy level, and then selectively
apply the policy to specific users.
Configure File Access settings. You can configure file access behavior based on the type of computer
being used to access Outlook Web App (private or public). You can also force Web Ready Document
viewing. Optionally you can use the Exchange Management Shell set-OWAVirtualDirectory cmdlet
with the parameters AllowedFileTypes, AllowedMimeTypes, BlockedFileTypes, BlockedMIMETypes,
ForceSaveFileTypes, and ForceSaveMIMETypes.
A full set of options for Outlook Web App is available in Exchange Management Shell. The SetOwaVirtualDirectory cmdlet must be used to define the properties of the OWA virtual directory
on the Client Access Server. Some of the most common switches that you can use with this cmdlet
include:
AllowedFileTypes. The AllowedFileTypes parameter specifies the extensions of file types that the
user can save locally and view from a web browser. If the same extensions are in multiple settings
lists, the most secure setting overrides the less secure settings.
BlockedFileTypes. The BlockedFileTypes parameter specifies a list of extensions of attachments

that are blocked. Attachments that contain these blocked extensions cannot be saved locally or
viewed from a web browser.
ChangePasswordEnabled. The ChangePasswordEnabled parameter controls whether users are

allowed to change their password using the OWA interface.
LogonFormat. The LogonFormat parameter specifies the type of logon format for Outlook Web
App or forms-based authentication that is used on the Outlook Web App sign-in page. Possible
attributes are FullDomain, UserName, or PrincipalName.
IRMEnabled. The IRMEnabled parameter specifies whether the Information Rights Management
(IRM) feature is enabled.
RedirectToOptimalOWAServer. This parameter, when set to $true, causes Outlook Web App to
use the service discovery to find the best Client Access server to use after a user authenticates. If
redirection is disabled, OWA does not redirect clients to the most optimal Client Access server.
You can also manage several Outlook Web App options in the EAC, by navigating to Outlook Web
App virtual directory features.
What Is Outlook Web App Policy?

Outlook Web App policy enables administrators
to set Outlook Web App behavior for a specific
user or users. OWA policy is an object that enables
you to configure a set of options for Outlook Web
App and assign these options to a specific users
mailbox. After you assign an Outlook Web App
policy, all settings from the policy will be applied
for that specific user when he or she uses the
Outlook Web App interface.
The Outlook Web App policy can be configured within the Exchange Administration Center by navigating
to Permissions and then clicking on Outlook Web App Policies tab. By clicking the New button, an
OWA policy is created but not immediately assigned to a mailbox. When creating new Outlook Web App
policy, you can specify the following settings:
Policy name. Enter a descriptive name for the policy.
Communication-management options. Specify whether users will be able to use instant messaging,
text messaging, unified messaging, ActiveSync, and Contacts.
Information-management options. Enable or disable Public Folders, Journaling, Notes, Search

Folders, Inbox Rules, and Recover Deleted Items functionalities.
Security options. Configure junk email filtering, and specify whether users are prevented from
changing their passwords in Outlook Web App.
User-experience options. Set options for Outlook Web App themes, premium client, and email
signature.
Time-management options. Specify whether users can update the Calendar, Tasks, Reminders, and
notifications.
Direct file access and web-ready document-viewing options. Select options for public and private
computers.
Offline Access. Indicate whether the offline Outlook Web App (discussed later in this lesson) can be
used, and on which computers (all or private) it can be employed.
After you set up an Outlook Web App policy, you must assign it to a user mailbox. This can be
accomplished by opening the user mailbox properties, navigating to Mailbox Features > Email
Connectivity, and then selecting the Outlook Web App Mailbox Policy to assign to the user. If you want
to assign an Outlook Web App policy to multiple users simultaneously, use the Exchange Management
Shell cmdlet Set-CASMailbox. For example, if you want to set a policy called External Users Policy to user
AidanD, you should type:
Set-CASMailbox identity AidanD@adatum.com OwaMailboxPolicy:External Users Policy
Demonstration: Configuring Outlook Web App Options and Policy

Demonstration Steps
1.
Sign in to Exchange Administration Center (EAC) on LON-CAS1, as Adatum\Administrator.
2.
Edit settings for Outlook Web App (Default Web Site).
3.
Set the external URL for Outlook Web App virtual directory to be https://mail.adatum.com.
4.
Disable Journaling and Themes functionalities in Outlook Web App.
5.
Disable Direct file access in Public or shared computer.
6.
Create a new Outlook Web App policy.
7.
Name the policy External Users Policy.
8.
Disable options for Instant messaging, Text messaging options, Recover deleted items, and direct file
access.
9.
Apply the policy to the user Adam Barr.
Integrated Applications in Outlook Web App

To enhance the users experience with Outlook
Web App, Microsoft has implemented some
additional applications in the OWA interface.
The purpose of these applications is to recognize
a users needs based on the message content.
By default, the following applications are installed
in the OWA interface:
Bing Maps. This application searches for

addresses in your email messages. If it finds
text that looks like an address, it displays an
additional Bing tab with a link to the address
location on the map, and provides directions
for how to get there. (This is limited to selected countries).
Suggested Appointments. This application looks for phrases in your messages that suggest or
propose meetings. If it finds a valid pattern, the application will offer to create an appointment in
your calendar.
Unsubscribe. This application is activated on messages from subscription message feeds, and enables
you to block the sender or unsubscribe from the source.
Action Items. This application looks for possible task suggestions in your emails. If a task suggestion is
found, the application will create a suggested task for you.
Administrators can use the Exchange Administration Center to manage the applications available to users
in the organization. In the Exchange Administration Center, you should click the organization and then
click on Apps tab. You can disable default applications and add new ones, and you can choose to add
applications from either the Office Store, a URL, or a file.
Demonstration: Using Apps in Outlook Web App

Demonstration Steps
1.
On LON-CL1, open Internet Explorer and sign in to Outlook Web App as Administrator.
2.
Send new email to Aidan Delaney with the following text:
Are you available to meet with me tomorrow at 10:00 AM? Meeting location is Microsoft Corp,
One Microsoft Way, Redmond, WA 98004.
3.
Sign out, and then sign in to LON-CL1 as Aidan.
4.
Open Outlook 2013.
5.
Click on the message from the Administrator.
6.
Verify that the Bing Maps and Suggested Meetings tabs are present in the email body.
What Is Office Web Apps Server Integration?

In previous versions of Exchange Server, such
as Exchange 2010, attachments on email
messages opened either by using a locally
installed application or by using web-ready
document viewing technology (for Microsoft
Office formats). Web-ready document viewing
enables users to open and see the content of
Office documents even if they do not have a
locally installed set of Office applications.
In Exchange Server 2013, Outlook Web App

provides enhanced attachment management. This
includes rich attachment preview functionality and
the ability for users to modify attachments online. For example, if you received Word documents as an
email attachment in Exchange Server 2010, you were able to see it in the Exchange Server 2010 version of
Outlook Web App, but you could not modify its content unless you had Word installed locally.
By implementing the Office Web Apps Server integration with Exchange Server 2013, users who do not
have Office installed locally can now open and modify email attachments by using Office Web Apps such
as Word, Excel, and PowerPoint.
Office Web Apps Server integration is available to all Exchange Online customers. For Exchange deployed
on-premises, you need to deploy Office Web Apps Server to enable this, and then integrate your locally
installed version of Exchange with the Office Web Apps Server. Your locally deployed Office Web Apps
Server must be accessible from the Internet so that both internal and external OWA users can use it when
handling attachments.
To use Office Web Apps Server to render attachments in Outlook Web App, you must specify the Office
Web Apps Server URL. You must use the Set-OrganizationConfig cmdlet to configure the URL.
For example, let us assume that your Office Web Apps Server is available at the following location:
https://Server1.adatum.com/hosting/discovery.
You should type the following cmdlet in the Exchange Management Shell to configure integration with a
locally installed Exchange Server:
Set-OrganizationConfig -WACDiscoveryEndPoint https://office.adatum.com/hosting/discovery
You also can control whether the users on public or private computers can use the Office Web Apps
Server integration when they sign in to Outlook Web App. For example, if you want to enable the Office
Web Apps Server integration on private computers, you can use the following cmdlet:
Set-OwaVirtualDirectory "LON-CAS01\owa (Default Web Site)"
-WacViewingOnPrivateComputersEnabled $true
Using Outlook Web App in Offline Mode

In Exchange Server 2013, Outlook Web App can
work in an offline mode. This means that users can
sign in to Outlook Web App and access mailbox
content even when they are not connected to an
Exchange Server. Everything that the user does in
the mailbox is synchronized with the Exchange
Server as soon as the connection to Exchange is
re-established. This also provides an improved
experience for users who work on a slow or
intermittently connected network because it
enables the user to work faster.
In previous versions of Exchange Server, users
could not use Outlook Web App offline. The only way to use email in offline mode was to configure
an Outlook client to work offline. Users did this by caching the users mailbox in an .ost file on a local
computer. This has changed with Exchange Server 2013 because of its ability to use Outlook Web App
in an offline mode.
Offline Outlook Web App is enabled on a computer-by-computer basis. This means that the user
should enable it on each computer where he or she wants to use this feature. We recommend that offline
Outlook Web App be enabled only on private computers, for security reasons, in part because the user
mailbox is stored on a local computer in browser cache. Internet Explorer will store cached mailbox data
in %systemdrive%\Users\%username%\AppData\Local\Microsoft\Internet Explorer\Indexed DB.
You also can manage this cache from the Internet Explorer option called Cache and databases. When you
open Internet Explorer Options, you should click Settings on the General tab, and then click on Caches
and databases. From here you can delete the cache (and basically disable Outlook Web App Offline) or
change notification settings for cache size.
Administrators can control which users are able to use offline Outlook Web App by implementing
Outlook Web App policies.
The functionality that Offline Outlook Web App provides is most similar to the capabilities provided by
phone clients that run Exchange Active Sync. Part of the mailbox content is cached locally on the
computer, just as it is cached on smartphones.
Users can perform following actions while working offline in Outlook Web App:
Access email stored in the Inbox, Drafts, or other folders (up to 15) viewed within the last three days.
Access Calendar (the previous month up to a year in advance).
Access Contacts.
Send messages and Calendar invitations.
Delete messages.
Receive active reminders (for the last two months).
Accept or decline meeting requests.
Set flags and categorize messages.
Offline Outlook Web App has certain limitations. For example, you cannot access your online archive,
team folders, or tasks. You also cannot perform full-text search in your mailbox. To use Outlook Web App
offline, you should use Internet Explorer 10 or newer, Google Chrome 17 or newer, or Safari 5 or newer.
You can use Exchange Management Shell to specify the computers that will be allowed to use OWA
Offline Access. You should use the Set-OWAVirtualDirectory cmdlet with the AllowOfflineOn switch.
The AllowOfflineOn parameter specifies which computers can use Outlook Web App in Offline mode. The
possible values include PrivateComputersOnly, NoComputers, or AllComputers. The value is set to
AllComputers by default. If you set the value to PrivateComputersOnly, only users who log into
Outlook Web App using the Private option will be able to use Outlook Web App in Offline mode.
Demonstration: Enabling and Using Outlook Web App in Offline Mode

Demonstration Steps
1.
On LON-CL1, sign in to OWA as Adatum\Aidan.
2.
In Outlook Web App options, turn on offline access.
3.
In Hyper-V Manager, temporarily disconnect LON-CL1 from the network.
4.
Open Windows Internet Explorer on LON-CL1, and open the https://lon-cas1.adatum.com

/owa.
5.
Verify that you can access mailbox content.
6.
Send a test email to Administrator while working offline.
7.
Reconnect LON-CL1 to the network.
8.
On LON-CAS1, log on to OWA as Administrator.
9.
Verify that you received an email that Aidan sent from the Outlook Web App offline mode.
Lesson 3
Planning and Configuring Mobile Messaging
Using smartphones and tablets for messaging has become very popular. Many smartphone users use
their devices intensively for email, calendar, tasks, and other purposes. By using the ActiveSync protocol,
Exchange Server 2013 provides a reliable platform for connecting various types of mobile devices. This
protocol not only provides functionality for mobile devices, but also enables administrators to secure and
manage these devices.
Lesson Objectives
Describe how Exchange ActiveSync works.
Describe the supported features in Exchange ActiveSync.
Describe direct push.
Describe remote wipe.
Describe mobile device quarantine.
Manage mobile devices with Exchange ActiveSync policies.
Describe options for mobile device management in the Exchange Server Administration Center.
Manage mobile devices using Outlook Web App.
Describe alternatives for mobile device management.
Discussion: Using Mobile Devices in Business Environments

This discussion focuses on the current use of
mobile devices in business environments, and
associated management and security techniques.
Discuss the following questions:
Do you use mobile devices (smartphones and

tablets) in your business environment?
Which mobile platform do you primarily use

in your company? On what did you base your
decision to choose that particular mobile
platform?
What services, such as, email, calendar, tasks,

and notes, do you use on mobile devices?
Are you connecting mobile devices to your company infrastructure, or do you use cloud-based
services such as Hotmail, Office 365, and Google Apps?
Do you have any security policies enforced for mobile devices that connect to your environment?
Do you have any management technology implemented for mobile devices?
Do you use ActiveSync?
How Exchange ActiveSync Works

Most mobile platforms now support ActiveSync
protocol for messaging, calendar, contacts, and
tasks. By using ActiveSync protocol, a mobile
device can securely connect to an Exchange
Server and synchronize its data. The connection
from the mobile device to the Exchange Server
is established securely by using HTTPS. Most
devices that support ActiveSync can also use
Autodiscover, so they are able to automatically
configure most of the settings on the mobile
devices by using following process:
1.
The user begins the configuration of the

Active Sync account on a mobile device by entering an email address and password.
2.
Based on the users email address, the mobile device connects to the DNS server, and looks for the IP
address and URL of the Autodiscover service in the specified domain (if it exists).
3.
The mobile device uses an HTTPS connection to connect to the Autodiscover service virtual directory.
The Autodiscover service builds the XML response based on the server synchronization settings.
4.
The Autodiscover service sends the XML response through the firewall over SSL. This XML response is
interpreted by the mobile device, and synchronization settings are configured automatically on the
mobile phone.
Note: Because mobile devices use HTTPS to connect to the Exchange Server, each device
must trust the issuer of the certificate that is implemented on the Exchange Server. If you do not
use public certificates for Exchange, you should manually import your RootCA certificate on the
mobile device. You can manually import various ways depending on the mobile platform you
used.
How ActiveSync-Based Clients Connect to the Exchange Server

When users connect to the Client Access server with a mobile device, the following process occurs:
1.
The Exchange ActiveSync client uses HTTPS to connect 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 and retrieves the mailbox data. If the Mailbox
server is in a different site, then the Client Access server proxies the client request to a Mailbox 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.
Once the client has established the ActiveSync connection to the Exchange Server, it downloads contacts,
calendar items, emails, and other configured items. On most platforms, you can choose how many days of
calendar and email messages you will sync to the device. This data is synchronized with the Exchange
Server in one of two ways--either automatically if Direct Push is enabled, or manually by the user.
Note: The data that a user syncs from the Exchange Server to his or her mobile device stays
on the device even when the connection to Exchange is not available. For this reason, it is very
important that devices are secured.
Supported Features in Exchange ActiveSync

The ActiveSync protocol provides many features
and functionalities. Some of the most important
features of Exchange ActiveSync in Exchange
Server 2013 include:
Support for HTML-formatted messages.
Support for follow-up flags on messages.
Conversation grouping of email messages.
Ability to synchronize or not synchronize an

entire conversation.
Synchronization of Short Message Service

(SMS) messages with a user's Exchange mailbox.
Support for viewing message reply status.
Support for fast message retrieval.
Meeting attendee information.
Enhanced Exchange Search.
PIN reset.
Enhanced device security through password policies.
Autodiscover for over-the-air provisioning.
Support for setting automatic replies when users are away, on vacation, or out of the office.
Support for task synchronization.
Direct Push.
Support for availability information for contacts.
Global address list (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 Exchange Active Sync. A method to apply digital rights
management control and encryption to email messages that are sent and received.
Exchange ActiveSync is licensed to many different mobile operating system manufacturers. You can use
ActiveSync to connect your mobile device to an Exchange Server, Windows Phone 7 (or later), iOS 4 (or
newer), and Android version 2 (and newer) 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 need to verify which features are supported on your mobile device.
Note: Because most tablet devices also run a mobile operating system, they also use
ActiveSync protocol to connect to the Exchange Server.
What Is Direct Push?

Direct Push is a feature built into Microsoft
Exchange Server 2013 that keeps a mobile
device current over a cellular or Wi-Fi network
connection. It provides notification to the
mobile device when new content is ready to be
synchronized to the mobile device. The client
then initiates synchronization to download the
new items.
You establish Direct Push by using the following
steps:
1.
The mobile device issues a longstanding

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.
To enable Direct Push to work through your firewall, you must open TCP port 443. This port is required
for ActiveSync communication, and it must be opened between the Internet and the Client Access server.
In addition to opening ports on your firewall, you should increase the time-out value on your firewall to
the value of 15 minutes to 30 minutes for optimal Direct Push performance. The maximum length of the
HTTPS request is determined by the following settings:
The maximum time-out value that is set on the firewalls that control the traffic from the Internet to
The firewall time-out values that are set by the mobile service provider.
A short time-out value causes the device to initiate a new HTTPS request more frequently. This can
shorten battery life on the device.
What Is Remote Wipe?

When an ActiveSync connection is established
between a mobile device and an Exchange Server,
the mobile device stores part of the data from
the users mailbox. The mobile device also stores
the users domain credentials, which are the user
name and password needed to authenticate to
the Client Access Server. If a device is lost or
stolen, that data can be compromised.
Because the risk of losing a mobile device is
especially high, you must secure data on mobile
devices. You can secure mobile devices by
enforcing an ActiveSync policy that specifies
password requirements for the device. However, this does not prevent data from being compromised
when devices are lost or stolen.
For cases when a device is lost or stolen, Exchange Server provides an option called Remote Wipe. When
this command is issued, it deletes all data on the phone and storage cards, and resets all settings to
factory defaults. Restoring settings to factory defaults prevents any unauthorized user from accessing your
account data or data cached on the device. If you are performing a remote device wipe on a mobile
phone in your possession, and you want to keep the data on the storage card, remove the storage card
before you initiate the remote device wipe.
Note: Many newer smartphones do not have removable storage, so keep in mind that
Remote Wipe will destroy all data on the device.
The Remote Wipe command can be issued from the user of a specific mobile device, by using the Outlook
Web App interface, or by having the administrator use the Exchange Administration Center or the
Exchange Management Shell. However, the Remote Wipe command will only be accepted by the device
if it still has connection with the Exchange server, either by data (3G, LTE, or similar mobile data service) or
by Wi-Fi. If connection is lost (for example, the subscriber identity module, or SIM, card is removed or
ActiveSync account is removed manually on the device), Remote Wipe will not work. In this case, you must
ensure that you issue a Remote Wipe command as soon as possible.
Note: After a remote device wipe, data recovery is very difficult. However, no data-removal
process leaves a device as free from residual data as when it is new. It may still be possible to
retrieve data from a device using sophisticated tools.
What Is Mobile Device Quarantine?

Microsoft Exchange Server 2013, with the latest
version of ActiveSync protocol, offers some new
features in the area 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 Server.
For example, you can specify that only devices
that are running a Windows Phone 7 or newer
operating system can connect to the Exchange
Server.
This capability is achieved by defining the device access state for each mobile device that connects to the
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 Allowed 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 ActiveSyncconfigured mailbox policies. This is the default state for all devices, because Exchange Server does not
define any quarantine policies.
Blocked. If the device access rule specifies a device that should be blocked, that device cannot
connect to the Exchange server, and receives an HTTP 403 Forbidden error. You can block a device
based on the device family or you can block a specific device model. The user will receive an email
message from the Exchange Server that indicates that the mobile device was blocked from accessing
their mailbox. A mobile device also may 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 indicates that the mobile device
was blocked from accessing his or her mailbox. However, the mobile device information displayed
in Outlook Web App shows that it is blocked due to the devices failure 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 his or her 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 is 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 ActiveSync device access rules by using the Exchange Administration Center
or the Exchange Management Shell.
Securing Mobile Devices with Mobile Device Mailbox Policies

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 Mobile Devices Mailbox Policy
Mobile Device Mailbox Policy provides 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, and
to configure several other security options. All of these settings are mandatory, which means that if they
are applied, users cannot change them from the client side.
Mobile Device Mailbox polices are applied on a user-by-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. Each
user is assigned a default policy that does not enforce any security settings. You can create a new policy
and declare it as the default policy so it will be automatically applied to all user accounts. To ensure that
mobile devices are as secure as possible, you should configure Mobile Device Mailbox policies that require
device passwords, and encrypt the data stored on the mobile device.
When implementing Mobile Device Mailbox Policy, you can configure the following options:
This is the default policy. Enables you to set policy as the default one and apply it to all users.
Allow mobile devices that do not fully support these policies to synchronize. Enables devices that do
not support all options from policy to sync anyway.
Require a password. Enables you to specify password requirements.
Allow simple passwords. Enables users to use passwords such as 1111 or 1234.
Require an alphanumeric password. Requires a password that includes both numbers and letters.
Require encryption on device. Requires the storage on a device to be encrypted.
Password must include this many character sets. Specifies how many different character sets a
password must have. The value for this is numerical. Character sets are lower- and upper-case letters,
numbers, and symbols.
Minimum password length. Specifies the minimum characters in the password.
Number of sign-in failures before device is locally wiped. Specifies the number of wrong attempts
to enter device password before wipe is performed. Local device wipe is the mechanism by which a
mobile phone wipes itself without the request coming from the server. The result of a local device
wipe is the same as that of a remote device wipe. The device is returned to its factory default
condition. When a mobile phone performs a local device wipe, no confirmation is sent to the
Exchange server.
Require sign-in after device has been inactive. Specifies the time, in minutes, of device inactivity after
which the password is required.
Enforce password lifetime (days). Specifies the maximum time a password can be used on device.
Password recycle count. Specifies how many different passwords a user must use before repeating
one of earlier used passwords.
Demonstration: Reviewing Options for Mobile Device Management in the

Exchange Server Administration Center
Demonstration Steps
1.
In the EAC, open the mobile pane.
2.
Configure options to quarantine all devices until the administrator decides if they will be allowed
access.
3.
Configure that administrator receives the message when the device is in quarantine.
4.
Configure new device access rule with the option: Quarantine Let me decide to block or allow
later.
Alternatives for Mobile Device Management

Exchange Server 2013 provides options for
enforcing security settings on mobile devices
through mobile device mailbox policies. However,
because there are no options for managing and
provisioning mobile devices, you usually have the
ability to perform the following tasks:
Preconfigure mobile devices with companydefined options.
Deploy configuration profiles to mobile

devices over the air.
Deploy applications to mobile devices over

the air.
Control hardware and software behavior on mobile devices.
Deploy updates to mobile devices from a single administration point.
Enforce security options for mobile devices.
Currently, there is no single administration software or platform that can perform management of every
type of mobile platform. Each mobile platform vendor provides its own management solution, or thirdparty companies provide on-premises or web-based solutions for mobile device management that are
usually based on client software being deployed on mobile devices.
For Microsoft mobile platforms, the only mobile platform that supports full management capabilities is
Windows Mobile 6.5 with Mobile Device Management Server 2008. However, this platform will no longer
be developed. The newest release of Windows Phone platform, version 8, supports greater management
capabilities than Windows Phone 7.
You also can use cloud-based services such as Windows InTune for managing mobile devices. Windows
Intune connects with the Exchange server installed on-premises and provides you the ability to create
mobile device policies. Some capabilities for mobile device management are also integrated in System
Center Configuration Manager.
Lesson 4
Configuring Secure Internet Access for Client Access

Server
Exchange Server 2013 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.
Lesson Objectives
Describe Exchange Server security guidelines.
Secure Internet access components.
Deploy Exchange Server 2013 for Internet access.
Secure Client Access traffic from the Internet.
Secure simple mail transfer protocol (SMTP) connections from the Internet.
Describe the benefits of using a reverse proxy.
Exchange Server Security Guidelines

The Exchange Server 2013 design 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,
organizations should 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; this includes both the operating system updates and the
Exchange Server updates.
Before you update the 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.
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. The only additional
software that you should install are utilities, such as antivirus software and server-management tools.
Install and Maintain AntiVirus Software

Virtually all organizations deploy antivirus software to guard against malicious email. You also should
deploy file-level antivirus software on the Exchange servers to ensure that the servers are secure from
virus attacks. Exchange Server 2013 comes with an antimalware functionality built in. You can use the
antimalware functionality as a messaging security solution.
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 guess. 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 2013 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 the types of access each
client type requires.
Client Access to Exchange Servers

The following list describes the services that
clients can use to access Exchange servers from
the Internet:
Outlook Anywhere. Outlook 2007 and newer

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 or newer clients only require
access to the RPC virtual directory.
Access to Autodiscover. Autodiscover provides automatic configuration for Outlook and ActiveSync
clients. It is enabled by default, and virtual directory called Autodiscover is created on Clients Access
server. The protocol requirement for Autodiscover is HTTPS.
Microsoft Outlook Web App. Outlook Web App provides access to Outlook Web App and Exchange
Control Panel virtual directories on a Client Access server. The protocol required for this service is
HTTPS.
Microsoft Exchange ActiveSync. ActiveSync provides access to the Microsoft-Server-ActiveSync virtual

directory on a Client Access server and access to the Autodiscover virtual directory on a Client Access
server if Autodiscover is enabled. The protocol required for this service is HTTPS.
Internet Message Access Protocol version 4rev1 (IMAP4). IMAP4 provides access to the IMAP4 service
on a Client Access server and access to a SMTP Receive connector with the following protocol
requirements: IMAP4, SMTP (Port 25 or 587).
Post Office Protocol 3 (POP3). POP3 provides access to the POP3 service on a Client Access server, and
access to a SMTP Receive connector on Client Access server, or another SMTP server with the
following protocol requirements: POP3, SMTP (Port 25 or 587).
Options for Configuring Internet Access

Several options are available to provide 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 2012 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
multifactor authentication and Network Access Protection (NAP). 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 it does raise potential
security issues. Standard firewalls can filter network traffic based on source and destination IP
addresses and ports, but they 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 2013 for Internet Access

When you deploy Exchange Server 2013 so that
it is accessible from the Internet, you must deploy
all server roles on the internal network. The
recommended deployment for Exchange Server
2013 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.
Note: Exchange Server 2013 does not
provide the Edge Transport Server role, although it does support the use of Edge Transport
Server role from Exchange Server 2010. If you decide to use Edge Transport server from Exchange
Server 2010, you can use settings from the table below. If you choose to use a third-party SMTP
gateway instead of Edge Transport Server, some modifications might be needed.
Configuring External Firewalls for Internet Access
An organizations Internet-facing or external firewall protects the perimeter network. The firewall can be
configured to accept packets based on source and destination IP addresses and ports. To support the
Exchange Server deployment, the external firewall must be configured with the following firewall rules:
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
443
Source address: All

Destination address: External IP address of the internal firewall
110, 995
Source address: All

Only required for POP3 access
143, 993
Source address: All

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 a 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: Mailbox 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 Client Access Server
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

Only required for IMAP4 access
587

Destination address: Client Access Server
Only required if POP3 and IMAP4 clients are using the SMTP client submission
port to send SMTP email
50636
Source address: Mailbox servers on the internal network

Required for the Mailbox 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
Edge Transport servers also listen on port 50389 for unencrypted Lightweight Directory Access Protocol
(LDAP) connections. This port is used only for administering the Active Directory Lightweight Directory
Services (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

You should implement the following
recommendations to ensure that your
organizations client connections are as secure
as possible:
Create and configure a server certificate.

By default, all Client Access servers are
configured with self-signed certificates during
Exchange Server 2013 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 SSL for all virtual directories. With Exchange Server 2013, 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 either basic
authentication or authentication by Microsoft Windows NTLAN) Manager, also known as NTLM. 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 Internet protocol security (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 inspect
the traffic for malicious code.
Note: Using Microsoft Forefront Threat Management Gateway 2010 (TMG) for Exchange
Server 2013 web services publishing is not supported by default, since TMG does not have a
publishing wizard for Exchange Server 2013. However, you can use publishing wizard for
Exchange Server 2010 to publish Exchange Server 2013. After you configure publishing rules,
you must manually modify address for logoff page.
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
Clients can use POP3 and IMAP4 to retrieve
messages from user mailboxes; however, they
cannot use these connections to send messages.
To enable these 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 SMTP Receive connector to
require authentication, and to accept SMTP connections from the Internet. By requiring authentication,
only users with valid accounts in the Exchange Server organization can relay messages through the server.
If you are using an Edge Transport Server or a third-party SMTP Gateway, you should be aware that 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

By default, Exchange Server 2013 provides the following receive connectors:
Client Frontend works on port 587, and it accepts secure connections, with TLS applied.
Client Proxy works on port 465, and it accepts connections from Client Access servers. This
connector runs on Mailbox Server.
Default Frontend works on port 25, and it accepts connections from SMTP senders over port 25.
This is the common messaging entry point into organization.
Default servername works on port 2525, and it accepts connections from Mailbox servers running
the Transport service, and from Edge servers (if deployed).
Outbound Proxy Frontend works on port 717, and it accepts messages from a Send Connector on a
Mailbox server, with front-end proxy option enabled.
These connectors are discussed with more details in later modules. To secure the SMTP connections,
1.
Enable TLS for SMTP client connections. You can configure the SMTP Receive connector 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 Frontend connector (port 587), and configure two SMTP Receive connectors. The
Default FrontEnd receive connector is configured to use port 25, while the Client FrontEnd 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. All receive connectors must 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.
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 A 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 sourceIP-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. This server encrypts data that is sent between the
web browser and the Client Access server, and 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.
Lab: Planning and Configuring Messaging Client

Connectivity
Scenario
A. Datum is planning its client connectivity solution for Exchange Server 2013. The company has several
different types of clients, and it needs to find an appropriate solution for each, while staying compliant
with the organizations security policy.
As A. Datums Exchange administrator, you need to propose and implement a solution for client
connectivity. You also must ensure that connections from the Internet are as secure as possible.
Objectives
Plan client connectivity.
Configure Outlook Web App and Outlook Anywhere.
Configure Exchange ActiveSync.
Publish Exchange Server 2013 through Threat Management Gateway 2010.
Lab Setup
Virtual machines
20341B-LON-DC1
20341B-LON-CAS1
20341B-LON-MBX1
20341B-LON-TMG
20341B-LON-CL1
User Name
Password
Pa$$w0rd
For this lab, you will use the available virtual-machine environment. Before you begin the lab, you must
1.
2.
3.
4.
Log on using the following credentials:
5.
a.
b.
Password: Pa$$w0rd
Repeat steps 2 to 4 for 20341B-LON-MBX1, 20341B-LON-CAS1, 20341B-LON-TMG, and

20341B-LON-CL1.
Exercise 1: Planning Client Connectivity

Scenario
To enable access to email, your organization must provide appropriate connectivity options for users
connecting from both its internal network and an external network (Internet). Internal clients are running
on the Windows 8 operating system. Some clients have Outlook 2010 installed, while others have either
Outlook 2003 or no Outlook client. A. Datum does not plan to buy any new client licenses at this point in
time.
Several users are using mobile computers in the office and while they are out of the office. These
computers are domain members, and all have Windows 8 and Outlook 2010 installed.
A majority of the clients have mobile devices, mostly smartphones and tablets. They are using mostly
Windows Phone 7.5 and Windows Phone 8 devices, but a number of clients are using Android 4 and iOS
5-based devices. A few have older Symbian devices.
The security officer at A. Datum Corporation has defined the following security requirements for email
access that must be implemented in this solution:
Internal clients must use an encrypted connection to the email server.
External clients must be able to check their email from any computer, including computers located in
public areas. However, these users should not be able to download attachments while they are on
public computers.
To enable mobile devices to connect to your network, you must be able to control their security
options and force password requirements. It is preferable, but not mandatory, that mobile devices are
authenticated by using certificates.
Each user must have a password protected device to access your network.
All devices that connect from an external network should have an A. Datum Root CA certificate
installed in Trusted Root store, and they must use SSL security.
Administrators must be able to manage mobile devices. It is desirable, but not mandatory, that they
be able to control some additional device features, such as usage of data sharing, Bluetooth, and
roaming options.
Each user must have the ability to delete content of his mobile device if it is lost.
Your proposed solution for client connectivity must address all of these requirements.
1.
Read and analyze scenario requirements.
2.
Propose a solution for client connectivity.
3.
Discuss your solution with the class.
Task 1: Read and analyze scenario requirements
Read the exercise scenario, and analyze the requirements from both a functionality and security
perspective. Identify the technologies that should be used.
Task 2: Propose a solution for client connectivity

Propose a solution for client connectivity for both internal and external clients. Use the following
questions as a guideline when making a solution:
1.
Which client platforms should you support for internal clients?
2.
Which client platforms should you support for external clients?
3.
What concerns do you have regarding internal clients?
4.
What concerns do you have regarding external clients?
5.
How will you address the requirement for client connection encryption?
6.
What solution will you propose for internal clients?
7.
What solution will you propose for external clients?
8.
How will you address the requirements for attachment downloading on public computers?
9.
How do you plan to force security requirements to mobile devices?
10. How do you plan to deploy the A. Datum Root CA certificate to client devices (both computers and
smartphones)?
11. Is there a way to control hardware features of mobile devices?
12. Can you implement certificate-based authentication for mobile devices?
13. How will you implement the requirement for deleting content from a lost mobile device?
Task 3: Discuss your solution with the class
Present your proposed solution. Discuss alternative solutions with the other students and the
instructor.
Results: After completing this exercise, the students will have created a plan for client connectivity.
Exercise 2: Configuring Outlook Web App and Outlook Anywhere

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.
You must ensure that users cannot download attachments while they are on public computers, and that
they cannot recover deleted messages by using the Outlook Web App interface.
You also should disable the instant messaging and text messaging options in the Outlook Web App
interface. To achieve this, you must configure Outlook Web App policies, apply them to users that are
accessing email from the Internet, and verify that the settings have been successfully applied. These users
will be identified with a Custom Attribute 1 set to external.
You also should enable Outlook Anywhere for users with mobile computers, and Offline Outlook Web
App for users that do not have Outlook installed but are using mobile computers.
1.
Configuring Outlook Web App policies.
2.
Configuring Outlook Anywhere.
3.
Enabling and using Offline Outlook Web App.
Task 1: Configuring Outlook Web App policies

1.
On LON-CAS1, on the Start screen click Internet Explorer.
2.
Browse to https://lon-cas1.adatum.com/ecp.
3.
Sign in to the EAC as Adatum\Administrator with the password Pa$$w0rd.
4.
In the EAC, in the permissions node, choose to create new Outlook Web App policy. Name the
policy External Users Policy.
5.
In a new Outlook Web App policy, configure options to prevent users from using Direct file access,
recovering deleted items, and using Instant messaging and Text messaging.
6.
Apply the new policy to the user Adam Barr.
7.
Apply the new policy to the user Aidan by using Exchange Management Shell.
8.
Use the Exchange admin center to set the attribute Custom Attribute 1 to a value of external for
users Brad Sutton, Chad Niswonger, and Daniel Durrer.
9.
Assign External Users Policy to these users by typing the following command in Exchange
Management Shell:
get-mailbox filter {CustomAttribute1 eq external} | Set-CASMailbox
- OwaMailboxPolicy:External Users Policy
10. Verify that the policy is applied to Brad Sutton, Chad Niswonger, and Danielle Durrer.
Task 2: Configuring Outlook Anywhere
On LON-CAS1, in Exchange admin center, configure the external name for Outlook Anywhere to be
mail.adatum.com and authentication to be NTLM.
Task 3: Enabling and using Offline Outlook Web App

1.
On LON-CL1, click to the desktop, open Internet Explorer and type https://lon-cas1.adatum.com
/owa, and sign in as Adatum\Aidan with the password Pa$$w0rd.
2.
In the Options menu in OWA, select to turn on offline access.
3.
Add the OWA URL to Favorites in Internet Explorer.
4.
Sign out of Outlook Web App and close Internet Explorer.
5.
Using Hyper-V Manager console, disconnect the network adapter for LON-CL1 from the network.
6.
Try to open OWA from Internet Explorer, and verify that you can access the content of your mailbox.
7.
Send a test email to the administrator.
8.
Reconnect LON-CL1 to the network.
9.
Verify that the administrator has received the email that you sent while using OWA offline.
Results: After completing this exercise, students will have Outlook Web App and Outlook Anywhere
configured.
Exercise 3: Configuring Exchange ActiveSync

Scenario
A. Datum Corporation has many users who use smart-phone devices to access their mail. The clients
are using mostly Windows Phone 7.5 and Windows Phone 8 devices, but a number of clients are using
Android and iOS-based devices, and a few have older Symbian devices. You need ensure that these users
can access their mailboxes by using Exchange ActiveSync. You also must ensure that their connections are
secure, and that consistent settings are applied to each device. The following requirements must be
fulfilled on each mobile device:
An alphanumerical password must be used on the device.
The password must include at least two different character sets.
The minimum password length must be five characters.
Users can type the wrong password a maximum of four times before the device is wiped.
Each device should be locked after five minutes of inactivity.
In addition to these requirements, A. Datums security policy specifies that each new mobile device that
connects to the organizations Exchange Server must be quarantined first, and then manually allowed or
blocked after the Exchange administrator has reviewed the request. You also should find a way to install a
root certificate on the mobile device and configure SSL security.
1.
Plan a mobile device deployment.
2.
Configure mailbox policies for mobile devices.
3.
Configure device access rules.
Task 1: Plan a mobile device deployment
Based on the exercise scenario, propose a plan for mobile device management from an Exchange Server
aspect. You can use the following questions as a guideline:
1.
Because many different device platforms will be accessing your Exchange Server, what are your main
concerns?
2.
How will you achieve the requirement that settings be consistent on each mobile device?
3.
How will you implement the password requirements on your mobile device?
4.
How will you implement the requirements for quarantine?
Task 2: Configure mailbox policies for mobile devices

1.
Open the EAC on LON-CAS1.
2.
Navigate to mobile in feature pane.
3.
Create a new mobile device mailbox policy and name it Adatum Mobiles.
4.
Set the new policy as the default policy.
5.
Specify the following options in the policy:

o
Require an alphanumeric password
Number of character sets included in a password: 2
Minimum password length: 5
6.
Number of sign-in failures before device is wiped: 4
Require sign-in after device has been inactive for: 5
Save the policy.
Task 3: Configure device access rules

1.
On LON-CAS1, in EAC, navigate to mobile->mobile device access in the menu.
2.
Select Quarantine Let me decide to block or allow later.
3.
Select the option to email the administrator when a device is in quarantine.
4.
Create a new device access rule.
5.
Configure the rule so that all devices are quarantined when they first connect.
6.
Cancel the creation of device access rule.
Results: After completing this exercise, the students will have configured mobile device options and
policies.
Exercise 4: Publishing Exchange Server 2013 Through TMG 2010

Scenario
After you configured all the client connectivity options, you need to securely publish your Client Access
server to the Internet. You can choose the Threat Management Gateway (TMG) 2010 as a solution to
perform that task.
1.
Publish Exchange web-based services through TMG 2010.
2.
Publishing rule testing.
3.
Task 1: Publish Exchange web-based services through TMG 2010

1.
On LON-CAS1, use Windows PowerShell to export webmail.adatum.com certificate with private key.
Set the password to be Pa$$w0rd and save CAS1.pfx file to C:\
2.
On LON-TMG machine, import the certificate from \\LON-CAS1\C$\CAS1.pfx save it to Computer

personal store.
3.
On the LON-TMG machine, in the Forefront TMG console, start the wizard to publish Exchange Web
Client Access.
4.
Choose to publish OWA on Exchange Server 2010.
5.
Use the public name webmail.adatum.com.
6.
Create new HTTPS listener, and configure it to use webmail.adatum.com certificate.
7.
Configure authentication for users to be HTML form.
8.
Configure authentication delegation to be Basic.
9.
On LON-CAS1, configure OWA virtual directory to use the external name

https://webmail.adatum.com/owa and Basic authentication.
10. On LON-CAS1, configure ECP virtual directory to use external name

https://webmail.adatum.com/ecp and Basic authentication.
11. Restart IIS on LON-CAS1.
12. Switch to LON-TMG and open Properties of OWA rule.
13. On Application Settings tab in Published server logoff URL, type /owa/logoff.owa. (Note: You are
doing this because TMG 2010 does not have a publishing rule for Exchange 2013, so the logoff page
still directs users to the old location used by Exchange Server 2010).
14. Test the rule. You should have green check marks for these two URLs.
Task 2: Publishing rule testing

1.
On the host machine, open settings for 20341B-LON-CL1 machine, and connect it to Private
Network 2.
2.
Log on as Adatum\Administrator to LON-CL1 machine.
3.
Change the IP address of the LON-CL1 machine to 131.107.0.2. Set the default gateway to
131.107.0.1. Clear the DNS settings.
4.
Open hosts file on LON-CL1 from location c:\windows\system32\drivers\etc\hosts. Choose to

open it with Notepad.
5.
At the bottom of the hosts file, type 131.107.0.1 webmail.adatum.com. Save the file.
6.
From Internet Explorer navigate to https://webmail.adatum.com/owa. Log on as

Adatum\Administrator with the password Pa$$w0rd.
7.
Verify that you can access mailbox content. Click Settings, and then click Options. Verify that you
can connect to the Exchange Control Panel.

following steps:
1.
2.
3.
4.
Repeat steps 2 to 3 for 20341B-LON-CAS1, 20341B-LON-MBX1, 20341B-LON-TMG, and

20341B-LON-CL1.
5.
6.
7.

a.
b.
Password: Pa$$w0rd
8.
9.
You must now move the subnet object currently associated with the Swindon site to the London site
before starting the Exchange Servers:
a.
On LON-DC1, click Server Manager.
b.
In Server Manager, click Tools and then click Active Directory Sites and Services.
c.
In Active Directory Sites and Services, click Subnets.
d.
Right-click 172.16.0.128/25 and then click Properties.
e.
In the 172.16.0.128/25 Properties dialog box, in the Site list, click London and then click OK.
f.
Close Active Directory Sites and Services.
g.
Close Server Manager.
repeat steps 5 to 7 for 20341B-LON-MBX2, 20341B-LON-CAS1, and 20341B-LON-CAS2.
Results: After completing this exercise, students will have Exchange Server 2013 published through TMG
2010.

Best Practice
Always configure Outlook Web App policy for public and private computers.
Use OWA Offline only on trusted computers.
Analyze security considerations for each mobile platform before you decide which platforms you will
support on Windows Server 2012 operating system Exchange Server side.
Always configure policies for mobile devices so that password is required on a device.

Common Issue
Troubleshooting Tip
Users get a warning when accessing

Outlook Web App page from the Internet
Users cannot connect with mobile devices

to Exchange Server
Review Question
Question: What should you use for secure access to Client Access server from Internet?
Tools
Forefront Threat Management Gateway

6-1
Module 6
Planning and Implementing High Availability
Contents:
Module Overview
6-1
Lesson 1: High Availability on Exchange Server 2013
6-2
Lesson 2: Configuring Highly Available Mailbox Databases
6-10
Lesson 3: Configuring Highly Available Client Access Servers
6-22
6-25
6-30
Module Overview
Messaging systems are considered a critical business tool in most organizations. Outages of even a
few hours reflect poorly upon the IT departments, and can result in sales losses or business reputation
damage. High availability helps ensure that messaging systems built on Microsoft Exchange Server 2013
can survive the failure of a single server, or even multiple servers. You can implement high availability for
all the server roles in Exchange Server 2013.
This module describes the high-availability technology built into Exchange Server 2013, and some of the
outside factors that affect highly available solutions.
Objectives
Describe high availability in Exchange Server 2013.
Configure highly available mailbox databases.
Configure highly available Client Access servers.
Lesson 1
High Availability on Exchange Server 2013
6-2 Planning and Implementing High Availability
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. Careful design and planning must be
performed to ensure 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.
Lesson Objectives
Describe the components of high availability.
Describe a database availability group (DAG).
Explain how database availability groups (DAGs) work.
Describe high availability with Client Access servers.
Explain transport high availability.
Explain high availability with Edge Transport server.
Describe site resilience.
Discuss virtualization high-availability technologies versus Exchange Server high-availability

technologies for Mailbox servers.
Components of High Availability

When an application such as Exchange Server
2013 requires high availability, you need to
consider more than just the application
components. All of the infrastructure and
services that the application relies on also must
be highly available.
You must consider the following additional
components when planning for high availability.
Data Center Infrastructure
The room that stores the server must have

sufficient power and cooling capacity, and that
capacity also must be highly available. You can make power highly available by ensuring that an alternate
power source, such as a battery or a generator, is available when the electrical utility experiences outages.
You can make cooling capacity highly available by using multiple cooling units with sufficient capacity to
keep the data center cool when one unit fails. In cases of a catastrophic failure, you can use an alternate
data center location.
Server Hardware
To make server hardware highly available, there must be redundant components in the server. Redundant
components can include power supplies, network adapters, processors, and memory. Error-correction
code (ECC) memory helps to resolve minor errors in memory.
Storage
To make storage highly available on a single server, you can use a version of Redundant Array of
Independent Disks (RAID). RAID uses parity information to ensure that a server can survive the loss of
at least one hard drive, without losing any data. If multiple servers are available, you can replicate data
between servers. This allows the data to survive the loss of an entire server, rather than just a hard drive.
Network Infrastructure
To make a local area network (LAN) highly available, you must introduce redundant components. Within
a LAN, this typically means redundant switches. Even moderately priced switches include redundant
configurations. To make the network connectivity for any individual computer fault tolerant, you
must configure redundant network interface cards on the computer. This is a standard feature in most
mid-level and higher servers. High availability for a wide area network (WAN) is typically the responsibility
of the WAN service provider. However, if you are using private links for your WAN, you can create
redundant paths through the WAN.
Internet Connectivity
For highly available Internet access, you must have redundant Internet connectivity. Ideally, you should
use two different Internet service providers (ISPs) and two different physical connectivity methods. For
example, one ISP could be land based, and the other wireless. If you use these methods, it is unlikely that
a problem affecting one ISP would affect the other. Many firewalls and routers are capable of using one
connection for Internet connectivity and failing over to another if the primary service fails. For incoming
email, you must use multiple mail exchange (MX) resource records, with one record pointing to the IP
address allocated by each ISP.
Network Services
Active Directory Domain Services (AD DS) and Domain Name System (DNS) service are the two services
that must be highly available to support highly available Exchange Server 2013 organizations. To make
AD DS servers highly available, you should have multiple domain controllers and global catalog servers.
Depending on the size of a location, multiple domain controllers and global catalog servers may reside in
a single location. To make internal DNS servers highly available, you must have multiple DNS servers with
DNS information synchronized between them. By default, the DNS zones for AD DS are Active Directory
integrated, and are replicated among all DNS servers in the forest.
What Is a Database Availability Group?

A database availability group (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. DAGs:
Require the Windows Server 2008 R2 or

Windows Server 2012 failover clustering
feature, although all installation and
configuration tasks occur with the Exchange
Administration Center (EAC) or Exchange
Management Shell. Even though a DAG
requires the failover clustering feature,
Exchange Server 2013 does not use Windows failover clustering to handle database failover; instead,
it uses Active Manager to control failover. Windows failover clustering is used for some failuredetection scenarios, such as a server failure.
Use an improved version of the continuous replication technology that was introduced in Microsoft
Exchange Server 2007. The improvements support the new high-availability features, such as
database copies and database mobility. Continuous replication is explained later in this lesson.
Note: DAGs also can use third-party replication instead of continuous replication.
Allow you to add and remove Mailbox servers at any time. You do not need to decide on the DAG
membership during installation.
Because DAGs use a subset of the Windows failover clustering feature such as cluster heartbeat,
Exchange Server 2013 must be installed on Windows Server 2012 Datacenter Edition or Standard
Edition, or Windows Server 2008 R2 Enterprise Edition or Datacenter Edition.
Allow you to move a single database between servers in the DAG without affecting other databases.
Allow 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 LON-MBX01, then you must also store it in D:\Mailbox\DB\Mailbox Database 1\ on all
other servers that host Mailbox Database 1 copies.
Define 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.
Prohibit you from adding an Exchange Server 2010 to an Exchange Server 2013 DAG.
Note: In Exchange Server 2013, the basic concept of a DAG is the same as in Microsoft
Exchange Server 2010. It differs only in the way that failover times have been reduced as a result
of transaction log code improvements and a deeper checkpoint on the passive databases.
Understanding How Database Availability Groups Work

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
component to maintain the status of all DAGhosted databases. The following are database
characteristics:
A single database can failover or switchover

between Mailbox servers that are members of
a DAG. 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 must 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 can cause the failure. A switchover occurs when an administrator
intentionally coordinates moving the active database from one server to another.
Understanding How High Availability Works with Client Access Servers

You configure high availability for Client Access
servers by adding at least two Client Access
servers to your Active Directory site. Exchange
Server 2013 Client Access servers are now
stateless. This means that a client request no
longer needs to use the same Client Access server,
and can use any server. This allows you to use the
following options in order to distribute the load
between the Client Access servers:
DNS round robin. To use a DNS round robin,

you must configure an A record for your
client communication, and add to it all of the
IP addresses of the available Client Access servers. If you have more than one physical location where
Mailbox servers are located, you should consider implementing a Geo-DNS, so that the client servers
always get the Client Access server IP address that is located closest to it. When you consider a DNS
round robin, you must consider that the failover takes place on the client side. Therefore the client
side must be aware of DNS round robin use. This option is normally used when you cannot use
Network Load Balancing (NLB) by having a multi-role server that is part of a DAG, but you cannot
afford a hardware-based load balancer.
Network Load Balancing. Windows Server 2012 provides a feature called Network Load Balancing
(NLB) that allows you to distribute client server load to Client Access servers equally. This is achieved
by assigning a virtual IP address (VIP) in addition to the regular IP address to every member of the
NLB cluster. The NLB feature then ensures that the service is available and will only respond when
available. When a server failure occurs, the IP address will no longer respond, and therefore the load
will be distributed between the servers that are still operating correctly. This option provides a serverbased failover because the client only will use the VIP and will be connected to a different Client
Access server automatically. This option is a good solution if you cannot afford a hardware-based
load balancer but still want to put high availability in place.
Hardware-based load balancing. Similar to a NLB, a hardware-based load balancer uses a VIP to
which the client sends all requests. The main difference between a Windows-based NLB and a
hardware-based load balancer is that you can configure a more sophisticated hardware-based load
balancer that also can be extended beyond the Windows based NLB limit, which is 16 cluster nodes.
In general, the performance is much better with a Hardware-based load balancer, but this option is
associated with high costs. This is the best option to provide high-availability, but also is the most
expensive one because it requires you to purchase a hardware load balancer.
To load balance Client Access servers, you must perform the following steps:
1.
Deploy multiple Client Access servers in a site.
2.
Use either hardware-based or software-based Network Load Balancing (NLB) to create a cluster.
3.
Add the name for the network load-balanced cluster into DNS. For example, add a host (A) resource
record for caa1.contoso.com that points to 10.10.10.25.
Note: In Exchange Server 2010, you were required to configure a client access array in
Exchange Management Shell for each Active Directory site. In Exchange Server 2013, this
requirement is no longer needed.
Understanding How Transport High Availability Works

Transport high availability in Exchange Server
2013 is more than just a means of ensuring
message redundancy. Exchange Server 2013
attempts to guarantee message redundancy by
combining two features, Shadow redundancy and
Safety Net (known as Transport dumpster in
Exchange Server 2010). Shadow redundancy
creates a redundant copy of the message on
another server before the message is accepted or
acknowledged. Safety Net stores messages that
were successfully processed by the Transport
service on Mailbox servers.
Shadow Redundancy
Shadow redundancy is a feature that Exchange Server 2010 introduced that ensures a copy of a message
is available if a mailbox server crashes before messages have been committed to the databases. Exchange
Server 2013 improves this feature by automatically creating a redundant copy of any message it receives,
before it acknowledges successful receipt to the sending SMTP server.
In Exchange Server 2013, it no longer matters if a sending server supports shadow redundancy because
now a shadow copy is automatically created every time. By default, a shadow copy of a message is
removed after two days.
The main goal of shadow redundancy is to always have two copies of a message within a transport highavailability boundary while the message is in transit. This boundary is one of the following:
A DAG, for Mailbox servers that are members of a DAG. This includes a DAG that spans multiple
Active Directory sites.
An Active Directory site, for mailbox servers that do not belong to a DAG.
Where and when the redundant copy of the message is created depends on where the message
originated and where it is going. There are three major determining factors:
Messages received from outside a transport high-availability boundary.
Messages sent outside a transport high-availability boundary.
Messages received from the mailbox transport submission service from a mailbox server within the
transport high-availability boundary.
Note: Shadow redundancy never tracks shadow messages across a transport highavailability boundary.
How Shadow Redundancy Works

The following is an example of how shadow redundancy works in a DAG:
1.
An SMTP server connects to the Transport service on a mailbox server where the active database of
the target recipient is mounted and transmits a message. Once the message is received, the session
stays active.
2.
The transport service opens a new Simple Mail Transfer Protocol (SMTP) session to a transport service
on another mailbox server in the same DAG to create a redundant copy of the message. If the DAG
spans multiple Active Directory sites, a mailbox server in another Active Directory site is preferred by
default. The copy of the message is the shadow message, and the mailbox server that holds it is the
shadow server for the primary server. The message exists in a shadow queue on the shadow server.
3.
After the message is successfully transmitted to the shadow server, the server acknowledges receipt of
the message to the SMTP server and closes the connection.
Note: If the Mailbox server is not member of a DAG, any mailbox server in the same Active
Directory site will be used a shadow server.
When Shadow Messages are Removed
When the server successfully transmits the message to the database, the server updates the discard status
of the message when the delivery completes. The discard status is essentially a message that contains of
list of messages that are being monitored. A successfully delivered message does not need to be kept in
a shadow queue. Once the shadow server knows the primary server has successfully transmitted the
message to the next hop, the shadow server moves the shadow message from the shadow queue into the
Safety Net.
How Message Recovery Works
When a mailbox server experiences an outage due to a hardware failure, each mailbox server that has
shadow messages queued for that mailbox server will assume ownership of those messages. When the
server comes back online again, it will try to resubmit the messages. All messages are then redelivered
to their destinations. This results in duplicate delivery of the messages. However, Exchange Server
automatically detects duplicate messages and will not add them to the database again. Only the messages
that are not already in the database will be added.
Safety Net
Safety net is a special message queue available in the Transport service on every Mailbox server. This
queue stores by default up to two days of messages that were successfully delivered to a mailbox
database. Safety net protects against mailbox server failures when transaction logs have been lost. If a
failure occurs and some transaction logs are not replicated to the passive copy, you can use safety net
to redeliver messages.
Safety net is improved in Exchange Server 2013 in the following ways:
Safety net is now redundant and uses Shadow Redundancy to provide a Shadow Safety Net queue
on another server. Shadow redundancy no longer needs to keep another copy of the message as it
did in Exchange Server 2010. If the primary Safety net is unavailable for more than 12 hours, resubmit
requests become shadow resubmit requests, and messages are redelivered from the shadow safety
net.
Safety net no longer requires DAGs. It essentially uses the same server that is used for shadow
redundancy to store a shadow safety net copy.
How Safety Net Works

Safety net works as follows when shadow redundancy is finished:
1.
The transport service on the primary server processes the primary message. The Mailbox Transport
service delivers the message to the local mailbox database. The message then is moved from the
queue to the primary safety net queue.
2.
The shadow server frequently polls the primary server for the discard status of the primary message.
Once the status is received, the shadow server moves the message from the shadow queue to the
shadow safety net queue.
Understanding How High Availability Works with Edge Transport Servers

The Edge Transport server role is not available in
the released version of Exchange Server 2013. You
can use an Exchange Server 2007 or 2010 Edge
Transport server, which are fully supported. The
functionality for high availability remains the same
with Exchange Server 2013 as in Exchange Server
2007 or 2010.
To make the Edge Transport server role highly
available, you can install a second Edge Transport
server and configure EdgeSync. For external
message delivery, no additional configuration
is required. For message reception, you must
configure an additional mail exchange (MX) record for the second Edge Transport server. If both MX
records have the same priority, then incoming messages are load balanced between the two Edge
Transport servers.
To provide network redundancy for message delivery to the Internet, you can use two Internet service
providers (ISPs). Many firewalls are capable of failing over to a second Internet connection when the
primary connection fails. To receive messages on the second Internet connection, you must create
additional MX records.
If your Exchange Server organization has multiple points of contact with the Internet and multiple
locations with Edge Transport servers, this does not provide redundancy for outgoing messages. Messages
are delivered only on the lowest-cost path. If the Edge Transport servers on the least-cost path are
unavailable, the messages are queued on a Mailbox server for delivery to the Edge Transport server.
Routing paths are not recalculated based on availability.
What Is Site Resilience?

Site resilience is the ability of the messaging
system to survive a site failure, and to continue
functioning through the use of an alternate data
center. In some cases, the alternate data center is
a site that is dedicated only to disaster recovery.
In other cases, the alternate data center might
be another company site that is in use, but has
sufficient capacity to handle services for the failed
location.
A DAG is capable of existing across multiple

subnets. This means that a DAG can exist across
multiple Active Directory sites. This is a major
improvement from previous versions of Exchange Server 2010, which required you to extend a subnet
across a WAN link.
Site resilience exists only for Mailbox servers. Any other required server roles must already exist in the site
or they will not fail over. For example, Client Access servers should already exist in the alternate data
center. Other services, such as DNS, domain controllers, and global catalog servers, also must be available
in the alternate data center.
Discussion: Virtualization High-Availability Technologies versus Exchange

High-Availability Technologies for Mailbox Servers
Discuss virtualization high-availability
technologies versus Exchange Server highavailability technologies for Mailbox servers.
Lead the discussion with the following questions:
Do you currently use virtualization for

maintaining high availability of Exchange
Server 2010 Mailbox Servers such as HyperV in Windows Server 2012 clustering?
What are the advantages and disadvantages

of using virtualization versus DAGs?
Which of these approaches would you

recommend: virtualizing mailbox servers on multiple hosts, or using multiple physical mailbox servers
with DAGs? Why do you make this recommendation?
Lesson 2
Configuring Highly Available Mailbox Databases

Historically, the Mailbox server role has been the most complex and critical component in a highly
available Exchange Server deployment. Although this remains true to some extent, in Exchange Server
2013 the complexity of deploying a highly available mailbox server is reduced. The DAG configuration
also reduces the likelihood that administrators will configure a mailbox server cluster improperly.
Lesson Objectives
Plan software and hardware components for DAGs.
Describe Active Manager.
Describe continuous replication.
Describe how database availability groups protect databases.
Create and configure a DAG.
Configure databases for high availability.
Describe lagged mailbox database copies.
Describe the failover process.
Describe how you can perform DAG monitoring and management.
Monitor replication health.
What Is a Quorum?
The quorum maintains the logic so that a cluster
knows which node is active, and which nodes are
passive. In addition, the quorum decides which
passive node will be activated if the active node
fails. The failover-cluster quorum configuration,
as used by the Exchange Server 2013 DAG,
determines the number of failed nodes, or failed
storage and network components that the cluster
can sustain while it continues to function.
A quorum prevents two sets of nodes from

operating simultaneously as the failover cluster.
Simultaneous operation could occur 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, causing a partition
within the cluster.
To prevent problems caused by a split in the cluster, failover clusters use a voting algorithm to determine
whether the cluster has enough votes to maintain a 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 will continue to listen for the
presence of other nodes, in case another node appears again on the network. However, 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 2013 can be a node or a witness
file share. When a majority of the votes is not available, or when only half of the votes are available, the
cluster will not start. In addition, when the majority drops below half of the available votes, Exchange
Server 2013 will dismount the databases.
Note: Exchange Server 2013 also supports placing the witness server in another site.
Windows Server 2012 Quorum Configurations
Windows Server 2012 provides the four quorum configurations: node majority, node and file share
majority, node and disk majority, and no majority: disk only. However, Exchange Server 2013 only
supports node and file share majority. In the node and file share majority configuration, each cluster
node plus a designated file share (also referred to as a witness server in Exchange Server 2013) can vote.
The cluster only functions with a majority of the votes, meaning that more than half of the votes are
available. If an active cluster loses communication with more than half of its votes, it will stop functioning.
Configuring Non-Voting Cluster Nodes
In Windows Server 2012, you can configure nodes that do not have a vote in the cluster to maintain a
quorum. You can configure Failover Cluster Manager using the Configure Cluster Quorum Wizard.
Exchange Server 2013 supports this configuration; however, you should carefully consider whether you
should use it.
For example, consider the site-resiliency scenario that provides additional local failures if the quorum is
lost. In this scenario, there are five DAG members, three in the primary site, and two in the failover site. If
needed, you can remove the votes of the two members in the failover site. This is possible because if the
secondary site fails, you still have one additional failure in your local site before the cluster will shut down
if the quorum is lost.
Planning Software and Hardware Components for Database Availability

Groups
When you implement a DAG, you must ensure
that you meet several very specific requirements.
You need to consider the requirements related to
general configuration, operating system version,
network configuration, and DAG configuration.
General Configuration
The general requirements for implementing a
DAG are:
DNS must be implemented with a host record

for each Exchange server. Dynamic updates
for DNS are preferred.
Each Mailbox server must be a member of the same domain. It is not possible to have Mailbox servers
in different Active Directory domains as members of the same DAG.
The Mailbox servers that are members of a DAG cannot also be domain controllers. This configuration
is not supported.
The computer name for the Mailbox server must be unique, and must be 15 characters or fewer.
Operating System Version
All members of a DAG must run the same operating system version. All DAG members must be running
either Windows Server 2008 R2 or Windows Server 2012. You cannot combine the two operating system
versions within the same DAG. The join to the DAG will fail if you try to join two different versions of the
operating system.
A DAG is based on the use of failover clustering in Windows Server. Only the Enterprise or Datacenter
versions of Microsoft Windows Server 2008 R2 or the Standard and Datacenter versions of Windows
Server 2012 include failover clustering. Therefore, you can use only these operating system versions for
DAG members.
Network Configuration
The network configuration requirements include the following:
One network adapter is supported; however, we recommend two network adapters. This allows you
to configure a messaging application programming interface (MAPI) network and a separate
replication network.
Latency between DAG members must be less than 500 milliseconds. This is important when you
configure a DAG with members in multiple physical locations.
You can use Internet Protocol version 6 (IPv6) only if Internet Protocol version 4 (IPv4) also is
configured. You cannot disable IPv4.
Automatic Private Internet Protocol Addressing (APIPA) is not supported for DAG members.
DAG Configuration
In addition to the physical network and IP addressing requirements for the DAG member servers, the DAG
itself has the following requirements:
The DAG must have at least one IP address on the MAPI network. This address can be static or
dynamic, although a static IP address is used in most environments.
If the DAG is expanded across multiple subnets, then the DAG must have an IP address on each
subnet.
The name of the DAG and the name of each DAG member must be 15 characters or less, and must be
unique.
Witness Server
Failover clustering in Windows Server 2012 uses the concept of a quorum for decision making in the
cluster. In clusters with a shared disk, connectivity to the shared disk can be used to define which nodes
potentially should be active in the cluster. In a DAG, there is no central disk.
A DAG requires the use of a witness server for a node and a file-share majority quorum. The witness server
functions as an additional DAG member for determining the quorum; however, it is only used when there
is an even number of members in the DAG. The witness server is a file share located on a server that is not
a DAG member.
The quorum for a DAG determines which members participate in replications, and which can mount
databases. For example, if one computer in a DAG loses network communication, that computer is not
part of the quorum and cannot mount databases.
We recommend that you configure the witness server on a Client Access server in the Exchange Server
organization. The additional load on the server is minimal, and it is already under the control of the
Exchange Server management group. The witness server does not need to run the same version of
Windows Server as the members of the DAG.
If the DAG witness server is not an Exchange server, then you need to add the Exchange Trusted
Subsystem group as a member of the local Administrators group on the witness server.
What Is Active Manager?

To manage mailbox database replication and
activation, Exchange Server 2013 includes a
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 that Microsoft Exchange Server
2003 and Exchange Server 2007 used. To simplify
the architecture, Active Manager runs on all
Mailbox servers, even if the server is not part of
a DAG.
Active Manager runs on all of the DAG members either as the Primary Active Manager or a Standby
Active Manager. The Primary Active Manager 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
for reacting to server failures. The DAG member that acts as the Primary Active Manager is always the
member that currently owns the default cluster group. To identify the Primary Active Manager, we
recommend that you 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.
The Standby Active Manager function has an active, not passive role. It provides information about which
server hosts the active copy of a mailbox database. The Standby Active Manager detects local database
and Microsoft Exchange Information Store failures, and reacts to them by requesting that the Primary
Active Manager initiate a failover when a copy is available. A Standby Active Manager does not determine
a failover target; nor does it update a databases location state for the Primary Active Manager. Each
Standby Active Manager accesses the state of the active database copy so that it can redirect Client Access
server requests. The Primary Active Manager also performs the functions of the Standby Active Manager
role on the local system.
What Is Continuous Replication?

Continuous replication was introduced for
Mailbox servers in Exchange Server 2007, and
Exchange Server 2010 continued to use
continuous replication. Since the release of
Exchange Server 2010 Service Pack 1 (SP1), there
are two more available options for continuous
replication: file mode and continuous replication
block mode.
Continuous Replication File 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
process includes the following steps:
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 the servers that host the passive databases.
3.
Because each copy of the database is identical, the transaction logs are inspected and then replayed
or applied to the database copies. The databases remain synchronized.
In Exchange Server 2013 seeding, you are no longer required to use the active copy as the source for the
seed. In addition, in Exchange Server 2013, you 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 in the following ways:
Automatically.
Manually, from the active or passive copies using the Update-MailboxDatabaseCopy cmdlet.
Manually, by copying the database files.
Continuous replication occurs over TCP sockets. Continuous replication occurs as follows:
1.
The target, or passive node notifies the active instance which transaction logs it expects.
2.
The source responds with the required transaction log files.
3.
After Exchange Server 2013 copies the log files, it places them in the target inspector directory for
processing.
4.
Log inspection verifies that the data is physically sound, and inspects the header. If the log passes
inspection, Exchange Server 2013 places the log in the target log directory. If the log does not pass
inspection, Exchange Server 2013 requests it from the source up to three times before failing.
5.
After Exchange Server 2013 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 Replication Block Mode
Continuous replication block mode was introduced in Exchange Server 2010 SP1. Block mode
reduces the exposure of data loss on failover by replicating the Extensible Storage Engine (ESE) log buffer,
which 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 copied automatically to the replication log buffer, and then to all of the
servers that host passive copies of the active database.
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,
the buffer on the server hosting the passive copy of the database is saved to a new transactional log
file.
Replication transport is identical 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 both the
possibility of data loss during a failover and the time it takes to perform a switchover.
Configuring a Database Availability Group

To configure a DAG, you must understand the
different settings that are available. Some of
these settings, such as the DAG IP address, are
required for every configuration. You can consider
other settings, such as network compression
settings, when you want to fine-tune your
DAG configuration. To plan your DAGs correctly,
you must understand the purpose of each
configuration setting available, so that you can
decide if you require it for your own Exchange
organization.
In the Exchange Management Console, the
following settings are available:
Witness Server. The server that you want to use as witness server. As a best practice, we recommend
that you use a Client Access 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 that you will enable
when the first witness server is no longer available.
Alternative Witness Directory. The directory that you will use 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 using a static IP addresses, or by using a Dynamic Host Configuration Protocol (DHCP)
server to get an IP address automatically. In addition to the DAG name, this is the only required
setting, and 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 MAPI traffic. Although Exchange Server supports one network adapter and path, we recommend
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 can configure replication in the EAC.
Note: If you disable replication on a DAG network to preserve it for MAPI traffic, this does
not automatically prevent the replication traffic from using the network. If no other network is
available, replication traffic will automatically use the other DAG network.
When you implement a DAG across multiple sites, you need to configure the DAG networks. A DAG
supports multiple subnets on the MAPI network, and on the replication network. Therefore, subnets do
not need to span a WAN link.
When you configure the multisite DAG, you must 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, if you configure multiple networks, there can be no routing between the MAPI
network and the replication network, or between replication networks.
DAG Network Compression
DAGs provide built-in compression for network traffic. This is based on an algorithm called XPRESS, which
is the Microsoft implementation of the LZ77 algorithm. The following options are used to configure DAG
network compression:
Disabled. Network traffic is not compressed.
Enabled. Compression is used for replication and seeding.
InterSubnetOnly. This is the default setting in which compression is only used when replicating across
different subnets within the subnet traffic that is not compressed.
SeedOnly. Compression is used only for seeding.
You can configure DAG network compression 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. This is the default setting in which network traffic is encrypted when replicating
across different subnets, within the subnet traffic that is not encrypted.
SeedOnly. Network traffic is only encrypted for seeding.
You can configure DAG network encryption using the following cmdlet:
Set-DatabaseAvailabilityGroup <DAG name> -NetworkEncrytion <Option>
Third-Party Replication Mode
By default, a DAG is designed to use the built-in continuous replication feature to replicate mailbox
databases among servers in the DAG. If your organization uses a third-party data-replication solution
that supports the third-party replication API in Exchange Server 2013, you also can configure the
DAG to use your third-party solution instead of the built-in replication feature. You use the
New-DatabaseAvailabilityGroup cmdlet to configure the DAG to use a third-party replication solution.
It can only be disabled by removing and re-creating 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.
You must specify the following information when
creating a mailbox database copy:
The name of the database you are copying.
The name of the Mailbox server that will host the database copy.
An activation preference number. This is referred to as a preferred list sequence number, and it
represents the activation preference order of a database copy after a failure or outage of the active
copy.
The amount of time (in minutes) for the log replay delay. This is the replay lag time, which specifies
how long to wait before the logs are committed to the database copy. Setting the value for replay lag
time to 0 turns off log replay delay.
The amount of time (in minutes) for log truncation delay. This is the truncation lag time, which
specifies how long to wait before truncating committed transaction logs. Setting the value for
truncation lag time to 0 turns off log truncation delay.
What Are Lagged Mailbox Database Copies?

A lagged mailbox database copy is a database
that uses a delayed replay lag time to commit the
log files to the database. This allows you to go
back to a point in time (a maximum of 14 days).
By delaying the replay of logs in to a database,
you have the capability to recover it to a point in
the past.
Lagged database copies can protect you from the
extremely rare logical corruption types of cases,
which include the following:
Database Logical Corruption
This is when the database pages checksum matches, but the data on the pages is logically wrong. It
can occur when the ESE attempts to write a database page and the operating system storage stack
returns success even though the data either never makes it to disk or gets written to the wrong place.
This behavior is called lost flush. To prevent lost flushes, ESE includes a lost-flush detection mechanism
in the database with the single page restore feature.
Store Logical Corruption
This indicates that data is added, deleted, or modified in a way that is not accepted by the user, so the
user views it as a corruption. Typically, this is caused by a third-party application that issues a series of
valid MAPI operations against the store. An example is a corrupt archiving solution that changes all user
message items. Single-item recovery or retention hold provides some protection against this case because
all changed items are kept and therefore can be restored. However, particularly when large amounts of
data is changed, it might be easier to recover the database to a point back in time before the corruption
occurred.
Rogue Admin Protection
This is when the organization seeks protection against malicious or rogue administrators. This mainly
protects against administrators who intentionally add, change, or remove data from the system in a way
that users find undesirable. To protect against this, the lag database copies can be placed on a server that
is under separate administrative control. Lagged database copies have been enhanced in Exchange Server
2013 in the following way:
Automatic log play down. Lagged copies can now implement their log files to a certain extent using
automatic log play down. When enabled, lagged copies will automatically play down log files in a
variety of situations, such as page patching and low disk space scenarios. If the system detects that
page patching is required for a lagged copy, the logs will automatically replay into the lagged copy
to perform page patching. Lagged copies will also invoke this auto replay feature when a low disk
space threshold has been reached, and when the lagged copy has been detected as the only available
copy for a specific period of time. You can enable automatic log play down for your lagged databases
by using the following cmdlet: Set-DatabaseAvailabilityGroup <DAGName>
ReplayLagManagerEnabled $True.
Simpler activation with Safety Net. Lagged copies leverage Safety Net so therefore recovery or
activation is now much easier. For more information about Safety Net, see the Understanding
How Transport High Availability Works topic earlier in this module.
You can configure a lagged database in the EAC or in the Exchange Management Shell.
Demonstration: How to Create and Configure a Database Availability

Group
In this demonstration, you perform the following:
Pre-stage the cluster network object for a database availability group (DAG).
Create a new DAG.
Add members to a DAG.
Add a mailbox database copy for Mailbox Database 1.
Demonstration Steps
1.
On the LON-DC1 machine, in Active Directory Users and Computers, create a computer object named
DAG1 and assign Full control permission to Exchange Trusted Subsystem group and LON-MBX1
(ADATUM\LON-MBX1$) computer account.
2.
Switch to LON-CAS1, open Windows Internet Explorer, and access the EAC. Create a Database
Availability Group named DAG1.
3.
Add LON-MBX1 and LON-MBX2 to DAG1.
4.
Add a database copy on LON-MBX2 for Mailbox Database 1.
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 that hosts
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. In Exchange Server 2013, this process is called best copy
and server selection (BCSS). While selecting the best copy to activate, Active Manager:
Creates a list of database copies that are potential candidates for activation.
Ignores and removes from the list any database copies that are unreachable or are administratively
blocked from activation.
Sorts the resulting list by using the copy queue length as the primary key. 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.
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 order set of criteria. These criteria
include various combinations of settings such as content indexing status, copy queue length, and
replay queue length. New in Exchange Server 2013 are additional criteria that measure the health
of the entire protocol stack and also consider a prioritized protocol health set in the selection.
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 then 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:
o
BestAvailability. This value allows the database to be automatically mounted if the copy queue
length, which is the number of logs that have not been replicated to the target mailbox server, is
less than or equal to 12. When Active Manager identifies the target server, Exchange Server 2013
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 2013 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 2013 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 BestAvailability as allowing for 12 missing transaction logs,
and GoodAvailability as only allowing six. In this case, however, 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
service loss. 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.
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 using the copy queue
length.
Planning, Monitoring, and Managing a Database Availability Group

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 you create and manage DAGs and database
copies. You can delegate these permissions using
role-based access control (RBAC). RBAC is the
permission model for Exchange Server 2013, and
is explained in more detail in Module 10.
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 unique challenge when you manage 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 that you can monitor DAG members is
by using Microsoft System Center Operations Manager 2012 (SCOM). SCOM 2012 proactively monitors
servers, and can notify administrators when errors and events occur.
Exchange Server 2013 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 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 includes metrics for continuous replication block mode, and more details from the replication and replay pipeline. 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 Server specific 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 2013 provides the following cmdlets for server maintenance:
Get-ServerComponentState. This cmdlet shows all the components of an Exchange server and the
current state of each component.
Set-ServerComponentState. This cmdlet performs server switchovers, and takes mailbox servers
offline or online.
Note: For examples on how to use the monitoring tools included in Exchange Server 2013,
see Monitoring High Availability and Site Resilience in the Exchange Server 2013 help file.
Demonstration: How to Monitor Replication Health
Demonstrate how to use the Exchange Management Console and Exchange Management Shell to review
the available information regarding database replication health.
In the demonstration, show how to view the health status of the database copies in the EAC or Exchange
Management Shell.
Demonstration Steps
1.
On the LON-CAS1, in the EAC, show details pane of Mailbox Database 1.
2.
Open Exchange Management Shell and run the following cmdlets:
3.
Test-ReplicationHealth
Get-MailboxDatabaseCopyStatus Server LON-MBX1
Run the following script:

o
CheckDatabaseRedundancy.ps1 MailboxDatabaseName Mailbox Database 1,
Lesson 3
Configuring Highly Available Client Access Servers

When you consider high availability with Exchange Server 2013, in addition to focusing on mailbox
servers, database copies or DAGs, you also must make sure that the Client Access servers are highly
available so that you can attain your required service levels.
Lesson Objectives
Plan software and hardware components for highly available Client Access servers.
Describe Network Load Balancing (NLB).
Consider options for implementing high availability for Client Access servers.
Configure options for highly available Client Access servers.
Planning Software and Hardware Components for Highly Available Client

Access Servers
All clients use Client Access servers to access
mailboxes. If a Client Access server is not available
in an Active Directory site, users can access a
Client Access server in another site.
If the users on the Internet connect to Client
Access servers in a single main Active Directory
site, and those requests are proxied to other
Active Directory sites, the failure of Client Access
servers in the main sites prevents access to those
proxied sites. Consequently, high availability
becomes critical for the main site that proxies the
requests.
To 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 2012 Network Load Balancing feature). You also can create multiple A records in DNS for your
Client Access servers, and you can 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.
Load balancing spreads client requests between the Client Access servers. If one Client Access server
becomes unavailable, then requests are handled by the remaining Client Access servers.
All Client Access servers should be configured with the same digital Secure Sockets Layer (SSL) certificate.
This is because all Client Access servers use the name specified in the Client Access server array.
Internet Users
For Internet users, you need to consider redundant Internet connections as part of your design. You
can have two separate Internet Service Providers (ISPs), and allow access through both ISPs to the Client
Access servers in your organization. If one ISP experiences a failure, users can access their mailbox content
by using the alternate ISP at a different domain name.
Alternatively, if you configure each Active Directory site to be available directly from the Internet, the
failure of a single Internet connection affects connectivity only to one Active Directory site. This mitigates
the damage caused by failure, but it does not provide complete redundancy.
What Is Network Load Balancing?

Network Load Balancing (NLB) enhances the
availability and scalability of server applications
such as those used on the Web server, File
Transfer Protocol (FTP), firewall, proxy, virtual
private network (VPN), and other servers.
A single computer running Windows Server can
provide a limited level of server reliability and
scalable performance. With NLB, you can group
up to 32 host computers in a NLB cluster to
provide load balancing and redundancy. Because
any server in an NLB cluster can respond to a
client request, both the application files and the
data on all servers must be identical.
You should be aware that hosts in a NLB cluster do not share data. Usually, this means that you either use
a separate, back-end server to store data or provide a way to synchronize the data on the Web servers.
However, this requirement limits the applications that are suitable for load balancing. Sometimes, these
applications are called stateless.
Key Benefits of Network Load Balancing

NLB hosts in a cluster communicate among the other hosts to provide the following key benefits:
Scalability. NLB allows you to scale network services to meet client demand. You can add new servers
to a load-balancing cluster without rewriting applications or reconfiguring clients. You do not need
to take the load-balancing cluster offline to add new capacity, and members of the load-balancing
cluster do not need to be based on identical hardware.
High availability. NLB supports high availability by redirecting incoming network traffic to working
cluster hosts if a host fails or is offline. Existing connections to an offline host are lost, but Internet
services remain available. In most cases, for example with Web servers, client software automatically
retries the failed connections, and the clients experience a delay of only a few minutes before
receiving a response. Many applications work with NLB. In general, NLB can load balance any
application or service that uses Transmission Control Protocol/Internet Protocol (TCP/IP) as its
network protocol and is associated with a specific TCP or User Datagram Protocol (UDP) port.
Performance. NLB supports server performance scaling by distributing incoming network traffic
among one or more virtual IP addresses assigned to the NLB cluster. The hosts in the cluster
concurrently respond to different client requests, even multiple requests from the same client. For
example, a web browser might obtain each of the multiple images on a single Web page from
different hosts within an NLB cluster. This speeds up processing and shortens the response time to
clients.
Considerations for Implementing Highly Available Client Access Servers

The following considerations should be taken into
account when you implement highly available
Client Access servers:
Management of digital certificates is

performed by the Client Access Server.
All digital certificates should match your
namespaces.
Know what protocols should be handled by

your Client Access servers. It is important to
enable the following protocols on all Client
Access servers:
o
Exchange ActiveSync
POP3
IMAP4
EWS
Outlook Anywhere
Use a hardware or software network load balancer for a service-aware, high-availability configuration.
You can configure the load balancers to use layer 4 or layer 7 load balancing. When using layer 7
load balancing and session affinity, all requests between the client and the server are sent to the same
Mailbox server. When using layer 4 load balancing, the requests are distributed at the transport layer.
Exchange Server 2013 does not require session affinity. Layer 4 load balancing without session affinity
allows you to increase the capacity and utilization of the load balancer because processing is not used
to maintain more involved affinity options such as IP-based load balancing.
Always try to deploy Client Access servers with similar hardware, memory, and performance, so that
you can understand when a system is causing issues.
Demonstration: Configuring Options for Highly Available Client Access

Servers
In this demonstration, you will see how to configure a DNS round-robin for the two Client Access servers
LON-CAS1 and LON-CAS2.
Demonstration Steps
1.
On the LON-DC1, open DNS Manager.
2.
Create a new host named webmail.adatum.com and add IP address 172.16.0.21.
3.
Create a new host named webmail.adatum.com and add IP address 172.16.0.22.

Scenario
You are the messaging administrator for A. Datum Corporation. You have completed the basic installation
for four Exchange Server 2013 servers. Now you must complete the configuration so that they are highly
available. This basically requires you to configure your mailbox databases as well as your Client Access
servers to be highly available, and to test if an automatic failover works.
Objectives
The students will be able to implement high availability in the Exchange Server 2013 environment.
Lab Setup
Virtual machines
20341B-LON-DC1
20341B-LON-CAS1
20341B-LON-CAS2
20341B-LON-MBX1
20341B-LON-MBX2
User Name
Password
Pa$$w0rd
1.
2.
3.
4.
5.
6.
Password: Pa$$w0rd
a.
b.
c.
d.
e.
f.
g.
Repeat steps 2 to 4 for 20341B-LON-MBX1, 20341B-LON-MBX2, 20341B-LON-CAS1, and

20341B-LON-CAS2.
Exercise 1: Creating and Configuring a Database Availability Group

Scenario
To complete the Mailbox server high-availability configuration, create a database availability group (DAG),
and make the Mailbox Database 1 database highly available.
1.
Pre-stage the cluster network object for a DAG.
2.
Create a DAG and add mailbox servers to the DAG.
3.
Create a mailbox database copy.
4.
Verify successful completion of copying a database.
5.
Suspend and resume a database copy.
Task 1: Pre-stage the cluster network object for a DAG

1.
On LON-DC1, in Server Manager, open Active Directory Users and Computers.
2.
In Active Directory Users and Computers, enable Advanced Features.
3.
In the left pane, expand Adatum.com, and create a computer object named DAG1 in Computers
container.
4.
Change DAG1s security settings as follows:
5.
Exchange Trusted Subsystem group: Allow Full control
LON-MBX1 (ADATUM\LON-MBX1$): Allow Full control
Disable the DAG1 computer account.
Task 2: Create a DAG and add mailbox servers to the DAG

1.
Switch to LON-CAS1. Open Internet Explorer, and type https://lon-cas1.adatum.com/ecp, and

sign in as Adatum\administrator with the password Pa$$w0rd.
2.
In the EAC, create a new Database Availability Group using the following settings:
3.
Database availability group name: DAG1
Witness server: LON-CAS1
Witness directory: C:\FSWDAG1
Database availability group IP addresses: 172.16.0.33
Manage DAG membership for DAG1, and add the following servers:
o
LON-MBX1
LON-MBX2
Task 3: Create a mailbox database copy

1.
In the EAC, click databases.
2.
For Mailbox Database 1, add a mailbox database copy to LON-MBX2.
Task 4: Verify successful completion of copying a database

1.
In tabs, click Refresh, and wait until the details pane shows Mailbox Database 1\LON-MBX2 as
Passive Healthy. This might take several minutes and up to several hours depending on the size of
the database.
2.
View details for Mailbox Database 1\LON-MBX2 and verify the following:
o
Status: Healthy
Content index state: Healthy.
Task 5: Suspend and resume a database copy

1.
In the EAC, suspend Mailbox Database 1\LON-MBX2.
2.
Resume Mailbox Database 1\LON-MBX2. If the Resume button is not available, wait and then click
Refresh a few more times. Verify in the details pane that copy queue length is zero.
Results: After completing this exercise, students will have pre-staged a cluster network object in Active
Directory, created a DAG, added two Mailbox servers to the DAG, and made a database highly available.
Students also will have suspended a database copy and resumed it.
Exercise 2: Deploying Highly Available Client Access Servers

Scenario
You decide to implement software Network Load Balancing (NLB) to load balance LON-CAS1 and
LON-CAS2 for Client Access server connections. You will use the IP address 172.16.0.6 as the virtual IP
address that handles the mail.adatum.com namespace for your client server connections. Now you must
complete the configuration to achieve this.
1.
Install the Network Load Balancing feature on Client Access servers.
2.
Create a load-balanced Client Access server cluster.
3.
Create a DNS record for the virtual IP address.
Task 1: Install the Network Load Balancing feature on Client Access servers
1.
Switch to LON-CAS1.
2.
In Server Manager, in the Add Roles and Features Wizard, add the following feature:
o
3.
Network Load Balancing
Switch to the LON-CAS2 virtual machine, in Server Manager, in the Add Roles and Features Wizard,
add the following feature:
o
Network Load Balancing
Task 2: Create a load-balanced Client Access server cluster

1.
Switch to LON-CAS1, and in Server Manager, open Network Load Balancing Manager.
2.
In the Network Load Balancing Manager, create a new Cluster with the following settings:
3.
HOST: LON-CAS1
Cluster IP Address: 172.16.0.6, Subnet mask: 255.255.0.0
Full Internet name: Webmail.adatum.com
Add the following host to cluster Webmail.adatum.com:

o
LON-CAS2
Task 3: Create a DNS record for the virtual IP address

1.
Switch to LON-DC1, and in Server Manager, open DNS.
2.
In the DNS Manager, under Adatum.com, create a new host with the following settings:
o
Name: Webmail
IP address: 172.16.0.6
Results: After completing this exercise, the students will have installed and configured NLB, and created a
DNS record for their load-balanced virtual IP address.
Exercise 3: Testing the High-Availability Configuration

Scenario
To verify that your high-availability configuration works as expected, you will check Client Access server
and DAG failover.
1.
Simulate failure on LON-CAS1 and verify Microsoft Outlook Web Access functionality.
2.
Enable LON-CAS1 and simulate a LON-CAS2 failure.
3.
Verify high availability of the database copies.
4.
Task 1: Simulate failure on LON-CAS1 and verify Microsoft Outlook Web Access
functionality
1.
Switch to LON-CAS1, and in Network Load Balancing Manager, stop LON-CAS1(Ethernet).
2.
Switch to LON-DC1, open Internet Explorer and type https://webmail.adatum.com/owa, and sign
in as Adatum\administrator with the password Pa$$w0rd.
3.
You should now see your Inbox. This indicates that LON-CAS2 is currently serving as the Client Access
server.
Task 2: Enable LON-CAS1 and simulate a LON-CAS2 failure

1.
Switch to the LON-CAS1 virtual machine, then in Network Load Balancing Manager, start
LON-CAS1(Ethernet).
2.
Switch to the Host machine, in Hyper-V Manager, turn off 20341B-LON-CAS2.
3.
Switch to the LON-DC1 virtual machine. In Internet Explorer, click Refresh (F5), and sign in as
Adatum\administrator with the password Pa$$w0rd.
4.
In Outlook Web App, verify that you can access folders such as Sent Items. This verifies that
LON-CAS1 took over the Client Access server role for the client.
Task 3: Verify high availability of the database copies

1.
Switch to LON-CAS1, and in the EAC, verify that Mailbox Database 1\LON-MBX1 is Active Mounted
and Mailbox Database 1\LON-MBX2 is Passive Healthy.
2.
Switch to the Host machine, in Hyper-V Manager, turn off 20341B-LON-MBX1.
3.
Switch to the LON-CAS1 virtual machine. In Internet Explorer, click Refresh (F5) and verify in the
EAC, that Mailbox Database 1\LON-MBX1 shows as Passive ServiceDown, and Mailbox Database
1\LON-MBX1 shows as Active Mounted.
4.
Switch to the LON-DC1 virtual machine, and in Internet Explorer and Outlook Web App, verify that
you can view folders such as Inbox and send a message.
following steps:
1.
2.
3.
4.
Repeat steps 2 to 3 for 20341B-LON-CAS1, 20341B-LON-CAS2, 20341B-LON-MBX1, and

20341B-LON-MBX2.
Note: Although some of the servers are not running, you must still revert them.
5.
6.
7.
8.
a.
b.
Password: Pa$$w0rd
Results: After completing this exercise, the students will have tested their high-availability configuration.

Review Question
Question: Your DAG has two mailbox servers (nodes) and one witness server. When will you
lose quorum and be unable to mount the databases automatically?
Best Practice
To decide for a witness server for a DAG, you should prefer a Client Access server over a file server.

Common Issue
You cannot add an Exchange server to a
DAG.
When you add a server to a DAG,

replication of the database fails.
Troubleshooting Tip

7-1
Module 7
Planning and Implementing Disaster Recovery
Contents:
Module Overview
7-1
Lesson 1: Planning for Disaster Mitigation
7-2
Lesson 2: Planning and Implementing Exchange Server 2013 Backup
7-8
Lesson 3: Planning and Implementing Exchange Server 2013 Recovery
7-13
Lab: Implementing Disaster Recovery for Exchange Server 2013
7-21
7-25
Module Overview
Backing up Exchange server data on a regular basis is an essential part of your general Exchange server
administration. Data backup enables you to restore the data at a later date, either in the event of data loss
or corruption, or for test purposes.
Backing up Exchange server is a relatively simple task, but the backup regime is determined by factors
such as backup hardware, backup windows durations, and restore constraints. Service Level Agreements
(SLAs) play a major part in determining backup regimes. If, for example, your SLA for Exchange server
specifies that Exchange services must not be down for more than two hours during a disaster, your
backup regime must be designed and performed with this goal in mind.
Exchange Server 2013 contains backup and restore features such as Exchange Native Data Protection that
you should consider before using the traditional backup-to-tape approach that organizations currently
use. This module describes backup and restore features of Exchange Server 2013, and the details that you
need to consider when you create a backup plan.
Objectives
Plan disaster mitigation.
Plan and implement Exchange Server 2013 backup.
Plan and implement Exchange Server 2013 recovery.
Lesson 1
Planning for Disaster Mitigation
7-2 Planning and Implementing Disaster Recovery
Disaster mitigation helps you to avoid the need for disaster recovery. It also allows you to recover data
much faster than you would with a full system restore. Exchange Server 2013 has improved the disaster
mitigation methods that are available to administrators, with new features such as database availability
groups (DAGs).
This lesson provides an overview of the options available in Exchange Server 2013 that enable you to
mitigate the effects of a disaster without restoring backups. The lesson also describes those scenarios
where backups are still required.
Lesson Objectives
Identify data-loss scenarios.
List data-loss mitigation features.
Plan a disaster mitigation strategy.
Describe the relationship between disaster recovery and high availability.
Describe Exchange Server Native Data Protection.
Describe when Exchange Server Native Data Protection is appropriate.
Describe the timelines for disaster recovery.
Identify scenarios that require backup and restore.
Identifying Data-Loss Scenarios

When you identify risks, you first must consider all
of the potential data-loss scenarios that can affect
users work. In an Exchange environment, possible
data-loss scenarios include lost item, lost mailbox,
lost database, and lost server.
Lost Item
A lost item from a mailbox often occurs because

a user deleted the item either accidently or on
purpose, and the user later realizes that the item
was required. One lost mailbox item typically
consists of a small amount of data. However, that
small amount of data can be very important. Lost
items often include an email message or a calendar item, and may include attachments important to the
user.
Lost Mailbox
A lost mailbox typically occurs when the Exchange administrator deletes a users mailbox. While this
could happen accidentally, it more commonly occurs when a user leaves the organization. In a common
scenario, after a user leaves the organization, the users manager needs access to the mailbox to view
projects on which the user was working. However, because the administrator already deleted the mailbox,
its contents are no longer available for viewing by the manager.
Lost Database
A lost database results in a loss of all mailboxes in that database. In addition, while the database is
missing, the users whose mailboxes are in this database can no longer send and or receive messages.
A lost database typically occurs because of a system malfunction, which can include disk failure or
database corruption. Lost database recovery is critical, because many users may be affected by the
outage.
Lost Server
A lost server results in a loss of all databases located on that server. A lost server typically occurs because
of a system or infrastructure failure. Lost server recovery is critical, because many users may be affected. In
the event that a data center is lost, multiple servers could also be lost.
Data-Loss Mitigation Features

Exchange Server 2013 includes a number of
features that you can use to mitigate data loss.
This is important because when data loss is
mitigated, you do not need to perform recovery
from a backup. Typically, it is much faster to use
these data-loss mitigation methods before you
attempt to perform recovery from a backup.
Deleted Items Recovery
In earlier versions of Exchange, items that were

deleted from a user were still recoverable until
the items were purged from the dumpster. A hard
delete (performed by clicking SHIFT + DELETE)
permanently removes the messages from the mailbox. In Exchange Server 2013, the dumpster is replaced
by the Recoverable Items store. If you do not modify the default retention times, messages are purged
from the mailbox database after 14 days, and calendar items after 120 days.
Single-Item Recovery
Microsoft Exchange Server 2010 introduced single-item recovery, a new feature that you could use to
recover items without having to restore the mailbox database using a backup. This feature is disabled by
default and needs to be enabled for each mailbox. Without single-item recovery enabled, items that are
purged from the Recoverable Items store can only be recovered through a backup of the mailbox
database.
When single-item recovery is enabled, all items in the Recovery Items store are preserved and cannot be
deleted by the user. Without single-item recovery in place, items are purged after 14 days, and calendar
items after 120 days. These default activities do not apply when the Recoverable Item warning quota is
reached. In that instance the items are purged in a first-in, first-out order.
In-Place Hold
Another option you can use to recover items from a users mailbox is to enable In-Place Hold for the user.
With this feature, all items that are deleted from the users mailbox are preserved in the Recoverable Items
store, and can be recovered through an eDiscovery search on the users mailbox. Administrators can
search and recover held items. Users can not search or recover the held items.
Additional Data-Loss Mitigation Features

Other data-loss mitigation features include:
Deleted mailbox retention. Use deleted mailbox retention to recover deleted mailboxes and their
contents. By default, Exchange Server 2013 retains deleted mailboxes for 30 days.
DAG. Use a DAG in most scenarios, to recover from a lost server or database. When a server or
database fails, Exchange Server 2013 activates a copy of that database automatically on another
member of the DAG. This process is much faster than restoring from a backup. When combined with
site resilience, a DAG mitigates the loss of an entire data center.
Shadow redundancy. In Exchange Server 2013, the transport server now makes a copy of each
message that it receives before it sends an acknowledgement to the sending server that it successfully
received the message. If Exchange Server 2013 determines that the original message was lost in
transit, the copy of the message is redelivered.
Planning a Disaster Mitigation Strategy

When you implement Exchange Server 2013,
the default configuration is sufficient for many
organizations. However, if you plan a disaster
mitigation strategy, consider the following:
Increase deleted item retention so that the

items are recoverable for a longer time
period, but in most cases, the default
configuration of 14 days is sufficient.
Increase deleted-item retention for critical

users. By increasing the retention time
for critical users, you limit the increase in
database size and better meet critical users
requirements.
Enable single-item recovery to ensure that all items are recoverable. Single-item recovery prevents
users from hard-deleting items and purging them from the Recoverable Items Store. With this option
enabled, an administrator can recover items if needed.
Increase deleted mailbox retention to make mailboxes recoverable for a longer time period, but for
sure, in most cases, the default configuration of 30 days is sufficient.
Use DAGs to provide a server-level redundancy and avoid data loss. You must have the Enterprise
version of the Windows Server 2008 R2 operating system or the Standard or Datacenter version of
Windows Server 2012 installed.
Use a lagged copy to prevent database corruption. Database corruption can occur when a transaction
is placed in the transaction logs. In such cases, a lagged passive copy with a configured replay lag
time may prevent corruption of the lagged passive copy, because you can prevent the offending
transaction from being replayed on the lagged passive copy.
Discussion: What Is the Relationship Between Disaster Recovery and High

Availability?
Use the discussion questions to help examine the
relationship between disaster recovery and high
availability.
Question: What high-availability features can
you use as a first line against a disaster?
Question: Would your organization accept
using only high availability features and not
use backups?
Exchange Server Native Data Protection

Exchange Server 2013 enables a much tighter
integration of high availability with disaster
recovery, especially if the Exchange Server 2013
high-availability features are sufficient for your
backup requirements.
Starting with Exchange Server 2010, a new feature
called Exchange Native Data Protection is included
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:
High availability to minimize downtime and data loss. If Exchange Server 2013 DAGs are the primary
means of disaster recovery, you can use their high availability features 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 sites. This 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 a database than to back up very large databases.
Single-item recovery and In-Place hold policies for recovering deleted messages. In Exchange Server
2013, single-item recovery ensures that all deleted and modified items are preserved so that you can
recover them. Users can no longer completely purge them from their mailboxes. In-place hold
preserves electronically stored information such as email messages so that users cannot delete them.
This feature replaces the need to perform a restore when a user deletes messages from a mailbox
when a compliance requirement requires that the mailbox be investigated.
Point-in-time database recovery with lagged database copies of a mailbox database. When you
configure a mailbox database copy, you can configure the database copy to delay replaying the log
files up to 14 days. Thus, you continuously maintain a database in the state it was in during the
previous days. This means that if you have an issue with your current active database, you can switch
to the lagged copy and commit the logs to the date or time period for which restoration is needed.
Archive mailboxes, retention and archive policies, and In-Place eDiscovery for managing large
mailboxes. By configuring archive mailboxes, you can provide users with a storage location for old
messages. You also can automate the process of managing messaging 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 costs associated
with recovering data and maintaining the backups. Depending on the requirements of your organization,
it is likely you can attain a lower Exchange Total Cost of Ownership through maintaining at least three
mailbox database copies instead of one with backups.
Even though it might appear that highly available deployments no longer require traditional backups,
you may still require them in your organization. Integrating high-availability features as an alternative to
backups only works for the mailbox databases. You still may consider using traditional backups for other
Exchange Server 2013 configurations.
Discussion: When Is Exchange Server Native Data Protection Appropriate?

Discuss Exchange Server Native Data Protection
with the students.
Does your organization work with Exchange

Server 2010 or 2013 and that uses only
Exchange Server Native Data Protection?
Why?
Does your organization use traditional

backups? Why?
Does your organization use combination of

Exchange Server Native Data Protection and
traditional backups? Why?
Which features of Exchange Server Native Data Protection do you use in your organization?
In which situation is it appropriate to use only Exchange Server Native Data Protection?
What Are the Timelines for Disaster Recovery?

The timelines for disaster recovery are determined
by the Service Level Agreement (SLA). Each SLA
should include a Recovery-Time Objective (RTO)
and a Recovery-Point Objective (RPO) that you
use to determine how to perform backups and
disaster recovery.
The RTO for a service defines how quickly you
should recover the service. For example, after
a Mailbox server fails, the RTO for the Mailbox
server might indicate that you need to recover the
mailboxes stored on that server within two hours.
In some cases, there may be a RTO for partial functionality. For example, after a Mailbox server fails, the
RTO for sending and receiving messages might be one hour, but the RTO for historical data in mailboxes
might be 12 hours.
The RPO for a service defines the point in time when you must recover the service. The RPO may indicate
that data from a specific timeframe can be lost, or that recovery must equal a certain point in time. For
example, the RPO for a Mailbox server may indicate that up to 12 hours of data may be lost, or that a
Mailbox server must be recovered to the backup at 2 a.m. the previous day.
Based on your RTO and RPO for Mailbox servers, you may choose to:
Keep databases small, to shorten recovery times.
Keep transaction logs on separate drives from the database, to ensure that you can replay them after
a database restore.
Perform a backup every few hours, to ensure minimal data loss.
Scenarios Requiring Backup and Restore

After implementing data loss mitigation and
high availability for Mailbox servers, you still may
encounter scenarios that require backup and
restore for data recovery. Data recovery scenarios
requiring backup and restore include:
Recovering a hard-deleted message when

single-item recovery is not enabled. If singleitem recovery is not enabled on a Mailbox
server, and a user hard-deletes an item,
Exchange Server 2013 removes the item
from the database without placing it in the
Recoverable Items Store.
Recovering a message after the item retention period has passed. Even when you enable single-item
recovery, Exchange Server 2013 only retains deleted items for the specified time period. By default,
this is 14 days for mail messages.
Recovering a public folder item after the item-retention period has passed. Exchange Server 2013
only retains a deleted item in a public folder for the specified time period. By default, this is 14 days.
Recovering a database when not using a DAG. You must recover failed databases from backup when
the Mailbox server is not a member of a DAG. A very rare but possible scenario is when only a single
copy is used in a DAG. Alternatively, you can use database repair tools, but it is faster typically to
restore from backup than to repair a database.
Recover from a server failure when the Mailbox server is not a member of a DAG. When a Mailbox
server fails, all databases on that server are lost if the server is not a member of a DAG. You must
recover the server from backup.
In addition to data-recovery requirements, a common reason for backups is compliance. Some

organizations are required by regulations or laws to maintain an archive of email for a period of time.
You can use a backup for this purpose, but you should also consider non-Microsoft archiving software.
Lesson 2
Planning and Implementing Exchange Server 2013 Backup

When planning Exchange Server 2013 backup, consider which data you need to restore. You only need to
back up the data that must be restored. Limiting the backup data size decreases the time it takes to
perform the backup, and provides more flexibility in your backup schedule.
The software you use to perform backups also can influence your backup process. There are many nonMicrosoft solutions for backing up Exchange Server 2013. You also can use Windows Server Backup in the
Windows operating system and the Microsoft System Center Data Protection Manager (Data Protection
Manager).
This lesson provides an overview of the requirements that are needed to implement an Exchange Server
2013 backup solution.
Lesson Objectives
Identify the backup requirements for Exchange Server 2013.
Choose Exchange Server backup software.
Choose Exchange Server backup media.
Describe how Volume Shadow Copy Service (VSS) backup works.
Backup Requirements for Exchange 2013

The backup requirements for Exchange Server
2013 computers depend on the Exchange server
role that is installed on the computer. The
following table lists the information that you
need to perform backup for each Exchange
server role.
Exchange
server role
Backed-up data
Purpose
All roles
System State of server and

Active Directory Domain
Services (AD DS) domain
controllers
System State includes the local configuration data

of the machine (this is an optional step and only
needed when restoring a particular server).
AD DS stores most Exchange server configuration
information, which is required to rebuild the
server using the RecoverServer switch.
Mailbox
server
Databases and transaction logs

Message-tracking logs
Unified Messaging custom audio
prompts
Restore data if a database is lost.

Restore tracking information for analysis.
Restore audio prompts.
Exchange
server role
Client Access
server
Backed-up data
Server certificates used for
Secure Sockets Layer (SSL)
Specific Internet Information
Server (IIS) configuration
Purpose
Restore the server certificate on a new Client

Access server.
Restore IIS configuration.
Choosing Exchange Server Backup Software

You can back up by using the built-in Windows
Server Backup software, Data Protection Manager,
or non-Microsoft software. Choose the software
based on the features that you require. At a
minimum, use backup software that works
properly with Exchange Server 2013.
The backup software that you choose must

support Volume Shadow Copy Service (VSS)
backups for Exchange Server 2013. A VSS backup
takes a snapshot of the database rather than
streaming the data from Exchange server. On the
Exchange server, the Exchange Server VSS writer is
responsible for triggering the snapshot and for making the Exchange server databases consistent before
the snapshot is taken.
Windows Server Backup
You can use Windows Server Backup, which is included with Windows Server 2008 R2 and later, to back
up Exchange Server 2013 databases and other data. When you install Exchange Server 2013, the version
of Windows Server Backup is updated to support Exchange Server 2013 backups. However, Windows
Server Backup has the following critical limitations:
It must run locally on the server that has the Exchange server data.
It must back up to a local disk or network share, and not to tape.
It restores only full databases.
It cannot back up passive DAG copies.
DPM
DPM is a backup solution for servers running Windows Server. DPM can back up basic file and print
servers, and application servers. DPM performs disk-based backups first, and then you can use it to
archive to tape.
DPM improves on Windows Server Backup in the following ways:
Unlike Windows Server Backup, Data Protection Manager requires only an agent to be installed on
the computer running Exchange Server 2013. Therefore, you can use Data Protection Manager to
centralize the backups of multiple servers.
You can restore databases or mailboxes. Recovering a mailbox is easier than restoring a database to a
recovery database and then extracting the mailbox contents.
You can back up passive database copies. This means that you can back up databases from a server
without determining whether the server has an active or passive database copy.
Non-Microsoft Backup Software
Most non-Microsoft backup software is similar to DPM. However, some non-Microsoft backup software
has the following additional features:
Individual-item restore. Some non-Microsoft backup software can restore individual mail messages
directly from backup to a users mailbox. This is less complex than first recovering to a recovery
database and then extracting the required message.
Brick-level backup. Brick-level backups are backups of mailbox contents. To perform a brick-level
backup, the backup software creates a Messaging Application Programming Interface (MAPI)
connection to each mailbox that it is backing up. This can be useful for backing up specific mailboxes
more frequently. However, in general, it is easier to separate mailboxes into databases based on
different backup requirements.
Choosing Exchange Server Backup Media

Tape backup remains a popular method of
performing backups. Tapes are easy to transport
and very durable. Tape capacity and speed have
steadily increased as manufacturers introduce new
products. If you need to expand backup capacity
beyond a single tape, you can use a tape changer
that automatically rotates several tapes in a single
unit. In high-capacity environments, you can use
a tape library. A tape library is a cabinet with one
or more tape backup units, and a robot arm that
moves tapes in and out of the tape backup units.
To increase backup performance, many
organizations use disk-based backups instead of tapes. Disk storage is often less expensive than tape
storage when you use large-capacity disks rather than the faster performing Small Computer System
Interface (SCSI) disks.
However, disk-based backups are not as well suited as tape-based backups for off-site storage. Disks
tend to be sensitive to physical movement, and may become unreliable if you transport them regularly.
Therefore, many organizations use disks as a first backup tier, and then transfer backups to tape for offsite storage.
If your Exchange server databases are located on a storage area network (SAN), then you can use
SAN-based snapshots to lessen backup traffic on the main network, and keep backup traffic on the SAN.
The backup is taken from the SAN snapshot rather than through the Exchange server. To implement
SAN-based snapshots for Exchange server backup, your backup application must support your specific
SAN hardware.
How Does a VSS Backup Work?

Starting with Exchange 2010, extensible storage
engine (ESE)-streaming application programming
interfaces (APIs) are no longer available. Exchange
now only supports use of VSS-based backups.
VSS
Volume Shadow Copy Service provides the
backup infrastructure for the Microsoft Windows
Server 2008 or newer operating systems, as well as
a mechanism for creating consistent point-in-time
copies of data known as shadow copies.
The VSS can be used for a number of purposes,
such as:
Creating consistent backups of open files and applications.
Creating shadow copies for shared folders.
Quickly recovering and restoring files and data.
Creating transportable shadow copies using a hardware provider for backup, testing, and data mining
scenarios.
The following components are included in VSS:

Component
Description
Volume Shadow Copy Service
A service that coordinates various components to create consistent

shadow copies of one or more volumes.
Requestor
An application that requests that a volume shadow copy can be

taken (such as Windows Server Backup).
Writer
Stores persistent information on one or more volumes that

participate in shadow copy synchronization.
Provider
Creates and maintains the shadow copies.
Source volume
Volume that contains the data to be shadow copied.
Storage volume
Volume that holds the shadow copy storage files for the system
copy-on-write software provider.
New to Exchange Server 2013
Microsoft Exchange Server 2007 and Exchange Server 2010 include two VSS writers, one inside the
Microsoft Exchange Information Store service and one inside the Microsoft Exchange Replication service.
With Exchange Server 2013, the writer inside the Microsoft Exchange Information service is moved to the
Microsoft Exchange Replication service and is referred to as the Microsoft Exchange Writer. This writer is
used by Exchange-aware VSS-based applications to back up active and passive database copies and
to restore them. For backup or restore of Exchange databases, both services (Microsoft Exchange
Information Store and Microsoft Exchange Replication) are required and need to be running.
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.
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 of 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, can therefore prepare for the
backup by cleaning up on-disk structures and flushing caches.
Supported Exchange Server 2013 Technologies
Only Exchange-aware, VSS-based backups are supported in Exchange Server 2013. Windows Server
Backup is extended with a plug-in through the installation of Exchange 2013 that makes it possible to
make VSS-based backups of Exchange data. The following Exchange-aware applications can be used to
back up and restore Exchange databases:
Windows Server Backup (with VSS plug-in)
Data Protection Manager
Third-party VSS-based application
Limitations of VSS
Be aware of the following limitations when you use VSS for Exchange data backup and restore:
With the Windows Server Backup, you can only back up volumes containing active mailbox database
copies or standalone mailbox databases. It is not possible to back up volumes containing passive
mailbox database copies. To back up these volumes, you must use either DPM or a third-party
VSS-based application.
A separate VSS writer in the Microsoft Exchange Replication service is used to back up the passive
mailbox database copies. The Microsoft Exchange Replication service VSS writer does not support
database restoration. You can back up a passive mailbox database using DPM or a third-party
Exchange-aware VSS-based application; it is not possible to perform a VSS restore directly to a
passive mailbox database copy. The steps for performing a VSS restore are:
o
Restore the passive mailbox database to an alternate location.
Suspend replication to the passive copy.
Copy the database and log files from the alternate location to the location of the passive
database.
Demonstration: How to Back Up Exchange Server 2013

Demonstration Steps
1.
In Server Manager, add the Windows Server Backup feature.
2.
Create a shared folder named Backup on LON-CAS1.
3.
In Windows Server Backup, create a backup set to back up the entire server to \\LON-CAS1\Backup,
and run the backup.
4.
Verify the backup in the Event Viewer.

Question: Do you plan to use Windows Server Backup as your primary Exchange Server
backup solution?
Lesson 3
Planning and Implementing Exchange Server 2013

Recovery
To restore lost servers and data in the most efficient manner, you need to understand the options
available for recovering Exchange server functionality and data. The recovery process varies depending on
the specific server roles. To ensure that everyone in your organization understands the recovery process,
you should create and maintain a disaster recovery plan.
This lesson provides an overview of the options that are available to recover mailbox items, databases, and
Exchange servers.
Lesson Objectives
Describe the options to recover Exchange server.
Describe the options to recover mailbox data.
Recover mailbox data.
Recover Client Access servers.
Recover the public folder hierarchy.
Recover data using the recovery database.
Repair a corrupted Exchange server database.
Recover a database with the dial-tone functionality.
Options for Recovering Exchange Server Functionality

You have two options when recovering Exchange
server functionality. You can either replace the lost
server roles or recover the lost server. Both
options allow you to recover full functionality.
Replace the Lost Server Roles

It is typically faster to replace a lost server role
than to restore a lost server. Replacing a lost
server role means that you install a new additional
server with the lost role on it. If you are using
a DAG, you can add a new server to the DAG
and create a new database copy on the server.
Other server roles may have customizations that
you need to configure.
Recover the Lost Server
When a server fails, you can recover the lost server to restore the functionality provided by that server.
Recovering the server requires you to build a new server, and to join that server to the domain using
the same computer account name. You can restore the computers system state to recover the computer
name and recover some configuration information, such as the IP address and certificates, but this is not
the recommended recovery process.
After joining the domain, install Exchange Server 2013 using the Recovery mode. The Recovery
mode reads the Exchange server configuration information from AD DS and automatically installs the
appropriate server roles that are linked to the computer account. After installation, the Exchange server
configuration information stored in AD DS is used for that computer.
Note: Never delete the computer account for a failed Exchange server. If you do, you
cannot recover the Exchange server functionality for that server.
When to Recover a Lost Server

Even though it is faster and easier to replace a lost server role than to recover a lost server, you should
recover the server in the following cases:
To avoid reconfiguring firewalls. Internet-accessible servers such as Microsoft Outlook Web App
and the Microsoft Exchange ActiveSync technology are protected by firewalls and proxy servers.
Re-creating the original configuration means that you do not need to reconfigure firewalls to direct
traffic to a new server. If the Client Access server is part of a client access array, then firewall
reconfiguration is not a concern because the replacement server will be a new node in the existing
Client Access array.
To recover poorly documented customizations. If a lost servers customizations are poorly

documented, you may not be able to replicate the configuration. Restoring from backup may be
the only option to recover the configuration.
To avoid reconfiguring applications configured to use a specific server. Some applications are
configured to use a specific server. For example, an application may be using a specific Hub Transport
server as a mail relay. Recovering the server means that you do not need to reconfigure a new Hub
Transport server with an appropriate Simple Mail Transfer Protocol (SMTP) receive connector.
Options for Recovering Mailbox Data and Databases

If a database is intact, you can use single-item
recovery to restore individual messages. If a
database is lost due to corruption or server failure,
you need to recover the data that was stored in
the lost database. There are many options that
you can use when you perform a recovery. Each
option is appropriate in different circumstances.
The available options are described in the
following table:
Option
Description
Database
restore
Recover a database lost due to corruption or disk failure by restoring the database.
After restoration, replay the transaction logs to bring the database up to the current
state just before it was lost.
Recovery
database
A recovery database is a database that is mounted on a Mailbox server, but is not

directly accessible to users. Use a recovery database if you need to recover data from
inside a database, instead of recovering the entire database. After restoring a database
in the recovery database, extract the messages or mailboxes that you want to restore.
Option
Description
Database
portability
You do not need to restore databases on the same servers that backed them up. You
can restore and mount databases on any Exchange Server 2013 Mailbox server in the
organization. This is useful when one of several Mailbox servers fails, and you want to
recover the database to a functional Mailbox server. You can also restore to a recovery
database located on a different server.
After restoring a database to an alternate server, you must use the Set-Mailbox
cmdlet with the Database parameter to link the mailboxes with the new location.
Dial-tone
recovery
When a mailbox database fails, users with mailboxes in that database can no longer
send and receive messages. You can create a dial-tone database by creating and
mounting an empty database for the mailboxes contained in the failed database. This
quickly allows users to send and receive messages again.
After the dial-tone database is functional, restore historical data to a recovery
database, and then merge the data into the dial-tone database.
If the dial-tone database is located on a different server than the failed database, use
the Set-Mailbox cmdlet with the Database parameter to link the mailboxes with the
new location.
DAG recovery
Performing a DAG recovery means that you do not need to perform a database
restore. When you have multiple database copies in a DAG and one database copy
fails, Exchange server automatically mounts and redirects users to another database
copy. To restore redundancy, create another database copy on a different server.
Planning the Recovery of Mailbox Data and Databases

When you plan Mailbox server recovery, consider
the following:
Any server in a DAG can host a copy of a

mailbox database from any other server in
the DAG. When a server is added to a DAG,
it works with the other servers in the DAG
to provide automatic recovery from failures
that affect mailbox databases. This is much
faster and easier than using other recovery
methods, and it improves the recovery
experience for users and administrators.
Place transaction logs and databases on

physically separate disks if you do not use a DAG, and if you may need to restore from backup. This
ensures that transaction logs will be available for replay if the disks containing the database are lost.
Recover basic functionality as soon as possible if you do not use a DAG, and a Mailbox server or
database fails. Use a dial-tone recovery database to allow users to send and receive messages as
quickly as possible. This is much faster than waiting for a database to restore.
Ensure that you have enough free disk space to hold a restored database. Allocate enough free disk
space to hold any database from which you might need to recover data. You can create a dedicated
restore logical unit number (LUN) on each Mailbox server, or allocate one server to use for database
recoveries.
Plan to use mailbox databases of a smaller size. This is important when it comes to a reseed process,
when data has to be reseeded to a disaster recovery site or across a wide area network (WAN). The
process can take much longer when you use bigger mailbox databases.
Planning the Recovery of Client Access Servers

The Client Access server handles all client
connections by admitting all client requests
and routing them to the correct active Mailbox
database. It also provides authentication,
redirection, and proxy services, but it does
not contain significant amounts of user or
configuration data. You can recover the basic
functions of Client Access servers without backing
up existing servers. Backups are required only if
you are restoring additional configuration options
that you may have set after installation.
Adding a Server Role
One way that you can replace a failed Client Access server is to add the server role to an existing
Exchange server in the same site. This way, you can recover functionality quickly. In most cases, this is a
temporary solution that you can use until you can rebuild the failed server, or deploy a new server as a
replacement.
Deploying a New Server

You also can deploy a new server with the same server role to replace a failed Client Access server. A
new Client Access server role replaces the functionality of a failed Client Access server after all needed
configurations are complete (such as adding to hardware load-balancing configuration and importing
the Exchange certificate).
You can recover the lost server by using the RecoverServer switch in Exchange Server 2013. Most of the
settings for a computer running Exchange Server 2013 are stored in Active Directory. The RecoverServer
switch rebuilds an Exchange server with the same name by using settings and other information stored in
Active Directory.
When you replace a Client Access server with a new one, you must perform additional configurations
rather than rebuild the failed server. Any configuration changes that you made to the websites that
were used on a Client Access serversuch as authentication optionsare lost when you replace a Client
Access server. To return the Client Access server role to its previous configuration state, you must have
documented your previous changes so that you can perform them again on the new server. When you
rebuild a server, these changes are restored from backup.
Considerations for Deploying a New Server
Deploying a new server may require you to reconfigure some applications. For example, if you configure
a Voice over IP (VoIP) gateway to communicate with the DNS name or IP address of the failed server, then
you must reconfigure the VoIP gateway.
If you choose not to rebuild a failed Exchange server, you must remove it manually from AD DS using
the LDP.exe tool. This tool is a Lightweight Directory Access Protocol (LDAP) client that allows users to
perform operations against the Active Directory.
Repairing Exchange Server Database Corruption

Exchange Server 2013 uses the
New-MailboxRepairRequest cmdlet to detect
and repair a corrupted mailbox or mailbox
database while leaving the mailbox database
online. This cmdlet was first introduced with
Exchange Server 2010 Service Pack 1 (SP1).
Note: Once you use these cmdlets to begin
the repair process, you can stop the process only
by dismounting the database.
Use the New-MailboxRepairRequest cmdlet to detect and fix mailbox and mailbox databases
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.
ProvisionedFolders
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
Process for Recovering Data 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 was first introduced
in Exchange Server 2010, and it replaced the
recovery storage group from previous Exchange
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 into the folder structure of the recovery database.
2.
Create a new recovery database with the Exchange Management Shell, and configure it to use the
database and log files from the restored database.
3.
Put the restored database in a clean shutdown state with Eseutil /R.
4.
Mount the recovery database, and merge the data from the recovery database mailbox into the
production or the archive mailbox of the user. You can use the Exchange Management Shell
New-MailboxRestoreRequest 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 a hold policy for this situation, as recovering the database might be time
consuming.
Demonstration: How to Recover Data by Using the Recovery Database

Demonstration Steps
1.
Use Windows Server Backup to restore Exchange to C:\Restore.
Note: The backup activity from the previous demonstration must be completed before you
can proceed.
2.
In the Exchange Management Shell, execute the following command to determine the appropriate
GUID and file locations.
Get-MailboxDatabase ID Mailbox Database 1 | fl name, guid, edbfilepath,
logfolderpath
3.
In the Exchange Management Shell, type the following command to create the Recovery database,
and press Enter.
New-MailboxDatabase Recovery Name RecoveryDB EdbFilePath C:\Restore\3c32c739a0ce-43bc-a299-2f56f2bcb20c\C_\Program Files\Microsoft\Exchange
Server\V15\Mailbox\Mailbox Database 1808842331\Mailbox Database 1808842331.edb
LogFolderPath C:\Restore\GUID\C_\Program Files\Microsoft\Exchange
Server\V15\Mailbox\Mailbox Database 1808842331 Server LON-MBX1
4.
Restart the Microsoft Exchange Information Store service.
5.
In the Exchange Management Shell, navigate to the folder of the mailbox database.
CD C:\Restore\3c32c739-a0ce-43bc-a299-2f56f2bcb20c\C_\Program
Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 1808842331
6.
Type the following command to bring the restored mailbox database into a clean shutdown status,
and press Enter.
Eseutil /r E00 /i /d
7.
In the Exchange Management Shell, type the following command to mount the restored mailbox
database, and press Enter.
Mount-Database RecoveryDB
8.
In the Exchange Management Shell, type the following command to list all mailboxes available in the
recovery database, and press Enter.
Get-MailboxStatistics Database RecoveryDB
9.
At the Exchange Management Shell prompt, type the following command, and press Enter.
New-MailboxRestoreRequest SourceDatabase RecoveryDB SourceStoreMailbox Tony Smith

TargetMailbox tony@adatum.com -SkipMerging StorageProviderForSource
10. At the Exchange Management Shell prompt, type the following command, and press Enter. This
command reports on the status of the mailbox restore request.
Get-MailboxRestoreRequest
What Is Dial-Tone Recovery?

Dial-tone recovery is a process in which the email
service is recovered first to the users through
creating a new mailbox database, called dial-tone
database. Recovering the mailbox data occurs in
a later step. With dial-tone recovery, users can
send and receive email very fast after a server or
database loss. Users can send and receive email
messages, but they do not have access to their
mailbox data. After recovering the mailbox
database, you can merge the content of the
recovered mailbox database into the dial-tone
database.
Using 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 must restore historical data from a backup as
quickly as possible. The loss may result from a hardware failure or database corruption. If the server fails, it
will take a considerable period of time to rebuild the server and restore the databases. If a large database
fails, it may take several hours to restore the database from a 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,
but all 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 mailbox
database for the client computers. There are
two methods for creating the dial-tone
database:
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.
Create the dial-tone database on a different server than the failed database. Use this method to
utilize a different server than a recover server, or if the original server fails.
2.
Configure the mailboxes that were on the failed database to use the new dial-tone database.
3.
Restore the database and log files that you want to recover into the Recovery Database.
4.
Swap the dial-tone database with the database that you have recovered in the step before.
5.
Export and import the content from the dial-tone database into the recovered original database.
Note: You do not need to reconfigure the Outlook profiles with Autodiscover in place,
because configuration is done automatically.
Lab: Implementing Disaster Recovery for Exchange

Server 2013
Scenario
You are a messaging administrator for A. Datum Corporation. Your organization has deployed Exchange
Server 2013. 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.
Objectives
After this lab, you will be able to:
Backup Exchange Server 2013.
Restore Exchange server data.
Lab Setup
Virtual machines
20341B-LON-DC1
20341B-LON-CAS1
20341B-LON-MBX1
User name
Password
Pa$$w0rd
For this lab, you will use the available virtual-machine environment. Before you begin the lab, you must
1.
2.
3.
4.
5.
Password: Pa$$w0rd
Exercise 1: Backing Up Exchange 2013

Scenario
You create a backup of your Exchange Server 2013 mailbox database to ensure that you can restore it
when necessary.
1.
Populate a mailbox with Outlook Web App.
2.
Install Windows Server Backup.
3.
Perform a backup of a mailbox database using Windows Server Backup.
4.
Delete message in mailbox
Task 1: Populate a mailbox with Outlook Web App
1.
On LON-CAS1, open Windows Internet Explorer. Type https://lon-cas1.Adatum.com/owa.
2.
Sign in as Adatum\michael with the password Pa$$w0rd.
3.
Send a new mail message to Mark Bebbington with the subject Message before backup, and then
sign out from Outlook Web App.
4.
Sign in again as Adatum\mark with the password Pa$$w0rd, and check that the message has
arrived.
5.
Sign out from Outlook Web App, and close Internet Explorer.
6.
From the Start screen, open the Exchange Management Shell, and use the following command to
take note of the name and GUID of the mailbox database associated with Mark Bebbington.
Get-Mailbox mark@ADatum.com |fl name,database,guid
Task 2: Install Windows Server Backup
On LON-MBX1, use the Server Manager to install the Windows Server Backup feature.
Task 3: Perform a backup of a mailbox database using Windows Server Backup

1.
On LON-CAS1, open File Explorer and create a folder named Backup on drive C:\. Share this folder
for Adatum\Administrator with Read/Write permissions. Close File Explorer.
2.
On LON-MBX1, start Windows Server Backup and perform a full server backup.
3.
As the location of the backup, select the shared folder \\LON-CAS1\Backup, and select Do not
inherit under Access control.
4.
Use the account Administrator with the password Pa$$w0rd as credentials.
5.
Close Windows Server Backup when the backup is finished successfully. It may take 10 to 15 minutes
to complete.
Task 4: Delete message in mailbox

1.
On LON-CAS1, open Internet Explorer. Type https://lon-cas1.ADatum.com/owa.
2.
Sign in as Adatum\Mark with the password Pa$$w0rd.
3.
Delete the message received from Michael.
4.
Empty the Deleted Items folder, and then from the Deleted Items folder, purge the message from
the recover deleted items window.
5.
Sign out from Outlook Web App.
Results: After completing this exercise, you have successfully backed up the mailbox databases.
Exercise 2: Restoring Exchange Server 2013 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 using Windows Server Database.
2.
Create a recovery database with the Exchange Management Shell.
3.
Recover the mailbox from the recovery database.
Task 1: Restore the database using Windows Server Database

1.
On LON-MBX1, open File Explorer and create a folder named C:\Restore.
2.
Open Windows Server Backup, and restore the backup located at \\LON-CAS1\Backup to the
alternate location C:\Restore.
Task 2: Create a recovery database with the Exchange Management Shell

1.
On server LON-MBX1, create a recovery database with the Exchange Management Shell by using the
restored mailbox database in C:\Restore.
2.
Restart the Microsoft Exchange Information Store service.
3.
In the Exchange Management Shell, change to the folder that contains the recovered database.
4.
Use the eseutil command to set the mailbox database to a clean shutdown state.
5.
Mount the restored database.
6.
Get all mailboxes located on that recovered mailbox database. Verify that Mark Bebbington is listed.
Task 3: Recover the mailbox from the recovery database

1.
On server LON-MBX1, recover Mark Bebbingtons mailbox by using the MailboxRestoreRequest

cmdlet.
2.
On LON-CAS1, open Outlook Web App and verify the recovered mailbox and the items in it.
Results: After completing this exercise, you will have successfully restored the missing items back into the
users mailboxes.
Exercise 3: Exchange Server 2013 Disaster Recovery (Optional)

Scenario
After a hard-disk malfunction, the Exchange Server 2013 Client Access server LON-CAS2 is no longer
operational. You have to restore the server with the /RecoverServer mode in the setup.
1.
Installing Exchange Server 2013 in Recover Server mode.
2.
Task 1: Installing Exchange Server 2013 in Recover Server mode

1.
On LON-DC1, reset the computer account of LON-CAS2 by using Active Directory Users and
Computers.
2.
Start 20341B-LON-SVR1 and sign in as Administrator using the password Pa$$w0rd.
3.
Change the IP address for the computer to 172.16.0.21, and the DNS address to 172.16.0.10.
4.
Rename LON-SRV1 to LON-CAS2 and join the server to the Adatum domain.
5.
In Hyper-V Manager, open the 20341B-LON-SVR1 settings, and attach the Exchange iso from
D:\Program Files\Microsoft learning\20341\Drives\ExchangeServer2013CU1.iso.
6.
On LON-CAS2, install Exchange Server 2013 with the RecoverServer switch.

following steps:
1.
2.
3.
4.
Repeat steps 2 to 3 for 20341B-LON-CAS1, 20341B-LON-SVR1, and 20341B-LON-MBX1.
5.
6.
7.
8.
Password: Pa$$w0rd
Results: After completing this exercise, you will have successfully recovered LON-CAS2.
Question: Which feature do you need before you can run a local backup on an Exchange
Server 2013 with the Mailbox role installed?
Question: Which tool do you need to create a Recovery Database in Exchange Server 2013?

Best Practice
Whenever possible, use a DAG to protect mailbox databases. DAG recovery is faster and easier than
backup recovery.
When you lose a database, use a dial-tone database to quickly recover basic messaging functionality.
Use a recovery database to retrieve specific items from a backup.
Allocate disk space for a recovery database when you are designing server storage.
Use single-item recovery to prevent users from purging messages before the messages reach the
item-retention limit.
Review Questions
Question: What are possible data-loss scenarios?
Question: What steps are required in the process of recovering data using the Recovery
Database?
Question: Which cmdlet do you use to repair database corruption?
Question: Which options do you have to recover mailbox data?
Tools
Windows Server Backup

8-1
Module 8
Planning and Configuring Message Transport
Contents:
Module Overview
8-1
Lesson 1: Overview of Message Transport and Routing
8-2
Lesson 2: Planning and Configuring Message Transport
8-18
Lesson 3: Managing Transport Rules
8-25
8-31
8-36
Module Overview
You must consider many factors when you implement message transport in Microsoft Exchange Server
2013. First, you must understand the components of message transport and how Exchange Server 2013
routes messages. You must understand how to troubleshoot message transport issues. Finally, it is
important that you know how to configure and apply transport rules.
This module describes planning and configuring message transport in an Exchange Server 2013
organization.
Objectives
Describe message transport in Exchange Server 2013.
Plan and configure message transport.
Manage transport rules.
Lesson 1
Overview of Message Transport and Routing
8-2 Planning and Configuring Message Transport
In this lesson, you will review message flow and the components that message transport requires. 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 2013 provides several tools
for troubleshooting Simple Mail Transfer Protocol (SMTP) message delivery, and this lesson describes how
you can use these troubleshooting tools.
Lesson Objectives
Describe message transport services.
Describe message transport components.
Describe message routing changes in Exchange Server 2013.
Describe routing destinations and delivery groups.
Describe routing in the Front End Transport service.
Describe routing in the Mailbox Transport service.
Describe how to modify default message flow.
Describe and use the tools for troubleshooting SMTP message delivery.
Describe transport agents.
Message Transport Services

In an Exchange Server 2013 organization, message
transport is performed through the transport
pipeline. The transport pipeline represents the set
of connections, connectors, services, components,
and queues that work together in order to
provide appropriate message routing.
In Exchange Server 2007 and Exchange Server
2010, message routing was performed by the
Hub Transport or Edge Transport server roles. In
Exchange Server 2013, the functionality of these
roles is distributed across the Client Access server
and Mailbox server roles. Several services work on
the Client Access server and Mailbox server to manage message routing for both internal and external
messaging traffic.
The following services participate in message transport:
Front End Transport service. This service, which runs on the Client Access server, behaves as a
stateless proxy component to all incoming and outgoing SMTP traffic that is external to the Exchange
organization. The service accepts the SMTP connections from other SMTP servers on the Internet,
receives messages, and initiates SMTP connections for message sending. However, this service is not
capable of message queuing. While this service is unable to inspect the content of messages, it is able
to perform filtering based on IP connections, domains, senders, or recipients. Internally, this service
only communicates with the Hub Transport service that resides on the Mailbox Server role.
Transport service. This service is almost identical to the Hub Transport server role in Exchange Server
2007 and Exchange Server 2010. It runs on all of the Mailbox servers in an Exchange Server 2013
organization. This service handles all internal SMTP flow, and performs message categorization and
content inspection. The most important difference between this service and the Hub Transport server
role in previous Exchange versions is that the Hub Transport service, in Exchange Server 2013, never
communicates directly with the mailbox databases. The Transport service routes messages between
the Front End Transport service and the Mailbox Transport service. The Mailbox Transport service, in
turn, communicates with the mailbox database.
Mailbox Transport service. Like the Hub Transport service, the Mailbox Transport service also runs on
a Mailbox Server role. It has the following components:
o
Mailbox Transport Delivery. This service receives SMTP messages from the Hub Transport service
and then establishes the Remote Procedure Call (RPC) connection to the mailbox database to
deliver the message to the appropriate mailbox.
Mail Transport Submission. This service works in the opposite direction of the Mailbox Transport
Delivery service. While it also connects the RPC to the mailbox database, its purpose is to retrieve
messages for sending rather than to deliver messages. It then submits the received messages to
the Hub Transport service by using the SMTP protocol. Unlike the Hub Transport service, the
Mailbox Transport service cannot perform local message queuing.
Messages coming from the Internet enter the Exchange transport pipeline through a Receive connector
on the Front End Transport service on a Client Access server. After that, messages are routed to the Hub
Transport service on a Mailbox server.
Messages inside the organization come directly to the Hub Transport service on a Mailbox server, through
the Receive connector, the Mailbox Transport service, or the agent submission.
Note: If you have an Exchange Server 2010 or Exchange Server 2007 Edge Transport
server deployed in your perimeter network, Internet mail flow occurs directly between the Hub
Transport service on the Mailbox server and the Edge Transport server, without passing through
Front End Transport on Client Access server.
Message Transport Components

Within the transport services that are running on
the Client Access server and Mailbox server, there
are several components that play very important
roles in message routing. The diagram on the slide
image shows these components and the possible
routing directions for messages in Exchange
Server 2013, and the relationships between the
components in the transport pipeline.
SMTP Receive
SMTP Receive works on the Front End Transport
service, and also on the Hub and Mailbox
Transport service. In each instance, it accepts
SMTP traffic from various sources. The message content inspection is performed when a message is
received by the Hub Transport service. In addition, transport rules are applied, and anti-spam and
antimalware inspection is performed. The SMTP session includes a series of events that work together
in a specific order to validate the contents of the message before it is accepted. After a message passes
completely through SMTP Receive and is not rejected by receive events, or by an anti-spam and
antimalware agent, it is placed in the Submission queue.
SMTP Send
SMTP Send also works in several places on both the Front End Transport service and the Hub Transport
service. Message routing uses SMTP Send from the Hub Transport service and depends on the location of
the message recipients relative to the Mailbox server where categorization occurred. The message can be
routed to the following locations:
The Mailbox Transport service on the same Mailbox server.
The Mailbox Transport service on a different Mailbox server that is part of the same database
availability group (DAG).
The Hub Transport service on a Mailbox server in a different DAG, AD DS site, or AD DS forest.
The Front End Transport service on a Client Access server for delivery to the Internet.
Categorizer
All routing decisions are made during a process called message categorization. The categorizer is
a component of the Hub Transport service that categorizes messages. The categorizer processes all
messages, and decides what to do with each message based on its destination. It also retrieves messages
from the Submission Queue, processes them, and delivers messages to Delivery Queue.
Each of these processes is described as follows:
Identifies and verifies recipients. All messages must have a valid SMTP address to be identified.
Bifurcates messages that have multiple recipients. The expansion of distribution lists enables
identification of individual recipients who belong to the distribution list. In addition, the categorizer
processes the return path for distribution-list delivery status notifications (DSNs), and it determines
whether Out-of-Office messages or automatically generated replies are sent to the original messages
sender.
Determines routing paths. When determining the routing path, the categorizer identifies the
destination, which must be a users mailbox, a public folder, or an expansion server for distribution
groups. If the categorizer cannot determine a valid destination, a non-delivery report (NDR) is
generated.
Converts content format. Recipients can require messages in different formats. The categorizer
converts the message to an appropriate format for the recipient. Inside the Exchange organization,
the recipient format is stored in AD DS. Messages routed to the Internet are sent in the Multipurpose
Internet Mail Extensions (MIME) or Secure/Multipurpose Internet Mail Extensions (S/MIME) format.
Applies organizational message policies. You can use organizational policies to control messaging
aspects such as size, permission to send messages to specific users, the number of message recipients,
and other characteristics.
Pickup and Replay Directories
Most messages enter the message transport pipeline through the SMTP Receive component, or by
submission through the store driver. However, messages also can enter the message transport pipeline by
being placed in the Pickup directory or Replay directory on a Mailbox 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 service 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. In addition, some legacy applications may place
messages directly into the Pickup directory for delivery, rather than communicate directly with Exchange
Server SMTP Receive connectors.
This example shows a plain text message that uses acceptable formatting for the Pickup directory.
To: mary@contoso.com
From: bob@adatum.com
Subject: Message subject
This is the body of the message.
The Replay directory is used to resubmit exported Exchange messages and to receive messages from
foreign gateway servers. These messages are already formatted for the Replay directory. There is little or
no need for administrators or applications to compose and submit new message files by using the Replay
directory. You can use the Pickup directory to create and submit new message files.
This example shows a plain text message that uses acceptable formatting for the Replay directory:
X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@adatum.com> BODY=7bit ENVID=12345AB auth=<someAuth>
Subject: Optional message subject
This is the body of the message.
Store Driver
The store driver is a software component that is present within the Mailbox Transport service in both the
Mailbox Transport Submission and the Mailbox Transport Delivery components. The Store Driver Submit
retrieves messages from the senders outbox, and then submits them to the Hub selector component. It
also uses RPC to deliver received messages to the users mailbox.
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 the 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 the messages, regardless of the format that created the messages. A Transport Neutral
Encapsulation Format (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 features require that TNEF encoding 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 a non-delivery report (NDR).
Submission Queue
When the Microsoft Exchange Transport service starts, the categorizer creates one submission queue
within each Hub Transport service. 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 the following 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 or Replay directories. This method is used for troubleshooting and
legacy applications.
Messages submitted by a transport agent, such as a non-Microsoft connector, to a foreign messaging

system.
Messages submitted by the store driver. This method is used to retrieve messages from the senders
outbox.
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 not delivered. Messages that are in the
Delivery Queue are sent to the SMTP Send component and, depending on their intended delivery route,
they can be forwarded to another Mailbox server or to the SMTP Receive component on the same
Mailbox server.
Below is a diagram of messages transport components and services in the Exchange Server 2013
infrastructure.
Message-Routing Changes in Exchange Server 2013

Exchange Server 2013 provides enhanced
message routing compared to previous Exchange
Server versions. In Exchange Server 2013, message
routing is integrated with the Client Access
server and the Mailbox Server role, and also is
functionally different.
Some of the most important enhancements and
changes in message routing include:
Routing in Exchange Server 2013 now uses

DAGs as a routing boundary. Because each
Mailbox Server also hosts Transport services,
when DAGs are implemented, the routing
mechanism becomes closely aligned with the DAG. Moreover, if one DAG spans multiple AD DS
sites, it is much more efficient to use the DAG as a routing boundary than as an AD DS site topology.
However, if DAGs are not implemented, message routing relies on AD DS site topology to define the
message-routing boundary. The same concept is applied to routing interoperability in previous
versions of Exchange Server.
The transport service on the Mailbox server role consists of two main services, the Hub Transport
service and the Mailbox Transport service. The Mailbox Transport service, or to be more precise,
its Mailbox Transport Delivery and Mailbox Transport Submission components, are the only
transport components that directly interact with the mailbox database. RPC is used by the Store
Driver when sending messages to, or receiving messages from the local mailbox database. When the
Mailbox server is a member of a DAG, the Mailbox Transport service only uses RPC to communicate
locally with the active copies of the mailbox databases. This means that RPC is never used for
communication between servers or transport components. This type of communication, and
communication between the Mailbox Transport service and the Hub Transport service, is performed
by using SMTP protocol.
Exchange Server 2013 uses more precise queuing for remote destinations than previous Exchange
version. Instead of using one queue for all destinations in a remote Active Directory site, Exchange
Server 2013 queues messages for specific destinations within the Active Directory site, such as
individual send connectors.
In Exchange Server 2013, linked connectors are deprecated. In previous Exchange versions, a linked
connector was a receive connector that linked to a send connector. All messages received by the
receive connector were automatically forwarded to the send connector.
Routing Destinations and Delivery Groups

Each message that is sent has a source and a
destination. The final destination for each
message in an Exchange Server 2013 organization
is called a routing destination. There are several
types of routing destinations, including:
Mailbox Database. When a message is sent

to a user with a mailbox on the Mailbox
server in an Exchange organization, the
routing destination for the message is the
Mailbox Database. This also applies to public
folders, which are a type of mailbox in
Connector. A connector is used as a routing destination when it is configured as a send connector for
SMTP messages. A delivery-agent connector or a foreign connector is used as a routing destination
for non-SMTP messages.
Distribution group expansion server. If a distribution group has a dedicated expansion server, then
that server is a routing destination for messages that are sent to the distribution group.
Delivery Groups
Delivery groups represent the collection of transport servers that are responsible for delivering messages
to a specific routing destination. Each routing destination has its own delivery group. Transport servers in
a delivery group can be Exchange Server 2013 Mailbox servers or Exchange Server 2010 Hub Transport
servers.
In scenarios where the routing destination is the mailbox database, the transport servers in the delivery
group are always the same version of Exchange Server as the mailbox database. In the cases where the
routing destination is a connector or distribution group expansion server, the transport servers can be
Exchange Server 2013 Mailbox servers or Exchange Server 2010 Hub transport servers.
The message routing path depends on the relationship between the source transport server and the
delivery group. When the source transport server is in the destination delivery group, then the routing
destination is actually the next hop for the message. Otherwise, if the source transport server is not in the
destination delivery group, the message is relayed by using the least-cost routing path. On that path, the
message can be relayed to other transport servers, or the message is relayed directly to a transport server
in the destination delivery group.
The message also can be delivered to the connector or the transport server in the delivery group.
When a distribution group expansion server is the routing destination, the distribution group is already
expanded by the time messages reach the routing stage of categorization on the distribution group
expansion server. Therefore, the routing destination from the distribution group expansion server is
always a mailbox database or a connector.
There are several types of delivery groups in Exchange Server 2013, including:
Routable DAG. This represents the set of Exchange Server 2013 servers that are members of the
same DAG. All mailbox databases in the DAG are routing destinations for this delivery group.
When the message arrives, the Hub Transport service on the Mailbox server accepts it and routes
it to the Mailbox Transport service on the Mailbox server that currently holds the active copy of the
destination database. The Mailbox Transport service uses the Transport delivery component to deliver
the message to the mailbox database. In this case, the DAG is the delivery group boundary.
Mailbox delivery group. This represents the set of Exchange servers that are running the same version
of Exchange Server in a single AD DS site, which is the delivery group boundary. Mailbox databases
located on Exchange Server 2010 Mailbox servers are serviced by the Exchange Server 2010 Hub
Transport servers located in the AD DS site. The mailbox databases located on Exchange Server 2013
Mailbox servers in the AD DS site (those that do not belong to a DAG) are serviced by the Hub
Transport service on Exchange Server 2013 Mailbox servers in the AD DS site. The message is
delivered by using different techniques, depending on where the final destination is located. If the
message arrives on the Mailbox Server 2013, then the Hub Transport service transfers the message
to the Mailbox Transport service by SMTP, and the Mailbox Transport service uses RPC to deliver the
message to the database. If the message arrives on the Exchange Server 2010 Hub Transport server,
then the store drive on the Hub Transport uses RPC to write the message to the mailbox database.
Connector source servers. The connector source servers represent a mixed set of Exchange Server 2010
Hub Transport servers and Exchange Server 2013 servers that are designated as source servers for
the send connector, the delivery agent connector, or a foreign connector in the same or a different
AD DS site. The connector is the routing destination. When a connector is scoped to a specific server,
only that server is allowed to route messages to the destination defined by the connector.
AD DS site. When the AD DS site is not the final destination for a message, but the message must pass
through that site, then you must use the AD DS site as the delivery group. You can do this if an AD DS
site is designated as a Hub site, or when the Exchange Edge server is subscribed to the specific site,
and other sites cannot access it directly.
Server list. The server list represents the collection of one or more Exchange Server 2010 Hub
Transport servers or Exchange Server 2013 Mailbox servers that are configured as distribution group
expansion servers. The distribution group expansion server is the routing destination that is serviced
by this delivery group.
Delivery group membership for the server is not exclusive. For example, an Exchange Server 2013 Mailbox
server that belongs to a DAG also can be the source server of a scoped send connector. This Mailbox
server would belong to the routable DAG delivery group for the mailbox databases in the DAG, and also
as a connector source server for the delivery group in the scoped Send connector.
Mail Flow in Exchange Server 2013

To better understand how the mail flow works
in Exchange Server 2013, follow the steps below.
The steps below show internal mail flow when the
user on Mailbox Server 1 sends a message to the
user on Mailbox Server 2 within same Exchange
organization.
1.
When the user sends the message from

the Outlook client, the Mailbox Transport
Submission service uses the Store Driver to
connect to the mailbox database using RPC
and retrieves the email from users Outbox.
2.
After the message recipient is received to its

mailbox database, the Mailbox Transport Submission service searches for the appropriate delivery
group. In this case, it is the Mailbox delivery group. The Store Driver sends the email to the Hub
Selector and is sent over SMTP to the appropriate server. It is important to note that in this case
the email is not passed to the Transport service on the senders Mailbox server. Instead, Mailbox
Transport Submission service sends the message directly to the Transport service on recipients
Mailbox server. In the scenario where the destination is routable to DAG, message will be directly
passed from Mailbox Transport service on senders mailbox server to Mailbox Transport service on
recipients mailbox server.
3.
The Transport service on the recipients mailbox server receives the email sent over SMTP from the
Mailbox Transport Submission service of senders mailbox server using its default receive connector.
Content inspection is performed, transport rules are applied and anti-spam/antimalware inspection is
performed (if enabled). If the message passes all inspections, it is placed in the Submission queue.
4.
The Categorizer picks up the email from the Submission Queue, processes it and puts into a delivery
queue for the local mailbox database.
5.
The email is then sent by using SMTP from the Transport service to the Mailbox Transport Delivery
service within the recipients mailbox server.
6.
The email is received over SMTP by the Mailbox Transport Delivery service from the Transport service:
7.
The Mailbox Transport Delivery service uses the Store Driver to connect to the mailbox database
using RPC, and writes the email to the mailbox database. In this moment, the message is received by
recipient.
The diagram below shows Mailflow in Exchange 2013.
Routing in the Front End Transport Service

The Front End Transport service runs on each
Client Access server. It acts as a proxy for all
incoming and outgoing SMTP traffic for the
Exchange organization. From the perspective of
SMTP traffic, its role is similar to Edge Transport
server in Exchange Server 2007 or Exchange
Server 2010, but the very important difference is
that Client Access server cannot perform message
queuing.
The Hub Transport service on the Mailbox Server

uses the send connector to communicate with
the Front End Transport server. If the parameter
FrontEndProxyEnabled is set to true, when you create the send connector on the Mailbox server, then
all outgoing messages are proxied through the Front End Transport service on the Client Access server.
In this case, when message is sent to the Internet, the Client Access server is the component that actually
sends the message to the destination SMTP server.
When the message arrives from the Internet, the Front End Transport service accepts the SMTP
connection, and then tries to find an available Hub Transport service on the Mailbox server to receive the
message. Because the Front End Transport service cannot queue the messages on itself, if it does not find
an available Hub Transport service, the email service will be perceived as unavailable by the external
senders.
The Front End Transport service builds the routing tables based on information from AD DS, and it uses
delivery groups to determine how to route messages. However, the Front End Transport service is never
considered a member of a delivery group, even when the Mailbox server and the Client access server are
installed on the same physical server. As a result, the Front End Transport service communicates only with
the Hub Transport service. In addition, the routing tables do not contain send connector routes; instead,
they contain a special list of Mailbox servers in the local AD DS site.
The Front End Transport routing service always resolves message recipients to the appropriate mailbox
databases. The list of Mailbox servers that the Front End Transport service uses is based on the mailbox
databases of the message recipients. However, it is possible that none of the recipients have mailboxes.
For example, when the recipient is a distribution group or a mail user, a random Mailbox server in the
local AD DS site is selected for delivery.
The Front End Transport service searches for the appropriate delivery group for each mailbox database,
and then tries to find the associated routing information. The following is a list of delivery groups that the
Front End Transport service can use:
Routable DAG.
Mailbox delivery group.
AD DS site.
When the front-end server accepts the message, it looks up the number and type of recipients and then
performs one of the following:
If the message has a single recipient with a mailbox, the Front End Transport service selects a Mailbox
server in the target delivery group. If the target delivery group spans multiple sites, the Front End
Transport Service will give preference to the Mailbox server that is based on the proximity of the
AD DS site.
If the message has multiple mailbox recipients, the Front End Transport service uses the first 20
recipients to select a Mailbox server in the closest delivery group.
Routing in the Mailbox Transport Service

The Mailbox Transport service, which runs on
every Mailbox Server in an Exchange Server 2013
organization, consists of two services, the Mailbox
Transport Submission service and the Mailbox
Transport Delivery service. The Mailbox Transport
service is stateless, and does not queue any
messages locally.
Similar to the Hub Transport service, the Mailbox
Transport service builds the routing table based
on information from the AD DS. The Mailbox
Transport service also uses delivery groups for
message routing.
The Mailbox Transport service always belongs to the same delivery group as the Mailbox server, and that
group is called the local delivery group. This service also does not automatically send messages to the
Hub Transport service in its local delivery group. The Mailbox Transport service only communicates with
the Hub Transport service on Mailbox servers and with mailbox databases on the local Mailbox server. It
never communicates with mailbox databases on other Mailbox servers.
When a message is sent from the users mailbox, the Transport Submission component in the Mailbox
Transport service resolves the message recipient to the appropriate mailbox database, and then the
Transport Submission component looks for the routing information for each mailbox database.
The delivery groups used by the Mailbox Transport Submission service are:
Routable DAG.
Mailbox delivery group.
AD DS site.
Depending on the number and the type of message recipients, the Mailbox Transport Submission service
performs one of the following actions:
If the message has a single recipient with a mailbox, the Mailbox Transport service selects a Mailbox
server in the target delivery group. If the target delivery group spans multiple sites, the Front End
Transport service gives preference to the Mailbox server based on the proximity of the AD DS site.
If the message has multiple mailbox recipients, the Mailbox Transport service uses the first 20
recipients to select a Mailbox server in the closest delivery group.
If there are no mailbox recipients in the message, the Mailbox Transport service selects a Mailbox
server in the local delivery group.
The Mailbox Transport service communicates with the Hub Transport service. The message can be
accepted or rejected for delivery to the local mailbox database when the message is sent from the Hub
Transport service to the Mailbox Transport service. The message is accepted for delivery if the recipient
resides in an active copy of a local mailbox database. However, if the recipient is not in the active copy of
the local mailbox database, the Mailbox Transport service provides a non-delivery response to the Hub
Transport service.
A non-delivery response occurs when an active copy of the local mailbox database is moved to another
mailbox server, but the Hub Transport service still does not have the updated information. In this case, the
Mailbox Transport service issues a NDR to the Hub Transport service, with instructions to retry delivery,
generate an NDR, or reroute the message.
Modifying the Default Message Flow

When a message is delivered to a remote delivery
group, a routing path must be determined for that
message. A routing path is calculated based on the
least-cost routing path by adding the cost of the
IP site links that must be traversed to reach the
destination. If the destination is a connector, the
cost assigned to the address space is added to the
cost to reach the selected connector. If multiple
routing paths are possible, the routing path with
the lowest aggregate cost is used.
In Exchange Server 2010, the message recipient

was bounded to one specific AD DS site, so only
one least-cost routing from source to destination existed. However, in Exchange Server 2013, a delivery
group can span multiple AD DS sites, which means that multiple least-cost routing paths can exist to
those multiple AD DS sites. As a result, Exchange Server 2013 designates a single AD DS site in the
destination delivery group as the primary site.
In some cases, you may want to modify the default message-routing configuration. You can do this by
configuring specific AD DS sites as Hub sites, and by assigning Exchange Server-specific routing costs to
AD DS site links. Hub sites are central sites that you define to route messages.
By default, the Hub Transport service in one site will try to deliver messages to a recipient in another site
by establishing a direct connection to a Hub Transport service in the remote AD DS site. However, you
can modify the default message-routing topology in three ways: by configuring hub sites, by configuring
Exchange-specific routing costs, and by configuring expansion servers for distribution groups.
Configuring Hub Sites
You can configure one or more AD DS sites in your organization as hub sites. When a hub site exists along
the least-cost routing path between two Mailbox servers, the messages are routed to a Mailbox server in
the hub site for processing before they are relayed to the destination server.
The Hub Transport service routes a message through a hub site only if it exists along the least-cost
routing path. The originating Mailbox 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 service will attempt a direct connection.
Use the following cmdlet to configure a site as hub site:
Set-ADSite Identity sitename HubSiteEnabled $true cmdlet
Use the following cmdlet to check whether you have configured a hub site:
Get-AdSite | Format-List Name,HubSiteEnabled
Configuring Exchange-Specific Routing Costs
You also can modify the default message-routing topology by assigning 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
service determines the least-cost routing path by using this attribute rather than the Active Directoryassigned cost, unless the mailbox server is a member of DAG.
Use the following cmdlet to assign an Exchange-specific routing cost to an Active Directory IP site link:
Set-AdSiteLink Identity ADsitelinkname ExchangeCost value
You also can assign a maximum message size limit for messages sent between AD DS sites by using the
following cmdlet:
Set-AdSiteLink Identity ADsitelinkname MaxMessageSize value
To check if you properly configured an Exchange cost, run following cmdlet:

Get-AdSite | Format-List Name,HubSiteEnabled
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 service 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 service resolves them.
Note: You might need to review the AD DS site design when you deploy Exchange Server
2013, 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

Exchange Server 2013 provides several tools for
troubleshooting SMTP message delivery.
Note: Exchange Server 2013 relies on the
AD DS site configuration for message routing.
Therefore, to troubleshoot a message-routing
issue, you might need to use AD DS tools to
validate or modify the site, site link, or IP subnet
information, and to verify AD DS replication. You
can use the Active Directory Sites and Services tool
to view IP subnets and site links.
Using the Queue Viewer
Messages waiting to be processed or delivered in Exchange Server 2013 reside in message queues on
the Exchange Server Mailbox servers. All of the message queues provide a 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 2013 features simplified queues. The
Hub Transport service maintains the following queues:
Submission queue. The 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 service routes mail.
Poison message queue. The 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
service can deliver messages.
Unreachable queue. The unreachable queue contains messages that the Hub Transport service cannot
route to the proper destination.
You can view the queues on a Mailbox server by accessing the Exchange Queue Viewer in the Toolbox.
To manage message queues from the Exchange Management Shell, use the following cmdlets:
Get-Queue
Get-Message
In addition, from the Exchange Management Shell, you can perform the following tasks on queues and
messages in queues:
Suspend-Queue and Resume-Queue
Retry-Queue
Suspend-Message and Resume-Message
Remove-Message
Message Tracking
You can also use message tracking to troubleshoot message flow. By default, message tracking is enabled
on Mailbox servers. 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. If you want to explore tracking logs, you can do that by using the
Get-MessageTrackingLog cmdlet
In Exchange Server 2013, you use Delivery Reports in the Exchange Administration Center (EAC) to
perform message tracking. The Message Tracking tool does not provide the level of detail that the
tracking logs provides. For example, when you send a message between two Exchange servers that are in
the same AD DS site, the Exchange server names do not appear in Delivery reports; however, the tracking
logs provide this information.
Using Protocol Logging
Protocol logging can be configured 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
Telnet can check whether the SMTP port responds, and it can send a SMTP mail to a connector to verify
whether the connector accepts it. Telnet is a command-line feature in Windows Server that uses the
following syntax: telnet <servername> SMTP or Port #. For example, you can use either TELNET LON-EX1
SMTP or TELNET LON-EX1 25, which are basically the same.
Remote Connectivity Analyzer Website
The following website enables you to test connectivity to various Exchange services from the Internet, and
the functionality of these services: https://www.testexchangeconnectivity.com/.
You also can test inbound and outbound email traffic that is using the SMTP protocol. You can use this
website to test both an on-premises Exchange Server and Exchange Online in Microsoft Office 365. To
use this tool, you must enter the credentials of a working account from the Exchange domain that you
want to test.
Note: To avoid the risk of having your working credentials exploited and possibly
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

Demonstration Steps
1.
Open the Command Prompt window.
2.
To start the Telnet tool, at the command prompt, type Telnet LON-MBX1 SMTP, and try to send a
mail message using Telnet.
3.
On LON-MBX1, from the Start screen, start the Queue Viewer tool.
4.
Suspend and resume the Submission queue.
5.
Close Queue Viewer.
6.
Open Exchange Outlook Web App, and sign in as Administrator.
7.
Send one message to Amr@adatum.com and one to Amr@contoso.com.
8.
Open the EAC on LON-CAS1, and in mail flow delivery reports, search for messages that
Administrator sent.
9.
View the message-delivery tracking report.
What Are Transport Agents?

Transport agents process email messages that
pass through the transport pipeline on Transport
service components. Custom transport agents
provide additional functionality to Exchange
Server 2013, such as anti-spam or antivirus
programs, or any transport function that your
organization may require. You can install custom
transport agents on Exchange Server 2013 as
additional software components.
Exchange Server 2013 includes the following
transport agents that enable it to provide features
such as transport rules and journaling:
Transport Rule agent. The Transport Rule agent processes transport rules on the Hub Transport
servers. It fires on the OnRoutedMessage transport event. Transport rules configured on the Hub
Transport servers are stored in AD DS, which makes them accessible to all the Hub Transport servers
in the Exchange organization. This allows the Exchange Server to consistently apply a single set of
rules across the entire organization.
Journaling agent. The Journaling agent is a compliance-focused transport agent that processes
messages on Hub Transport servers. It fires on the OnSubmittedMessage and OnRoutedMessage
transport events. When you enable standard journaling on a Mailbox database, this information is
saved in AD DS, and is read by the Journaling agent during the message-journaling process.
Active Directory Rights Management Services Prelicensing agent. You can use the Active Directory
Rights Management Services (AD RMS) Prelicensing agent to certify the Outlook recipient's
authenticity, so that the recipient can open messages without receiving a credential prompt on
every attempt. It fires on the OnRoutedMessage transport event.
Note: Transport agents have full access to all messages that they process; and Exchange
places no restrictions on a transport agent's behavior. Consequently, transport agents that are
unstable or contain security flaws may affect the stability and security of Exchange Server 2013.
Lesson 2
Planning and Configuring Message Transport
Message transport planning is an important part of any Exchange infrastructure deployment. You should
understand how you can manage mail flow, and how to configure email domains that your Exchange
server hosts. In addition, you should know how to configure and manage SMTP Send and Receive
connectors, which are the most important components for establishing message flow.
Lesson Objectives
Plan Exchange messaging transport.
Describe mail flow settings.
Plan accepted and remote domains.
Create and configure accepted and remote domains.
Describe SMTP connectors.
Create and configure SMTP connectors.
Describe foreign connectors.
Planning Exchange Messaging Transport

Before you actually configure the transport
component in your Exchange Server 2013
infrastructure, it is important that you carefully
plan your SMTP traffic in general, and identify
routes, paths, and transition points for message
transport.
In an Exchange Server 2013 infrastructure, you
can configure and manage SMTP transport on the
following:
Client Access server, which hosts Front End

Transport Service.
Mailbox server, which hosts the Hub Transport Service and Mailbox Transport Service.
Edge Transport server 2007 or 2010, if implemented.
Non-Microsoft SMTP Gateway, if implemented.
You should take into account the following considerations when you plan for messaging transport:
On which email domains will you accept SMTP traffic? You should identify all email domain names for
which your organization will accept messages. You also should identify domain names for which you
will be accepting and forwarding messages.
Which component initially accepts SMTP connections? The SMTP connections can be configured on
the Client Access server or the Edge Transport server. Some firewalls also have the ability to accept
and inspect SMTP traffic.
On which point do you implement SMTP traffic inspection for viruses and malware? You can
implement a third-party anti-virus solution on-premises for this purpose, or you can use integrated
antimalware protection. You also can use Exchange Online Protection for antimalware protection.
Are there any hosts in your network that require SMTP relaying? You might have applications or
services that need to send emails by relaying them through your Exchange server. It is very important
that you identify these services so that you can properly configure options for relaying email
messages.
Do you have reliable connections for SMTP traffic inside your organization? For example, in some
scenarios, servers might not be connected well, and that can affect SMTP message transport.
Are you going to implement secure SMTP traffic with another organization? In some scenarios, you
will need to implement dedicated SMTP connectors secured with Transport Layer Security (TLS) for
message transport between your organization and another Exchange organization.
Do you need to directly communicate with an organization that does not use SMTP for messaging?
After answering these questions and providing the necessary details, you will have enough information to
properly configure your messaging transport structure inside the organization, and also to and from the
Internet.
Demonstration: Reviewing Mail-Flow Settings

Demonstration Steps
1.
On LON-CAS1, switch to the EAC.
2.
Navigate to mail flow.
3.
Browse through all of the tabs in the mail flow section.
Planning Accepted Domains and Remote Domains

As part of the message transport configuration
process, you should configure the domains for
which the Exchange server will accept email, and
optionally configure users with alternate email
addresses.
Accepted Domains
When you create a new accepted domain, you
have three options for the domain type:
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 your Exchange server should accept the email, but relay
it to another messaging organization in another AD DS forest. The recipients in an internal relay
domain do not have mailboxes in this Exchange organization, but they do have contacts in the global
address list (GAL). When messages are sent to the contacts, the Transport service forwards them to
another SMTP server. Exchange Server does not generate NDRs for recipients for which it is not
responsible, because it is not authoritative for the Internal Relay Domain.
External Relay Domain. Select this option if your Exchange server should accept the email, but relay it
to an alternate SMTP server. In this scenario, the Transport service 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.
By default, only the forest root domain is established as an accepted domain. You should consider adding
additional accepted domains in the following situations:
Additional namespaces. If you have additional domains within your forest, in particular, additional
treeswhich represent different namespacesyou may consider adding authoritative domains for
them. If you add an authoritative domain for an additional tree or domain within your AD DS forest,
you also must create an email address policy to support the domain.
Mergers and acquisitions. When your organization acquires another organization, you may decide to
configure an accepted domain to facilitate internal relay to the acquired organization.
External relay. You must configure an accepted domain to support external SMTP relay. Unlike an
internal relay, in which your Exchange Server organization routes messages to an Exchange server
in another AD DS forest, an external relay routes messages when you relay to any SMTP host outside
your organization. An Internet Service Provider (ISP) might configure an external relay for a customer.
Remote Domains
Remote domains define SMTP domains that are external to your Exchange Server organization. You can
create remote domain entries to define the settings for message transfer between the Exchange Server
2013 organization and domains outside your AD DS forest. When you create a remote domain entry, you
control the types of messages that are sent to that domain. You also can apply message-format policies
and acceptable character sets for messages that are sent from your organizations users to the remote
domain.
The settings for remote domains determine the Exchange Server organizations global configuration
settings.
You can create remote domain entries to define the mail transfer settings between the Exchange Server
2013 organization and a domain that is outside your AD DS forest. When you create a domain entry,
you provide a name to help the administrator identify the entrys purpose when he or she views the
configuration settings.
The domain name is limited to 64 characters. You also provide the domain name to which this entry and
the associated settings will apply. You can use a wildcard character in the domain name to include all
sub-domains. The wildcard character must appear at the start of the domain name entry. The SMTP
domain name is limited to 256 characters.
The default settings may be suitable for most situations, but when you work with a partner organization,
you may choose to create a remote domain for their SMTP namespace, and configure specific settings
accordingly. You also can choose to define your Office 365 domain as your remote domain.
Demonstration: Creating and Configuring Accepted and Remote Domains

Demonstration Steps
1.
In the EAC, navigate to mail flow.
2.
On the accepted domain tab, create a new accepted domain named adatum.local of internal relay
type.
3.
Open Exchange Management Shell.
4.
Review the list of remote domains.
5.
Create new remote domain called contoso.com.
6.
Review all settings for remote domain contoso.com.
7.
Set properties AutoForwardEnabled and DeliveryReportEnabled of remote domain Contoso to

false.
What Is an SMTP Connector?

An SMTP connector is an Exchange server
component that supports one-way SMTP
connections that route mail between the Hub
Transport service and the Front End Transport
service, or between the transport servers and the
Internet. You create and manage SMTP
connectors from the EAC or the Exchange
Management Shell. Exchange Server 2013
provides two types of SMTP connectors, SMTP
Receive connectors and SMTP Send connectors.
For Exchange server to send or receive messages
using SMTP, at least two SMTP connectors must
be available on the server.
What Are SMTP Receive Connectors?
Exchange Server 2013 requires an SMTP Receive connector to accept any SMTP email. An SMTP Receive
connector enables an Exchange Transport service 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, and
other Exchange Server SMTP servers.
You create SMTP Receive connectors on each server running the Client Access or Mailbox server role.
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. Default maximum message size for new receive connector
is 35 MB.
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. When you install Exchange Server 2013, Receive
connectors are created by default on the Mailbox Transport Service and the Front End Transport Service.
Default Receive Connectors on the Mailbox Transport Service
When you install a Mailbox server role, two Receive connectors are automatically created. No additional
Receive connectors are needed for a typical Exchange operation, and in most cases, the default
connectors will not require a configuration change. These connectors include:
Default <server name>. Accepts authenticated connections from Mailbox servers running the
Transport service and from Edge servers. This connector has the Hub Transport role, and it accepts
connections on port 2525.
Client Proxy <server name>. This connector accepts connections from front-end servers. It has the
Hub Transport role, accepts connections on port 465 (Secure SMTP), and requires authentication.
Default Receive Connectors on a Front End Transport Service

During installation, the following Receive connectors are created on the Client Access server:
Default FrontEnd <server name>. The connector accepts connections from SMTP senders over port
25. This is the common messaging entry point into the Exchange organization. This connector accepts
non-authenticated (anonymous) connections and has a Front End Transport role.
Outbound Proxy Frontend <server name>. The connector accepts messages from a Send Connector
on a back-end server, with front-end proxy enabled. It accepts connections on port 717.
Client Frontend <server name>. This connector accepts authenticated connections from clients such
as Windows Mail for sending emails. It works on port 587. This connector has a Front End Transport
role.
Note: In a typical installation, no additional Receive connectors are required.
What Are SMTP Send Connectors?

An Exchange Server 2013 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.
By default, no SMTP Send connectors are configured on Mailbox or Client Access servers, except for the
implicit SMTP Send connectors. These are created dynamically to communicate with Transport services in
other sites.
Keep in mind the relationship between the Front End Transport service on the Client Access server and
the Transport service on Mailbox servers in Exchange Server 2013, because Send connectors function
differently in Exchange Server 2013 than in previous Exchange Server versions. You can now set a Send
connector in the Transport service on a Mailbox server to route outbound mail through a Front End
transport server in the local AD DS site, by means of the FrontEndProxyEnabled parameter of the
Set-SendConnector cmdlet. This allows you to manage how email is routed from the Transport service.
The default maximum message size is specified by the MaxMessageSize parameter. Default maximum
message size for a new send connector is 10 MB. The Set-SendConnector cmdlet provides more
information on how to set parameters on a Send connector.
In addition, the TlsCertificateName parameter has been added. It authenticates the local certificate to be
used for outbound connections and minimizes the risk of fraudulent certificates.
How to Manage SMTP Connectors
You can use the EAC or the Exchange Management Shell to create, configure, and view SMTP connectors.
In the EAC, SMTP Receive connectors can be configured for each Mailbox server, while Send connectors
are configured in the Organization Configuration node. To manage connectors using the Exchange
Management Shell, use the Set-ReceiveConnector and Set-SendConnector cmdlets. If you incorrectly
configure the SMTP Receive connectors, this can lead to open relay on the mail server. Therefore, you
must carefully test the configuration.
Demonstration: How to Create and Configure SMTP Connectors

Demonstration Steps
1.
2.
Use the Exchange Management Shell to create a new Send connector with the following properties:
a.
Name: Send to Internet
b.
Address space: *
c.
Source: LON-MBX1
Use Exchange Management Shell to create a new Send connector with the following properties:
a.
Name: Secure Email to Contoso
b.
Address space: contoso.com
c.
DNSRoutingEnabled: false
d.
Smarthost: 172.16.0.10
e.
Authentication: basic
f.
Credentials: Administrator, Pa$$w0rd
3.
Use the EAC to verify the settings on new Send connectors.
4.
Use the EAC to create a new Client receive connector to accept anonymous connections only from
172.16.0.10.
What Are Foreign Connectors?
Sometimes you have to deliver email messages

to a system that does not support SMTP as a
transport mechanism. One such example is a faxgateway server. In this scenario, you can use a
Foreign connector, which uses the Drop directory
to send outbound messages. The Drop directory
can be local or shared. As a transport mechanism,
it uses file transfer protocols rather than SMTP. In
the opposite direction, Foreign gateway servers
can send messages to the Exchange Server 2013
organization by using the Pickup or Replay
directories, as discussed earlier in this module.
Correctly formatted email message files that you copy to each directory are submitted for delivery to an
Exchange mailbox.
You can create Foreign connectors on the mailbox transport service running on the Mailbox server role.
You must use the Exchange Management Shell to create and configure a Foreign connector.
The following example displays how to create a Foreign connector:
New-ForeignConnector -Name "FaxGW Foreign Connector" -AddressSpaces
"X400:c=US;a=Fabrikam;P=Contoso;5" -SourceTransportServers LON-MBX1,LON-MBX2
To configure a Drop directory path for a Foreign connector, you should run following cmdlet:
Set-ForeignConnector "Contoso Foreign Connector" -DropDirectory "C:\Drop Directory"
To check a Foreign agent configuration, you should run the Get-ForeignConnector cmdlet.
A delivery agent also can deliver messages from your SMTP Exchange Server environment to a system
that does not use the SMTP protocol. Each delivery agent is associated with a delivery agent connector,
which queues messages routed to the delivery agent for processing and delivery to the non-SMTP device
or system.
Although the Foreign connector architecture remains in Exchange Server 2013, we recommend that you
use delivery agents for routing messages to non-SMTP systems whenever possible. The primary reasons
for this recommendation include:
You can use queue management for messages.
There is no need to manage file transfer to a Drop directory.
You can verify message delivery.
Note: Typically, delivery agents are produced by third-party companies. By default,

Exchange Server 2013 comes with only one delivery agent connector, which is the Text
Messaging Delivery Agent connector.
Lesson 3
Managing 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. For example, you
can use transport rules to ensure compliance with data-loss prevention policies.
Lesson Objectives
Describe transport rules.
Configure transport rules.
Plan transport rules.
Create transport rules.
Describe data-loss prevention policies.
Configure data-loss prevention policies.
What Are Transport Rules?

Exchange Server applies transport rules to
messages as they pass through the Edge Transport
or through service on Mailbox Server. The
transport rule agent applies transport rules on
the Hub Transport service. Transport rules restrict
message flow and 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 Active Directory Rights Management Services (AD RMS) templates to the messages based on
message criteria.
Transport rules configured on one Mailbox server automatically apply to all other Mailbox servers in
the organization. Exchange Server stores the transport rules in the Configuration container in AD DS,
and replicates them throughout the AD DS forest so that they are accessible to all other Mailbox servers.
This means that Exchange Server applies the same transport rules to all email messages that users send or
receive in the organization.
Configuring Transport Rules

Transport rules are configured by using a wizard,
similar to the wizard that Outlook uses for mailbox
rules. When you configure transport rules, you
should define the following elements:
Conditions. Transport rule conditions indicate

which email message attributes, headers,
recipients, senders, or other message parts
Exchange Server uses to identify the email
messages to which it applies a transport
rule action. If the email message data 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 the
number of conditions that you can apply to a single transport rule.
Note: If you configure multiple conditions on the same transport rule, all of 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.
Planning Transport Rules

Transport rules provide you with an almost
limitless ability to control messaging in your
Exchange Server organization. Always carefully
plan your transport rules to ensure that they
behave as intended. Otherwise, you could
accidentally delete messages, or deliver messages
to unintended recipients.
Consider the following recommendations when
you plan transport rules:
Plan conditions and exceptions carefully.

Transport rule conditions and exceptions
define which messages are affected by the
transport rule. If you implement the rules incorrectly, you may unintentionally modify or delete
messages.
Plan for Transport rule priority and order. In many cases, you will have to apply several transport rules
in your organization. If these transport rules have conditions that can overlap in some cases, it is very
important that you order them properly.
Use regular expressions to check message contents. Use regular expressions to simplify the list of
terms when you are including a text string in a condition. You can use one regular expression, rather
than a list of variations on the same word. For example, when searching for a phone-number pattern,
you can use the expression \d\d\d(-|.)\d\d\d\d, which denotes a pattern of three digits, then a dot
or dash, and then four digits.
Test application of transport rules. Test new transport rules to ensure they behave as intended. This is
important because a new transport rule could conflict with existing transport rules.
Plan for transport rule limitations on encrypted and digitally signed messages. AD RMS integration
with Exchange Server 2013 enables you to implement transport rules and messaging policies when
you are using AD RMS Information Rights Management encryption to protect messages. Encryption
through other mechanisms may prevent you from applying transport rules or records management.
For example, Exchange Server may not be able to scan encrypted messages for the text string
specified in a transport rule. In addition, antivirus scanners cannot scan messages with encrypted
attachments.
Consider transport rule recovery. Deleted transport rules are not easily recoverable. Transport rules
are stored in AD DS, and restoring rules from AD DS is a complex process. Alternatively, documented
transport rules are easy to re-create, and you can export transport rules to backup files by using the
Export-TransportRuleCollection cmdlet. However, when you import transport rules onto a Hub
Transport server, the server replaces all of the existing transport rules for the organization.
Demonstration: Creating Transport Rules

Demonstration Steps
1.
On LON-CAS1, switch to the EAC.
2.
Navigate to mail flow.
3.
Choose to create new transport rule.
4.
Configure rule with following properties:

a.
Rule name: Test Transport Rule
b.
Condition: Apply this rule if, the subject or body includes password
c.
Action: Redirect the message to Administrator
d.
Activate this rule now
5.
Sign in to LON-CL1 as Aidan, and open Outlook 2013. Send a message to Amr@adatum.com with
the following text in the body: My password is Pa$$w0rd.
6.
Sign in to Outlook Web App as Administrator.
7.
Verify that you received an email from Aidan, and that the original message that Aidan sent to Amr is
included.
What Are Data-Loss Prevention Policies?

In todays business environment, email is a
critical communication resource. Various kinds of
information is exchanged by using email, and in
some cases, business-critical information can leak
out of a company in unprotected email.
To prevent this, Microsoft has implemented DataLoss Protection policies in Exchange Server 2013.
The primary purpose of Data Protection policies is
to enforce compliance requirements for businesscritical data and manage its use in email, without
hindering the productivity of workers. For
example, you can configure a policy to prevent
sending data such as credit card numbers, Social Security numbers, and IP addresses in email messages.
Note: Data Loss Prevention is a premium feature that requires an Enterprise Client Access
License (CAL).
Data Loss Protection policies are a set of conditions that contain transport rules, actions, and exceptions.
When Data Loss Protection policies are applied, they filter email traffic to prevent business-critical
information in email from leaving the company. Data Loss Protection Policies are very similar to transport
rules; in fact, they are transport rules with an extended set of options.
The difference between transport rules and Data Loss Protection policies is a new approach to classifying
sensitive information that can be incorporated into mail flow processing. This includes the performance of
deep content analysis through keyword matches, dictionary matches, regular expression evaluation, and
other content examination to detect content that violates organizational policies.
You can create Data Loss Protection policies in the EAC, and also in the Exchange Management Shell. It is
possible to create these policies for testing, where you just observe the effects of the policies, or you can
enforce them to all email traffic in your organization.
One benefit of Data Loss Protection policies is the ability to inform email senders that they may be
violating one of your policies, even before they send a message. This is accomplished by using Data Loss
Protection Policy Tips, which are very similar to MailTips, but are preconfigured to be used with Data Loss
Protection policies.
Microsoft provides numerous Data Loss Protection policy templates in Exchange Server 2013. You also
have the option of defining your own custom policies and transport rules as an alternative to using
predefined policy templates provided by Microsoft.
There are three different methods that can be applied when implementing Data Loss Protection policies:
Use the templates provided by Microsoft. This is the quickest way to start using Data Loss Protection
policies, and you do not have to build a complete set of rules from the beginning. However, in this
case, you must be sure that the template requirements are addressing your compliance requirements.
Some of the predefined policy templates include:
o
U.S. Financial Data. Helps to detect the presence of data commonly associated with financial
information in the United States. This includes information such as credit card numbers, account
numbers, and debit card data.
Germany Financial Data. Helps to detect the presence of data commonly associated with financial
information in Germany. This also includes information such as credit card numbers, account
numbers, and debit card data.
U.S. Health Insurance Portability and Accountability Act (HIPAA). Helps to detect the presence of
data commonly associated with health information that is subject to HIPAA.
U.S. Patriot Act. Helps to detect the presence of data commonly subject to the U.S. Patriot Act.
U.K. Access to Medical Reports Act. Helps to detect the presence of data commonly associated
with health information in the United Kingdom.
Israel Protection of Privacy: Helps to detect the presence of data commonly associated with
private information in Israel.
Saudi Arabia Anti-Cyber Crime Law. Helps to detect the presence of data commonly associated
with the cyber-crime law in Saudi Arabia.
Use policy files created by a third-party software vendor. You can import policies that are created by
independent software vendors. This enables you to extend the functionality of Data Loss Protection
policies to better suit your compliance requirements. You can import these policies from the policy
file.
Create a custom policy. If any of the predefined policies do not meet your requirements, you have
the option to create your own custom policy to start checking and acting upon your own unique
message data. To implement a custom Data Loss Protection policy, you need to know the
requirements and constraints of the environment in which the policy will be enforced.
When you create Data Loss Protection policies, you also can include rules that check for sensitive
information. These information types should be used in your policies. The conditions that you establish
within a policy, such as how many times something is found before an action is taken, might be
customized within your new policies, to meet your specific policy requirements.
To implement Data Loss Protection policy features, you must have Exchange Server 2013 configured with
at least one sender mailbox.
Demonstration: Configuring Data Loss Protection Policies

Demonstration Steps
1.
In the EAC on LON-CAS1, navigate to compliance management data loss prevention.
2.
Select to create new custom DLP Policy.
3.
Configure the policy as follows:
4.
a.
Policy is Enforced
b.
Name of policy: IP address block
c.
Include rule: Block messages with sensitive information
d.
Sensitive information type: IP address
e.
Action: Generate incident report and send it to Administrator
f.
Include following properties: sender, recipient, subject and matching content
g.
Action: notify the sender with a Policy Tip with text your message is blocked.
Activate and save the policy.

Scenario
You are a messaging administrator in A. Datum Corporation, which is a large multinational organization
that has offices in several cities. Your organization has deployed Exchange Server 2013. You need to
configure Exchange Server to send messages to the Internet and receive messages from the Internet. You
also need to ensure that you can troubleshoot message transport, if necessary. At the end, you need to
implement some configure message transport rules, according to the corporate security policy.
Objectives
At the end of this lab, you will be able to:
Configure message transport.
Troubleshoot message delivery.
Configure transport rules and data-loss prevention policies.
Lab Setup
Virtual machines
20341B-LON-DC1
20341B-LON-CAS1
20341B-LON-MBX1
20341B-LON-CL1
User Name
Password
Pa$$w0rd
1.
2.
3.
4.

a.
b.
Password: Pa$$w0rd
5.
6.
Repeat steps 2 and 3 for 20341B-LON-CL1. Do not sign in until directed to do so.
Exercise 1: Configuring Message Transport

Scenario
Your organization has deployed Exchange Server 2013 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 message
transport to and from the Internet. You also need to enable one application that is running on the host
with IP address 172.16.0.10 to anonymously relay email through your Exchange server.
1.
Configure a Send connector to the Internet.
2.
Configure a receive connector to accept relaying.
Task 1: Configure a Send connector to the Internet

3.
On LON-CAS1, open Windows Internet Explorer and type https://lon-cas1.adatum.com/ecp,

and press Enter.
4.
5.
Navigate to mail flow send connectors.
6.
Select to create a new send connector with the following properties:

a.
Name: Internet sending
b.
Type: Internet
c.
Resolution: MX record associated with recipient domain
d.
FQDN : *
e.
Source Server: LON-MBX1
Task 2: Configure a receive connector to accept relaying

1.
In the EAC, select to create a new receive connector.
2.
Name the connector AppClient.
3.
Allow connections only from IP address 172.16.0.10.
4.
Allow anonymous connections from this IP.
Results: After completing this exercise, the students will have configured message transport.
Exercise 2: Troubleshooting Message Delivery

Scenario
You have successfully installed Exchange Server 2013 in two sites. You now need to make sure that mail
flow is working correctly.
1.
Verify that messages from the Internet can be received.
2.
Troubleshoot message transport.
Task 1: Verify that messages from the Internet can be received

1.
On LON-DC1, use Telnet to connect to LON-CAS1 with SMTP protocol.
2.
Issue the following commands at the Telnet prompt, and press Enter between the commands:
a.
helo
b.
mail from: info@internet.com
c.
rcpt to:Aidan@adatum.com
d.
data
e.
Test from Internet
f.
. (period)
3.
Switch to LON-CL1, log on as Aidan with the password Pa$$w0rd, open Outlook 2013, and verify
that you received an email from info@internet.com.
4.
Reply to the message with the text of your choice.
Task 2: Troubleshoot message transport

1.
On LON-MBX1, open the Exchange Toolbox.
2.
Start Queue Viewer.
3.
Verify that there is a queue for the domain internet.com.
4.
Remove the message from Aidan@adatum.com.
5.
Switch to Outlook 2013 on LON-CL1, and ensure that Aidan received a NDR.
Results: After completing this exercise, the students will have completed SMTP troubleshooting.
Exercise 3: Configuring Transport Rules and Data-Loss Prevention Policies

Scenario
You are testing transport rules and Data-Loss Prevention policies. At first, you will implement a transport
rule that appends a disclaimer for every message that is sent from A. Datum organization. In addition,
according to the corporate security policy, you should create a data-loss prevention policy that prevents
users from sending IP address data in emails.
1.
Implementing and testing a disclaimer transport rule.
2.
Create a Data-Loss Prevention policy.
3.
Verify data-loss prevention policy functionality.
4.
Task 1: Implementing and testing a disclaimer transport rule

1.
On LON-CAS1, in the Exchange admin center, click mail flow in the feature pane.
2.
On the rules tab, start the wizard for the new rule.
3.
Select that the rule is applied whenever the sender of the message is inside the organization.
4.
Select action for the message to be Append the disclaimer.
5.
Type the text this is Adatum Disclaimer text as the disclaimer.
6.
Select wrap as the fallback action.
7.
Configure that Administrator should be excluded from this rule.
8.
Switch to LON-CL1 and in Outlook 2013, send a test message to Administrator.
9.
Sign in to Outlook Web App as Adatum\Administrator with the password Pa$$w0rd.
10. Verify that you received the message from Aidan, and that it includes the disclaimer.
11. Reply to that message.
12. On LON-CL1, open the message from Administrator, and verify that there is no disclaimer.
Task 2: Create a Data-Loss Prevention policy

1.
In the EAC on LON-CAS1, navigate to compliance management data loss prevention.
2.
Select to create a new custom DLP Policy.
3.
Configure the policy as follows:
4.
a.
Policy is Enforced
b.
Name of policy: IP address block
c.
Include rule: Block messages with sensitive information
d.
Apply this rule if: The recipient is located inside the organization.
e.
Sensitive information type: IP address
f.
Action: Generate incident report and send it to Administrator
g.
Action: notify the sender with a Policy Tip with text your message is blocked
Activate and save the policy.
Task 3: Verify data-loss prevention policy functionality
1.
Ensure that you are logged on to LON-CL1 as Aidan.
2.
Switch to Outlook 2013.
3.
Send a message to amr@adatum.com with the following text: This is my IP address: 192.168.0.100.
4.
Wait for a few moments, and see if you receive an email message that your previous message to Amr
Zaki is undeliverable. Also ensure that Your message is blocked text appears. Review the message
content.
5.
Switch to Internet Explorer.
6.
In the Outlook Web App, ensure that you received an email from Aidan and that original message
that Aidan sent to Amr is attached.
following steps:
1.
2.
3.
4.
5.
6.
7.
8.
a.
b.
Password: Pa$$w0rd
Results: After completing this exercise, the students will have configured transport rules and data-loss
prevention policies.

Best Practice
Do not modify default message routing flow unless it is absolutely necessary.
Use Queue Viewer as the first tool to diagnose message delivery failure.
Understand the difference between transport rules and data-loss prevention policies.

Common Issue
Troubleshooting Tip
Transport rule is not applied to the message
Review Question
Question: Where is the Hub Transport functionality from Exchange Server 2007 and
Exchange Server 2010 located in Exchange Server 2013?
Tools
Queue Viewer

9-1
Module 9
Planning and Configuring Message Hygiene
Contents:
Module Overview
9-1
Lesson 1: Planning Messaging Security
9-2
Lesson 2: Implementing an Antivirus Solution for Exchange Server 2013
9-9
Lesson 3: Implementing an Anti-Spam Solution for Exchange Server 2013
9-15
9-27
9-33
Module Overview
In any deployment, Exchange Server 2013 is exposed to the Internet 24 hours a day because email
messages are commonly sent and received from the Internet. Users connect from the Internet to access
their mailboxes by using different types of web browsers, computers, and devices. When users have this
exposure to the Internet, organizations must plan and deploy security solutions that will protect their
Exchange infrastructure. Organizations also must ensure that critical data, such as email messages, are
protected from unauthorized access from the Internet, and that servers are protected from network
attacks and malware.
Objectives
Plan messaging security.
Implement an antivirus solution for Exchange Server 2013.
Implement an anti-spam solution for Exchange Server 2013.
Lesson 1
Planning Messaging Security

When administrators plan Exchange Server 2013 deployment, security should be part of their
organizations overall IT infrastructure security strategy. Administrators should have expertise in
Exchange Server 2013, networking, security, Windows Server 2012 operating system, and Active
Directory Domain Services (AD DS) when they plan messaging security.
Security solutions complexity and cost might differ depending on the organizations business
requirements and security requirements. Because cost is important, administrators should make sure
that they include business managers in the process of approving the optimal security solution.
Lesson Objectives
Define messaging security requirements.
Plan a Simple Mail Transfer Protocol (SMTP) gateway solution.
Plan restrictions to message flow.
Plan SMTP connector security.
Plan secure message routing between partner organizations.
Plan client-based messaging security.
Defining Message Security Requirements

When administrators plan security, they should
align their plan with the global corporate-security
requirements. Organizations should define the
types of clients that will be connecting to their
Exchange Server. They also should define how to
protect their messaging infrastructure from both
external and internal security threats.
Defining message security requirements includes
following components:
9-2 Planning and Configuring Message Hygiene
Exchange Server security requirements.

Exchange servers must be configured with
malware protection and spam protection.
Organizations can use on-premise or cloud-based anti-spam and antimalware solutions to protect
from unwanted email and security threats. In addition, operating systems where Exchange Server
2013 is installed should have Windows Firewall with Advanced Security configured.
Perimeter security requirements. Organizations should deploy firewalls and reverse proxy software
or devices to protect the internal IT infrastructure and Exchange Servers from attacks and malware
originating from the Internet. In addition, you can use SMTP gateway software or devices deployed
in the perimeter network. SMTP gateway software or devices should have antimalware and anti-spam
software installed.
Internal client security requirements. Each client that connects to the Exchange infrastructure through
the organizations internal network should have antimalware software installed. In addition, we
recommend that internal clients have local firewall enabled and configured.
Core Solutions of Microsoft Exchange Server 2013
9-3
External client security requirements. Organizations should decide which external clients they will
allow to connect to Exchange Server infrastructure. The external clients that are allowed to connect
through the Internet also should have antimalware software installed and a local firewall enabled and
configured. Organizations should also decide which type of access they will allow, such as Microsoft
Outlook Web App, Outlook Anywhere, and Microsoft Exchange ActiveSync.
SMTP Gateway Solution

The Simple Mail Transfer Protocol (SMTP)
gateway solution is software or a device that is
deployed in a perimeter network. If the SMTP
gateway solution in a perimeter network runs
on a Windows Server operating system, the
computer should not be a member of the domain.
This configuration makes it much easier and
more secure to deploy in a perimeter network,
because domain member computers located
in perimeter network need more ports opened
on firewall for connecting to domain controllers,
comparing to non-domain computers. When
you deploy a SMTP gateway solution, consider the following infrastructure requirements:
The SMTP gateway solution should help prevent spam messages and malware from reaching your
organizations users by providing different layers of spam filtering and malware protection.
You should install a SMTP gateway solution on standalone servers, or as a device. The SMTP gateway
solution must have a fully qualified domain name (FQDN) configured. This is because the MX record
of the organizations SMTP domain resolves to the FQDN of the SMTP gateway when external mail
servers send email to the organization. The SMTP gateway also must be able to communicate on port
25 in both directions with internal network.
You should deploy a SMTP gateway solution in a perimeter network. This configuration provides the
highest level of security.
The firewall configuration required for a SMTP gateway solution 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 TCP port 25 from all external IP

addresses to the SMTP gateway solution.
This rule enables SMTP hosts on the

Internet to send email.
External
Allow TCP port 25 to all external IP

addresses from the SMTP gateway
solution.
This rule enables the SMTP gateway

solution to send email to SMTP hosts
on the Internet.
External
Allow TCP and UDP port 53 to all external

IP addresses from the SMTP gateway
solution.

solution to resolve Domain Name
System (DNS) names on the Internet.
Internal
Allow TCP port 25 from the SMTP

gateway solution to specified Client
Access servers.

solution to send inbound SMTP email
to Client Access servers.
Firewall
Firewall rule
Explanation
Internal
Allow TCP port 25 from specified Client

Access servers to the SMTP gateway
solution.
This rule enables the Client Access

servers to send email to the SMTP
gateway solution.
Internal
If the SMTP gateway solution is

configured to contact AD DS, allow the
specific port needed for secure access
between SMTP gateway solution and
domain controllers, such as Lightweight
Directory Access Protocol (LDAP) port
636.
This rule enables the AD DS to

communicate with the SMTP gateway
solution.
Internal
Allow a port 3389 for remote

administration of the Remote Desktop
Protocol (RDP) from the internal network
to the SMTP gateway solution.
This rule is used for optional remote

desktop administration of the SMTP
gateway solution.
If the SMTP gateway solution directly routes email to the Internet, you must configure the server with
the IP addresses of the DNS servers that can resolve DNS names on the Internet.
Note: Although an Edge server role is included in Microsoft Exchange Server 2007
and Microsoft Exchange Server 2010, it is not included in Exchange Server 2013. However, an
Exchange Server 2013 environment supports the deployment of an Exchange Server 2010 Edge
role as an SMTP gateway solution in a perimeter network.
Planning Restrictions to Message Flow

Every organization sends and receives email
messages 24 hours a day, seven days a week.
The messages are sent and received from the
Internet, and within the organization. To increase
messaging security, organizations can optionally
restrict message flow, so that some emails will not
be allowed to be sent to the Internet, and others
will not be sent within the corporate network.
Planning restrictions to message flow includes:
Planning for message delivery restrictions.

Organizations might decide to restrict who
can send email to selected users or groups.
For example, you can configure some distribution groups in your organizations to receive email only
from authenticated users.
Planning for transport rules. Transport rules are applied as messages pass through the Exchange
Server transport components on the Mailbox server role. 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 the
9-5
Planning for message moderation. You can assign moderators permissions to review all messages that
are sent to the recipient object, such as a user mailbox or a distribution list. You also can configure a
list of users that do not require moderation. In addition, you can configure notifications to alert the
message originators if their message is approved or not.
Planning for data-loss prevention. Data Loss Prevention (DLP) is a new custom feature in Exchange
Server 2013 that performs message content analysis and filtering by using keyword matches,
dictionary matches, regular expression evaluation, and other content examination. The features goal
is to detect content that is not compliant with organizational security and compliance policies.
Planning SMTP Connector Security

Exchange Server 2013 offers several options to
secure SMTP messaging traffic. All of 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.
IPSec
IPSec provides a set of extensions to the basic

IP protocol, and you can use it to encrypt serverto-server communication. You can use IPSec to
tunnel traffic, or peer-to-peer, to secure all IP
communications natively. Because IPSec operates
on the transport layer and is network based, applications that run on Exchange Server 2013 do not need
to be aware of IPSec. You can use IPSec to secure server-to-server or client-to-server communication. You
do not need another encryption method when using IPSec.
VPN
VPN also operates on the transport layer, and it frequently uses IPSec as the underlying protocol. You can
use VPN 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 transport layer security (TLS) protocol is the default protocol that an Exchange Server 2013
organization uses 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 SSL protocol.
Exchange Server 2013s Domain Security feature uses TLS with mutual authentication, also known as
mutual TLS, to 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.
Alternate Options for Securing SMTP Traffic
Besides the abovementioned options, you can also implement authentication and authorization on SMTP
connectors for security. This does not enforce traffic encryption, but it can prevent unauthorized users
from sending SMTP messages to users in your organization, or relaying SMTP messages to the Internet.
You can configure authentication and authorization based on user login, or on IP addresses or IP ranges.
Planning Secure Message Routing Between Partner Organizations

You can configure Exchange Server 2013 to 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.
Securing a Connector to a Partner

Organization
To secure a connector to a partner organization,

you should configure mutual TLS, where each
server verifies the identity of the other server by validating the certificate that the other server provides. 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 that 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.
Securing a connector to a partner organization works in a manner similar to establishing a TLS connection
to an SMTP Receive connector. However, because mutual TLS is used, both the sender and the recipient
authenticate each another before they send data. The message takes the following route from one
organization to the other:
1.
The transport component on the sender Mailbox server initiates a mutual TLS session with the
transport component on the target Mailbox 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.
2.
The SMTP communication is encrypted and transferred to the target Mailbox server.
3.
The message is marked as secure, which displays in Outlook 2007 or newer versions, and in Outlook
Web App.
To secure a connector to a partner organization, you need to perform the following process:
1.
On the Mailbox 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.
2.
Import and enable the certificate on the Mailbox server. After you request the certificate, you must
import the certificate on the Mailbox server, and then enable the certificate for use by the SMTP
connectors that are used to send and receive domain-secured email.
9-7
3.
Configure outbound connector security. To configure outbound connector 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 connector security. To configure inbound connector security, use Exchange
Management Shell cmdlets to specify the domains from which you will receive domain-secured email,
and then configure the SMTP Receive connector to use domain-secured email.
5.
Notify partner to configure connector security. Connector security must be configured on both sides,
the sending and receiving side. This means that you also need to contact your partners administrator
to configure your domain for connector security.
6.
Test message flow. Finally, send a message to the partner, and vice versa, to verify that domain
security is working correctly.
Note: When you install the Mailbox server role, a self-signed certificate is issued to the
server. No other computers trust this certificate. When you require that the partner organization
trusts the certificate, you should purchase a certificate from a commercial CA. If you do not want
to purchase a certificate from a commercial CA, you can create across-forest trust, or import a
CAs certificate in the trusted root CA store on both sides.
Planning Client-Based Messaging Security

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 actually did 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 onetime 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

When you configure S/MIME, consider the following:
A client certificate is required on each computer that sends secure email. Distributing client
certificates for users who do not understand the technology takes significant administrative time.
A sender must obtain access to the recipients public key before the sender can send an encrypted
email. Normally, this is accomplished by sending a digitally signed email.
S/MIME is a user-based security model; therefore, the user has to take the action to sign or encrypt
the message. Users may forget or not realize which email messages to secure.
Certificates must be backed up. If one is lost, the user will not be able to decrypt messages that were
encrypted with the public key associated with the certificate.
Messages cannot be scanned for policy compliance, viruses, or spam because the messages entering
or leaving the organization are encrypted. The messages remain encrypted in the users mailbox.
To set up a secure channel, all other solutions require some level of agreement between the messaging
administrators in the two organizations. If users need to send secure emails to recipients in many different
organizations, S/MIME is the most feasible option.
Demonstration: Configuring Secure Message Routing Between Partner

Organizations
Demonstration Steps
1.
On LON-CAS1, open the Exchange Administration Center (EAC) at https://LON-CAS1.adatum.com

/ecp, and then sign in as Adatum\Administrator with the password Pa$$w0rd.
2.
Navigate to mail flow send connectors.
3.
Create a send connector dedicated to the contoso.com domain. Click Partner type of connector.
Select LON-MBX1 as a source server and select the option to proxy through client access server.
4.
Create a receive connector dedicated to contoso.com.
5.
Click Partner type of connector, and then configure the connector to accept email only from
172.16.0.101.
6.
On LON-CAS1, in the Exchange Management Shell, type :

Set-TransportConfig TLSSendDomainSecureList adatum.com and press Enter.
7.
On LON-CAS1, in the Exchange Management Shell type :

Set-TransportConfig TLSReceiveDomainSecureList contoso.com, and press Enter.
Note: The steps described in this demonstration also should be performed in the partner
organization Contoso. Contoso should create partner send connector for adatum.com domain,
create a receive connector for adatum.com, and configure TLS security for SMTP protocol with
adatum.com domain.
Lesson 2
Implementing an Antivirus Solution for Exchange

Server 2013
9-9
Email is one of the most common ways to spread viruses from one organization to another. One of your
primary tasks in protecting your Exchange Server organization is to ensure that all messages that contain
viruses are stopped at the messaging environments perimeter, but also within the corporate network.
Exchange Server 2013 introduces a built-in feature for antimalware protection. This feature can be used
as a standalone solution, or it can be paired with Microsofts cloud-based solution known as Exchange
Online Protection. It also can be replaced with a third-party antivirus solution.
Lesson Objectives
Describe antivirus solution requirements.
Describe options for implementing an antivirus solution in Exchange Server 2013.
Configure antivirus solution features in Exchange Server 2013.
Describe Exchange Online Protection.
Describe deployment options for Online Protection.
Define best practices for deploying an antivirus solution.
Overview of Antivirus Solution Requirements

Organizations should evaluate and plan their
antivirus solution on a corporate level. They
must ensure that their IT infrastructure is
protected from any threat, regardless of whether
it originates from the Internet or from within their
internal corporate network. To successfully protect
their Exchange Server environment, organizations
must also protect all other software products,
such as Windows server and client computers,
Microsoft SQL Server, and Microsoft SharePoint
Server.
When planning an antivirus solution,
organizations should consider the following requirements:
Protection from malware (viruses and spyware). The solution must be efficient in recognizing and
removing all threats from the email, including viruses and spyware.
Protection from spam. The solution should also have anti-spam features in order to provide a single
management console for protection from both malware and spam.
Designed for Exchange Server 2013. An antivirus solution must be designed to support the new
architecture in Exchange Server 2013. Antivirus solutions designed for previous Exchange Server
versions cannot be used with Exchange Server 2013. Furthermore, we do not recommend file-levelbased antivirus solutions for protecting Exchange Server 2013. If you use file-level-based antivirus
solutions, you must follow Microsoft documentation on how to configure this type of antivirus
software.
Corporate antivirus software. Organizations also might choose to deploy a corporate antivirus
solution that has agents that provide protection for different technologies, including file-level based
protection, Exchange Server, and Microsoft Lync Server. In this scenario, security administrators have
a single console for monitoring multiple servers and their protection status.
Options for Implementing an Antivirus Solution in Exchange Server 2013

Each organization has its own unique strategy
for antivirus protection, which is based on the
organizations business requirements. Some
organizations choose to deploy the built-in
antimalware protection in Exchange Server 2013,
while other organizations invest in third-party
solutions. Some organizations might choose to
use a cloud-based solution such as Exchange
Online protection to eliminate any potential
infected email before it reaches the corporate
network.
When you plan your antivirus solution for
Exchange Server 2013, you should consider the following options:
Use the built-in antimalware features. Antivirus organizations can use the built-in protection that
runs on the Mailbox server role of Exchange Server 2013, and configure it according to their business
requirements. No investment in additional antivirus software is needed.
Use a hosted, cloud-based solution or hybrid solution. In this scenario, organizations can choose to
use both onsite antimalware protection in Exchange Server 2013 and Exchange Online Protection.
Organizations benefit from multiple antimalware filtering performed with different engines in the
cloud and on-premise.
Use the existing corporate antivirus solution. Some organizations already have a third-party corporate
antivirus solution. In this scenario, they would disable the built-in antimalware protection for
Exchange Server and install third-party antivirus software for Exchange Server 2013 that will integrate
with the corporate antivirus solution.
Deploy an antivirus solution in the perimeter network. Many organizations deploy a SMTP gateway
solution that also has antivirus and anti-spam software installed. In this scenario, email is inspected for
malware before it enters the corporate network. It is also recommended that the SMTP gateway and
Exchange Server Mailbox role have different engines.
Antivirus Solution Features in Exchange Server 2013

Exchange Server 2013 introduces built-in
antimalware protection that is deployed on
the Mailbox server role. This protection is not
available on the Client Access server role.
Exchange antimalware protection features include:
9-11
Antimalware protection can be enabled or

disabled. Organizations might choose
between Exchange Server 2013 antimalware
protection and using a third-party antivirus
solution. If a third-party antivirus solution is
used, then Exchange antimalware protection
should be disabled. You can enable or disable
antimalware protection only in Exchange Management Shell. Exchange antimalware protection can
also be bypassed by using Exchange Management Shell, which is used in scenarios where you would
troubleshoot issues that are related to Exchange antimalware protection.
Once enabled, antimalware protection will connect to the Internet using HTTP port 80 in order to
download engine and definition updates. By default, engine and definition updates are downloaded
every hour. We highly recommend that you download engine and definition updates before the
Exchange Server is deployed in a production environment, because an Exchange Server that is not
updated is vulnerable to security threats. You can manually download engine and definition updates
by using Exchange Management Shell.
The scanning is performed on each message that is sent or received by the Mailbox server role.
Scanning does not occur on a message that is accessed by the user, because that message was
already scanned when it was received.
You can configure the default antimalware policy by using both the EAC and Exchange Management
Shell. Default antimalware policy cannot be deleted. Configuration settings allow you to choose one
of the following actions if malware is detected in a message:
o
Delete the entire message. This is the default setting that will delete the entire message, including
attachments, and prevent them from being delivered to users. This setting will also apply if
malware is detected in the body of the message, regardless of the antimalware policy
configuration.
Delete all attachments and use default alert text. If malware is detected in an attachment, this
action will delete all message attachments, including those that are not infected. In addition, the
following default alert text will be inserted into a text file that replaces the attachments: Malware
was detected in one or more attachments included with this email. All attachments have been
deleted.
Delete all attachments and use custom alert text. If malware is detected in an attachment, this
action will delete all message attachments, including those that are not infected. In addition, you
can configure a custom message that will be inserted into a text file that replaces the
attachments.
Notify the administrator and sender. A message can be sent to the sender or administrator that
an email was not delivered because of the malware detected.
What Is Exchange Online Protection?

Exchange Online Protection (formerly Microsoft
Forefront Protection for Exchange) is a cloudbased anti-spam and antimalware solution.
Organizations can choose to deploy it as a single
solution or a hybrid solution together with the
Exchange Server on-premise antimalware
protection. Because this is a cloud-based product,
it does not require any hardware or software
deployment. Instead, the current Mail Exchanger
(MX) records of the on-premise Exchange Server
are reconfigured to point to the servers where
Exchange Online Protection is hosted.
Exchange Online Protection has the following features:
Web-based management console. Administrators can manage antimalware protection according to

their organizations requirements, even if the server is not hosted on-premise.
Multi-engine antivirus. Multiple engines that run on Exchange Online Protection eliminate malware
threats before they reach the corporate network.
Real-time response. Exchange Online Protection is updated every two hours with definition updates
and antimalware rules. Antimalware engines are updated before they are publicly released.
Email availability. If an on-premise Exchange Server infrastructure is unavailable for any reason,
Exchange Online Protection automatically queues email and delivers messages once the Exchange
Server infrastructure comes back online.
Reporting. This feature provides comprehensive reporting, auditing, and message-tracing capabilities.
Best Practices for Deploying an Antivirus Solution

Deploying and managing an antivirus solution in
Exchange Server is a continuous process. Exchange
administrators should regularly monitor and
evaluate their antivirus solution to report on its
efficiency; this may include statistics such as the
percentage of messages cleaned from malware.
Furthermore, Exchange administrators and security
administrators should also stay abreast of the
latest security threats.
You should consider the following best practices
when you deploy an antivirus solution:
Provide multi-layered protection. 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. Therefore, as a best practice, you should implement several layers of antivirus
protection, such as on-premise Exchange antimalware protection, a firewall, a SMTP gateway server
at the client-computer level, and cloud-based Exchange Online Protection. Furthermore, it is
recommended that antimalware engines on the cloud-based solution or on the SMTP gateway be
different from those on the on-premise antimalware solution.
9-13
Maintain regular antivirus updates. Installing an antivirus product does not automatically mean
that your organization is fully protected. Regular antivirus pattern updates are crucial to a wellimplemented antivirus solution. You also should monitor your antivirus patterns frequently to
ensure that they are up to date.
Monitor antivirus reports. Exchange administrators should regularly monitor antivirus software reports
to evaluate statistical information, such as the total number of messages received from the Internet
and the number of blocked messages due to malware.
Stay informed on the latest Internet security and malware threats. Exchange administrators and
security administrators should regularly update their knowledge about the latest security, spam, and
malware threats. You should also reconfigure the antimalware settings according to the most recent
best practices and recommendations.
Demonstration: Configuring Antimalware Protection for Exchange Server

Demonstration Steps
Enabling antimalware features in Exchange Server 2013
1.
On LON-MBX1, in the Exchange Management Shell, type the following:

CD C:\Program Files\Microsoft\Exchange Server\V15\Scripts
2.
In the Exchange Management Shell, enable antimalware scanning by typing the following script:
.\Enable-AntimalwareScanning.ps1
3.
Verify that the following message appears: Antimalware engines are updating. This may take a
few minutes.
4.
In the Exchange Management Shell, restart the Microsoft Exchange Transport Service by running
the following cmdlet:
Restart-Service MSExchangeTransport
5.
Type CTRL-C to stop running the script.
6.
In the Exchange Management Shell, list the installed transport agents by running the following
cmdlet:
Get-TransportAgent
7.
Verify that the following antimalware agent is listed: Malware Agent. Verify that the status of
Malware Agent is Enabled True.
Configuring the default antimalware policy

1.
Switch to LON-CAS1.
2.
In the EAC, open the Malware filter tab.
3.
Edit the default antimalware policy by selecting:

o
Malware Detection Response: select Delete all attachments and use custom alert text.
Custom alert text box, and then type:

The attachment has been deleted because it contained malware. Contact your
administrator.
4.
5.
Notifications: select both the Notify internal senders and Notify external senders check
boxes.
Administrator Notifications: select Notify administrator about undelivered messages from

internal senders check box.
Administrator email address box: type administrator@adatum.com.
Next, continue to edit the default antimalware settings by selecting:

o

external senders check box.
Save the configuration settings.
Lesson 3
Implementing an Anti-Spam Solution for Exchange

Server 2013
9-15
Spam messages can adversely affect the messaging environment of your organization. Therefore,
implementing an anti-spam solution is a critical component of maintaining your organizations messaging
environment hygiene. Exchange Server 2013 includes several features that you can use to implement antispam protection in your organization.
This lesson provides an overview of the options available for anti-spam filtering, and describes how you
can configure your Exchange Server 2013 to reduce spam in your organization.
Lesson Objectives
Define anti-spam solutions.
Describe Exchange Server 2013 spam-filtering features.
Apply Exchange Server 2013 spam filters.
Configure Sender ID filtering.
Configure sender reputation filtering.
Configure content filtering.
Understand the spam confidence level (SCL) in Exchange Server 2013.
Apply best practices for deploying an anti-spam solution.
Overview of Anti-Spam Solutions

Organizations should evaluate and plan their
strategy regarding the most appropriate
anti-spam solution based on their network
infrastructure and business requirements. They
might consider using different solutions, including
on-premise software or devices, or cloud-based
anti-spam services.
When you plan to deploy an antivirus solution,
you should consider the following options:
Ease of configuration. The solution should be

straightforward to configure and manage. It
should also be efficient in how it recognizes
and blocks spam.
Protection from malware. Ideally, the solution should also have antimalware features to provide
a single management console for protection from both spam and malware.
Use the built-in anti-spam features. Organizations can use the built-in protection that runs on
the Mailbox server role of Exchange Server 2013 and configure it according to their business
requirements. No investment in additional antivirus software is needed.
Hosted, cloud-based solution or hybrid solution. In this scenario, organizations might choose to use
both onsite anti-spam features in Exchange 2013 and Exchange Online Protection. Organizations will
benefit from multiple anti-spam filtering solutions that will help keep spam outside the corporate
network.
Deploying an anti-spam solution in the perimeter network. Many organizations deploy a SMTP
gateway solution that also has anti-spam features. In this scenario, email is inspected for spam before
it enters the corporate network.
End-user notification for quarantined messages. The solution notifies users if an email sent is blocked.
If the email is blocked, it is sent to quarantine. Messages located in the quarantine are very likely to
be false positive, which means that the email has is blocked due to anti-spam or antimalware
scanning. If he email is not a spam and does not contain malware users can request that the
administrator to forward quarantined message to the users inbox. Some anti-spam software solutions
have options to enable users to retrieve their quarantined messages without administrators authority.
Overview of Spam-Filtering Features

The spam-filtering functionality available on the
Mailbox server role is not enabled by default. If
you do not have a SMTP gateway, Exchange
Edge Transport server 2010 or online anti-spam
solution, you should enable spam filtering in
Exchange Server 2013. To enable and configure
anti-spam filtering in Exchange Server 2013, you
should use the Exchange Management Shell. You
cannot configure spam-filtering with the EAC.
Mailbox Server Anti-Spam Agents

The following table lists the anti-spam agents
implemented during the default installation of the
Agent
Description
Content
Filtering
Filters messages based on the message contents. This agent uses Microsoft
SmartScreen technology to assess the message contents. It also supports safelist
aggregation.
Sender ID
Filters messages by verifying the IP address of the sending SMTP server against the
purported owner of the sending domain.
Sender
Filtering
Filters messages based on the sender in the MAIL FROM: SMTP header in the
message.
Recipient
Filtering
Filters messages based on the recipients in the RCPT TO: SMTP header in the
message.
Sender
Reputation
Filtering
Filters messages based on many sender characteristics accumulated over a specific

period.
Unlike previous Exchange Server versions, Exchange Server 2013 does not provide an option for
connection filtering based on sender IP or real-time block list (RBL) providers. It is critical that
organizations deploy a connection filtering gateway or a cloud based anti-spam solution that
includes connection filtering based on sender IP and RBL lists, because most of the spam can be
blocked by using RBL providers.
9-17
Anti-spam configuration filtering features in Exchange Server 2013 is only performed by using Exchange
Management Shell. The filtering agents are not installed by default. To install all anti-spam agents, you
should run the Install-AntiSpamAgents.ps1 script in Exchange Management Shell, located in following
path the ExchangeInstallPath\Scripts, where ExchangeInstallPath is a variable that represents a folder
where Exchange Server files have been installed.
Note: You can view all the agents installed on the Mailbox server by using the
Get-TransportAgent cmdlet on the Mailbox server.
Safelist Aggregation
In Exchange Server 2013, the Content Filter agent on the Mailbox 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 2013 share. This
anti-spam functionality collects data from the anti-spam safe lists that Microsoft Outlook users configure,
and makes this data available to the anti-spam agents on the Mailbox server. You must use the
Update-Safelist cmdlet to configure safelist aggregation.
Applying Exchange Server 2013 Spam Filters

The Mailbox server role in Exchange Server 2013
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 Exchange Client Access server and initiates
an SMTP session, the SMTP protocol is proxied to
the Mailbox server, where the Mailbox server
examines each message by using the following
sequence:
1.
The Mailbox 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. In addition, 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.
2.
The Mailbox server examines the recipient against the Recipient Block list configured in recipient
filtering. If the intended recipient matches a filtered email address, the Mailbox 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.
3.
Exchange Server 2013 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.
4.
The Mailbox server applies content filtering, which 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 SCL rating and content filtering performs one of the following actions:
o
If the SCL rating is higher than one of the configured Mailbox 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 Mailbox server thresholds, the message is passed to a
transport component of the 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 and Recipient Filtering?

Sender and recipient filtering are features that
provide protection from unwanted email in
Exchange Server 2013. Sender filtering evaluates
the MAIL FROM: SMTP header from an incoming
email. Based on that information, sender filtering
can reject the message if it originates from an
unwanted domain. Recipient filtering evaluates the
RCPT TO SMTP header from an incoming email.
Based on that information recipient filtering can
send an SMTP error message to the sending server
if the message is sent to a non-existing recipient.
Sender Filtering
Sender filtering is performed by the sender filter agent. If the sender email address or a domain matches
the sender filter configuration, the filtering agent performs one of the following actions:
The sender filter agent rejects the SMTP request with a 554 5.1.0 Sender Denied SMTP session error
message and closes the connection.
The sender filter agent does not reject the message, but it stamps the message with information that
it was sent by the blocked sender. Other anti-spam agents that process the same message use the
stamp information to increase the SCL value of the email message sent by the blocked sender.
You can configure sender filtering to block a specific email address, a domain, or a domain with
its subdomains. By default, sender filtering is performed on the email that is sent only from the
non-authenticated servers, which are external senders.
After you install anti-spam agents on the Exchange Server Mailbox role, you should check if Sender Filter
Agent is enabled by typing the following cmdlet in Exchange Management Shell:
Get-SenderFilterConfig | Format-List Enabled
9-19
To configure sender filtering to block messages from marketing@contoso.com, you should type the
following cmdlet:
Set-SenderFilterConfig -BlockedSenders marketing@contoso.com
To configure sender filtering to block all messages originating from company with an SMTP domain of
contoso.com, you should type the following cmdlet:
Set-SenderFilterConfig -BlockedDomains contoso.com
Recipient Filtering
Recipient filtering is performed by the recipient filter agent. Based on the destination email address of the
recipient, recipient filter agent performs one of the following actions:
If the recipient email address does not exist or it should be blocked from receiving email from
external senders, appropriate action is performed by the filter agent, such as the Exchange server
sends a 550 5.1.1 User unknown SMTP session error to the sending server.
If an incoming email message is sent to the existing email address, and the recipient does not match
the criteria to be blocked, the recipient filtering agent processes the message and the next anti-spam
agent evaluates the message and the sender.
After you install anti-spam agents on the Exchange Server Mailbox role, you should check if the Recipient
Filter Agent is enabled by typing the following cmdlet in the Exchange Management Shell:
Get-RecipientFilterConfig | Format-List Enabled
To configure recipient filtering to block external messages sent to helpdesk@adatum.com, you should
run the following cmdlet:
Set-RecipientFilterConfig -BlockListEnabled $true -BlockedRecipients helpdesk@adatum.com
To configure recipient filtering to block messages to recipients that do not exist in your organization, run
Set-RecipientFilterConfig -RecipientValidationEnabled $true
What Is Sender ID Filtering?
Sender ID filtering enables received email

messages to be filtered based on the servers from
which they originated. Sender ID filtering requires
implementation of the Sender ID Framework,
which 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. Then, email recipients can filter email from that domain that does not come from the specified
servers.
Sender Policy Framework 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 website.
How Sender ID Works

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.
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.
How Sender ID is configured
After you install anti-spam agents on the Exchange Server Mailbox role, you should check if Sender ID is
enabled by typing the following cmdlet in the Exchange Management Shell:
Get-SenderIDConfig | Format-List Enabled
To configure Sender ID filtering to reject email from spoofed domains, you should type the following
cmdlet in the Exchange Management Shell:
Set-SenderIDConfig -SpoofedDomainAction Reject
You can also configure Sender ID filtering to bypass a specific internal recipient, or for a specific sender
domain. To configure Sender ID filtering exception for a specific internal user, for email received by
contoso.com domain, you should type following cmdlet in the Exchange Management Shell:
Set-SenderIDConfig -BypassedRecipients adam@adatum.com -BypassedSenderDomains
contoso.com
What Is Sender Reputation Filtering?
9-21
The Sender Reputation is part of Exchange Server

2013 Sender anti-spam functionality and it 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 Mailbox 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. The sender open proxy test is 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
Mailbox 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.
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 only by using the Exchange Management Shell. Settings
include the Sender Reputation block threshold, and configuring the timeout period for how long a sender
will remain on the IP Block list. By default, if sender reputation threshold is reached, the sender IP
addresses are blocked for 24 hours.
The agent that performs Sender Reputation filtering is called the Protocol Analysis Agent, and it is not
installed by default. After you install anti-spam agents on the Exchange Server Mailbox role, you should
check the Reputation filtering configuration settings by typing following cmdlet in the Exchange
Management Shell:
Get-SenderReputationConfig | Format-List Enabled,*MailEnabled
To configure sender SRL block threshold to 7 and to add senders that reached that threshold value to the
IP Block List for 36 hours, you should type following cmdlet in Exchange Management Shell:
Set-SenderReputationConfig -SrlBlockThreshold 7 -SenderBlockingPeriod 48
Understanding the SCL in Exchange Server 2013

The Content Filter agent analyzes the content
of every email message to evaluate whether the
message is spam. When the Mailbox 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 a 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.
SCL Thresholds and Actions
You can configure SCL thresholds and actions only in the Exchange Management Shell. The Exchange
server evaluates the SCL value for a specific message and performs the corresponding action defined for
that value in the Exchange Management Shell. Exchange administrators can configure SCL threshold from
0 to 9 and define the following actions:
SCL delete threshold. If the SCL value is equal to or higher than the SCL delete threshold, the message
will be deleted. If the value is lower than the SCL delete threshold, the message will be compared to
the SCL reject threshold.
SCL reject threshold. If the SCL value is equal to or higher than the SCL reject threshold, the message
will be rejected and a non-delivery report (NDR) will be sent to the original sender of the message. If
the value is lower than the SCL reject threshold, the message will be compared to the SCL quarantine
threshold.
9-23
SCL quarantine threshold. If the SCL value is equal to or higher than the SCL quarantine threshold,
the message will be sent to the quarantine mailbox. The users who have administrative permissions
to open the quarantine mailbox might check for any false-positive messages and forward them to
the recipients. False positive is an email has been blocked due to anti-spam or antimalware scanning,
but the email actually is not a spam and does not contain malware. If the value is lower than the SCL
quarantine threshold, the message will be compared to the SCL Junk Email folder threshold.
SCL junk email folder threshold. If the SCL value is equal to or higher than the SCL quarantine
threshold, the message will be sent to the user's Junk Email folder. If the value is lower than the SCL
junk email folder threshold, the message will be delivered to the users mailbox.
What Is Content Filtering?

Content filtering 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 Shell.
You can modify the following settings in the
Exchange Management Shell:
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 from content filtering that
are addressed to recipients on the exceptions list.
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 Mailbox 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 make sure 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 a Mailbox Server, use the scripts located in the following folder:
%programfiles%\Microsoft\Exchange Server\Scripts. 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
in the following folder: %programfiles%\Microsoft\ExchangeServer\TransportRoles\Logs
\AgentLog.
The SCL Junk Email Folder Threshold
If the SCL value for a specific message exceeds the SCL junk email folder threshold, then the Mailbox
server places the message in the Outlook users junk email folder. If the SCL value for a message is lower
than the SCL delete, reject, quarantine, and junk email folder threshold values, then the Mailbox server
puts the message in the users Inbox.
Best Practices for Deploying an Anti-Spam Solution

Anti-spam protection requires ongoing
monitoring of the anti-spam solution reports.
Administrators have to evaluate anti-spam
settings and adjust the configuration according
to current Internet spam threats and the users
feedback. For example, an organizations users
might complain that they receive more than five
spam messages per day, which indicates that antispam configuration should be enhanced with
additional settings.
When configuring anti-spam settings, consider the
following best practices:
Update anti-spam definitions. Anti-spam software uses definitions to scan email for content that is
likely to be spam. However, spam senders are continuously trying to use new techniques to hide the
spam content to avoid anti-spam softer filters. Therefore, anti-spam software vendors must remain
diligent in updating their anti-spam definitions. Consequently, organizations should regularly update
their anti-spam definitions to stay abreast of the latest changes from their anti-spam vendors.
Monitor anti-spam reports. Exchange administrators should regularly monitor anti-spam software
reports to evaluate the total number of messages received from Internet, the number of blocked
messages due to spam, and the number of quarantined messages.
Regularly read about latest Internet security and spam threats. Exchange administrators and security
administrators should regularly update their knowledge about the latest security, spam, and malware
threats. Anti-spam settings should be reconfigured according to latest best practices and
recommendations.
9-25
Regularly evaluate end users feedback. User feedback related to the number of spam messages
received per day or per week and the number of spam messages quarantined per day or per week is
critical when you evaluate the effectiveness of your anti-spam solution. Exchange administrators and
security administrators should regularly evaluate end users feedback on their everyday experience,
and then reconfigure their solution, if necessary, to provide better protection. For example, users
might complain about the excessive number of spam messaged received each day. Conversely, users
might mention that they do not receive email from business partners; this would indicate that antispam software should be reconfigured with less aggressive protection settings.
Use multi-layered anti-spam protection. Exchange Server 2013 anti-spam agents are located on the
4stopped before it enters the internal network. One way that an organization could address this is by
deploying hybrid anti-spam protection; in other words, by using both cloud-based Exchange Online
Protection and Exchange on premise anti-spam features. Another option would be to deploy a SMTP
gateway with anti-spam functionality that is located in the perimeter network, in addition to the antispam features in the Exchange on-premise deployment.
Demonstration: Configuring Anti-Spam Features on Exchange Server 2013

Demonstration Steps
Enabling anti-spam features on LON-MBX1
1.
Switch to LON-MBX1.
2.
Switch to the Exchange Management Shell.
3.
In the Exchange Management Shell, install anti-spam agents by running the following Windows
PowerShell script:
.\Install-AntiSpamAgents.ps1
4.
5.
In the Exchange Management Shell, specify the IP addresses of the internal SMTP servers
LON-MBX1 and LON-MBX2 that should be ignored by the Sender ID agent, by running the
following cmdlet:
Set-TransportConfig -InternalSMTPServers @{Add=172.16.0.22,172.16.0.223}
6.
In the Exchange Management Shell, list installed transport agents by running the following cmdlet:
Get-TransportAgent
7.
Verify that the following anti-spam agents are listed: Content Filter Agent, Sender ID Agent,
Sender Filter Agent, Recipient Filter Agent, Protocol Analysis Agent.
Configuring content filtering on LON-MBX1

1.
In the Exchange Management Shell, verify that content filtering is enabled by running the following
cmdlet:
Get-ContentFilterConfig | Format-List Enabled
Verify that Enabled:True is displayed.

2.
In the Exchange Management Shell, configure the blocked phrase Poker results by running the
following cmdlet:
Add-ContentFilterPhrase -Influence BadWord -Phrase "Poker results"
3.
In the Exchange Management Shell, configure the allowed phrase Report document by running the
following cmdlet:
Add-ContentFilterPhrase -Influence GoodWord -Phrase "Report document"

Scenario
9-27
You are a messaging administrator in A. Datum Corporation, which is a large multinational organization.
Your organization has deployed Exchange Server 2013 internally, and now you must configure options for
message security.
Objectives
After completing this lab, you will be able to:
Configure antimalware in Exchange Server 2013.
Configure anti-spam in Exchange Server 2013.
Lab Setup
Virtual machines
20341B-LON-DC1
20341B-LON-CAS1
20341B-LON-MBX1
User name
Password
Pa$$w0rd
1.
2.
In the Windows Hyper-V Manager, click 20341B-LON-DC1, and in the Actions pane, click Start.
3.
4.
5.
a.
b.
Password: Pa$$w0rd
Repeat steps 2-4 for 20341B-LON-MBX1 and 20341B-LON-CAS1.
Exercise 1: Configure Antimalware Options in Exchange Server 2013

Scenario
A. Datum organization has decided to use Exchange Server 2013 antimalware features. You have to
configure antimalware features to prevent malware from entering your network.
1.
Enable antimalware features in Exchange Server 2013.
2.
Configure the default antimalware policy in Exchange Server 2013.
Task 1: Enable antimalware features in Exchange Server 2013

1.
On LON-MBX1, on the Start screen click Exchange Management Shell.
2.
In Exchange Management Shell, change current folder to \Program Files\Microsoft

\Exchange Server\V15\Scripts by typing the following cmdlet, and then press Enter:
cd \Program Files\Microsoft\Exchange Server\V15\Scripts
3.
In the Exchange Management Shell, enable antimalware scanning by typing the following script:
4.
few minutes. Note that because the lab environment does not have an Internet connection, the
engine update cannot complete. Type CTRL-C to stop the script.
5.
6.
Get-TransportAgent
7.
Verify that the following antimalware agent is listed: Malware Agent. Note that the status of
Malware Agent is Enabled True if the script was allowed to complete.
Task 2: Configure the default antimalware policy in Exchange Server 2013

1.
Switch to LON-CAS1.
2.
Start Internet Explorer.
3.
In Internet Explorer, open the EAC located on following address: https://lon-cas1.adatum.com/ecp.
4.
5.
In the EAC, from the protection feature open the malware filter tab.
Edit the default antimalware policy using following settings:
6.
7.
Malware Detection Response: select Delete all attachments and use custom alert text.
Custom alert text box, type following text: The attachment has been deleted because it
contained malware. Contact your administrator.
Notifications: select both Notify internal senders and Notify external senders check boxes.

internal senders check box.
Next, continue to change the default antimalware policy settings by selecting:

o

external senders check box.
Save the configuration settings.
Exercise 2: Configuring Anti-Spam Options on Exchange Server

Scenario
A. Datum organization has decided to use Exchange Server 2013 anti-spam features. You have to
configure anti-spam features to prevent spam from entering your network.
1.
Enable anti-spam features on LON-MBX1.
2.
Configure content filtering on LON-MBX1.
3.
Configure sender and recipient filtering on LON-MBX1.
Task 1: Enable anti-spam features on LON-MBX1
1.
Switch to LON-MBX1.
2.
In the Exchange Management Shell, install anti-spam agents by running the following PowerShell
script:
3.
4.
In the Exchange Management Shell, specify the IP addresses of the internal SMTP servers
LON-MBX1 and LON-MBX2 that should be ignored by the Sender ID agent, by running the
following cmdlet:
5.
Get-TransportAgent
6.
Verify that the following anti-spam agents are listed: Content Filter Agent, Sender ID Agent,
Sender Filter Agent, Recipient Filter Agent, Protocol Analysis Agent.
Task 2: Configure content filtering on LON-MBX1

1.
9-29
In the Exchange Management Shell, verify that content filtering is enabled by running the following
cmdlet:
2.
3.
In the Exchange Management Shell, configure blocked phrase Poker results by running the following
cmdlet:
4.
In the Exchange Management Shell, configure allowed phrase Report document by running the
following cmdlet:
5.
In the Exchange Management Shell, configure the quarantine mailbox quarantine@adatum.com by

running the following cmdlet, and then press Enter:
Set-ContentFilterConfig
-QuarantineMailbox quarantine@adatum.com
Note: In a production environment, you should also create a user mailbox and configure it
to be a quarantine mailbox.
6.
In the Exchange Management Shell, configure SCL thresholds with the following values
SCLRejectThreshold 8, SCLQuarantineThreshold 7, and enable quarantine by running the following
cmdlet:
Set-ContentFilterConfig -SCLRejectEnabled $true -SCLRejectThreshold 8 SCLQuarantineEnabled $true -SCLQuarantineThreshold 7
7.
In the Exchange Management Shell, configure custom rejection response "Your message was
rejected by our spam filter. Contact your administrator." by running the following cmdlet:
Set-ContentFilterConfig -RejectionResponse "Your message was rejected by our spam
filter. Contact your administrator."
8.
In the Exchange Management Shell, configure the SCL junk threshold with the value 6 for all
mailboxes in your organization by running the following cmdlet:
Set-OrganizationConfig -SCLJunkThreshold 6
Task 3: Configure sender and recipient filtering on LON-MBX1

1.
On LON-MBX1, in the Exchange Management Shell, configure sender filtering to block messages
from marketing@contoso.com by running the following cmdlet:
2.
In the Exchange Management Shell, configure recipient filtering to block messages sent to
helpdesk@adatum.com by running the following cmdlet:
Set-RecipientFilterConfig -BlockListEnabled $true -BlockedRecipients
helpdesk@adatum.com
Note: In this scenario, we assume that the email address helpdesk@adatum.com is for
internal purposes only, and should not receive email from external senders.
Exercise 3: Validating Antimalware and Anti-Spam Configuration

Scenario
9-31
In this exercise, you will validate antimalware and anti-spam configuration by sending a test email that
contains simulated test malware. Then you will connect to LON-MBX1 by using the telnet command, and
you will send email messages that should be blocked by the anti-spam agents.
1.
Validate antimalware configuration.
2.
Validate anti-spam configuration.
3.
Task 1: Validate antimalware configuration

1.
Switch to LON-CAS1.
2.
Edit the E:\Labfiles\Mod09\Eicar.txt file and remove the line breaks between the first line and the
subsequent text line. All of the text should be on one line. Save the file.
3.
Close any instances of Internet Explorer.
4.
Open Windows Internet Explorer and type https://lon-cas1.adatum.com/owa.
5.
Sign in as Adatum\Michael with the password of Pa$$w0rd, and save the default settings on the
Language and time zone page.
6.
In the Outlook Web App window, create a new email to mark@adatum.com with the subject Test
Message, message body text Daily report, and then attach the file named EICAR.TXT located in
E:\Labfiles\Mod09.
7.
In the Outlook Web App window, click on Michael Allen, and then click Sign out.
8.
In Internet Explorer, on the Outlook Web App logon page, sign in as Adatum\Mark with the
password Pa$$w0rd. Click Save.
9.
In the Outlook Web App window, double-click the new message from Michael Allen. Open the
attachment and verify that the code that was in the file has been deleted and replaced by the custom
text you configured.
10. In the Outlook Web App window, click on Mark Bebbington, and then click Sign out.
Task 2: Validate anti-spam configuration

1.
Switch to LON-DC1.
2.
On LON-DC1, open Windows PowerShell from the task bar.
3.
At the command prompt, type telnet LON-CAS1 smtp, and then press Enter.
4.
Type helo, and press Enter.
5.
Type mail from: info@internet.com, and press Enter.

You should receive the response: 250 2.1.0 Sender OK
6.
Type rcpt to: michael@adatum.com, and press Enter.

Response: 250 2.1.5 Recipient OK.
7.
Type data, and press Enter.

Response: 354 Start mail input; end with <CRLF>.<CRLF>
8.
Type Subject: Information for you and then press Enter twice. Type Please find below poker
results, and press Enter.
9.
Press the period (.) key, and then press Enter.
10. Verify that following message is displayed: Your message was rejected by our spam filter. Contact
your administrator.
11. Type Quit, and press Enter.
When you finish the lab, revert the virtual machines to their initial state by performing the following steps:
1.
2.
3.
4.
Repeat steps 2 and 3 for 20341B-LON-CAS1, and 20341B-LON-MBX1.
5.
6.
7.
8.
a.
b.
Password: Pa$$w0rd
Results: After completing this exercise you should have validated antimalware scanning when sending
test message with malware simulation attachment, where the attachment will be deleted by the Exchange
Server 2013 antimalware feature. You should have also validated anti-spam content filtering when
sending a simulation of a spam message, where the message will be stored in the recipients junk email
folder by the Exchange Server 2013 content filtering feature.
Question: What anti-spam agents are available in Exchange Server 2013?
Question: What is the purpose of the SCL threshold?

Review Question
Question: What strategy for anti-spam and antimalware protection are you going to suggest for
your organization?
9-33
Your employees often complain about email being blocked as a spam or malware, when the email
was neither spam nor malware. Such false-positive email is one of the biggest issues in anti-spam and
antimalware protection. False positive means that an email has been blocked due to anti-spam or
antimalware scanning, but the email actually is not a spam and does not contain malware.
To address the issue, contact security administrators to investigate the reasons why those emails have
been identified as a spam or malware. Re-evaluate your anti-spam and antimalware protection settings,
and edit the settings if neccecery.
Best Practice
When configuring an anti-spam and antivirus solution, always follow the vendors technical
documentation on how to deploy, manage, and maintain those solutions. Internet threats are changing
every day, so Exchange administrators and security administrators must be regularly educated on and
aware of the latest security threats. As security threats change, an organizations anti-spam and antivirus
solutions and management best practices might also change.

Common Issue
Troubleshooting Tip
You have configured anti-spam content

filtering, but employees complain that
they still receive spam email.
You have configured anti-spam content

filtering, but employees complain that
they do not receive email from business
partners.
One employee complained that when he

received an email, the attachment was
missing, and was replaced with another
attachment with a warning about
malware.
Tools
Exchange Administration Center (EAC) Used for configuring antimalware policy
Exchange Management Shell Used for configuring antimalware policy, antimalware settings, and
anti-spam settings

10-1
Module 10
Planning and Configuring Administrative Security
and Auditing
Contents:
Module Overview
10-1
Lesson 1: Configuring Role-Based Access Control
10-2
Lesson 2: Configuring Audit Logging
10-13
10-17
10-23
Module Overview
In many organizations, Microsoft Exchange Server provides a critical business function for both internal
and external users. In addition, many organizations expose at least a few of their Exchange servers to the
Internet. For these reasons, it is important that you take appropriate actions 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 Microsoft Exchange Server 2013.
Objectives
Configure role-based access control (RBAC) permissions.
Configure audit logging.
Lesson 1
Configuring Role-Based Access Control
10-2 Planning and Configuring Administrative Security and Auditing
Exchange Server 2013 uses the role-based access control (RBAC) permissions model to restrict the
administrative tasks that users can perform on the Mailbox, Edge Transport, 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 2013, and how
to configure permissions on Edge Transport servers.
Lesson Objectives
Describe RBAC.
Describe management role groups.
Identify Exchange Server 2013 built-in management role groups.
Manage RBAC permissions.
Configure custom management role groups.
Describe 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 permissions model available since
the Microsoft Exchange Server 2010 release. With
RBAC, you do not have to modify and manage
access control lists (ACLs) on Exchange Server or
Active Directory Domain Services (AD DS) objects.
In Exchange Server 2013, 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 Shell, and the Exchange
Administration Center (EAC), use RBAC to determine user permissions. Therefore, permissions are
consistent regardless of which tool you use.
Note: If RBAC allows a user to run a specific cmdlet, that cmdlet actually runs in the
security context of the Exchange Trusted Subsystem, and not in the context of the user. The
Exchange Trusted Subsystem is a highly privileged universal security group that has read/write
access to every Exchange Server-related object in the Exchange organization. It also is a member
of the Administrators local security group and the Exchange Windows Permissions universal
security group, which enables Exchange Server 2013 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 an end user:
Management role groups. RBAC uses management role groups to assign permissions to
administrators. These administrators may require permissions to manage the Exchange organization
or some part of it. Some administrators may require limited permissions to manage certain 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 enduser management roles. Role-assignment policies consist of roles that control what users can do with
their mailboxes or distribution groups. These roles do not allow management of features with which
users are not associated directly.
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, we recommend that you avoid using direct role assignment, as it is significantly more
complicated to configure and manage than using management role groups.
What Are Management Role Groups?

A management role group is a universal
security group that simplifies the process of
assigning management roles to a group of users.
All members of a role group are assigned the
same set of roles. In Exchange Server 2013, groups
such as organization management and recipient
management are assigned administrator and
specialist roles that define major administrative
tasks. Role groups enable you to more easily
assign a broader set of permissions to a group of
administrators or specialist users.
Management role groups are used 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.
These include:
Role holder. A role holder is a user or security group that can be added 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 of the roles assigned to a role group defines everything that users added to a
role group can manage in the Exchange 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 grant rights
to manage or view the objects associated with that cmdlet.
Management role assignment. A management role assignment assigns a management role to a

role group. Once you create a management role, you must assign it to a role group so that the role
holders can use it. Assigning a management role to a role group grants the role holders the ability to
use the cmdlets that the management role defines.
Management role scope. A management role scope is the scope of influence or impact that the role
holder has once RBAC assigns a management role. When you assign a management role, you can use
management scopes to target which objects that role controls. Scopes can include servers,
organizational units, and recipient objects, among others.
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 holder
Management role
group
Management role
Management role
entries
Management role
scope
Stan
Organization
Management
Organization
Management
All Exchange
cmdlets
Organization
Joel
Help Desk
HelpDesk
Cmdlets related to
mailbox and user
account
management
Organization
Andy
Sales Admins
SalesAdminRole
Cmdlets related to
Recipient
management only
Sales department
organization unit
(OU) in AD DS or
Active Directory
Built-In Management Role Groups

Exchange Server 2013 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
Management
Role holders have access to the entire Exchange Server 2013 organization
and can perform almost any task against any Exchange Server object.
View-Only Organization
Management
Role holders can view the properties of any object in the organization.
Recipient Management
Role holders have access to create or modify Exchange Server 2013

recipients within the Exchange organization.
UM Management
Role holders can manage the Unified Messaging (UM) features within the
organization, such as UM 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, and transport rules. Role holders also can
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.
Public Folder
Management
Role holders can manage public folders and databases on Exchange

servers.
Delegated Setup
Role holders can deploy previously provisioned Exchange servers.
Compliance
Management
Role holders can configure and manage compliance settings. This role
group is new in Exchange Server 2013.
Hygiene Management
Role holders can manage Exchange Server anti-spam features and grant
permissions for antivirus products to integrate with Exchange Server. This
role group is new in Exchange Server 2013.
Note: All of these role groups are located in the Microsoft Exchange Server Security Groups
organization unit (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 2013 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 LON-DC1, open Active Directory Users and Computers, and add Tony to the Recipient
Management group located in the Adatum.com\Microsoft Exchange Security Groups OU.
2.
On LON-CAS1, open the EAC, sign in as Adatum\Tony and verify that you can see the Exchange
Servers, but not modify them. Also verify that you can modify the user properties of Adam Barr.
3.
Start the Exchange Management Shell, and run the following cmdlets:
Get-ExchangeServer | FL
Set-User Adam -Title Manager
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 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 2013
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 EAC. When you create the
group, you must specify the management roles. In addition, 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 2013 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 EAC.
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 can 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 EAC or
the New-RoleGroup cmdlet to create the link among 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
The cmdlet does the following:
o
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 see how to create a custom role group, add roles and members to the role
group, and verify that the permissions you granted are working as expected.
Demonstration Steps
1.
On LON-CAS1, in the EAC, create a new role group named MarketingAdmins. This group should be
located in the Marketing OU and be assigned the Mail Recipients and Mail Recipient Creation roles.
Brad Sutton should initially be a member.
2.
Switch to LON-MBX1, verify in Active Directory Users and Computers that the new group has been
created.
3.
Verify in the EAC that the permissions are correctly working.
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 the changes that users can make to
their own mailbox settings and to distribution
groups that they own. Every user with an
Exchange Server 2013 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 2013, you can use the EAC to view and modify the default management role
assignment policy and configure additional management role assignment policies with different
permissions. For example, you can modify the default role assignment policy so the users cannot change
their own properties, such as their addresses or telephone numbers. 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 2013. 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 of 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.
What Are Exchange Server Split Permissions?

AD DS and Exchange Server 2013 are
highly integrated, and there is no option for
changing this. In many small or medium sizedorganizations, the same administrators are
responsible for managing both the Exchange
Server 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 its 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 Server administrators to
create security principals, such as user or security group objects, in AD DS by using the Exchange Server
management tools. This applies to both user account and security groups. The end result of implementing
split permissions is that security principals must 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 2013 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 2013

The following are the Exchange Server 2013 options for implementing split permissions:
RBAC split permissions. When you implement RBAC split permissions, you remove the Exchange
administrators ability 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 the Exchange
Management Shell cmdlets run in the security context of the Exchange servers, this prevents anyone
from using the Exchange Server 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 2013, 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 2013 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
In addition, the associated features in the Exchange Server Management Console and the EAC (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 Server 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 Server
attributes using the Exchange Server management tools.
In addition, configuring RBAC split permissions 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 Server
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 it is one that enables you to configure a special
group of Exchange Server administrators that will still be able to use the Exchange Server
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 it 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. This 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 administrator
who is a member of the new group will 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 must assign
the Mail Recipients role to the new role group.
Configuring Active Directory Split Permissions

Active Directory split permissions differ from
RBAC split permissions. When you implement
Active Directory split permissions, the Exchange
servers no longer have permission to create AD DS
security principals, because the permissions that
are normally granted to the Exchange Windows
Permissions group are removed. Since the
Exchange Trusted Subsystem group that contains
all of the Exchange Server 2010 and Exchange
Server 2013 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 Server
attributes of existing security principals in AD DS.
You can enable Active Directory split permissions when you run the Exchange Server 2013 setup
program during the initial deployment of Exchange Server 2013. 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 2013, or you can run this command after installing Exchange
Server to change an existing deployment to use Active Directory split permissions.
You enable or disable Active Directory split permissions by using the Exchange Server 2013 setup
program. If you enable Active Directory split permissions, Exchange Server 2013 Setup makes the
following changes to the AD DS and Exchange Server 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 non-delegating management role assignments to management roles with the
following management role type:
MailRecipientCreation
SecurityGroupCreationandMembership
It does not add access control entries 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 Server configuration objects. In addition, it can be difficult
to provide information about users who access other mailboxes or perform other types of data access.
Exchange Server 2013 contains logging functionality that can provide you with information about
administrative tasks performed on your Exchange servers.
Lesson Objectives
Describe administrator audit logging.
Describe mailbox audit logging.
Configure audit logging.
What Is Administrator Audit Logging?

In Exchange Server 2013, 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 2013 administrator audit logs
track all Exchange Management Shell cmdlets
that make changes to the Exchange Server
environment. Because all tasks performed in the
EAC are translated to Exchange Management
Shell cmdlets, all changes are logged, regardless
of which tool you use to perform the task.
Audit logging is intended to show which actions were taken to modify objects in an Exchange
organization, rather than which 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, logging is enabled in
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.
If you want to see how administrator audit logging is configured currently, run the
Get-AdminAuditLogConfig cmdlet.
Each time a cmdlet is logged, Exchange Server creates an audit log entry. Exchange Server 2013 stores
audit logs in a hidden, dedicated arbitration mailbox that you can only access by using the EAC 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, and you cannot modify this dedicated mailbox.
In the EAC, you can view or export 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/2013 and 3/16/2013, and
send the search results to Andreas@adatum.com. To accomplish this, you would run the following cmdlet:
New-AdminAuditLogSearch -Cmdlets Set-Mailbox -StartDate 02/16/2013 -EndDate 03/16/2013
-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 also can use the 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
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 the 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.
Planning for Mailbox Audit Logging
Unlike administrator audit logging, mailbox audit logging is not enabled by default, so you must 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. We recommend 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 Anil Elsons mailbox:
Set-Mailbox -Identity " Anil Elson" -AuditEnabled $true
To disable mailbox auditing, change the $true parameter to $false.
To search the mailbox audit log, you can use both the EAC and the Exchange Management Shell. The EAC
allows you to generate reports for non-owner 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 2013, limiting results
to 2,000:
Search-MailboxAuditLog -Identity Anil -LogonTypes Admin,Delegate -StartDate 1/1/2013
-EndDate 12/31/2013 -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/2013 -EndDate 12/31/2013
-StatusMailRecipients "auditors@adatum.com"
This cmdlet locates access attempts by administrators and delegates during 2013. Results are sent to the
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 EAC and the Exchange Management Shell.
Demonstration Steps
1.
On LON-CAS1, in Exchange Management Shell, review how the Audit Log is currently configured.
2.
In the EAC, add Send As permissions on Anil Elsons mailbox for Allie Bellew.
3.
In Exchange Management Shell, verify that you see the permission change in the admin log.
4.
Enable audit logging on Anils mailbox.
5.
Send a message from Allies mailbox as Anil.
6.
In the EAC, run a Run a non-owner mailbox access report to verify that the message was logged
correctly.

Scenario
A. Datum Corporation has deployed Exchange Server 2013. The company security officer has provided
you a set of requirements to ensure that the Exchange Server 2013 deployment is as secure as possible.
The requirements specific concerns 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.
AD DS object creation should be done by only the HRAdmins group. Nobody else should create AD
DS objects such as user accounts in Exchange.
Objectives
The students will be able to configure Exchange Server 2013 RBAC permissions and audit logging for both
administrators and users.
Lab Setup
Virtual machines
20341B-LON-DC1
20341B-LON-CAS1
20341B-LON-MBX1
User Name
Password
Pa$$w0rd
1.
2.
3.
4.
5.
Password: Pa$$w0rd
Exercise 1: Configuring Exchange Server Permissions

Scenario
A. Datum Corporation has completed the Exchange Server 2013 deployment, and is working on
integrating Exchange Server and recipient management with its current management practices. To meet
the management requirements, you need to ensure that:
Members of the IT administrators group can administer individual Exchange Server 2013 servers, but
cannot modify any of the Exchange organization settings. Tony Smith is a member of the IT group.
Members of the HelpDeskAdmins 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 also should be able to create new mailboxes.

1.
Configure Exchange server permissions for the IT administrators group.
2.
Configure permissions for the Support Desk and HelpDeskAdmins groups.
3.
Verify the permissions for the three role groups created.
Task 1: Configure Exchange server permissions for the IT administrators group

1.
On LON-MBX1, open Server Manager, and then open Active Directory Users and Computers.
2.
Add the IT group as member to Server Management group located in Adatum.com\Microsoft

Exchange Security Groups OU.
Task 2: Configure permissions for the Support Desk and HelpDeskAdmins groups
1.
On LON-MBX1, from the Start screen, open Exchange Management Shell.
2.
In the Exchange Management Shell, run the following cmdlets:
New-RoleGroup -Name HelpDeskAdmins -roles Mail Recipients

New-RoleGroup -Name SupportDesk -roles Mail Recipients, Mail Recipient Creation,
Distribution Groups
3.
Open Internet Explorer, connect to https://LON-CAS1.adatum.com/ecp. Sign in as

Adatum\Administrator using the password Pa$$w0rd.
4.
In the EAC, in permissions, add Ryan Spanton to SupportDesk role group and add Carol Troup to
HelpDeskAdmins role group.
5.
Close Internet Explorer.
Task 3: Verify the permissions for the three role groups created
1.
On LON-MBX1, open Windows Internet Explorer, and connect to

https://LON-CAS1.adatum.com/ecp. Sign in as Adatum\Tony using the password Pa$$w0rd.
2.
Modify the Research database:

o
3.
Issue a warning at (GB): unlimited
Verify that you can see the UM dial plans, but not create or modify them. Remember that Tony is part
of the IT group, and therefore is able to modify server properties but not unified messaging settings.
4.
Close Internet Explorer, open Internet Explorer, and connect to https://LON-CAS1.adatum.com

/ecp. Sign in as Adatum\Ryan using the password Pa$$w0rd. Recognize that in the feature pane,
there are no servers. This is because Ryan does not have permissions to manage servers.
5.
In recipients feature, in mailboxes, modify Alan Steiner:

o
6.
In recipient feature, in groups, try to modify Research:

o
7.
Department: IT
Group description: test
In recipients feature, in mailboxes, create a new mailbox:

o
Alias: Test
First name: Test
Last name: Test
User logon: Test
New password: Pa$$word
Confirm password: Pa$$word
8.
Close Internet Explorer, open Internet Explorer, and connect to https://LON-CAS1.adatum.com

/ecp. Sign in as Adatum\Carol using the password Pa$$w0rd.
9.
In the feature pane, access recipients. Note that there is no New user button on the toolbar.
10. In recipients feature, in mailboxes, modify Alan Steiner:

o
Department: Customer Service
11. Verify that groups is not available in tabs as Carol does not have permission to manage groups.
12. Close Internet Explorer.
Results: After completing this exercise, the students will have configured RBAC roles and verified that the
permissions are granted accordingly.
Exercise 2: Configuring Audit Logging

Scenario
You now need to configure audit logging on the Info@Adatum.com shared mailbox. This mailbox is used
by the IT group to send out information to everyone in the organization.
1.
Configure audit logging on the Info@Adatum.com mailbox.
2.
Perform SendAs activity on the Info@Adatum.com mailbox.
3.
Verify that the activity is logged.
Task 1: Configure audit logging on the Info@Adatum.com mailbox

1.
On LON-MBX1, open Exchange Management Shell.
2.
In the Exchange Management Shell, run the following cmdlet:

Set-Mailbox -Identity "Info" -AuditDelegate SendAs,SendOnBehalf -AuditEnabled $true
Task 2: Perform SendAs activity on the Info@Adatum.com mailbox
1.
On LON-CAS1, open Internet Explorer, and connect to https://LON-CAS1.adatum.com/owa. Sign

in as Adatum\Tony using the password Pa$$w0rd.
2.
Create and send a new mail message:

o
From: Info@adatum.com
To: Tony Smith
Subject: Testing Send As logging
3.
Verify that the message is sent.
4.
Close Internet Explorer
Task 3: Verify that the activity is logged

1.
On LON-MBX1, open Internet Explorer, and connect to https://LON-CAS1.adatum.com/ecp. Log

in as Adatum\Administrator using the password Pa$$w0rd.
2.
In compliance management, in auditing, run a non-owner mailbox access report:

o
3.
Search for access by: All non-owners
In the search results, view the report that shows that Tony Smith accessed the Info mailbox.
Results: After completing this exercise, the students will have configured mailbox audit logging and
verified that audit logging works correctly.
Exercise 3: Configuring RBAC Split Permissions on Exchange Server 2013

Scenario
You want to separate those who can create security principals in the AD DS domain partition from those
who administer the Exchange organization data in the AD DS configuration partition. Only the HRAdmins
group should be allowed to create objects in AD DS domain partition. You decide to implement the RBAC
split permissions model on your organization.
1.
Create a new role group called HRAdmins, and assign permissions.
2.
Remove the permission to create AD DS objects from other Exchange Server administrator groups.
3.
Validate RBAC split-permissions functionality.
4.
Task 1: Create a new role group called HRAdmins, and assign permissions
1.
2.
New-RoleGroup "HRAdmins" -Roles "Mail Recipient Creation", "Security Group Creation

and Membership"
New-ManagementRoleAssignment -Role "Mail Recipient Creation" -SecurityGroup
"HRAdmins" -Delegating
New-ManagementRoleAssignment -Role "Security Group Creation and Membership"
-SecurityGroup "HRAdmins" Delegating
Add-RoleGroupMember "HRAdmins" -Member Tony
3.
4.
From Server Manager, open Active Directory Users and Computers and modify HRAdmins group
located in Microsoft Exchange Security Groups:
o
Managed By: HRAdmins
Manager can update membership list: enabled
Add HRAdmins to the Recipient Management group. This is required to assign the HRAdmins
group the necessary permissions to be able to create a mailbox.
Task 2: Remove the permission to create AD DS objects from other Exchange Server
administrator groups
1.
2.

Get-ManagementRoleAssignment -Role
Role, RoleAssigneeName Auto
$_.RoleAssigneeName -NE "HRAdmins"
$_.RoleAssigneeName -NE "HRAdmins"
3.
"Mail Recipient Creation" | Format-Table Name,
"Mail Recipient Creation" | Where {

} | Remove-ManagementRoleAssignment
"Security Group Creation and Membership" | Where {
} | Remove-ManagementRoleAssignment
Close the Exchange Management Shell.
Task 3: Validate RBAC split-permissions functionality

1.
On LON-MBX1, open Internet Explorer, and connect to https://LON-CAS1.adatum.com/ecp. Sign

in as Adatum\Administrator using the password Pa$$w0rd.
2.
In the recipients feature, in mailboxes, create a new mailbox. When you click on New user that all
fields required to create a new user are greyed out. This is because you do not have the permission to
create a new user account in AD DS.
3.
Close Internet Explorer and open Internet Explorer, connect to https://LON-CAS1.adatum.com

/ecp. Sign in as Adatum\Tony using the password Pa$$w0rd.
4.
In recipients feature, in mailboxes, create a mailbox with a new user:

o
Alias: Test2
First name: Test2
Last name: Test2
User logon: Test2
New password: Pa$$word
Confirm password: Pa$$word
This confirms that Tony is able to create user accounts for new mailboxes.
5.

following steps:
1.
2.
3.
4.
5.
6.
7.
8.
Password: Pa$$w0rd
Results: After completing this exercise, students will have created a new role group, configured RBAC split
permissions, and validated that RBAC split permissions are working as expected.
Question: You have a shared mailbox that requires logging any activity in which other users
send on behalf of this mailbox. What do you need to do?
Question: Your compliance office requires permission to configure and manage compliance
settings in your Exchange organization. You want to make sure that the compliance officer
has the least amount of permissions necessary for doing his or her job. What built-in
management role group would you use?

Best Practice
When you configure permissions in the Exchange organization, make sure that the 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 organization.
Creating custom role groups with customized permissions is more complicated, and it may lead to
users having too many, or too few, permissions.
Enable administrative audit logging on shared mailboxes.
Do not enable RBAC or Active Directory split permissions if you do not have a usage scenario to
support these permissions models.
Ensure that you document all permissions that you assign in the Exchange organization. If users
are unable to perform required tasks, or if users are performing tasks to which they should not
have access, you should be able to identify the reason by referring to your documentation.

Common Issue
Troubleshooting Tip
Your Exchange mailbox administrators are

not able to create user accounts when
creating a mailbox.
An administrator is able to log on to the

Exchange server and start Exchange
Management Shell, but cannot run the
cmdlets to manage recipient objects.
Review Questions
Question: In which scenario should you implement AD split permissions in your Exchange
Server 2013 organization?
Question: You need to enable members of the Human Resources department to configure
user mailboxes for the entire organization. What should you do?
Question: How can you identify whether someone was accessing another users mailbox?

11-1
Module 11
Monitoring and Troubleshooting Microsoft Exchange
Server 2013
Contents:
Module Overview
11-1
Lesson 1: Monitoring Exchange Server 2013
11-2
Lesson 2: Maintaining Exchange Server 2013
11-15
Lesson 3: Troubleshooting Exchange Server 2013
11-21
Lab: Monitoring and Troubleshooting Exchange Server 2013
11-29
11-35
Course Evaluation
11-38
Module Overview
Monitoring and troubleshooting processes for Microsoft Exchange Server 2013 are very important
because they allow administrators to provide performance optimized messaging infrastructures.
Monitoring processes can improve your ability to identify, troubleshoot, and repair issues before end
users experience them.
By designing a comprehensive monitoring solution for your Exchange Server 2013 organization, you can
reduce end-user problems and prevent potentially serious issues.
After you deploy Exchange Server 2013, you must make sure that it continues to run efficiently by
maintaining a stable environment. This module describes how to monitor, maintain, and troubleshoot
your Exchange Server 2013 environment.
Objectives
After completing this module, you will be able to
Monitor Exchange Server 2013.
Maintain Exchange Server 2013.
Troubleshoot Exchange Server 2013.
Lesson 1
Monitoring Exchange Server 2013
11-2 Monitoring and Troubleshooting Microsoft Exchange Server 2013
Exchange administrators must know how Exchange works so that they can implement monitoring tools by
using the appropriate metrics, to ensure a healthy Exchange environment. You must develop a monitoring
solution to improve the ability to identify, troubleshoot, and repair issues before they affect end users.
To reduce and prevent end-user problems, you must engage in additional consideration and planning to
design a monitoring solution for your Exchange Server 2013 organization. In this lesson, you will review
the basic monitoring tools and the metrics that you use to monitor Exchange Server 2013.
Lesson Objectives
Explain why the Performance Monitor is important.
Describe performance baseline.
Establish a performance baseline.
Describe the Exchange Server 2013 monitoring tools.
Collect the key performance data for Exchange Server 2013.
Collect the performance counters that you should monitor on the Mailbox server role.
Collect the performance counters that you should monitor on the transport components.
Collect the performance counters that you should monitor on the Client Access server role.
Use the collected performance data.
Why Is Performance Monitoring Important?

Every organization should have well-defined
monitoring procedures in place for its Exchange
Server environment. Monitoring provides up-todate information about key Exchange Server
health and performance parameters. Furthermore,
monitoring procedures should be reevaluated on
a regular basis to accommodate the changes in
organizations IT infrastructure.
To monitor Exchange Server performance most
efficiently, you must:
Identify performance issues. When problems

arise, you can identify and repair them
without relying on users to report the problems.
Identify growth trends to improve plans for upgrades. As the system grows and usage patterns
change, hardware modifications may be required to accommodate these changes. You must identify
trends to allow you to forecast future changes that might be necessary.
Measure performance against service level agreements (SLAs). You need to demonstrate whether
Exchange Server meets performance-based service SLAs, and measuring the end-user experience
shows the value that Exchange Server administrators provide.
Identify security issues and denial-of-service attacks. When performance and other metrics do not
meet the established baselines, you can correlate these incidents to identify and mitigate the source.
To effectively monitor performance, you must gather and monitor metrics from the processor, memory,
disk, and Exchange services. You can monitor additional information, depending on the Exchange Server
roles that you install.
What Is a Performance Baseline?

Monitoring Exchange Server performance
produces data output that Exchange
administrators should review. Administrators
should review this data to determine whether
system behavior and performance addresses
business requirements. Monitoring data helps
Exchange administrators to identify growth
patterns, performance issues, application or
service impact, and the impact of organizational
or user changes. Monitoring data also helps
administrators to decide whether an Exchange
Server upgrade or server replacement is needed.
During the monitoring process, administrators need to compare current performance data with their
servers average usage. You may want to monitor server usage every day over a one-month period to
determine the average server usage. This average usage is called the performance baseline. Based on the
comparison between the current performance data and the performance baseline, you can choose to
perform one of the following:
If server performance is similar to the performance baseline, administrators can conclude that this is
the expected server performance. Administrators do not need to troubleshoot if the performance
baseline is predictable; instead, they should continue to monitor the servers.
If server performance deviates substantially from the performance baseline, administrators must take
immediate action to find the reasons for that deviation and start performance troubleshooting.
Without having a performance baseline, administrators cannot perform a relevant analysis of the
performance data, and therefore cannot decide correctly on what action to take. Administrators should
create a performance baseline for each server. Developing a performance baseline for each server is
important because servers are configured differently. Each server can vary depending on several factors,
including whether it is a physical or virtual machine and the varying amounts of memory and processor
types.
Even identical servers can have different performance baselines; for example, they might host different
server roles, such as Client Access server and Mailbox server. In fact, even when two identical servers have
the same server roles, such as Mailbox server roles, they still may have different performance baselines.
This can happen when the number of user mailboxes that are located on each of the Mailbox servers is
different.
You should evaluate performance baseline regularly. IT infrastructure in organizations is dynamic, and
servers are upgraded or replaced on a regular basis; therefore, performance baselines change as well.
Exchange performance baseline also depends on the number of user mailboxes and software or service
pack updates. Moreover, new software installation and software upgrades, such as antivirus or backup
software, might also change the performance baseline.
Establishing a Performance Baseline

Establishing a performance baseline is an
essential step during Exchange server monitoring.
Organizations that use management and
monitoring software such as Microsoft System
Center Operations Manager 2012 (Operations
Manager) can use it to create a performance
baseline automatically. Operations Manager alerts
administrators of any substantial deviation from
the performance baseline. In addition, Operations
Manager will update the performance baseline
over time dynamically, according to changes in
the Exchange Server infrastructure.
If your organization does not use Operations Manager or other software that automatically creates a
performance baseline, you should create it manually by using following recommendations:
Performance baseline is established during relevant timeframe, such as one month.
If Exchange Server usage during the weekends or after office hours is not the same as during office
hours, then you should not consider performance data obtained during the weekend or after office
hours in your performance baseline.
If backup procedures affect server performance, those procedures should be scheduled after office
hours, and that time schedule should not be calculated in the performance baseline.
Performance baseline should not be measured during the server updates, hardware upgrades, or
maintenance.
Performance baseline should be reevaluated regularly, especially after hardware upgrades, changes in
user mailbox distribution through servers, software updates, or new software installation, such as
antivirus software or backup software.
Tools for Monitoring Exchange Server

Organizations use different types of software
or tools to monitor their Exchange Server
environments. Depending on the size of the
organizations and the complexity of their IT
infrastructure, monitoring software can be
classified in two categories:
Enterprise monitoring solutions, such as

Operations Manager.
Small and medium-sized organization

monitoring solutions, such as Performance
Monitor.
Enterprise Monitoring Solutions
Most enterprise environments already use monitoring and service management solutions across their IT
infrastructures. An example includes Operations Manager with the Exchange Server 2013 management
pack, which provides a monitoring solution for IT infrastructures, including monitoring for Exchange
Server 2013.
Operations Manager performs multiple monitoring tasks, such as:
Monitoring Exchange Server 2013 events.
Collecting Exchange component-specific performance counters in one central location.
Alerting operators if intervention is necessary.
Correlating critical events automatically.
Managing Exchange servers and identifying issues before they become critical.
Operations Manager also allows you to customize the data you need to collect. Therefore, you can make
adjustments to accommodate your particular usage and hardware scenarios.
Monitoring Solutions by Using Performance Monitor
In situations where no enterprise monitoring solution exists, you can use the Performance Monitor in
the Windows Server 2012 operating system to collect performance data and monitor Exchange Server
health. The Performance Monitor analyzes how Exchange Server 2013 affects your computer's
performance, both in real time and by collecting log data for future analysis.
The Performance Monitor uses performance counters, event trace data, and configuration information,
which can be combined into Data Collector Sets. It also provides a system-stability overview and details
about events that impact reliability.
Collecting Performance Data for the Exchange Server

When you monitor Exchange Server 2013 servers,
you should know which performance aspects are
most important for your organization. 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 you troubleshoot.
Because these values are general guidelines,
it is important to trend and perhaps adjust
these values to meet the needs of a specific
environment. You can determine values that work
in a specific environment by documenting normal
operating values to create a baseline. After you create the baseline, set thresholds so that when
performance metrics are not met, you know that the server is not operating optimally.
In addition, when you run Exchange Server 2013 in a virtualized environment, you should consider adding
virtualization counters in your monitoring strategy. Some examples of virtualization counters include:
Hyper-V Virtual Machine Health Summary counters.
Counters related to Hyper-V processor utilization, such as Hyper-V Hypervisor Logical Processor and
Hyper-V Hypervisor Virtual Processor.
Counters related to Memory utilization on both physical and virtual machines.
Counters related to Hyper-V networking utilization, such as Hyper-V Legacy Network Adapter and
Hyper-V Virtual Network Adapter and Hyper-V Virtual Network Switch.
Counters related to Hyper-V storage utilization, such as Hyper-V Virtual Storage Device.
Processor
The processor is a fundamental component that you need to monitor to ensure server health on Exchange
Server 2013 roles. The following table includes the description and expected value for the counters you
can use to monitor the server.
Counter
Description
_Total\% Processor Time
Displays the percentage of time that the processor is executing

application or operating system processes.
_Total\% User Time
Displays the percentage of processor time that is spent in user mode.

This represents the time spent processing applications, environment
subsystems, and integral subsystems.
_Total\% Privileged Time
Displays the percentage of processor time that is spent in privileged

mode. This represents the time spent processing operating system
components and hardware-manipulating drivers.
The Processor Queue Length is an additional counter related to processor performance. If a Processor
Queue 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 the Processor Queue Length counter for capacity planning, you can
use it to determine whether you should purchase faster processors for future servers.
The following table displays the description and expected value of the Processor Queue Length counter in
the System group.
Group
System
Counter
Processor
Queue Length
Description
Displays the number of threads each processor is servicing. You
can use this 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. By tracking how much memory is available
and how much memory has to be written to the page file, you can determine when you need to either
increase server memory or reduce server load.
The following table displays the description and expected values for memory counters.
Counter
Description
Available Mbytes
Displays the amount of physical memory, in megabytes (MB), immediately

available for allocation to a process, or for system use. This value is equal to
the sum of memory assigned to the standby (cached), free, and zero page lists.
Pool Paged Bytes
Displays the portion of shared system memory that you can page to the disk
paging file. The paged pool is created during system initialization, and is used
by kernel-mode components to allocate system memory.
Transition Pages
Repurposed/sec
Indicates system cache pressure.
Page Reads/sec
Displays that data must be read from the disk instead of memory. Indicates
there is not enough memory, and paging is beginning. A value of more than
30 per second means that the server is no longer keeping up with the load.
Counter
Description
Pages/sec
Displays the rate at which pages are read from or written to disk to resolve
hard page faults. 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 with other counts of pages, such as Memory\Page Faults/sec,
without requiring conversion. Pages/sec includes pages retrieved to satisfy
faults in the file system cache (usually requested by applications) and noncached mapped memory files.
Pages Input/sec
Displays the rate at which pages are read from disk to resolve hard-page
faults. Hard-page 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 with the value
of Memory\Page Reads/sec to determine the average number of pages read
into memory during each read operation.
Pages Output/sec
Displays the rate at which pages are written to disk to free space in physical
memory. Pages are written to disk only if they are changed in physical
memory; thus they are likely to hold data, and not code. If a large number of
pages are output, this can indicate a memory shortage. The Windows Server
operating system writes additional pages back to disk to free up space when
physical memory is in short supply. This counter displays the number of pages,
and you can compare it with other page counts without using conversion.
MSExchange ADAccess Domain Controllers
Exchange Server 2013 relies heavily on Active Directory Domain Services (AD DS) for storing and
reading its configuration data. Therefore, it is essential to measure the response time and connection
health to AD DS.
The following table displays descriptions and expected values of Lightweight Directory Access Protocol
(LDAP)-related counters.
Counter
Description
LDAP Read Time
Displays the time in milliseconds (ms) that it takes to send an LDAP read
request to the specified domain controller and receive a response.
LDAP Search Time
Displays the time (in ms) to send an LDAP search request and receive a
response.
Long running LDAP

operations/min
Displays the number of LDAP operations on this domain controller that

took longer than the specified threshold per minute. (Default threshold is
15 seconds.).
LDAP Searches timed

out per minute
Displays the number of LDAP searches that returned LDAP Timeout during
the last minute.
Monitoring Services and Logs
It is also important that you verify that each of the Exchange Server 2013 services are running and
servicing requests. You can monitor services by polling the service status using the Services management
tool, the Get-Services cmdlet, or a third-party monitoring tool. Items logged in the Event logs also may
indicate Exchange Server 2013 server problems. These events typically are classified as Errors or Warnings.
Collecting Performance Data for the Mailbox Server

When you collect performance data associated
with Mailbox servers, you may focus on diskresponse time and the speed with which the
server responds to requests. If the disk queue
length begins to grow, this is another indicator
that the disk system is not meeting demand. All
of these indicators may signify that you to need
to purchase additional or faster disks, or modify
the disk configuration.
There are many Mailbox servers performance

counters that you can monitor depending on your
messaging environment. The following counters
are crucial, and they are a good starting point when you collect 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.
The following table displays descriptions and expected values for Logical Disk counters.
Counter
Description
Avg. Disk sec/Read
Displays the average time for reading data from the disk.
Avg. Disk sec/Write
Displays the average time for writing data to the disk.
Avg. Disk sec/Transfer
Displays the average number of bytes transferred to or from the disk

during write or read operations.
MSExchangeIS Store
The Client Access and Transport services use Microsoft Remote Procedure Call (RPC) to communicate with
Mailbox servers. Thus, it is important to monitor the response time for RPC requests to ensure that the
mailbox server is responding quickly enough to support the load.
The following table displays the descriptions and expected values of RPC-related counters.
Counter
Description
% RPC Requests
Displays the overall RPC requests that are currently executing within
the information store process.
RPC Averaged Latency
Shows the RPC latency (in ms) averaged for all operations in the last
1,024 packets.
RPC Operations/sec
Displays the current number of RPC operations occurring per second.
MSExchangeDatabase ==> Instances
In Exchange Server, database performance is one of the most critical parameters. The following table
displays the counters you can use to monitor database performance.
Counter
Description
Log Threads Waiting
Displays the number of threads waiting for their data to be written to the
log to complete an update of the database. If this number is high for an
extended period of time, the log may be in a bottleneck.
I/O Database Reads

Average Latency
Displays the average length of time, in ms, per database read operation.
I/O Database Writes

Average Latency
Shows the average length of time, in ms, per database write operation.
Database Cache % Hit
Shows the percentage of database file page requests fulfilled by the

database cache without causing a file operation. If this percentage is too
low, the database cache size may be too small.
Question: If any of these performance counters is measured outside its normal range, what
will it most likely affect in the production environment?
Collecting Performance Data for the Transport Components

Transport components are installed on both the
Mailbox server role and Client Access server role.
Therefore, there are different counters for each
role that should be monitored.
Transport Components on the Mailbox

Server Role
The transport component on the mailbox server

role uses a queue database, which is a temporary
holding location for messages that are processed
in a specific order. Therefore, a disk system
must meet the performance requirements for
processing organizations email. If the disk system
does not meet performance requirements, you will need to replace your disk system with faster disks, or
modify the disk configuration. For more information on monitoring Logical Disk on mailbox server, read
the previous topic Collecting Performance Data for the Mailbox Server.
MSExchange Database ==> Instances

Monitoring queue database performance will help you identify issues with reading or storing queue
information in the databases. The following table displays descriptions of transport database counters.
Counter
Description
Log Generation
Checkpoint Depth
Displays the amount of work (in count of log files) that needs to be redone or
undone to the database file(s) if a process crashes.
Version buckets
allocated
Displays the total number of allocated version buckets. Shows the default
backpressure values as listed in the EdgeTransport.exe.config file.
Note: Version buckets are outstanding message queue database transactions
that are kept in memory, but not committed and not written to the message
queue database.
Log Record
Stalls/sec
Displays the number of log records that cannot be added to the log buffers
per-second because they are full. If this counter is nonzero most of the time,
the log buffer size may be a bottleneck.
MSExchangeTransport Queues
Messages that are being queued for submission may indicate a problem with connectivity to the transport
component of the Client Access server. The following table displays the description and expected values
for transport queue length-related counters.
Counter
Description
Messages Queued for

Delivery
Shows the current number of submitted messages that are not yet
processed by transport.
Active Mailbox Delivery

Queue Length
Displays the number of messages in the active mailbox queues.
Retry Mailbox Delivery

Queue Length
Displays the number of messages in a retry state that are attempting

to deliver a message to a remote mailbox.
Unreachable Queue Length
Displays the number of messages in the Unreachable queue.
Poison Queue Length
Displays the number of messages in the poison message queue. The

poison message queue contains messages that are determined to be
harmful to the Exchange 2013 system after a server failure.
Transport Components on the Client Access Server Role
The Transport component on Client Access server role proxies the SMTP protocol to the Mailbox server
role where the user mailbox database is located. Therefore, it is important that you measure the success of
the message-routing process. In addition, it is important that you measure performance counters such as
number of sent and received messages, and SMTP service availability.
The following table displays the description transport component counters on Client Access server.
Group
MSExchangeFrontEndTransportSmtpAvailability
Counter
Description
MessagesFailedToRoute
Displays the number

of messages that
failed to route.
MessagesSuccessfullyRouted
Displays the number

of messages that
were successfully
routed.
MSExchangeFrontEndTransportSmtpReceive
InboundMessagesReceived/sec
Displays the number

of messages
received per second.
MSExchangeFrontEndTransportSmtpSend
MessagesSent/sec
Displays the number

of messages sent
per second.
Question: If one of these performance counters is measured outside its normal range, what
will it most likely affect in the production environment?
Collecting Performance Data for the Client Access Components

Assessing the Client Access components entails
monitoring a variety of objects and counters.
Your users client experience is affected by the
response time of services used by the Client
Access components.
Just like the transport components, the Client
Access components are installed on both the
Mailbox server role and the Client Access server
role. Therefore, you should monitor different
counters for each server role.
Performance Counters for Client Access Components on the Mailbox Server Role
ASP.NET 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.
Group
ASP.NET
ASP.NET
Applications
Counter
Description
Application Restarts
Shows the number of times the application has been

restarted during the Web servers lifetime.
Worker Process Restarts
Shows the number of times a worker process has

restarted on the computer.
Requests Current
Shows the current number of requests (including those

that are queued) currently executing, or waiting to be
written to the client. Under the ASP.NET process model,
when this counter exceeds the requestQueueLimit
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 Time
Shows how long (in ms) the most recent request was
waiting in the queue.
Requests in Application
Queue
Shows the number of requests in the application request

queue. The maximum value is 5,000. The server return a
503 error if the counter exceeds this value.
MSExchange Web Services
Response times for web services, such as Outlook Web App, the Outlook Anywhere (RPC/HTTP) proxy,
Microsoft Exchange ActiveSync, Offline Address Book downloads, and the Availability Service are
valuable metrics to monitor. If an Exchange administrator discovers that the value of these performance
counters are different from performance baseline, a client might experience a slow server response.
Group
MSExchange OWA
Counter
Description
Average Response Time
Shows the average time (in ms) that elapsed for the
request. Used to determine the latency that a client
is experiencing.
Average Search Time
Shows the average time (in ms) that elapsed while

waiting for a search to complete.
RPC/HTTP Proxy
Number of failed
back-end connection
attempts per second
Shows the rate at which the RPC proxy attempts fail

to establish a connection to a back-end server.
MSExchange
ActiveSync
Average Request Time
Shows the average time that elapsed while waiting

for a request to complete. Determines the rate at
which the Availability Service requests are occurring.
MSExchange
Availability Service
Average Time to Process

a Free Busy Request
Shows the number of requests serviced per second.
Performance Counters for Client Access Components on the Client Access Server Role
In Exchange Server 2013, Client Access components on the Client Access server perform authentication
and proxy of HTTP traffic to client access components on the Mailbox server role. The following table
describes some of the recommended performance counters relevant to components of the Client Access
server role:
Group
Counter
Description
MSExchange HTTP
Proxy
Proxy Requests/Sec
Shows the number of proxy requests

serviced per second.
RPC/HTTP Proxy
Number of failed back-end

connection attempts per second
Shows the rate at which the RPC proxy

attempts fail to establish a connection to a
back-end server.
MSExchange
Authentication
Total Authentication requests
Shows the number of authentication

requests serviced per second.
Question: If any of these Client Access server performance counters is measured outside its
normal range, what will it most likely affect in the production environment?
Using the Collected Performance Data

To determine which thresholds indicate an
existing problem, set a monitoring baseline by
reviewing performance 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:
o
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:

o
Adjust thresholds.
Adjust server configurations.
It is important that you review your thresholds periodically so that you can adjust the serversor the
thresholds themselvesto ensure that the system is functioning properly.
Note: Operations Manager employs a self-tuning threshold technology. This feature

automatically adjusts thresholds for an objects counters based on learned values. These
thresholds are automatically adjusted according to the current system usage and comparison
with the baseline that was learned during the previous monitoring.
Lesson 2
Maintaining Exchange Server 2013
Maintaining the Exchange Server messaging solution is an ongoing process that requires established
procedures that will not affect server availability and user experience. Administrators also should follow
best practices and recommendations from Microsoft related to maintenance procedures. Using changemanagement techniques to control change delivers many benefits, which are described in this lesson.
Change management often includes controlling which software updates are applied, and how 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 the techniques you can use to
perform upgrades to your Exchange Server computers.
Exchange Server 2013 introduces two new concepts for managing health and performance: Workload
Management and Managed Availability.
Lesson Objectives
Describe Exchange workload management.
Configure Exchange workload management.
Describe managed availability.
Describe change management.
Plan deployment of Exchange software updates.
Plan Exchange hardware updates.
What Is Exchange Workload Management?

Exchange Server 2013 introduces a new concept
in monitoring and management called Workload
Management. Workload is defined as a feature,
protocol, or service, such as Outlook Web App,
Exchange ActiveSync, or mailbox migration.
Workloads such as Outlook Web App are
monitored and managed instead of the services
that Outlook Web App uses or depends upon,
such as Internet Information Services (IIS) and
Active Directory.
You can manage workloads in Exchange Server
2013 in the following ways:
Monitoring system resources. This type of monitoring was introduced in Microsoft Exchange Server
2010, and was called throttling. To monitor the Exchange workload, resources used by it are
monitored, such as CPU usage, memory consumption, and network utilization, among others. If server
resources are highly utilized, Exchange Server progressively slows down the lowest priority workloads.
Priorities are defined by the classification assigned to workload: Urgent, Customer Expectation,
Internal Maintenance, and Discretionary, where the Urgent classification has the highest priority and
Discretionary classification has the lowest priority. System resource thresholds, where utilization is
measured, have three levels: Underloaded, Overloaded, and Critical.
Controlling how individual users consume resources. This method of managing workloads introduces
different types of workload usage by users, including:
o
Burst allowances. Exchange Server allows users to have greater resource consumption for short
periods of time without throttling.
Recharge rate. Exchange server uses a resource budget system, where administrators set a rate
where users budgets are recharged in defined periods of time. For example, a value of 300,000
milliseconds means that users budgets are recharged on five minutes of usage per hour.
Traffic shaping. Exchange Server delays the user whenever a user reaches the configured limit
for the defined time interval. This type of workload usage prevents users from overloading the
performance of the server. Usually, users business tasks are not affected because the delays are
short and almost undetectable.
Maximum usage. Exchange Server temporarily blocks users from performing their tasks, because
they have reached their threshold in resource usage. Users are unblocked the moment their
budget is recharged.
Configuring Exchange Workload Management

Exchange workload management is configured
in the Exchange Management Shell by creating
or changing the workload management policy
settings. These setting can be configured at the
organizational level and applied to all Exchange
Servers in the organization, or at the server level
and applied only to that specific server.
The cmdlets used to manage resource policy
include:
New-ResourcePolicy
Remove-ResourcePolicy
Get-ResourcePolicy
Set-ResourcePolicy
Cmdlets used to manage workload management policy include:
New-WorkloadManagementPolicy
Remove-WorkloadManagementPolicy
Get-WorkloadManagementPolicy
Cmdlets used to manage workload policies include:
New-WorkloadPolicy
Remove-WorkloadPolicy
Get-WorkloadPolicy
Set-ResourcePolicy
Throttling policies are managed and assigned by using the following cmdlets:
New-ThrottlingPolicy
Get-ThrottlingPolicy
Set-ThrottlingPolicy
Remove-ThrottlingPolicy
Get-ThrottlingPolicyAssociation
Set-ThrottlingPolicyAssociation
To display current workload management policies, use the following cmdlet:
Get-WorkloadManagementPolicy
To change the default workload management policy for your organizations Outlook Web App workload,
use the following cmdlet:
New-WorkloadPolicy OrgOWAWorkloadPolicy -WorkloadType OWA -WorkloadClassification
Discretionary -WorkloadManagementPolicy GlobalOverrideWorkloadManagementPolicy.
To create a workload management policy for Outlook Web App for a specific server, perform the
following steps:
1.
You should create a custom workload management policy that will be applied later to a specific
server by using the following cmdlet:
New-WorkloadManagementPolicy LondonWorkloadManagementPolicy
2.
Next, you should create a new Outlook Web App workload policy by using the following cmdlet:
New-WorkloadPolicy LondonOWAWorkloadPolicy -WorkloadType OWA -WorkloadClassification

Discretionary -WorkloadManagementPolicy LondonWorkloadManagementPolicy
3.
At the end, you should apply the custom workload management policy you just created to a specific
server by using following cmdlet:
Set-ExchangeServer -WorkloadManagementPolicy LondonWorkloadManagementPolicy -Identity
LON-MBX01
What Is Managed Availability?

Managed availability is a new infrastructure of
monitoring and managing Exchange workloads.
Managed availability monitors the Exchange
workloads health state. If there are any issues
with Exchange workload health state, managed
availability will try to perform recovery of the
Exchange workload. This feature provides users
with continued access to their mailboxes to avoid
experiencing any failures or disconnections.
In previous Exchange Server versions, whenever server or performance issues arose, administrators usually
performed one of the following procedures to troubleshoot and diagnose the issue:
Check whether the service is running in the Services console.
Run different test cmdlets.
Review data in the performance monitor console.
In Exchange Server 2013, managed availability monitors workloads instead of services or performance. If
any Exchange workload has a slow response or is not responding, managed availability will try to detect
and recover the workload. Managed availability is integrated with Exchange Server high availability. For
example, database failover might be initiated even when the active database itself is healthy, but the
protocol that connects clients to their mailboxes located on that particular database is not responding.
Managed availability consists of three components:
Probes. Uses checks to monitor current user connections and creates notifications based on current
state and availability information.
Monitor engine. Analyzes data output from the probe engine, and reacts with two possible decisions,
healthy or non-healthy.
Responder engine. Tries to recover the Exchange workload if the monitor state is unhealthy.
Depending on the issue type, the recovery action can be different, such as restarting service, resetting
application pool, and failover mailbox database, among others. If none of these actions result in issue
resolution, then the responder will escalate the issue, by notifying the administrators or by creating an
alert in Operations Manager.
Considerations for Change Management

The change-management process varies widely
from organization to organization. The basic
components for managing change are:
Adopt a process model. A number of welldefined frameworks are available, such as

Microsoft Operations Framework. Adopting
an established framework may make it easier
to educate employees, because they might
be familiar with the framework.
Define a process and use it consistently. Once

you have implemented a process, ensure that
everyone involved understands why it was
adopted and how to follow it.
Support the change-management process. If you do not support the process properly, you will not be
able to maximize its effectiveness. It is essential that everyone works to support the process.
Successful change management depends on ensuring that everyone, from the engineers who implement
the changes, to the organizations executives, understand the process and follow it. Although managing
change requires additional work up front, the process ensures proper and effective change. Properly
implementing change saves time and effort, and improves user satisfaction.
Planning Deployment of Exchange Software Updates

You can update Microsoft Exchange Server 2013
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; instead, you must use
packages that contain several updates and fixes.
Service packs and update rollups are part of the
servicing strategy for Exchange Server 2013. These
resources provide an effective and easy method
for distributing Exchange Server 2013 fixes and
modifications. We recommend that you install the
latest service pack and update rollup to keep the
product up-to-date.
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 2013 RTM, it includes the
fixes that were released in Update Rollup 1 and Update Rollup 2. Therefore, you need only the latest
Update Rollup to be current.
Applying rollup packages and service packs is usually a straightforward 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 CRLs 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-Internetfacing Client Access servers.
When you install an update rollup, the Setup program automatically stops the appropriate Exchange
services and services related to IIS. Therefore, during the installation process, the server might 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:
a.
Run the StartDagServerMaintenance.ps1 script to put the DAG member into maintenance mode,
and prepare it for the update rollup installation.
b.
Install the update rollup.
c.
Run the StopDagServerMaintenance.ps1 script to take the DAG member out of maintenance
mode and put it back into production.
d.
Optionally, rebalance the DAG by using the RedistributeActiveDatabases.ps1 script.
e.
Use this process to install operating system updates from Microsoft Update.
Planning Exchange Hardware Upgrades

Exchange Server 2013 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 2013 reduces disk activity. Disk capacity is
one of the most commonly required hardware
upgrades.
Proactively monitoring hardware performance

processor, memory, disk, or networkis the best
way to determine if there are bottlenecks in the
environment. Another way to research hardware
issues is to gather and examine 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 2013 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, and 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. Instead, you can deploy a new Mailbox server, move some mailboxes to it, and
then form a DAG. In this way, you scale out your Exchange environment instead of scaling it up.
When you plan for virtualization, you should consider deploying hardware that lets you increase physical
resources for the virtual environment when needed. When you plan for physical Exchange server
deployment, you might consider using blade servers for scale out, because they have same architecture
and provide unified monitoring and management.
Lesson 3
Troubleshooting Exchange Server 2013
Even in a well-maintained Exchange Server 2013 organization, problems can arise, and you must identify
and repair them. Although general troubleshooting guidelines exist, your experience and an analytical
attitude often provide the best tools to successfully detect the problems source and fix it.
Lesson Objectives
Develop a troubleshooting methodology.
Troubleshoot database failures.
Troubleshoot database replication.
Troubleshoot performance issues.
Troubleshoot connectivity issues.
Describe troubleshooting tools.
Describe how to troubleshoot Mailbox servers.
Describe how to troubleshoot Client Access servers.
Describe how to troubleshoot Transport components.
Developing a Troubleshooting Methodology

To troubleshoot effectively, you must identify
and diagnose problems, and then determine
and execute the necessary repair. There are
many troubleshooting methods, and they vary
depending on the type of problem that you need
to resolve. The key is to implement a repeatable
troubleshooting process 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. When you define the scope of the problem, you actually define the area
that the problem affects. For example, the scope can be defined by the number of users affected by a
specific problem. Scope also 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 you complete
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 some 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. You should 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 the 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.
Question: Why is it important to have a methodology for troubleshooting?
Troubleshooting Database Failures

Database availability and health are critical
for Exchange Server functioning, because all
mailboxes and data are stored on mailbox
databases. Administrators should follow guidelines
and best practices on creating, configuring,
managing, and maintaining mailbox databases.
If mailbox database failure occurs, use the
troubleshooting methodology previously
discussed, and incorporate the following
guidelines:
Analyze event logs. If your organization does

not use a monitoring solution such as System
Center 2012, you should analyze event logs for any error messages that will guide you to the next
troubleshooting steps.
Troubleshoot storage-system health. Databases can be corrupted in a scenario in which the storage
system has issues or internal errors. Usually, storage systems have their own diagnostic software that
can detect any issues. If you locate a problem on storage-system functioning, replace it, recover
databases from backup, or reseed the database if configured in a DAG. In a DAG configuration, do
not activate the database until you test the storage system for a relevant amount of time, such as one
week.
Check disk free space. If the logical disk where your databases are located is full, the database will be
dismounted automatically, and users will be not able to connect to their mailboxes. If there is no free
space on the disk, extend the logical disk or move the database to another logical disk where more
free disk space exists.
Analyze services dependencies. Mailbox databases are managed by the Microsoft Exchange
Information Store service, which also depends on other services, such as Microsoft Exchange Active
Directory Topology. If services on which the mailbox database depends have failed, you should
investigate their failures and to try to bring them back to a running state.
Analyze which applications are installed on Exchange Server. Some organizations deploy third-party
business applications that communicate with their Exchange servers. If these applications are not
installed according to vendor requirements, the software might cause database failure. Moreover,
antivirus applications that are not designed for Exchange Server might corrupt the database, which
will also result in database failure. Make sure that no applications can access the Exchange server that
Microsoft does not recommend, or that are not installed according to vendor specifications.
Troubleshooting Database Replication

Organizations that have deployed DAGs should
carefully monitor and manage DAG components
and services. Monitoring replication enables you
to maintain healthy and redundant databases
across multiple DAG members.
If database replication failure occurs, use the
discussed, and incorporate the following
guidelines:
Use database-failure troubleshooting

guidelines. Check for individual databasehealth guidelines that might influence
replication health. For example, if disk free space is critical on DAG members, replication will not
continue.
Check if Microsoft Exchange Replication service is running. Database replication in DAG members is
dependent on Microsoft Exchange Replication service health. Check if the service is healthy on all
DAG members. Also check for all service dependencies for this service, such as Microsoft Exchange
Active Directory Topology service.
Use Exchange Management Shell cmdlets. You can use different test cmdlets in order to troubleshoot
replication issues.
You can use the Test-ReplicationHealth cmdlet to troubleshoot database replication and to review
the status for a specific DAG member. For example, consider the following cmdlet to troubleshoot
database replication on LON-MBX1:
Test-ReplicationHealth -Identity LON-MBX1
You can use the Get-MailboxDatabaseCopyStatus cmdlets to analyze health and status information
about mailbox database copies in a DAG. For example, consider the following cmdlet to troubleshoot
database replication on the ExecutivesDB database:
Get-MailboxDatabaseCopyStatus -Identity ExecutivesDB | Format-List
You can use the CollectOverMetrics.ps1 script that collects metrics in real time, while the script is
running. CollectReplicationMetrics.ps1 collects data from performance counters and generates a
report on different statistical data. For example, consider the following script to troubleshoot
database replication for database ExecutivesDB:
CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -Database:"ExecutivesDB"
-GenerateHTMLReport ShowHTMLReport
Troubleshoot network infrastructure. If the network infrastructure that DAG members are using for
replication is disconnected or has connectivity or latency issues, those issues will affect database
replication. You must ensure that network infrastructure is working properly, or in some scenarios
provides redundant network paths for database replication.
Troubleshooting Performance Issues

Performance issues can affect user experience and
organizations in an Exchange Server production
environment. Therefore, you must perform a
detailed analysis and diagnose the reasons for the
performance issues. Performance issues may result
from a variety of circumstances, including:
Increased number of user mailboxes because

of new employees.
New software is installed, such as backup

software, or software that is connected to
the Exchange Server that is not configured
according to documentation best practices.
A new update is installed that is not configured according to documentation best practices, or the
update process has not been performed according to best practice.
A security issue, malware, or network attack.
If performance issues occur, use the troubleshooting methodology previously discussed, and incorporate
the following guidelines:
Operations Manager. If you are using Operations Manager, review the events reported, and use its
diagnostics and resolution capabilities.
Performance Monitor. If you are using Performance Monitor in Windows Server 2012, review the
relevant performance counters, and add additional counters, if necessary, to obtain as much
information as possible about server performance.
Performance Counters. Compare the current performance counters with your servers performance
baselines. Then follow the guidelines for using performance baseline that were described earlier in
this module.
Software Upgrade Issues. If the performance issue is related to a software upgrade, plan the
appropriate upgrade steps. Determine the extent to which your hardware supports additional
components. You may need a new server may be needed, and you may need to migrate Exchange
server to the new server.
Malware Issues. If the performance issue is related to malware, disconnect the server from the
network, and work with network and security administrators to resolve the issue. Perform a detailed
analysis on security settings and malware protection through your entire IT infrastructure, and not just
your Exchange servers.
Troubleshooting Connectivity Issues

Exchange Server 2013 relies on fast and
reliable network connections with domain
controllers, because most of the Exchange Server
configuration data is stored on domain
controllers. Client connections also rely on stable
network connectivity with client access servers
to provide users with a productive messaging
environment where they can perform their tasks.
If connectivity issues occur, use the
discussed, and include the following guidelines:
Use Microsoft Remote Connectivity Analyzer.

Microsoft Remote Connectivity Analyzer is a web-based tool that simulates external client
connections to your Exchange Server infrastructure. The Remote Connectivity Analyzer tool is located
at http://go.microsoft.com/fwlink/?LinkId=290683.
Use Microsoft Connectivity Analyzer Tool. Microsoft Connectivity Analyzer Tool is a client program
that simulates internal client connections to your Exchange Server infrastructure. You can download
the Connectivity Analyzer Tool from http://go.microsoft.com/fwlink/?LinkId=290683.
Analyze internal network infrastructure. Work closely with your network administrators to identify any
issues that might originate from:
o
Internal network equipment failures.
Internet network communication equipment.
Firewall devices.
Analyze Exchange servers firewall configuration. Each Exchange server has its own setting in
Windows Firewall with Advanced Security in the Windows Server 2012 operating system. Check if
the ports Exchange Server 2013 uses are opened in Windows Firewall with Advanced Security.
Analyze Client Access servers health. Whenever users report connectivity issues, check for Client
Access server health and connectivity. When you use network load balancing technology, if there is
any issue with a specific Client Access server, the communication will failover to another member of
the Client Access array.
Troubleshooting Tools
Over time, many Exchange Server troubleshooting
tools have been introduced. Each tool has a
specific purpose, but they all require detailed
product knowledge and information about your
environment to detect potential problem
solutions. Two primary tools include:
Microsoft Remote Connectivity Analyzer.

Microsoft Remote Connectivity Analyzer is
a web-based tool that simulates external
client connections to your Exchange Server
infrastructure. In addition, this tool performs
multiple tests and troubleshoots potential
connectivity issues. The Microsoft Remote Connectivity Analyzer is located at
Microsoft Connectivity Analyzer Tool. Microsoft Connectivity Analyzer Tool is a client program that
simulates internal client connections to your Exchange Server infrastructure. You can download the
Connectivity Analyzer Tool from http://go.microsoft.com/fwlink/?LinkId=290683.
Delivery Reports. Delivery Reports is a message-tracking tool in the Exchange Administration Center
(EAC) for troubleshooting the delivery status on email messages for up to 14 days after they are sent
or received.
Other tools, such as the Performance 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 troubleshoot network issues and message tracking, and the Routing Log Viewer can help
you troubleshoot message delivery issues.
In addition to the Exchange Administration Center, the Exchange Management Shell, and Active Directory
Users and Computers, there are many other tools that you can use to manage and troubleshoot an
Exchange Server 2013 organization. A number of these tools are included in the following table.
Tool name
Description
ADSI Edit (adsiedit.msc)
Use this tool for low-level editing of Active Directory objects and
attributes. On Windows Server 2012, it is installed as part of the
Remote Server Administration Tools.
Event Viewer (eventvwr.msc)
Use this MMC snap-in to view logged events such as errors and
warnings.
Performance Monitor
Use this tool to monitor the performance of hardware

components, operating system and applications.
Task Manager
Use this tool to review which services are running and how many
resources they utilize.
Exchange Server Database

Utilities (Eseutil.exe)
Use this tool to perform offline database procedures, such as

defragmentation and recovery.
New-MailboxRepairRequest
Use this tool to find and remove errors in the mailbox

and public folder databases. You also can run the
New-MailboxRepairRequest cmdlets against mailboxes.
Tool name
Description
LDP (ldp.exe)
Use this tool to perform operations such as connect, bind, search,

modify, add, and delete against Active Directory Domain Services
(AD DS).
Microsoft Baseline Security

Analyzer (MBSA) GUI: MBSA.exe
Command line: mbsacli.exe
Use this tool to determine the security state of the organizations

servers in accordance with Microsoft security recommendations. It
also offers specific remediation guidance.
Microsoft Error Reporting
Exchange Server 2013 uses this tool 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 2013. This
service gives administrators and users the opportunity to send
data about errors to Microsoft, and to receive information about
errors. Administrators can use Microsoft Error Reporting to
address customer problems in a timely manner, and to help
improve the quality of Microsoft products.
Process Monitor (procmon.exe)
Use this tool to monitor real-time file system, registry, and

process/thread activity.
Test-Outlook Connectivity
Use this cmdlet to confirm the Outlook Anywhere connectivity

between the computer that is running the Exchange Server, and
any of the Outlook client workstations on the network.
Telnet (telnet.exe)
Use this tool to troubleshoot Exchange Server mail flow.
Discussion: Troubleshooting Mailbox Servers

When you troubleshoot Mailbox server issues,
you should check the databases health and
availability first. 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 Remote Connectivity Analyzer and 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 Transport Components

Transport server issues usually are due to
mail queue database corruption or network
connectivity problems. Use tools such as the
Microsoft Remote Connectivity Analyzer, Delivery
Reports, and Queue Viewer to identify the
problem, and then work toward a resolution.
Question: Users are reporting nondeliverable and slow-to-deliver outbound
email. What process can you use to
troubleshoot the problem?
Lab: Monitoring and Troubleshooting Exchange

Server 2013
Scenario
You are the messaging administrator at A. Datum Corporation. You need to configure basic monitoring by
using the Performance Monitor. You also need to troubleshoot mailbox database and Client Access server
issues.
Objectives
After performing this lab, you will be able to:
1.
Monitor Exchange Server.
2.
Troubleshoot database availability.
3.
Troubleshoot Client Access servers.
Lab Setup
Virtual machines
20341B-LON-DC1
20341B-LON-CAS1
20341B-LON-MBX1
User name
Password
Pa$$w0rd
1.
2.
3.
4.
5.
a.
b.
Password: Pa$$w0rd
Exercise 1: Monitoring Exchange Server

Scenario
You are the messaging administrator at A. Datum Corporation. You need to configure basic monitoring
using the Windows Performance Monitor. Before you implement Microsoft Systems Center Operations
Manager to monitor your Exchange Server 2013 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.
Task 1: Create a new data collector set named Exchange Monitoring
On LON-MBX1, from Server Manager open the Performance Monitor, and create a data collector set
named Exchange Monitoring. Configure the Data Collector Set to include the Performance counter
data logs.
Task 2: Create a new performance-counter data collector set for monitoring basic
Exchange Server performance
1.
Add a new data collector to the Exchange Monitoring data collector set named Base Exchange
Monitoring.
2.
Add the performance counters in the following table to monitor basic Exchange Server performance
on LON-MBX1. Configure the sample interval to run every 1 minute.
Object
Counter
Processor
% Processor Time
% User Time
% Privileged Time
MSExchange ADAccess
Domain Controllers
LDAP Read Time

LDAP Search Time
LDAP Searches timed out per minute
Long running LDAP operations/Min
Memory
Available Mbytes
Page Reads/sec
Pages Input/sec
Pages/sec
Pages Output/sec
Pool Paged Bytes
Transition Pages Repurposed/sec
System
Processor Queue Length
Task 3: Create a new performance-counter data collector set for monitoring Mailbox
server role performance
1.
Add a new data collector to the Exchange Monitoring data collector set named Mailbox Role
Monitoring.
2.
Add the following performance counters to monitor basic Exchange Server 2013 performance on
LON-MBX1. Configure the sample interval to run every 1 minute.
Object
Counter
LogicalDisk
Avg.Disk sec/Read
Avg.Disk sec/Transfer
Avg.Disk sec/Write
MSExchangeIS Store
RPC Average Latency

RPC Operations/sec
RPC Requests
Messages Delivered/sec
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.
3.
Close the Performance Monitor.
Results: After this exercise, you should have created a data collector set for monitoring LON-MBX1 that
uses the recommended performance counters.
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.
List the probable causes of the problem, and rank the possible solutions if multiple options exist.
4.
Review the database configuration.
5.
Reconfigure and mount the database.
Task 1: Identify the scope of the problem

Before you begin this exercise, complete the following steps:
1.
On LON-MBX1, open the Exchange Management Shell. At the prompt, type

c:\scripts\Lab11Prep1.ps1, and then press Enter. This script will simulate database failure.
2.
On LON-MBX1, open the Exchange admin center using the link https://lon-cas1.adatum.com/ecp,
and in Username box, type Adatum\Administrator, and in Password box, type Pa$$w0rd.
3.
Identify whichif anymailbox databases are not mounted on LON-MBX1. Verify that database
MailboxDB100 is dismounted.
4.
Try to mount the database, and verify that two warning windows will appear, where the second will
display the message that at least one database file is missing. In this warning window, click on the
cancel button to cancel the mount process.
Task 2: Review the event logs
Open the Event Viewer. In the Application Log and System Log, review the events generated, and
note any errors.
Task 3: 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
Task 4: Review the database configuration

1.
On LON-MBX1, open the Exchange Administration Center, and then review the database
configuration.
2.
Open a File Explorer window, and locate the database files.
Task 5: Reconfigure and mount the database

1.
On LON-MBX1, in the Exchange Management Shell, reconfigure the MailboxDB100 database by

running the following cmdlet:
Move-DatabasePath MailboxDB100 LogFolderPath C:\Program Files\Microsoft\Exchange
Server\V15\Mailbox\MailboxDB100 EdbFilePath C:\Program Files\Microsoft\Exchange
Server\V15\Mailbox\MailboxDB100\MailboxDB100.edb ConfigurationOnly force
2.
Mount the database by running following cmdlet:

Mount-Database MailboxDB100
3.
In the EAC, verify that database MailboxDB100 status is Mounted.
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.
Use the Test cmdlets to verify server health.
2.
List the probable causes of the problem, and rank the possible solutions if multiple options exist.
3.
Check the Outlook Web App configuration.
4.
Verify that you resolved the problem.
Task 1: Use the Test cmdlets to verify server health

1.
On LON-MBX1, in the Exchange Management Shell, at the prompt, type c:\scripts\Lab11Prep2.ps1,

and then press Enter.
2.
3.
On LON-MBX1, open the Exchange Management Shell, and run the Test-ServiceHealth cmdlet.
4.
Verify that the output does not return any errors.
5.
Run the Test-OwaConnectivity URL https://LON-MBX1.Adatum.com/OWA

-TrustAnySSLCertificate cmdlet to test Outlook Web App connectivity.
6.
Note the authentication errors.

Problem
Possible solution
Task 3: Check the Outlook Web App configuration

1.
On LON-MBX1, verify that you cannot log on to EAC.
2.
From Exchange Management Shell, display the verification methods for owa virtual directory, and
verify that all methods are set to False.
3.
From Exchange Management Shell, configure the verification method for owa virtual directory, to be
set on FormsAuthentication.
4.
From Exchange Management Shell, run IISReset command.
5.
Verify that you can start the Exchange Administration Center.
Task 4: Verify that you resolved the problem

1.
Attempt to log on to https://LON-CAS1.adatum.com/owa as Adatum\Administrator with the

password Pa$$w0rd.
2.
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.

Best Practice
Follow the same steps each time you troubleshoot a problem. Then you will get into a habit of
making informed decisions and finding the answers quickly.
Be diligent about separating the facts about the issue from any subjective information. A single
persons subjective observation could cause you to troubleshoot the wrong problem and delay
resolution of the actual issue.
Ask many questions about the problem before you start to troubleshoot. If you have not properly
defined the problem, you cannot properly target your troubleshooting steps.

Common Issue
Troubleshooting Tip
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. In what should
the company invest to ensure that it can
support continued growth?
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?
An Exchange Server service pack was

recently released, and the company has
decided to deploy it. What should you do
before scheduling the deployment?
Review Question
Question: After reviewing the trend information retrieved from the monitoring system, you
notice that the processor usage for one of the four Mailbox servers is higher than average.
What should you do?
Your organization has deployed Exchange Server 2013, with two Client Access servers and two Mailbox
servers. There is no high availability configured. After several months, many users are complaining about
slow response. Your task is to troubleshoot and resolve this issue. What will you do?
First, you should investigate whether this issue is occurring with all users or just some users. You should
start by using Remote Connectivity Analyzer to troubleshoot user connectivity. You also should analyze
information in Performance Monitor to check if this behavior is due to performance reasons. If you use
System Center Operations Manager, you will be able to troubleshoot the user experience with the
products end-to-end monitoring capabilities.
In addition, you could deploy high availability for Client Access and Mailbox server roles. In this scenario,
the new managed availability feature in Exchange Server 2013 will try multiple steps to improve the user
experience. For example, if the slow response is due to issues on the HTTPS protocol from the Client
Access server to the Mailbox server, Exchange Managed Availability will perform a database failover
process to another DAG member. After the failover process is completed, the Client Access server will be
connected with another Mailbox Server that does not experience HTTPS protocol issues.
Tools
Tool name
Description
Microsoft Remote Connectivity

Analyzer
Use this web-based tool to simulate external client connections

to Exchange Server infrastructure. Located at
Microsoft Remote Connectivity

Analyzer Tool
Use this client program to simulate internal client connections to

Exchange Server infrastructure. Located at
ADSI Edit (adsiedit.msc)
Use for low-level editing of Active Directory objects and attributes.

On Windows Server 2012, it is installed as part of the Remote
Server Administration Tools.
Event Viewer (eventvwr.msc)
Use this MMC snap-in to view logged events such as errors and
warnings.
Performance Monitor
Use this tool to monitor the performance of hardware

components, the operating system, and applications.
Task Manager
Use this tool to review which services are running and how much
resources they utilize.
Exchange Server Database

Utilities (Eseutil.exe)
Use this tool to perform offline database procedures, such as

defragmentation and recovery.
New-MailboxRepairRequest
Use this tool to find and remove errors in the mailbox

and public folder databases. You can also run the
New-MailboxRepairRequest command against mailboxes.
LDP (ldp.exe)
Use this tool to perform operations such as connect, bind, search,

modify, add, and delete against AD DS.
Microsoft Baseline Security

Analyzer (MBSA) GUI: MBSA.exe
Command line: mbsacli.exe
Use this tool to determine the security state of the organizations

servers in accordance with Microsoft security recommendations.
Also use it to obtain specific remediation guidance.
Tool name
Description
Microsoft Error Reporting
Use this tool in Exchange Server 2013 to collect crash dumps and
debug information. This tool enables administrators to track and
address errors related to the Windows operating system, Windows
components, and applications such as Exchange Server 2013. This
service gives administrators and users the opportunity to send data
about errors to Microsoft, and to receive information about errors.
Administrators can use Microsoft Error Reporting to address
customer problems in a timely manner, and to help improve the
quality of Microsoft products.
Process Monitor (procmon.exe)
Use this tool to monitor real-time file system, registry, and

process/thread activity.
Test-OutlookConnectivity
Use this cmdlet to confirm the Outlook Anywhere connectivity

between the computer that is running the Exchange Server, and
any of the Outlook client workstations on the network.
Telnet (telnet.exe)
Use this tool to troubleshoot Exchange Server mail flow.
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.

L1-1
Module 1: Deploying and Managing Microsoft Exchange

Server 2013
Lab: Deploying and Managing Exchange

Server 2013
Exercise 1: Evaluating Requirements and Prerequisites for an Exchange
Server 2013 Installation
Task 1: Evaluate the Active Directory Requirements
1.
On LON-DC1, if necessary, on the task bar, click Server Manager.
2.
In Server Manager, click Tools, and then click Active Directory Users and Computers.
3.
Right-click Adatum.com, and then click Properties.
4.
In the Adatum.com Properties dialog box, verify that the domain and forest functional levels are
compatible with the Exchange Server 2013 requirements. (Note: It should be at least Windows Server
2003)
5.
Click OK, and then close Active Directory Users and Computers.
6.
Click to the Start screen and then type adsi edit, and then press Enter.
7.
Right-click ADSI Edit, and then click Connect to.
8.
In the Connection Settings dialog box, in the Connection Point section, in the Select a wellknown Naming Context list, click Configuration, and then click OK.
9.
In the left pane, expand Configuration [LON-DC1.adatum.com], and then click

CN=Configuration,DC=adatum,DC=com.
10. Expand CN=Services, and verify that the CN=Microsoft Exchange has not been created.
11. Close ADSI Edit.
Task 2: Evaluate the DNS requirements

1.
On LON-EX1, on the task bar, click Windows PowerShell.
2.
In the Windows PowerShell window, type IPConfig /all, and then press Enter. Verify that the
Domain Name System (DNS) server IP address for the Local Area Connection is 172.16.0.10.
3.
At the command prompt, type Ping LON-DC1.adatum.com and press Enter. 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.adatum.com, and then press Enter. Verify that
an SRV record for lon-dc1.adatum.com is returned.
7.
Results: After completing this exercise, the students will have evaluated the AD DS requirements.
Exercise 2: Deploying Exchange Server 2013

Task 1: Preparing AD DS for Exchange Server 2013 deployment
L1-2 Deploying and Managing Microsoft Exchange Server 2013
1.
On LON-DC1, in the Virtual Machine Connection window click Media menu, select DVD Drive, and
then click Insert Disk.
2.
Navigate to C:\Program Files\Microsoft Learning\20341\Drives\ExchangeServer2013CU1.iso

and click Open.
3.
On the task bar, click Windows PowerShell.
4.
Type D: and press Enter.
5.
Type the following command, and then press Enter:

.\Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms /OrganizationName:Adatum
6.
Wait until the process completes.
7.
Task 2: Performing Exchange Server 2013 installation on a single server

1.
On LON-EX1, in the Virtual Machine Connection window, click Media menu, select DVD Drive, and
then click Insert Disk.
2.
Navigate to C:\Program Files\Microsoft Learning\20341\Drives\ExchangeServer2013CU1.iso

and click Open.
3.
On LON-EX1, open Windows PowerShell window from the task bar.
4.
Type the following command to install the Exchange Server 2013 Windows components:
Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSATClustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model,
Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing,
Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-HttpTracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, WebMgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server,
Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, WindowsIdentity-Foundation, and press Enter. (If you do not want to type this command you can copy the
content of the file cmdlet.txt from C:\ drive.)
5.
Wait until installation of Windows components finishes.
6.
Close the PowerShell window, and restart the server.
7.
Sign in to LON-EX1 as Adatum\Administrator with the password Pa$$w0rd.
8.
From the desktop, open File Explorer and navigate to D: drive.
9.
Double-click setup.exe.
10. On the Check for Updates? page, click Dont check for updates right now, and click next. Wait
until setup copies files and initializes the setup process.
11. On the Introduction page, click next.
12. On the License Agreement page, click I accept the terms in the license agreement, and then click
next.
13. On the Recommended Settings page, click next.
Core Solutions of Microsoft Exchange Server 2013 L1-3
14. On the Server Role Selection page, select Mailbox role and Client Access role, and then click next.
15. On the Installation Space and Location page, accept the default values, and click next.
16. On the Malware Protection Settings make sure that No is selected, and then click next.
17. On the Readiness Checks page, ensure that all prerequisites are met, and then click install.
18. Wait until the installation completes. It can take 30 to 40 minutes to finish. On the Setup Completed
page, click finish.
19. Restart LON-EX1 and sign in as Adatum\Administrator with the password Pa$$w0rd.
Task 3: Verify Exchange Server installation

1.
On LON-EX1, open the Server Manager console, and then click Tools.
2.
Select Services.
3.
Scroll down the list of services, and click the Microsoft Exchange Active Directory Topology
service. Review the service description.
4.
Review the status of the remaining Exchange Server services. Ensure that all services that are set for
Automatic startup are running.
5.
Close Services.
6.
From the task bar, open File Explorer.
7.
Browse to C:\Program Files\Microsoft\Exchange Server\V15. This list of folders includes

ClientAccess, Mailbox, and TransportRoles. These roles were installed as part of the typical setup.
8.
Close File Explorer.
9.
From the Start screen, click Internet Explorer.
10. In the Address bar, type https://lon-ex1.adatum.com/owa, and then press Enter.
11. Sign in as Adatum\Administrator with the password Pa$$w0rd.
12. At the Language and Time zone page, click save.
13. Click new mail.
14. Send an email to Administrator.
15. Verify that the email is received in the inbox.
16. Close Outlook Web App.
Results: After completing this exercise, the students will have deployed Exchange Server 2013.
Exercise 3: Managing Exchange Server 2013

Task 1: Explore Exchange Server 2013 Administration Center
1.
On LON-EX1, from the Start screen, open Internet Explorer, type https://lon-ex1.adatum.com
/ecp, and then press Enter.
2.
In the Domain\user name text box type Adatum\Administrator, and type Pa$$w0rd in the
Password field, and then click sign in.
3.
In the EAC, click recipients in the left pane, and then click mailboxes in the central pane.
4.
Click on the + sign and then click User mailbox.
5.
In the new user mailbox window, select Existing user, and then click browse.
6.
In the Select User Entire Forest window, select Aidan Delaney, and click ok.
7.
In the Alias text box, type AidanD, and click save.
8.
Make sure that Aidan Delaney appears in the list of mailboxes.
9.
In the recipients node in the Exchange admin center, click groups.
10. Click the arrow next to the + sign.

11. Select Distribution group.
12. In the new distribution group window, type Adatum News in the Display name text box.
13. In the Alias text box, type AdatumNews.
14. Scroll down and make sure that Open is selected in last two sections. Click save.
15. In the upper right corner, click the arrow next to Administrator, and select Sign out.
Task 2: Manage Exchange Server with Exchange Management Shell

1.
On LON-EX1, switch to the Start screen, and then click Exchange Management Shell.
2.
In Exchange Management Shell, type get-user and press Enter.

All users from Adatum.com domain will be listed.
3.
Type enable-mailbox identity Robert, and press Enter.
4.
Type Get-Mailbox, and press Enter. You will receive all mailboxes on the server in the list.
5.
Type get-mailbox | set-mailbox issuewarningquota 209715200 prohibitsendquota

262144000, and press Enter.
6.
Type get-mailbox, and press Enter. Ensure that ProhibitSendQuota is set to 250 MB to all users.
7.
Type Get-User | Where-Object {$_.distinguishedname

ilike *ou=IT,dc=adatum,dc=com} | Enable-Mailbox, and press Enter.
8.
Ensure that mailboxes for the IT organizational unit are created.
9.
Close the Exchange Management Shell window.
Task 3: Explore Outlook Web App
L1-4 Deploying and Managing Microsoft Exchange Server 2013
1.
On LON-EX1, from the Start screen, open Internet Explorer and type https://lon-ex1.adatum.com
/owa.
2.
In the Outlook Web App window, sign as Adatum\Aidan with the password Pa$$w0rd.
3.
Click save on the next page.
4.
In the Outlook Web App window, click new mail.
5.
In the window on the right, send a new email to Administrator.
6.
Click on the wheel icon in the upper right corner. Select Options.
7.
In the options window, click on groups in the left pane.
8.
In the central pane, click the Join button.
9.
In the All Groups window, double-click Adatum News.
10. In the Adatum News window, click Join.

11. Close the all groups window.
12. Click on settings in the left pane
13. In the email signature box, type Aidan Delaney, Adatum Corp., and select Automatically include
my signature on messages I send.
14. Click save.
15. Click the arrow in the upper left corner (back).
16. Click on the wheel icon in the upper right corner.
17. Select Change theme.
18. Click on theme of your choice, and then click OK.
19. Close the Internet Explorer window.
following steps:
1.
2.
In the Virtual Machines list, right-click 20341B-LON-DC1-B, and then click Revert.
3.
4.
5.
6.
7.
8.
Password: Pa$$w0rd
Results: After completing this exercise, the students will have explored Exchange management tools.

L2-7
Module 2: Planning and Configuring Mailbox Servers

Exercise 1: Planning Configuration for Mailbox Servers
Task 1: Analyze requirements for the A. Datum Exchange Server deployment
Read the Lab and Exercise scenario. Summarize the requirements from the exercise scenario.
Task 2: Use the Exchange Mailbox Server Role Requirements Calculator

1.
On LON-CL1, click the Desktop tile.
2.
On the task bar, click File Explorer, navigate to C:\Files and double-click on E2013Calc.xlsm. On the
Security warning, click Enable Content. If the Welcome to Your New Office Wizard launches, click
Next three times and then click All done!.
3.
In the E2013Calc, on the Input sheet, enter the values in the following sections:
o
Exchange Environment Configuration
Server Multi-Role Configuration (MBX+CAS): No
Server Role Virtualization: Yes
High Availability Deployment: Yes
Number of Mailbox Servers Hosting Active Mailboxes/DAG: 4
Number of Database Availability Groups: 2
Mailbox Database Copy Configuration
Total Number of HA Database Copy Instances (Includes Active Copy) within DAG: 3
Total number of Lagged Database Copy Instances within DAG: 1
Exchange Data Configuration
Mailbox Moves/Week Percentage: 2%
LUN Free Space Percentage: 25%
Tier-1 User Mailbox Configuration
Total Number of Tier-1 User Mailboxes/Environment: 5,000
Projected Mailbox Number Growth Percentage: 5%
Total Send/Receive Capability/Mailbox/Day: 150 messages
Average Message Size (KB): 75
Mailbox Size Limit (MB): 1,024
Personal Archive Mailbox Size Limit (MB): 2,048
Deleted Item Retention Window (Days): 30
Single Item Recovery: Enabled
Calendar Version Storage: Enabled
Backup Configuration
Backup Methodology: Software VSS Backup/Restore
Backup Frequency: Weekly Full / Daily incremental
Database and Log Isolation Configured: Yes
Backup/Truncation Failure Tolerance: 3
Network Failure Tolerance (Days): 0
Primary Datacenter Disk Configuration
Database: 1,000 GB, 7.2K RPM SAS 3.5
Log: 500 GB, 7.2K RPM SAS 3.5
Restore LUN: 1500 GB, 7.2K RPM SAS 3.5
Task 3: Analyze output from the Exchange Mailbox Server Role Requirements
Calculator
1.
In the E2013Calc, click on the Role Requirements tab.
2.
Review the calculated requirements provided in this sheet.
3.
4.
Click Fail Server for each server. Observe where the databases will be distributed.
5.
Click Export DAG Scripts.
6.
7.
Click the LUN Requirements sheet. Review the calculated requirements provided in this sheet.
8.
Click the Backup Requirements sheet. Review calculated requirements provided in this sheet.
9.
Click the Replication Requirements sheet. Review the calculated requirements provided in this
sheet.
11. Open File Explorer, and navigate to C:\Files.
L2-8 Planning and Configuring Mailbox Servers
12. Right-click the CreateMBDatabases.ps1 file, and select Edit. Review the contents of the generated
script.
13. Right-click the CreateMBDatabaseCopies.ps1 file, and select Edit. Review the contents of the
generated script.
14. Right-click the Diskpart.ps1 file, and select Edit. Review the contents of the generated script.
15. Close the Windows PowerShell ISE window.
Task 4: Discuss the solution with the instructor and the class
1.
Discuss the solution provided by the Exchange Mailbox Server Role Requirements Calculator with
other students and with the instructor.
2.
Change the values on the Input tab of the Exchange Mailbox Server Role Requirements Calculator,
and see how that reflects on the results that this tool provides.
Results: After completing this exercise, the students will have created a plan for their mailbox server
configuration.
Exercise 2: Configure Storage on the Mailbox Servers

Task 1: Create and Configure iSCSI target and drives
1.
On LON-DC1, open Server Manager, click Manage, and then click Add Roles and Features.
2.
In the Add Roles and Features Wizard, on the Before you begin page, click Next.
3.
On the Select installation type page, click Next.
4.
On the Select destination server page, make sure that Select a server from the server pool is
selected, and then click Next.
5.
On the Select server roles page, expand File And Storage Services (Installed), expand File and
iSCSI Services (Installed), select the iSCSI Target Server check box, and then click Next.
6.
On the Select features page, click Next.
7.
On the Confirm installation selections page, click Install.
8.
When installation is complete, click Close.
9.
On LON-DC1, in Server Manager, in the navigation pane, click File and Storage Services.
10. In the File and Storage Services pane, click iSCSI.
11. In the iSCSI VIRTUAL DISKS pane, click TASKS, and then in the TASKS drop-down list, select New
iSCSI Virtual Disk.
12. In the New iSCSI Virtual Disk Wizard, on the Select iSCSI virtual disk location page, under Storage
location, click C:, and then click Next.
13. On the Specify iSCSI virtual disk name page, in the Name box, type iSCSIDisk1, and then
click Next.
14. On the Specify iSCSI virtual disk size page, in the Size box, type 2, make sure GB is selected in the
drop-down list, and then click Next.
15. On the Assign iSCSI target page, click New iSCSI target, and then click Next.
16. On the Specify target name page, in the Name box, type LON-MBX1, and then click Next.
17. On the Specify access servers page, click Add.
18. In the Select a method to identify the initiator dialog box, click Browse. In the Select Computer
window, type LON-MBX1, click Check Names and click OK, and then click OK.
19. On the Specify access servers page, click Next.
20. On the Enable Authentication page, click Next.
21. On the Confirm selections page, click Create.
22. On the View results page, wait until the creation is completed, and then click Close.
iSCSI Virtual Disk.
25. On the Specify iSCSI virtual disk name page, in the Name box, type iSCSIDisk2, and then click
Next.
26. On the Specify iSCSI virtual disk size page, in the Size box, type 2, make sure GB is selected in the
drop-down list, and then click Next.
27. On the Assign iSCSI target page, click lon-mbx1, and then click Next.
iSCSI Virtual Disk.
32. On the Specify iSCSI virtual disk name page, in the Name box, type iSCSIDisk3, and then click
Next.
33. On the Specify iSCSI virtual disk size page, in the Size box, type 500, make sure MB is selected in
the drop-down list, and then click Next.
34. On the Assign iSCSI target page, click lon-mbx1, and then click Next.
Task 2: Connect Exchange Server to the storage

1.
On LON-MBX1, click the Desktop tile.
2.
From the task bar, click Server Manager.
3.
In Server Manager, click Tools, and then click iSCSI Initiator.
4.
In the Microsoft iSCSI dialog box, click Yes.
5.
Click the Discovery tab.
6.
Click Discover Portal.
7.
In the IP address or DNS name box, type 172.16.0.10, and then click OK.
8.
Click the Targets tab.
9.
Click Refresh.
10. In the Targets list, select iqn.1991-05.com.microsoft:lon-dc1-lon-mbx1-target, and then click

Connect.
11. Select Add this connection to the list of Favorite Targets, and then click OK two times.
Task 3: Configure storage

1.
On LON-MBX1, in Server Manager, click Tools, and then click Computer Management.
2.
Expand Storage, and then click Disk Management.
3.
Right-click Disk 1, and then click Online.
4.
Right-click Disk 1, and then click Initialize disk. In the Initialize Disk dialog box, click OK.
5.
Right-click the unallocated space next to Disk 1, and then click New Simple Volume.
6.
On the Welcome to the New Simple Volume Wizard page, click Next.
7.
On the Specify Volume Size page, click Next.
8.
On the Assign Drive Letter or Path page, click Next.
9.
On the Format Partition page, in the Volume Label box, type DB1. Select the Perform a quick
format check box, and then click Next.
10. Click Finish. (Note: If the Microsoft Windows window pops up with prompt to format the disk, click
Cancel.)
11. Repeat steps 3 through 10 for Disk 2 and Disk 3. (Note: Use DB2 and Logs for Volume Labels,
respectively.)
12. Close the Computer Management window.
Results: After completing this exercise, the students will have configured iSCSI storage for their mailbox
databases and logs.
Exercise 3: Creating and Configuring Mailbox Databases

Task 1: Configure Mailbox Settings for the Existing Mailbox Database
1.
On LON-MBX1, click to the Start screen, and then click Internet Explorer.
2.
In Internet Explorer, type https://lon-cas1.adatum.com/ecp, and press Enter.
3.
4.
In the EAC, in the feature pane, click servers.
5.
Click the databases tab.
6.
Double-click Mailbox Database 1.
7.
In the Mailbox database window, click limits.
8.
In the Issue a warning at (GB) text box, type 0.9.
9.
In the Prohibit send at (GB): text box, type 1.
10. In the Prohibit send and receive at (GB): text box, type 1.3.
11. In the Keep deleted items for (days): text box, type 30.
12. Click save. Minimize the EAC window.
13. On LON-MBX1, click to the Start screen and then click Exchange Management Shell.
14. In the Exchange Management Shell window, type Get-MailboxDatabase and press Enter.
15. See the list of mailbox databases created.
16. In the Exchange Management Shell window, type the following command, and then press Enter:
Move-DatabasePath Identity Mailbox Database 1 EdbFilePath E:\DB1\DB1.edb
LogFolderPath G:\Logs\DB1
17. Type y, and press Enter.
19. Minimize the Exchange Management Shell window.
20. Open File Explorer and navigate to E:\ and open the DB1 folder. Make sure that the database
DB1.edb file is present.
21. Navigate to G:\, and open the folder Logs\DB1. Ensure that the log files are present.
22. Close File Explorer.
Task 2: Create and configure additional mailbox databases

1.
Restore the EAC window.
2.
Click servers in the feature pane, and then click the databases tab.
3.
Click New.
4.
In the Database window, in the Mailbox database text box, type DB2.
5.
Click browse.
6.
In the Select Server window, select LON-MBX1, and then click OK.
7.
In the Database file path text box, type: F:\DB2\DB2.edb.
8.
In the Log folder path text box, type G:\Logs\DB2.
9.
Make sure that the Mount this database is selected, and then click save. Click ok.
10. Restore the Exchange Management Shell window.

11. In Exchange Management Shell window, type the following:
Set-MailboxDatabase identity DB2 DeletedItemRetention 20.00:00:00
-CircularLoggingEnabled $true ProhibitSendQuota 2.2GB, and then press Enter.
12. Type Dismount-Database identity DB2, and press Enter.
14. Type Mount-Database identity DB2, and press Enter.
15. Leave the Exchange Management Shell window open.
Task 3: Export mailbox data to the .pst file
1.
On the LON-MBX1 virtual machine, restore the Exchange Management Shell window.
2.
Type New-ManagementRoleAssignment Role "Mailbox Import Export" User Administrator,

3.
4.
From the Start screen, click Exchange Management Shell.
5.
Type the following, and then press Enter:

New-MailboxExportRequest -Mailbox aidan -FilePath \\lon-dc1\MailboxExport\aidan.pst
6.
Type Get-MailboxExportrequest, and press Enter.
7.
Make sure that the status of the request is completed. (If it is not completed, wait for several minutes,
and then repeat step 6.)
8.
Switch to LON-DC1. Open File Explorer and then browse to the C:\MailboxExport folder, and make
sure that the aidan.pst file is present.
9.
following steps:
1.
2.
3.
4.
5.
6.
7.
8.
Password: Pa$$w0rd
Results: After completing this exercise, the students will have their mailbox databases created and
configured.

L3-15
Module 3: Managing Recipient Objects

Exercise 1: Configure Trey Research Recipients
Task 1: Create the Trey Research AD DS objects
1.
On LON-CAS1, start Server Manager.
2.
Click Tools, and then click Active Directory Module for Windows PowerShell.
3.
Type e: and press Enter.
4.
Type cd Labfiles\Mod03, and then press Enter.
5.
Type .\TreyResearchSetup.ps1, and then press Enter.
6.
At the Type the Password prompt, type Pa$$w0rd and press Enter.
7.
Close the Active Directory Module for Windows PowerShell window.
8.
In Server Manager, click Tools, and then click Active Directory Users and Computers.
9.
Expand Adatum.com, expand TreyResearch, and verify that the TreyResearch OU contains child OUs
with user accounts and groups.
10. Close Active Directory Users and Computers.
Task 2: Create the Trey Research mailboxes

1.
On LON-CAS1, click to the Start screen, and then click Exchange Management Shell.
2.
At the command prompt, type New-MailboxDatabase Name TreyResearchDB Server LONMBX1, and then press Enter.
3.
At the command prompt, type Invoke-Command ComputerName LON-MBX1 ScriptBlock

{Restart-Service msexchangeis} and then press Enter.
4.
At the command prompt, type Mount-Database id TreyResearchDB, and then press Enter.
5.
At the command prompt, type Get-User OrganizationalUnit TreyResearch | Enable-Mailbox

-Database TreyResearchDB.
6.
At the command prompt, type Get-Group OrganizationalUnit TreyResearch | EnableDistributionGroup, and then press Enter.
7.
On LON-CAS1, open Internet Explorer and connect to https://LON-CAS1.adatum.com

/ecp.
8.
Sign in as Adatum\administrator using the password Pa$$w0rd.
9.
Click the resources tab.
10. Click New, and then click Room mailbox.

11. Fill in the following information:
o
Room name: TR_Room1
Email address: TR_Room1
Organizational unit: click browse, click TreyResearch, and then click ok
Location: Harrow
Capacity: 20
12. Click Select delegates who can accept or decline booking requests.
13. Click Add, click Charlotte Weiss, click add, and then click ok.
L3-16 Managing Recipient Objects
14. Click more options, and under Mailbox database, click browse, click TreyResearchDB, and then
click ok.
15. Click save.
16. In the Exchange Management Shell, type the following command, and then press Enter.
Set-CalendarProcessing id TR_Room1
BookinPolicy AllTreyResearch.
17. On LON-CAS1, in the EAC, in the Features pane, click recipients.
18. Click the shared tab.
19. Click New.
o
Display name: TreyResearch Sales
Email address: TreyResearchSales
21. Under Full Access, click Add, click TR_Sales, then click add, and then click ok.
22. Click More options.
23. Under Mailbox database, click browse, click TreyResearchDB and then click ok.
24. Click save.
Task 3: Create the Trey Research distribution groups

1.
On LON-CAS1, in the EAC, click the groups tab.
2.
Click New, and then click Distribution group.
3.
Fill in the following information:

o
Display name: Trey_SalesMgrs
Alias: TreySalesMgrs
Members: Florence Flipo, Sidney Higa

4.
Click save.
5.
On the groups tab, click New, and then click Distribution group.
6.
Fill in the following information:

o
Display name: TreyResearchNews
Alias: TreyResearchNews
Members: none
Owner approval is required: Open
Choose whether the group is open to leave: Open
7.
Click save.
8.
On LON-CAS1, in the Exchange Management Shell, type cd E:\Labfiles\Mod03, and then press
Enter.
9.
Type $users=import-csv .\TreyResearchIntegrationTeam.csv, and press Enter.
10. Type foreach ($i in $users) {set-mailbox Identity $i.alias CustomAttribute1 TreyResearch
Integration Project Team}, and press Enter.
11. On LON-CAS1, in the EAC, on the groups tab, click New, and then click Dynamic distribution
group.
o
Display name: TreyIntegration
Alias: TreyIntegration
Owner: Administrator
13. Under Members, click Only the following recipient types, and select the Users with Exchange
mailboxes check box.
14. Click add a rule.
15. From the drop-down list, click Recipient container.
16. Click Adatum.com, and then click ok.
17. Click add a rule.
18. From the drop-down list, click Custom Attribute 1.
19. In the specify words or phrases page, type TreyResearch Integration Project Team, click Add and
then click ok.
20. Click save.
Results: In this exercise, you created AD DS user and group accounts for Trey Research, created a room
mailbox with custom permissions, and configured a shared mailbox. You also configured distribution
groups for the Trey Research users.
Exercise 2: Configure Address Lists and Policies for Trey Research

Task 1: Configure TreyResearch.net as an accepted domain
1.
On LON-CAS1, in the EAC, click mail flow in the Features pane, and then on the accepted domains
tab, click New.
2.
In the new accepted domain window, type TreyResearch as the Name, and TreyResearch.net as
the Accepted domain.
3.
Click save.
Task 2: Configure an email address policy for Trey Research users

1.
On the email address policies tab, click New.
2.
In the new email address policy window, type TreyResearch Email as the Policy name.
3.
Under Email address format, click Add.
4.
From the Select an accepted domain drop-down list, select TreyResearch.net.
5.
Click John.Smith@contoso.com, and then click save.
6.
In the new email address policy window, click add a rule.
7.
Click Select one, and then click Recipient container.
8.
Click TreyResearch, and then click ok.
9.
Click save, and then click ok.
10. Click TreyResearch Email. In the Details pane, click Refresh, click Apply, and then click yes.
11. Click close.
Task 3: Configure an address list for TreyResearch users

1.
In the EAC, click organization in the Features pane, and then click address lists.
2.
On the address lists tab, click New.
3.
In the new address list window, type TreyResearch as the Name.
4.
Click add a rule.
5.
In the select one list, click Recipient container.
6.
In the select an organizational unit dialog box, click TreyResearch, and click ok.
7.
Click save, click ok, and then click Update.
8.
Click yes, and then click close.
Task 4: Configure an address book policy for Trey Research users

1.
On LON-CAS1, if required, open the Exchange Management Shell.
2.
At the command prompt, type the following command, and press Enter.
New-GlobalAddressList -Name TreyResearchGAL -RecipientContainer TreyResearch
3.
Update-GlobalAddressList -id TreyResearchGAL
4.
New-OfflineAddressBook -Name TreyResearchOAB -AddressLists TreyResearch
5.
At the command prompt, type the following command, and type Enter.
New-AddressList -Name TreyResearchRooms RecipientContainer
-IncludedRecipients Resources
6.
TreyResearch
Update-AddressList TreyResearchRooms
7.
Set-OfflineAddressBook -id "TreyResearchOAB" VirtualDirectories LON-CAS1\oab
(Default Web Site),LON-MBX1\oab (Exchange Back End)
8.
Update-OfflineAddressBook -id "TreyResearchOAB"
9.
New-AddressBookPolicy -Name TreyResearchABP -AddressLists \TreyResearch
-OfflineAddressBook TreyResearchOAB -GlobalAddressList TreyResearchGAL -RoomList
\TreyResearchRooms
10. At the command prompt, type the following command, and press Enter.
Get-Mailbox -OrganizationalUnit TreyResearch | Set-Mailbox -AddressBookPolicy
TreyResearchABP
Task 5: Validate the deployment

1.
In the EAC, click recipients in the Features pane.
2.
Click mailboxes, and then double-click Aaron Nicholls and click the mailbox features tab.
3.
Verify that the TreyResearchABP has been assigned to Aarons mailbox. Click cancel.
4.
On LON-CL1, sign in as Adatum\Aaron using the password Pa$$w0rd.
5.
Right-click on the Start screen, and click All apps.
6.
Open Outlook 2013.
7.
On the Welcome to Outlook 2013 page, click Next.
8.
On the Add an Email Account page, click Next.
9.
On the Auto Account Setup page, verify that Aarons information is automatically added, and click
Next.
10. Click Finish, and wait for Outlook to open.

11. In the First things first window, click Ask me later, and click Accept.
12. After Outlook opens, click New Email. In the Untitled Message (HTML) window, click To.
13. Verify that the user can only see users and groups in the TreyResearch OU.
14. Click Trey_SalesMgrs and click To, and then click OK.
15. Type a subject of test and short email message and then click Send.
16. Click the Calendar icon.
17. Click New Meeting.
18. In the Untitled Meeting window, click To.
19. Click Cindy White, and click Required.
20. Under Address Book, click TreyResearchRooms. Click TR_Room1 and click Resources. Click OK.
21. In the Untitled Meeting window, pick a time tomorrow in the Start time box.
22. Type a subject of test meeting and short message and click Send.
23. Review the Meeting Response message and close the message.
24. Open Internet Explorer, and connect to Https://lon-cas1.adatum.com/owa.

25. Sign in as Adatum\Aaron using the password Pa$$w0rd.
26. In the Outlook Web App window, click save.
27. In the Outlook Web App window, click the Settings icon in the top right corner, and click Options.
28. Under options, click groups.
29. Under distribution groups I belong to, click Join.
30. In the all groups dialog box, double-click Trey_SalesMgrs.
31. In the Trey_SalesMgrs dialog box, click Join.
32. Review the error message stating that the group is closed and click ok. Click close.
33. In the all groups dialog box, double-click TreyResearchNews.
34. In the TreyResearchNews dialog box, click Join.
35. Close the all groups dialog box, and verify that Aaron is now a member of the TreyResearchNews
distribution group. Close Internet Explorer.
36. In Outlook 2013, click New Email.
37. In the To box, type treyintegration@adatum.com. Type a subject and short message and click
Send.
38. Open Internet Explorer, and connect to Https://lon-cas1.adatum.com/owa.
39. Sign in as adatum\aidan using the password Pa$$w0rd. Click save.
40. In the Outlook Web App window, verify that Aidan received the message sent to the treyintegration
dynamic distribution group.
Results: In this exercise, you created an email address policy and address list for Trey Research. You also
created an address book policy for Trey Research and validated the deployment.
Exercise 3: Configure Public Folders for Trey Research

Task 1: Create the public folder mailbox
1.
On LON-CAS1, switch to EAC.
2.
In the Feature pane, click public folders.
3.
Click the public folder mailboxes tab, and then click new public folder mailbox.
4.
On the new public folder mailbox page, type PFMBX1 in the Name field.
5.
Under Organizational unit, click browse, click TreyResearch, and then click ok.
6.
Under Mailbox database, click browse, click TreyResearchDB and then click ok.
7.
Click save.
Task 2: Create the public folders

1.
Click public folders, and then click New public folder.
2.
On the new Public Folder page, in the Name field, type TreyResearch, and then click save.
3.
Click TreyResearch, and then click New public folder.
4.
In the new public folder window, in the Name field, type Research, and then click save.
Task 3: Configure public folder permissions

1.
Click Go to the parent folder.
2.
Verify that TreyResearch is listed in the folder list, select the folder, and then under Folder
permissions, click Manage.
3.
In the TreyResearch window, click Add.
4.
In the public folder permissions window, next to User, click browse.
5.
In the Select Recipient window, click TR_IT, and then click ok.
6.
Under Permission level, click Owner, and then click save.
7.
Select the Apply changes to this public folder and all its subfolders check box.
8.
In the TreyResearch window, click Add.
9.
In the public folder permissions window, next to User, click browse.
10. In the Select Recipient window, click AllTreyResearch, and then click OK.
11. Under Permission level, click Author, and then click save.
12. Click save and then click close.
Task 4: Validate the public folder deployment

1.
On LON-CL1, in Outlook 2013, open the Folders view.
2.
Verify that the Public Folders are listed in the left pane.
3.
Expand the Public Folders and verify that the TreyResearch and Research public folders are visible.
Note: It can take several minutes for the public folders to appear. If the public folders are
not visible, wait a few minutes, close Outlook 2013 and open it again. If the public folders still do
not appear, sign out on LON-CL1, sign in as Cindy using the password Pa$$w0rd, and open
Outlook 2013. Configure the Outlook profile, and verify the public folder are visible.
following steps:
1.
2.
3.
4.
5.
6.
7.
8.
Password: Pa$$w0rd
Results: In this exercise, you will have created public folder mailboxes for Trey Research and verified that
users can access the mailboxes.

L4-23
Module 4: Planning and Deploying Client Access Servers
Lab: Deploying and Configuring a Client

Access Server Role
Exercise 1: Configuring Certificates for the Client Access Server
Task 1: Make a certificate request on Exchange Server
1.
On LON-CAS1, open Internet Explorer, type https://lon-cas1.adatum.com/ecp, and press Enter.
2.
3.
In the EAC, in the left navigation pane, click servers.
4.
In the right pane, click certificates.
5.
Click on the + sign.
6.
In the Exchange Certificate Windows Internet Explorer window, in the new Exchange certificate
Wizard, select Create a request for a certificate from a certification authority, and then click
next.
7.
In the Friendly name for this certificate, type mail.adatum.com, and click next.
8.
On the page with the option for using wildcard certificates, do not make any changes, and click next.
9.
Click browse.
10. In the Select a Server window, click LON-CAS1, and click ok.
11. Click next.
12. On the next page, click Outlook Web App (when accessed from the Internet), and then click the
Edit icon.
13. In the Specify the domains for the above Access type, enter mail.adatum.com, and click OK.
14. Repeat steps 12 and 13 for items where <not specified> is in the DOMAIN column.
15. Click next.
16. On the next page, make sure that you have the following names in the list: mail.adatum.com,
lon-cas1.adatum.com, AutoDiscover.Adatum.com, LON-CAS1, and Adatum.com, and then click
next.
17. On the next page, fill in the following fields as follows:
a.
b.
Department name: IT
c.
d.
State/Province: WA
e.
18. Click next.

19. On the next page, type \\lon-cas1\C$\windows\temp\certreq.req, and click finish.
Task 2: Issue a certificate from an internal CA
L4-24 Planning and Deploying Client Access Servers
1.
On LON-DC1, in Start, click Certification Authority.
2.
In certsrv [Certification Authority (Local)], right-click Adatum-LON-DC1-CA, point to All Tasks,

and then click Stop Service.
3.
Right-click Adatum-LON-DC1-CA, point to All Tasks, and then click Start Service.
4.
On LON-CAS1, open File Explorer, and navigate to C:\windows\temp.
5.
Right-click CertReq.req, and then click Open with.
6.
In the Windows dialog box, click Notepad.
7.
In the CertReq.req Notepad window, press Ctrl+A to select all the text, and then press Ctrl+C to
copy and save the text to the clipboard. Close Notepad.
8.
Click to the Start screen, and then click Internet Explorer.
9.
Connect to http://lon-dc1.adatum.com/certsrv.
10. Sign in as Administrator, using the password Pa$$w0rd.

11. On the Welcome page, click Request a certificate.
12. On the Request a Certificate page, click advanced certificate request.
13. On the Advanced Certificate Request page, click Submit a certificate request by using a base64-encoded CMC or PKCS#10 file, or submit a renewal request by using a base-64-encoded
PKCS#7 file.
14. 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.
15. In the Certificate Template drop-down list box, click Web Server, and then click Submit.
16. On the Certificate Issued page, click Download certificate.
17. In the File Download dialog box, click the arrow next to Save. Select Save As.
18. In the Save As dialog box, click Save.
19. In the Download complete dialog box, click Open.
20. 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.
21. On LON-CAS1, open File Explorer and create new folder called cert on the C:\ drive. Share the
folder, and give Read permission to Everyone.
22. Copy the file certnew.cer from C:\Users\Administrator.ADATUM\Downloads to C:\cert.
23. Close File Explorer.
Task 3: Assign a certificate to Exchange services

1.
On the LON-CAS1, switch to the EAC.
2.
Click servers, and then click certificates.
3.
Next to Select server, click LON-CAS1.Adatum.com.
4.
Click on mail.adatum.com, and then click on the toolbar and select import Exchange certificate.
5.
Type \\lon-cas1\cert\certnew.cer and click next.
6.
On the next page, click the + sign.
7.
Select LON-CAS1, and click add and then click ok.
8.
Click finish.
9.
Make sure that mail.adatum.com appears in the list.
10. Click on mail.adatum.com, and click the pencil icon on the toolbar.
11. Click services.
12. Select IIS, and click save.
Results: After completing this exercise, the students will have a certificate installed on the Exchange
Server Client Access server.
Exercise 2: Configuring Client Access Services Options

Task 1: Configure Client Access server options
1.
In the EAC, on LON-CAS1, click servers in the left pane.
2.
In the central pane, click virtual directories on the toolbar.
3.
In the Select server list, click LON-CAS1.Adatum.com.
4.
Click the mechanical key icon on the toolbar.
5.
In the configure external access domain window, click the + sign.
6.
Click on LON-CAS1, and click add-> button, and then click ok.
7.
In the text box below Enter the domain name, type mail.adatum.com, and click save.
8.
Click close after the operation completes.
9.
In the center pane, click servers.
10. Click on LON-CAS1, and then click the pencil icon on the toolbar.
11. Click on POP3 in the left navigation pane.
12. Set the Logon method to Secure TLS connection.
13. Scroll down, and select More options.
o
Set Maximum connections to 100.
Set Maximum connections from a single IP address to 20.
Set Maximum connections from a single user to 2.
14. Click save.

15. Click ok on the warning window.
Task 2: Verify authentication options on Client Access server

1.
On LON-CAS1, in the EAC, in the servers node, click virtual directories.
2.
Review the list of virtual directories for LON-CAS1.
3.
Click on the Autodiscover virtual directory, and then click the pencil icon on the toolbar.
4.
In the Virtual Directory Windows Internet Explorer window, click authentication.
L4-26 Planning and Deploying Client Access Servers
5.
Review the supported and selected options for authentication.
6.
Make no changes, and click cancel.
7.
Click on ecp virtual directory, and then click the pencil icon on the toolbar.
8.
Review the supported and selected options for authentication. Notice that no options are selected.
9.
Make no changes, and click Cancel.
10. Click on the PowerShell virtual directory, and then click the pencil icon on the toolbar.
11. In the Virtual Directory Windows Internet Explorer window, click Authentication.
12. Review the supported and selected options for authentication. Notice that no options are selected.
13. Make no changes, and click Cancel.
14. Click on the Microsoft-Server-ActiveSync virtual directory, and then click the pencil icon on the
toolbar.
15. In the Virtual Directory Windows Internet Explorer window, click Authentication.
16. Review the supported and selected options for authentication. Notice that the certificate
authentication options are present in this virtual directory.
18. Click on the OAB virtual directory, and then click the pencil icon on the toolbar.
19. In the Virtual Directory Windows Internet Explorer window, notice that there are no
authentication options for this virtual directory.
Results: After completing this exercise, the students will have configured Client Access server.
Exercise 3: Configuring Custom MailTips

Task 1: Configure MailTips
1.
On LON-CAS1, in the EAC, click recipients, and then click mailboxes.
2.
In the list of mailboxes, click on April Reagan, and then click on the Edit icon on the toolbar.
3.
In the April Reagan window, click MailTip.
4.
In the text box, type Test e-mail tip for April, and click save.
5.
From the Start screen, click Exchange Management Shell.
6.
Type the following, and then press Enter:

Set-Mailbox Identity Aidan Mailtip this is english mail tip MailtipTranslation
(FR: Cest la lague francaise)
7.
Close the Windows PowerShell window.
Task 2: Test MailTips

1.
Open Internet Explorer and type https://lon-cas1.adatum.com/owa.
2.
Sign in as Adatum\Don with the password of Pa$$w0rd.
3.
On the Language and time zone page, select English, and make no changes to time zone, and then
click Save.
4.
5.
Type April in the To field, and press Tab. Make sure that the field is populated with April Reagan.
6.
Click in the Subject field. Ensure that email tip has appeared.
7.
Click Discard, and click Discard again.
8.
9.
Type Aidan in the To field, and press Tab. Make sure that the field is populated with Aidan Delaney.
10. Click in the Subject field. Ensure that E-mail tip has appeared, and that it appears in English.
11. Sign out of OWA.
12. Sign in as Adatum\Amr with the password of Pa$$w0rd.
13. On the Language and time zone page, select Francais (France), and make no changes to time
zone, and then click Save.
14. In the Outlook Web App window, click nouveau message.
15. In A field type Aidan, and press Tab. Make sure that the field is populated with Aidan Delaney.
16. Click in the Objet field. Ensure that E-mail tip has appeared. and that it appears in French.
17. Click Ignorer, and click Ignorer again.
18. Sign out.
following steps:
1.
2.
3.
4.
5.
6.
7.

a. User name: Adatum\Administrator
b. Password: Pa$$w0rd
8.
repeat steps 5 to 7 for 20341B-LON-CAS1, 20341B-LON-TMG, and 20341B-LON-CL1.

L5-29
Module 5: Planning and Configuring Messaging Client

Connectivity
Lab: Planning and Configuring Messaging

Client Connectivity
Exercise 1: Planning Client Connectivity
Task 1: Read and analyze scenario requirements
Read the exercise scenario, and analyze the requirements from both a functionality and security
perspective. Identify the technologies that should be used.
Task 2: Propose a solution for client connectivity

1.
Which client platforms should you support for internal clients?
For internal clients, you must support the Windows 8 operating system, Outlook 2003, and Outlook
2010. However, since Outlook 2003 is not supported by Exchange Server 2013, it cannot be included
in your client connectivity plan.
2.
Which client platforms should you support for external clients?
For external clients, you must support Windows 8 and Outlook 2010 for mobile computers, along
with Windows Phone 7.5, Windows Phone 8, iOS5 and Android 4.0 mobile platforms.
3.
What concerns do you have regarding internal clients?
The biggest concern for internal clients is the fact that there is no unique email client software on
client computers.
4.
What concerns do you have regarding external clients?

The biggest concern for external clients is security. You have to support multiple platforms
connecting from various locations while maintaining security requirements.
5.
How will you address the requirement for client connection encryption?
Client connections to the Client Access server will be encrypted by using SSL.
6.
What solution will you propose for internal clients?
Outlook 2010 clients are supported by default. However, clients that are running Outlook 2003
cannot connect to Exchange Server 2013. For these clients, and for clients without Outlook software,
you can propose two solutions:
7.
a.
Use the Outlook Web App interface to access their mailboxes.
b.
Use the built-in email client in Windows 8 to access their mailboxes by using the ActiveSync
protocol.
What solution will you propose for external clients?
External clients with mobile computers will be using Outlook Anywhere, while clients without mobile
computers can use the Outlook Web App interface. Clients with smartphones can connect by using
the ActiveSync protocol if the device operating system supports it.
8.
How will you address the requirements for attachment downloading on public computers?
Clients that are connecting from public computers will be using Outlook Web App. To prevent them
from downloading and saving attachments, you can implement Outlook Web App Policy.
9.
How do you plan to force security requirements to mobile devices?
L5-30 Planning and Configuring Messaging Client Connectivity
Security requirements for mobile devices can be enforced by implementing ActiveSync policies.
Windows Phone, iOS 5, and Android 4.0 support ActiveSync policies. However, you should check if
Symbian devices can support ActiveSync policies; if they cannot, they might not be able to connect.
10. How do you plan to deploy the A. Datum Root CA certificate to client devices (both computers and
smartphones)?
The Root CA certificate is deployed to client computers by using Group Policy. If A. Datum has
an enterprise CA implemented, this is done by default. If it is a standalone CA, you can deploy it
manually in GPO. For mobile devices, you can use configuration utilities to distribute certificates,
or you can send a Root CA certificate file in an email to all users with a smartphone, along with
instructions on how to import it.
11. Is there a way to control hardware features of mobile devices?
Exchange Server 2013 does not support policies for hardware control on mobile devices.
12. Can you implement certificate-based authentication for mobile devices?
Currently, certificate-based authentication is selectively supported. You should check with mobile
platform vendors to see if this feature is supported.
13. How will you implement the requirement for deleting content from a lost mobile device?
For deleting the content on a lost mobile device, you should train users on how to use the Remote
Wipe functionality available in the Exchange Outlook Web App interface.
Task 3: Discuss your solution with the class
Present your proposed solution. Discuss alternative solutions with the other students and the
instructor.
Results: After completing this exercise, the students will have created a plan for client connectivity.
Exercise 2: Configuring Outlook Web App and Outlook Anywhere

Task 1: Configuring Outlook Web App policies
1.
On LON-CAS1, on the Start screen click Internet Explorer.
2.
Browse to https://lon-cas1.adatum.com/ecp.
3.
4.
In the EAC window, click permissions in left navigation pane.
5.
In the central pane, click Outlook Web App policies.
6.
Click the New icon.
7.
In the new Outlook Web App mailbox policy, in the Policy name text box, type External Users
Policy.
8.
In the Communication management section, clear the Instant messaging and Text messaging
check boxes.
9.
Scroll down and click More options.
10. In the Information management section, clear the Recover deleted items check box.
11. In the Public or shared computer section, clear the Direct file access check box.
12. Click save.
13. In the EAC console, click recipients.
14. Double-click Adam Barr.
15. In the Adam Barr window, click mailbox features in the left navigation pane. In the warning dialog
box, click ok.
16. In the right pane, scroll down to Email Connectivity section, and click View details.
17. In the Outlook Web App mailbox policy window, click browse.
18. Select External Users Policy and click ok, and then click save two times.
19. Click to the Start menu and then click Exchange Management Shell.
20. Type following command: Set-CASMailbox identity Aidan@adatum.com
OwaMailboxPolicy:External Users Policy, and press Enter.
21. In Internet Explorer, in the Exchange admin center, click recipients and then in the central pane
double-click user Brad Sutton.
22. In the Brad Sutton window, on general tab, click More options.
23. In the Custom attributes section, click Edit.
24. In the 1: text box type external and click ok, and then click save.
25. Repeat steps 21 to 24 for users Chad Niswonger and Daniel Durrer.
26. Switch to Exchange Management Shell and type : get-mailbox filter {CustomAttribute1 eq
external} | Set-CASMailbox -OwaMailboxPolicy: External Users Policy, and press Enter.
27. Switch back to the EAC.
28. Double-click on Brad Sutton.
29. In the Brad Sutton window, click mailbox features.
30. In the right pane, scroll down to the Email Connectivity section and click View details.
31. Ensure that External Users Policy is applied.
32. Click cancel two times.
33. Repeat the steps 28 to 32 for users Chad Niswonger and Daniel Durrer.
Task 2: Configuring Outlook Anywhere

1.
On LON-CAS1, in Exchange admin center, click servers in the left navigation pane.
2.
In the central pane, double-click LON-CAS1.
3.
In the LON-CAS1 window, click Outlook Anywhere.
4.
In the first text box, type mail.adatum.com.
5.
Make sure that second text box has the value lon-cas1.adatum.com, and that the third one has a
value Negotiate.
6.
Select NTLM in the third option.
7.
Click save.
Task 3: Enabling and using Offline Outlook Web App
1.
On LON-CL1, click to the desktop, open Internet Explorer and type https://lon-cas1.adatum.com
/owa.
2.
Sign in as Adatum\Aidan with the password Pa$$w0rd. Click save.
3.
In Outlook Web App window, open the Settings menu next to the user name in the right corner of
the browser, click Offline settings and then click Turn on offline access, and then click OK.
4.
Click Next twice, and then press Ctrl+D.
5.
In Add a favorite dialog box, click Add.
6.
Sign out from Outlook Web App and close Internet Explorer.
7.
On your host, open Hyper-V Manager.
8.
Right-click the 20341B-LON-CL1 machine, and choose Settings.
9.
Click on Network Adapter, and then in the Network drop-down box, select Not connected.
10. Click OK. By doing this you temporarily disconnect your client from the network.
11. Switch to the 20341B-LON-CL1 virtual machine.
12. Open Internet Explorer, and from the Favorites menu, choose Aidan Delaney - Outlook
Web App.
13. When the Outlook Web App window opens, verify that you can access mailbox content.
14. Send a test email to the administrator@adatum.com.
15. On your host, switch to Hyper-V Manager.
16. Right-click the 20341B-LON-CL1 machine and choose Settings.
17. Click on Network Adapter, and then in the Network drop-down box, select Private Network.
Click OK.
18. Wait for 20 to 30 seconds, and then refresh the Outlook Web App window. If a Security Alert
window appears, click Yes, and refresh the Outlook Web App window.
19. On LON-CAS1, open https://lon-cas1.adatum.com/owa, and sign in as Administrator.
20. Verify that you received the email from Aidan that was sent from the offline Outlook Web App.
Results: After completing this exercise, students will have Outlook Web App and Outlook Anywhere
configured.
Exercise 3: Configuring Exchange ActiveSync

Task 1: Plan a mobile device deployment
Because many different device platforms will be accessing your Exchange Server, what are your main
concerns?
The main concern regarding the different device platforms will be their ability to support Exchange
policies. From security perspective, it is required that you can force the password requirements to
mobile devices.
How will you achieve the requirement that settings be consistent on each mobile device?
You can implement a mobile-device mailbox policy to achieve consistent settings.
How will you implement the password requirements on your mobile device?
You will enforce password requirements to all devices that connect to your Exchange by
implementing appropriate policy.
How will you implement the requirements for quarantine?
Requirements for quarantine can be implemented by configuring mobile device access options in the
Exchange Administration Center.
Task 2: Configure mailbox policies for mobile devices

1.
On LON-CAS1, switch to Internet Explorer and in the EAC, click mobile, and then click mobile
device mailbox policies.
2.
Click the New icon.
3.
In the new mobile device mailbox policy window, type Adatum Mobiles for the policy name.
4.
Select the This is the default policy check box.
5.
Do not select the Allow mobile devices that dont fully support these policies to synchronize
check box.
6.
Select the Require a password check box.
7.
Select the Require an alphanumeric password check box.
8.
Select 2 in the drop-down box called Password must include this many character sets.
9.
Select the Minimum password length check box, and type 5 in the text box.
10. Select the Number of sign-in failures before device is wiped check box, and type 4 in the text box.
11. Select the Require sign-in after device has been inactive for, check box and type 5 in the text box.
12. Click save.
Task 3: Configure device access rules

1.
On LON-CAS1, in the EAC, click mobile, and then click mobile device access.
2.
Click the edit button.
3.
In the Exchange ActiveSync access settings window, click Quarantine Let me decide to block or
allow later.
4.
In the Quarantine Notification Email Messages section, click the Add icon.
5.
In the Select Administrators window, select Administrator, click add, and then click ok.
6.
In the text box below, type the following text: Your device is temporary in quarantine. The
Administrator will examine your request and will allow or block your connection according to
the policy.
7.
Click save.
8.
In the Device Access Rules pane, click the New icon.
9.
In the new device access rule, in the Device family section, click browse.
10. In the Device Family window, click All families, and then click ok.
11. Under the Only this model section, click browse. Verify that no devices are listed, and then click
cancel. In a production environment, you could expect to see several models listed here.
12. In the new device access rule window, click Quarantine Let me decide to block or allow later.
13. Click cancel.
Results: After completing this exercise, the students will have configured mobile device options and
policies.
Exercise 4: Publishing Exchange Server 2013 Through TMG 2010

Task 1: Publish Exchange web-based services through TMG 2010
1.
On LON-CAS1, open Windows PowerShell from taskbar, and type mmc.exe and then press Enter.
2.
In the Console1 window, open the File menu and then click Add/Remove Snap-in.
3.
Click Certificates and then click Add. Select Computer account and click Next.
4.
Select Local computer, and then click Finish. Click OK.
5.
Expand Certificates, expand Personal, and then click on Certificates.
6.
Right-click the certificate Webmail.adatum.com, navigate to All Tasks, and select Export.
7.
On the Welcome page, click Next.
8.
On the Export Private Key page, select Yes, export the private key and click Next.
9.
On the Export File Format page, click Next.
10. On the Security page, select Password and type Pa$$w0rd in both fields. Click Next.
11. On the File to Export page, type C:\CAS1.pfx as the file name, and then click Next.
12. Click Finish. In the pop window click OK. Close Console1 and click No to the Save console settings
to Console1? prompt.
13. Switch to LON-TMG machine.
14. On LON-TMG, click Start. In the Search box, type MMC, and then press Enter.
15. On the File menu, click Add/Remove Snap-in.
16. On the Add or Remove Snap-in page, click Certificates, and then click Add.
17. Click Computer account, click Next, click Finish, and then click OK.
18. Expand Certificates, right-click Personal, point to All Tasks, and then click Import.
19. On the Certificate Import Wizard page, click Next.
20. On the File to Import page, type \\LON-CAS1\C$\CAS1.pfx, and then click Next.
21. On the Password page, type Pa$$w0rd in the Password field, and then click Next.
22. On the Certificate Store page, click Next, and then click Finish.
23. Click OK, and then close Console1 without saving changes.
24. On LON-TMG, click Start, point to All Programs, click Microsoft Forefront TMG, and then click
Forefront TMG Management.
25. Expand Forefront TMG (LON-TMG), and then click Firewall Policy.
26. On the Firewall Policy Tasks pane, on the Tasks tab, click Publish Exchange Web Client Access.
27. On the Welcome to the New Exchange Publishing Rule Wizard page, type OWA Rule, and then
click Next.
28. 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.
29. On the Publishing Type page, click Next.
30. 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.
31. On the Internal Publishing Details page, in the Internal site name text box, type
LON-CAS1.Adatum.com, and then click Next.
32. 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 webmail.Adatum.com, and then
click Next.
33. On the Select Web Listener page, click New.
34. On the Welcome to the New Web Listener Wizard page, type HTTPS Listener, and then click
Next.
35. On the Client Connection Security page, ensure that Require SSL secured connections with
clients is selected, and then click Next.
36. On the Web Listener IP Addresses page, select the External check box, and then click Next.
37. On the Listener SSL Certificates page, click Select Certificate.
38. In the Select Certificate dialog box, click Webmail.adatum.com, click Select, and then click Next.
39. On the Authentication Settings page, accept the default of HTML Form Authentication, and then
click Next.
40. On the Single Sign On Settings page, type Adatum.com as the single sign-on (SSO) domain name,
click Next, and then click Finish.
41. On the Select Web Listener page, click Next.
42. On the Authentication Delegation page, accept the default of Basic authentication, and then click
Next.
43. On the User Sets page, accept the default, and then click Next.
44. On the Completing the New Exchange Publishing Rule Wizard page, click Finish.
45. Click Apply twice to apply the changes, and then click OK when the changes have been applied.
46. Switch to the LON-CAS1 machine.
47. Switch to Internet Explorer and in the EAC, click servers in Feature pane.
48. Click virtual directories tab.
49. On the virtual directories tab, double-click owa (Default Web Site) LON-CAS1.
50. In the External URL box, type https://webmail.adatum.com/owa.
51. Click authentication, and then click Use one or more standard authentication methods, and then
select the Basic Authentication check box, and click save. Read the information on the window that
appears, and click ok.
52. On the virtual directories tab, double-click ecp (Default Web Site) LON-CAS1.
53. In the External URL box, type https://webmail.adatum.com/ecp.
54. Click authentication, and then click Use one or more standard authentication methods, and then
select the Basic Authentication check box, and click save.
55. Click yes on the warning window. Click ok.
56. Open the Windows PowerShell. At the PS prompt, type IISReset /noforce, and then press Enter.
57. Wait until IIS service restarts.
58. Switch back to LON-TMG machine.
59. In the Forefront TMG console, double-click OWA rule.
60. In the OWA rule properties windows, click on the Application Settings tab.
61. In the Published server logoff URL, type /owa/logoff.owa. (Note: you are doing this because TMG
2010 does not have publishing rule for Exchange 2013 so logoff page still direct users to old location
used by Exchange Server 2010.)
62. Click OK and then click Apply two times.
63. Click OK.
64. Double-click OWA rule.
65. On the General tab, click Test Rule.
66. In Web Publishing Rule Test Results window, look for results for
https://webmail.adatum.com:443/ecp and https://webmail.adatum.com:443/owa. You should
have green check marks for these URLs. Click Close, and then click OK.
Task 2: Publishing rule testing

1.
On the host computer, in Hyper-V Manager, right-click 20341B-LON-CL1, and then click Settings.
2.
Click Network Adapter, and in the Network drop-down list, click Private Network 2, and then
click OK.
3.
Log on to LON-CL1 as Adatum\Administrator with password Pa$$w0rd.
4.
On LON-CL1, in the Start screen, type control panel. Click on the Control Panel icon.
5.
Open the Control Panel, and then click View network status and tasks.
6.
Click Change adapter settings.
7.
Right-click Ethernet, and then click Properties.
8.
Click Internet Protocol Version 4 (TCP/IPv4), and then click Properties.
9.
Change the IP address to 131.107.0.2, change the Default Gateway to 131.107.0.1.
10. Delete the value for DNS server.

11. Click OK, and then click Close. Close the Control Panel.
12. On the Start screen, type cmd and press Enter.
13. In the command prompt window, type notepad c:\windows\system32\drivers\etc\hosts, and then
press Enter.
14. At the bottom of the hosts file, type 131.107.0.1 webmail.adatum.com, and then save and close the
file.
15. Open Internet Explorer, and then connect to https://webmail.adatum.com/owa.
16. Log on as adatum\administrator using the password Pa$$w0rd, and then verify that you access the
user mailbox.
17. In the Outlook Web App window, click Settings and then click Options. Verify that you can connect
to the options of your mailbox.
following steps:
1.
2.
3.
4.
Repeat steps 2 to 3 for 20341B-LON-CAS1, 20341B-LON-MBX1, 20341B-LON-TMG, and

20341B-LON-CL1.
5.
6.
7.
8.
9.
a.
b.
Password: Pa$$w0rd
a.
b.
c.
d.
e.
f.
g.
repeat steps 5 to 7 for 20341B-LON-MBX2, 20341B-LON-CAS1, and 20341B-LON-CAS2.
Results: After completing this exercise, students will have Exchange Server 2013 published through TMG
2010.

L6-39
Module 6: Planning and Implementing High Availability

Exercise 1: Creating and Configuring a Database Availability Group
Task 1: Pre-stage the cluster network object for a DAG
1.
On LON-DC1, in Server Manager, click Tools, and then click Active Directory Users and Computers.
2.
In Active Directory Users and Computers, on the menu bar, click View, and then click Advanced
Features.
3.
In the left pane, expand Adatum.com, click Computers, then right-click Computers, point to New,
and then click Computer.
4.
In the New Object Computer dialog box, in the Computer name field, type DAG1, and then
click OK.
5.
In the right pane, right-click DAG1, and then click Properties.
6.
In the DAG1 Properties dialog box, click the Security tab.
7.
On the Security tab, click Add, and in the Enter the object names to select field, type Exchange
Trusted Subsystem. Click Check Names, and then click OK.
8.
On the Security tab, click Add, and then click Object Types.
9.
In the Object Types dialog box, click Computers, and then click OK.
10. In the Select Users, Computers, Service Accounts, or Groups window, in the Enter the object
names to select field box, type LON-MBX1$, then click Check Names, and then click OK.
11. On the Security tab, select LON-MBX1 (ADATUM\LON-MBX1$), then in the Allow column in the
Permissions for LON-MBX1 list, click Full control.
12. On the Security tab, select Exchange Trusted Subsystem (ADATUM\Exchange Trusted
Subsystem), then in the Allow column in the Permissions for Exchange Trusted Subsystem list,
click Full control, and then click OK.
13. In the Active Directory Users and Computers window, in the right pane, right-click DAG1, and then
click Disable Account.
14. In the warning window, click Yes, and then on the next information window, click OK.
Task 2: Create a DAG and add mailbox servers to the DAG

1.
Switch to LON-CAS1. Open Internet Explorer, and type https://lon-cas1.adatum.com/ecp, and

then press Enter.
2.
3.
In the EAC, in the Feature pane, click servers.
4.
On tabs, click database availability groups, and then on the toolbar, click New.
5.
In the New database availability group window, in the Database availability group name field,
type DAG1, then click Witness server, and type LON-CAS1 in the Witness server field. Click
Witness directory, in the Witness directory field, type C:\FSWDAG1, click Enter an IP address, in
Database availability group IP addresses field, and type 172.16.0.33. Then click Add, and then
click save.
6.
In the list view, click DAG1, and on the toolbar, click Manage DAG membership.
L6-40 Planning and Implementing High Availability
7.
In the manage database availability group membership window, click Add.
8.
In the Select Server window, click LON-MBX1, click add, and then click LON-MBX2. Click add, and
then click ok.
9.
In the manage database availability group membership window, click save.
10. In the Saving completed successfully window, click close.
Task 3: Create a mailbox database copy

1.
In the EAC, in tabs, click databases, then click Mailbox Database 1 on the toolbar, click More, and
then click Add database copy.
2.
In the add mailbox database copy window, click browse.
3.
In the Select Server window, click LON-MBX2, and then click ok.
4.
In the add mailbox database copy window, click save.
5.
Wait until the saving completes successfully, then click close.
Task 4: Verify successful completion of copying a database

1.
In tabs, click Refresh, and wait until the details pane shows Mailbox Database 1\LON-MBX2 as
Passive Healthy. This might take several minutes and up to several hours depending on the size of
the database.
2.
In the details pane, under Mailbox Database 1\LON-MBX2, click View details.
3.
Make sure that the Status displays Healthy and the Content index state also displays Healthy. Then
click cancel. Note that this might take some time, so please wait.
Task 5: Suspend and resume a database copy

1.
In the EAC, in the details pane, click Mailbox Database 1, and then under Mailbox Database
1\LON-MBX2, click Suspend.
2.
In the Suspend database window, in the Comments field, type Test Suspend, and then click save.
Now the database copy is suspended and will not receive any updates.
3.
In the details pane, under Mailbox Database 1\LON-MBX2, click Resume. If the Resume button is
not available, wait and then click Refresh a few more times.
4.
In the warning window, click yes.
5.
In tabs, click Refresh, and then wait until the details pane shows Mailbox Database 1\LON-MBX2 as
Copy queue length: 0.
Results: After completing this exercise, students will have pre-staged a cluster network object in Active
Directory, created a DAG, added two Mailbox servers to the DAG, and made a database highly available.
Students also will have suspended a database copy and resumed it.
Exercise 2: Deploying Highly Available Client Access Servers

Task 1: Install the Network Load Balancing feature on Client Access servers
1.
Switch to LON-CAS1.
2.
Click the Server Manager icon on the taskbar to open Server Manager.
3.
Click Add roles and features.
4.
In the Add Roles and Features Wizard, on the Before you begin page, click Next.
5.
On the Select installation type page, click Next.
6.
On the Select destination server page, make sure that Select a server from the server pool is
7.
On the Select server roles page, click Next.
8.
On the Select features page, click Network Load Balancing, and in the Add Roles and Features
Wizard window, click Add Features, and then click Next.
9.
On the Confirm installation selections page, click Install.
10. In the Add Roles and Features Wizard, wait until the feature installation has succeeded, and then click
Close.
11. Switch to the LON-CAS2 virtual machine.
12. Click the Server Manager tile.
13. Click Add roles and features.
14. In the Add Roles and Features Wizard, on the Before you begin page, click Next.
15. On the Select installation type page, click Next.
16. On the Select destination server page, make sure that Select server from the server pool is
17. On the Select server roles page, click Next.
18. On the Select features page, click Network Load Balancing. In the Add Roles and Features
Wizard window, click Add Features, and then click Next.
19. On the Confirm installation selections page, click Install.
20. In the Add Roles and Features Wizard, wait until the feature installation has succeeded, and then
click Close.
Task 2: Create a load-balanced Client Access server cluster

1.
Switch to LON-CAS1, and in Server Manager, on the menu bar, click Tools, and then in the Tools
drop-down list, select Network Load Balancing Manager.
2.
In the Network Load Balancing Manager, on the menu bar, click Cluster, and then click New.
3.
In the New Cluster: Connect dialog box, type LON-CAS1 in the Host field, click Connect, and then
click Next.
4.
In New Cluster: Host Parameters dialog box, click Next.
5.
In New Cluster: Cluster IP Address dialog box, click Add.
6.
In the Add IP Address dialog box, type 172.16.0.6 as the IPv4 address, type 255.255.0.0 as the
Subnet mask, and then click OK.
7.
In the New Cluster: Cluster IP Address dialog box, click Next.
8.
In the New Cluster: Cluster Parameters dialog box, type webmail.adatum.com in the Full Internet
name box, and then click Next.
9.
In New Cluster: Port Rules dialog box, click Finish.
10. In Network Load Balancing Manager, wait until the LON-CAS1 icon turns green.
11. In the left pane, right-click Webmail.adatum.com (172.16.0.6), and then click Add Host To
Cluster.
12. In the Add Host to Cluster: Connect dialog box, type LON-CAS2 in Host field, click Connect, and
then click Next.
13. In the Add Host to Cluster: Host Parameters dialog box, click Next.
14. In the Add Host to Cluster: Port Rules dialog box, click Finish.
15. In Network Load Balancing Manager, wait until the LON-CAS2 icon turns green, and the Status says
Converged.
Task 3: Create a DNS record for the virtual IP address

1.
Switch to LON-DC1, and in Server Manager, click Tools, and then click DNS.
2.
In the DNS Manager, in the left pane, expand Forward Lookup Zones, select and then right-click
Adatum.com, and then click New Host (A or AAAA).
3.
In the New Host dialog box, in Name field type Webmail, in the IP address field, type 172.16.0.6,
and then click Add Host.
4.
Click OK, and then click Done.
Results: After completing this exercise, the students will have installed and configured NLB, and created a
DNS record for their load-balanced virtual IP address.
Exercise 3: Testing the High-Availability Configuration

Task 1: Simulate failure on LON-CAS1 and verify Microsoft Outlook Web Access
functionality
1.
Switch to LON-CAS1, then in Network Load Balancing Manager, in the left pane, right-click
LON-CAS1(Ethernet), click Control Host, and then click Stop.
2.
Switch to LON-DC1, open Internet Explorer and type https://webmail.adatum.com/owa, and

then press Enter.
3.
In Outlook Web App, sign in as Adatum\administrator with the password Pa$$w0rd.
4.
You should now see your Inbox. This indicates that LON-CAS2 is currently serving as the Client Access
server.
Task 2: Enable LON-CAS1 and simulate a LON-CAS2 failure

1.
Switch to the LON-CAS1 virtual server, in Network Load Balancing Manager, in the left pane, rightclick LON-CAS1 (Ethernet), click Control Host, and then click Start.
2.
In Network Load Balancing Manager, wait until the LON-CAS1 (Ethernet) icon turns green, and the
Status says Converged.
3.
Switch to the Host machine, in Hyper-V Manager, right-click 20341B-LON-CAS2, and then click
Turn Off. Click Turn Off.
4.
Switch to the LON-DC1 virtual machine. In Internet Explorer, click Refresh (F5).
5.
In Outlook Web App, if the sign in page appears, sign in as Adatum\administrator with the
password Pa$$w0rd.
6.
In Outlook Web App, in the left pane click, Sent Items to make sure Outlook Web App is still
working. This verifies that LON-CAS1 took over the Client Access server role for the client.
Task 3: Verify high availability of the database copies

1.
Switch to LON-CAS1, and in the EAC, click servers, and then on tabs, click databases.
2.
In list view, click Mailbox Database 1, and in the details pane, verify that Mailbox Database
1\LON-MBX1 is Active Mounted and Mailbox Database 1\LON-MBX2 is Passive Healthy.
3.
Switch to the Host machine, in Hyper-V Manager, right-click 20341B-LON-MBX1, and then click
Turn Off. Click Turn Off.
4.
Switch to the LON-CAS1 virtual machine. In Internet Explorer, click Refresh (F5).
Note: If you receive an error in Internet Explorer, close it and reopen it and reconnect to
the EAC.
5.
In the EAC, if the sign-in page appears, sign in as Adatum\administrator with the password
Pa$$w0rd.
6.
In the EAC, in the Feature pane, click Servers.
7.
On tabs, click databases, and then in the list view, click Mailbox Database 1.
8.
Verify that in the details pane Mailbox Database 1\LON-MBX1 shows as Passive ServiceDown, and
Mailbox Database 1\LON-MBX2 shows as Active Mounted.
9.
Switch to the LON-DC1 virtual machine, and in Internet Explorer and Outlook Web App, in the left
pane, click Inbox. Create and send a new message to make sure the mailbox is available and can be
used.
following steps:
1.
2.
3.
4.
Repeat steps 2 to 3 for 20341B-LON-CAS1, 20341B-LON-CAS2, 20341B-LON-MBX1, and

20341B-LON-MBX2.
Note: Although some of the servers are not running, you must still revert them.
5.
6.
7.
8.
a.
b.
Password: Pa$$w0rd
Results: After completing this exercise, the students will have tested their high-availability configuration.

L7-45
Module 7: Planning and Implementing Disaster Recovery
Lab: Implementing Disaster Recovery for

Exchange Server 2013
Exercise 1: Backing Up Exchange 2013
Task 1: Populate a mailbox with Outlook Web App
1.
On LON-CAS1, open Internet Explorer. Type https://lon-cas1.Adatum.com/owa.
2.
Sign in as Adatum\michael with the password Pa$$w0rd.
3.
On the Language and Time zone page, click save.
4.
Click new mail.
5.
In the To section, type Mark Bebbington, and type Message before backup into the subject line.
6.
Click Send.
7.
8.
Sign in again as Adatum\mark with the password Pa$$w0rd.
9.
On the Language and Time zone page, click save.
10. Check that the message is received.

11. Sign out from Outlook Web App.
13. Switch to the Start screen, and click the Exchange Management Shell.
14. Type the following command, and press Enter:
Get-Mailbox mark@ADatum.com |fl name,database,guid
Notice the name and the GUID of the Mailbox Database. This is needed for the restore.
15. Close the Exchange Management Shell.
Task 2: Install Windows Server Backup

1.
On LON-MBX1, on the Start screen, click Server Manager.
2.
In the Dashboard, click Add roles and features. The Add Roles and Features Wizard opens.
3.
On the Before You Begin page, click Next.
4.
On the Installation Type page, select Role-based or feature-based installation, and click Next.
5.
On the Server Selection page, select Select a server from the server pool, click
LON-MBX1.Adatum.com in the Server Pool, and click Next.
6.
On the Server Roles page, click Next.
7.
On the Features page, scroll down in the Features list, select Windows Server Backup, and click
Next.
8.
On the Confirmation page, do not select the Restart the destination server automatically if
required option, and then click Install.
9.
On the Results page, click Close.
Task 3: Perform a backup of a mailbox database using Windows Server Backup
L7-46 Planning and Implementing Disaster Recovery
1.
On LON-CAS1, open File Explorer, and create a folder named Backup on drive C:\.
2.
Right-click the Backup folder, select Share with, and select Specific people.
3.
Check that the Administrator account has Read/Write permissions, and click Share. Click Done.
4.
5.
On LON-MBX1, on the Start screen, click Administrative Tools.
6.
Scroll down the tools list and double-click Windows Server Backup.
7.
In the left navigation pane, select Local Backup.
8.
In the Actions pane on the right side, click Backup Once.
9.
In the Backup Once Wizard on the Backup Options page, select Different options, and click Next.
10. On the Select Backup Configuration page, select Full server (recommended), and click Next.
11. On the Specify Destination Type page, select Remote shared folder, and click Next.
12. On the Specify Remote Folder page, under Location type \\LON-CAS1\Backup, under Access
control, select Do not inherit and click Next.
13. In the Windows Security pop-up window, enter Administrator as the name and Pa$$w0rd as the
password, and click OK.
14. On the Confirmation page, click Backup.
15. On the Backup Progress page, click Close.
16. When the backup completes, close Windows Server Backup. It may take 10 to 15 minutes to
complete.
Task 4: Delete message in mailbox

1.
On LON-CAS1, open Internet Explorer. Type https://lon-cas1.ADatum.com/owa.
2.
Sign in as Adatum\Mark with the password Pa$$w0rd.
3.
Delete the message received from Michael.
4.
Empty the Deleted Items folder.
5.
Right-click the Deleted Items folder and select recover deleted items.
6.
In the recover deleted items window, select the message received from Michael, and click purge.
7.
Click ok to confirm the purge action on the selected item.
8.
Close the recover deleted items window.
9.
Results: After completing this exercise, you have successfully backed up the mailbox databases.
Exercise 2: Restoring Exchange Server 2013 Data

Task 1: Restore the database using Windows Server Database
1.
On LON-MBX1, open File Explorer, and create a folder named Restore on drive C:\.
2.
On the Start screen, click Administrative Tools.
3.
Scroll down the tools list, and double-click Windows Server Backup.
4.
In the Actions pane, click Recover.
5.
In the Recovery Wizard on the Getting Started page, select A backup stored on another location,
and click Next.
6.
On the Specify Location Type page, select Remote shared folder, and click Next.
7.
On the Specify Remote Folder page, type \\LON-CAS1\Backup, and click Next.
8.
On the Select Backup Date page, select the date and time of the backup, and click Next.
9.
On the Select Recovery Type page, select Applications, and click Next.
10. On the Select Applications page, verify that Exchange is selected.

11. Select Do not perform a roll-forward recovery of the application database, and click Next.
12. On the Specify Recovery Options page, select Recover to another location, and click Browse.
13. In the Browse For Folder window, select the C:\Restore folder, and click OK. Click Next.
14. On the Confirmation page, click Recover.
15. On the Recovery Progress page, check that the status of the recovery is Completed, and click Close.
16. Close Windows Server Backup.
Task 2: Create a recovery database with the Exchange Management Shell

1.
On LON-MBX1, click to the Start screen, and then click Exchange Management Shell.
2.
In the Exchange Management Shell, execute the following command. This command identifies the
Mailbox Database 1 GUID, as well as the locations for the database and transaction log files.
Get-MailboxDatabase ID Mailbox Database 1 | fl name, guid, edbfilepath,
logfolderpath
3.
In the Exchange Management Shell, type the following command to create the Recovery database,
and press Enter. Verify that the GUID, database and transaction log names match the output from the
previous command.
New-MailboxDatabase Recovery Name RecoveryDB EdbFilePath C:\Restore\3c32c739a0ce-43bc-a299-2f56f2bcb20c\C_\Program Files\Microsoft\Exchange
Server\V15\Mailbox\Mailbox Database 1808842331\Mailbox Database 1808842331.edb
LogFolderPath C:\Restore\GUID\C_\Program Files\Microsoft\Exchange
Server\V15\Mailbox\Mailbox Database 1808842331 Server LON-MBX1
4.
At the Exchange Management Shell prompt, type the following command, and then press Enter.
Restart-service msexchangeis
5.
CD C:\Restore\3c32c739-a0ce-43bc-a299-2f56f2bcb20c\C_\Program
Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 1808842331
6.
Eseutil /r E00 /i /d
7.
Mount-Database RecoveryDB
8.
Get-MailboxStatistics -Database RecoveryDB
9.
This cmdlet displays all mailboxes within the recovery database. Check that the Mark Bebbington
mailbox is listed.
Task 3: Recover the mailbox from the recovery database

1.
New-MailboxRestoreRequest SourceDatabase RecoveryDB SourceStoreMailbox Mark
Bebbington TargetMailbox mark@adatum.com -SkipMerging StorageProviderForSource
2.
Get-MailboxRestoreRequest
3.
Repeat step 2 until the status is shown as Completed.
4.
On LON-CAS1, open Internet Explorer.
5.
Type https://lon-cas1.adatum.com/owa.
6.
Sign in as adatum\mark with the password Pa$$w0rd.
7.
Verify that the message has been restored.
8.
9.
Results: After completing this exercise, you will have successfully restored the missing items back into the
users mailboxes.
Exercise 3: Exchange Server 2013 Disaster Recovery (Optional)

Task 1: Installing Exchange Server 2013 in Recover Server mode
1.
On LON-DC1, from Server Manager, open Active Directory Users and Computers.
2.
In the console tree, click Computers.
3.
In the details pane, right-click the computer LON-CAS2, and then click Reset Account.
4.
Click Yes and then click OK.
5.
On your host, in Hyper-V Manager, click 20341B-LON-SVR1, and in the Actions pane, click Start.
6.
7.

o
User name: Administrator
Password: Pa$$w0rd
8.
On the Start screen, click Server Manager.
9.
In Server Manager, click Local Server in the console tree. Beside Ethernet, click the 172.16.0.30,
IPv6 Enabled.
10. Right-click Ethernet, and click Properties.

11. Click Internet Protocol Version 4 (TCP/IP v4), and click Properties.
12. Change the IP address to 172.16.0.21, and the Preferred DNS server to 172.16.0.10.
13. Click OK, click Close, and then close the Network Connections window.
14. Click the link next to Computer name in the Properties tile.
15. In the System Properties dialog box, on the Computer Name tab, click Change.
16. In Computer Name, type LON-CAS2. Under Member of, click Domain, and then type
adatum.com. Click OK.
17. When you are prompted for a user name and password, type Administrator and the password
Pa$$w0rd, and then click OK.
18. When you see a dialog box welcoming you to the adatum.com domain, click OK.
19. When you are prompted that you must restart the computer, click OK.
20. On the System Properties dialog box, click Close.
21. When you are prompted to restart the computer, click Restart Now.
22. All steps referring to LON-CAS2 should be performed on the renamed virtual machine (previously
LON-SVR1).
23. Sign in to LON-CAS2 as Adatum\Administrator with the password Pa$$w0rd.
24. In Hyper-V Manager, open the 20341B-LON-SVR1 settings, and attach the Exchange iso from
D:\Program Files\Microsoft learning\20341\Drives\ExchangeServer2013CU1.iso.
25. On LON-CAS2, open a Command Prompt as an administrator.
26. Type D:, and press Enter.
27. Type the following command and press Enter
Setup.exe /m:RecoverServer /Iacceptexchangeserverlicenseterms
28. After setup has finished, restart the server.
following steps:
1.
2.
3.
4.
Repeat steps 2 to 3 for 20341B-LON-CAS1, 20341B-LON-SVR1, and 20341B-LON-MBX1.
5.
6.
7.
8.
Password: Pa$$w0rd
Results: After completing this exercise, you will have successfully recovered LON-CAS2.

L8-51
Module 8: Planning and Configuring Message Transport
Lab: Planning and Configuring Message

Transport
Exercise 1: Configuring Message Transport
Task 1: Configure a Send connector to the Internet
1.
On LON-CAS1, open Internet Explorer and type https://lon-cas1.adatum.com/ecp, and press

Enter.
2.
3.
In the EAC, in the Feature pane, click mail flow.
4.
Click the send connectors tab.
5.
Click the New button.
6.
In the new send connector window, type Internet sending in the Name text box.
7.
Select Internet (For example, to send internet mail), and click next.
8.
On the next wizard page, make sure that MX record associated with recipient domain is selected,
and click next.
9.
On the next wizard page, click Add.
10. In the add domain window, in the Full Qualified Domain Name (FQDN) text box, type * and click
save, and then click next.
11. On the next wizard page, click Add.
12. Select LON-MBX1, and click the add-> button, and click ok.
13. Click finish.
Task 2: Configure a receive connector to accept relaying

1.
In the EAC, click the receive connectors tab.
2.
Click New.
3.
In the new receive connector window, type AppClient in the Name box, and select Client.
Click next.
4.
On the next page, click Remove to remove scope 0.0.0.0 255.255.255.255. Click Add.
5.
In the add IP address window, type 172.16.0.10, and click save.
6.
Click finish.
7.
Click on AppClient, and then click Edit.
8.
Click security.
9.
Select the Anonymous users check box, and click save.
Results: After completing this exercise, the students will have configured message transport.
Exercise 2: Troubleshooting Message Delivery

Task 1: Verify that messages from the Internet can be received
1.
2.
3.
4.

You should receive response: 250 2.1.0 Sender OK
5.
Type rcpt to: Aidan@adatum.com, and press Enter.

Response: 250 2.1.5 Recipient OK.
6.

7.
Type Test from Internet, and press Enter.
8.
Press the period (.) key, and then press Enter.
9.
Type Quit, and press Enter.
10. Switch to LON-CL1, and log on as Adatum\Aidan with the password Pa$$w0rd.
11. In Start, right-click Start, click All apps, and then click Outlook 2013.
12. In the Welcome to Microsoft Outlook 2013 Wizard, click Next three times and then click Finish.
13. If prompted about a certificate, in the Security Alert dialog box, click Yes.
14. In the First things first dialog box, click Ask me later and then click Accept.
15. Verify that you received a new message from info@internet.com.
16. Reply to the message with the text of your choice, and click Send.
Task 2: Troubleshoot message transport
L8-52 Planning and Configuring Message Transport
1.
On LON-MBX1, on the Start screen, click on Exchange Toolbox.
2.
In the Exchange Toolbox window, double-click Queue Viewer.
3.
In the Queue Viewer window, ensure that the internet.com domain is listed with one message in the
queue.
4.
Double-click on internet.com
5.
Right-click on the Aidan@adatum.com message, and select Remove (with NDR).
6.
Click OK in the Bulk Action window, and then click Yes.
7.
Switch to LON-CL1 machine, and ensure that you are still logged on as Aidan.
8.
In the Outlook 2013 window, ensure that you received non-delivery report for the message you sent
to info@internet.com.
Results: After completing this exercise, the students will have completed SMTP troubleshooting.
Exercise 3: Configuring Transport Rules and Data-Loss Prevention Policies

Task 1: Implementing and testing a disclaimer transport rule
1.
On LON-CAS1, in the EAC, click mail flow in the Feature pane.
2.
Click the rules tab.
3.
Click the New and then click Create a new rule.
4.
In the new rule window, in the Name text box, type Adatum Disclaimer.
5.
In the Apply this rule if drop-down box, select The sender is located option, and then in the select
sender location window, select Inside the organization, and then click ok.
6.
In the Do the following drop-down box, select Append the disclaimer.
7.
Click Enter text.
8.
In the specify disclaimer text, type This is the Adatum Disclaimer, and click ok.
9.
Click Select one, and then in the specify fallback action window, select Wrap and click ok.
10. Click More options.
11. Click the add exception button. In the Except if drop-down box, point to The sender and then click
is a member of this group.
12. In the Select Members window, click Administrator, and click add->. Then click ok.
13. Select the check box on the option Activate this rule on the following date and select tomorrows
date in drop-down box and then click save.
14. Switch to LON-CL1, and in Outlook 2013, click New Email.
15. In the To field, type administrator@adatum.com.
16. In the Subject field, type disclaimer test.
17. In the message body, type Test, and then click Send.
18. Open Internet Explorer, and type https://lon-cas1.adatum.com/owa.
19. In the Outlook Web App window, sign in as Adatum\Administrator with the password Pa$$w0rd.
20. In the Outlook Web App, ensure that you received an email from Aidan, and that the disclaimer text
is appended to the messages.
21. Reply to that message with any text.
22. Switch to Outlook 2013, and make sure that you received the message from Administrator, but
without the disclaimer.
Task 2: Create a Data-Loss Prevention policy

1.
On LON-CAS1, in the EAC, click compliance management in the Feature pane.
2.
Click on the data loss prevention tab.
3.
Click an arrow next to the + sign.
4.
Select New custom DLP policy.
5.
In the new custom DLP policy window, in the Name text box, type IP address block.
6.
Click Enforce, and then click save.
7.
Select the IP address block policy, and then click Edit.
8.
In the IP address block window, click rules.
9.
Click an arrow next to the + sign, and then select Block messages with sensitive information.
10. In the New Rule window, click Outside the organization. In the select recipient location window,
select Inside the organization, and click ok.
11. Click Select sensitive information types.
12. In the sensitive information types windows, click Add.
13. Scroll down the list and select IP Address, and then click add->. Then click ok two times.
L8-54 Planning and Configuring Message Transport
14. In the Do the following drop-down box, select Generate incident report and send it to, and then
click Select one.
15. In the list, select Administrator, and click ok.
16. Click Block the message.
17. In the notify the sender with a Policy Tip, type Your message is blocked in the Enter the
message for the NDR that users will receive text box, and click ok.
18. Click Include message properties, and in the Include message properties window, select the
original mail check box and then click ok.
19. Select the check box on the option Activate this rule on the following date, and then click save.
20. In the IP address block, click save.
Task 3: Verify data-loss prevention policy functionality

1.
Switch to LON-CL1, and switch to Outlook 2013.
2.
Click New Email.
3.
In the To field, type amr@adatum.com.
4.
In the Subject field, type block test.
5.
In the message body, type This is my IP address: 192.168.0.100, and then click Send.
6.
Wait for a few moments, and see if you receive an email with the message that your previous
message to Arm Zaki is undeliverable. Also ensure that Your message is blocked text appears.
Review the message content.
7.
Switch to Internet Explorer, and in the Outlook Web App window, ensure that you received an
email from Aidan and that the original message that Aidan sent to Amr is attached.
8.

following steps:
1.
2.
3.
4.
5.
6.
7.
8.
a.
b.
Password: Pa$$w0rd
Results: After completing this exercise, the students will have configured transport rules and data-loss
prevention policies.

L9-57
Module 9: Planning and Configuring Message Hygiene
Lab: Planning and Configuring Message

Security
Exercise 1: Configure Antimalware Options in Exchange Server 2013
Task 1: Enable antimalware features in Exchange Server 2013
1.
On LON-MBX1, on the Start screen click Exchange Management Shell.
2.
In the Exchange Management Shell, change current folder to \Program Files\Microsoft

\Exchange Server\V15\Scripts by typing the following cmdlet, and then press Enter.
cd \Program Files\Microsoft\Exchange Server\V15\Scripts
3.
In the Exchange Management Shell, enable antimalware scanning by typing following script, and then
press Enter.
4.
few minutes. Note that because the lab environment does not have an Internet connection, the
engine update cannot complete. Type CTRL-C to stop the script.
5.
In the Exchange Management Shell, restart the Microsoft Exchange Transport Service by typing
following cmdlet, and then press Enter.
6.
In the Exchange Management Shell, list installed transport agents by typing the following cmdlet, and
then press Enter.
Get-TransportAgent
7.
Verify that the following antimalware agent is listed: Malware Agent. Note that the status of
Malware Agent is Enabled True if the script was allowed to complete.
Task 2: Configure the default antimalware policy in Exchange Server 2013

1.
Switch to LON-CAS1.
2.
Move the mouse pointer to the lower right corner of the window, and then click on the Start charm.
3.
On the Start screen, click on the Internet Explorer tile.
4.
In Internet Explorer, type the following address in the address bar, https://lon-cas1.adatum.com
/ecp and then press Enter.
5.
Sign in to the EAC as Adatum\Administrator with the password Pa$$w0rd, and then click on the
sign in button.
6.
In the EAC, on the feature pane, click on protection.
7.
In the EAC window, on malware filter tab, click on the edit button on the toolbar.
8.
In the Default window, click on settings.
9.
Under Malware Detection Response, select Delete all attachments and use custom alert text.
L9-58 Planning and Configuring Message Hygiene
10. In the Custom alert text box, type the following text: The attachment has been deleted because it
contained malware. Contact your administrator.
11. Under Notifications, select both Notify internal senders and Notify external senders check boxes.
12. Under Administrator Notifications, select the Notify administrator about undelivered messages
from internal senders check box.
13. In the Administrator email address box, type administrator@adatum.com.
14. Under Administrator Notifications, select the Notify administrator about undelivered messages
from external senders check box.
15. In the Administrator email address box, type administrator@adatum.com.
16. In the Default window, click the save button.
Exercise 2: Configuring Anti-Spam Options on Exchange Server

Task 1: Enable anti-spam features on LON-MBX1
1.
Switch to LON-MBX1.
2.
In Exchange Management Shell, install anti-spam agents by typing following script and then press
Enter.
3.
In Exchange Management Shell, restart the Microsoft Exchange Transport Service by typing
following cmdlet and then press Enter.
4.
In Exchange Management Shell, specify the IP addresses of the internal SMTP servers LON-MBX1
and LON-MBX2 that should be ignored by the Sender ID agent, by typing following cmdlet and then
press Enter.
5.
In Exchange Management Shell, list installed transport agents by typing following cmdlet and then
press Enter.
Get-TransportAgent
6.
Verify that following anti-spam agents are listed: Content Filter Agent, Sender ID Agent, Sender
Filter Agent, Recipient Filter Agent, Protocol Analysis Agent. Verify that the status of anti-spam
agents is Enabled True.
Task 2: Configure content filtering on LON-MBX1

1.
In the Exchange Management Shell, verify that content filtering is enabled by typing the following
cmdlet, and then press Enter.
2.
3.
In Exchange Management Shell, configure the blocked phrase Poker results by typing the following
4.
In the Exchange Management Shell, configure the allowed phrase Report document by typing the
5.
In the Exchange Management Shell, configure the quarantine mailbox quarantine@adatum.com by

typing the following cmdlet, and then press Enter.
Set-ContentFilterConfig -QuarantineMailbox quarantine@adatum.com
Note: In a production environment, you should also create a user mailbox and configure it
to be a quarantine mailbox.
6.
In the Exchange Management Shell, configure SCL thresholds and enable quarantine by typing the
Set-ContentFilterConfig -SCLRejectEnabled $true -SCLRejectThreshold 8 SCLQuarantineEnabled $true -SCLQuarantineThreshold 7
7.
In the Exchange Management Shell, configure a custom rejection response by typing the following
Set-ContentFilterConfig -RejectionResponse "Your message was rejected by our spam
filter. Contact your administrator."
8.
In the Exchange Management Shell, configure the SCL junk threshold with value 6 for all mailboxes
in your organization by typing the following cmdlet, and then press Enter.
Set-OrganizationConfig -SCLJunkThreshold 6
Task 3: Configure sender and recipient filtering on LON-MBX1

1.
On LON-MBX1, in the Exchange Management Shell, configure sender filtering to block messages
from marketing@contoso.com by typing the following cmdlet, and then press Enter.
2.
In the Exchange Management Shell, configure recipient filtering to block messages sent to
helpdesk@adatum.com by typing the following cmdlet, and then press Enter.
Set-RecipientFilterConfig -BlockListEnabled $true -BlockedRecipients
helpdesk@adatum.com
Note: In this scenario, we assume that email the address helpdesk@adatum.com is for
internal purposes only, and should not receive email from external senders.
Exercise 3: Validating Antimalware and Anti-Spam Configuration

Task 1: Validate antimalware configuration
L9-60 Planning and Configuring Message Hygiene
1.
Switch to LON-CAS1.
2.
Edit the E:\Labfiles\Mod09\Eicar.txt file and remove the line breaks between the first line and the
subsequent text line. All of the text should be on one line. Save the file.
3.
If Internet Explorer is currently open, close it.
4.
Open Internet Explorer, and type https://lon-cas1.adatum.com/owa.
5.
Sign in as Adatum\Michael with the password Pa$$w0rd.
6.
On the Language and time zone page, make no changes to the time zone, and then click Save.
7.
8.
Type mark@adatum.com in the To field.
9.
Click in the Subject field, and type Test Message.
10. In the message body, type Daily report, click Insert, and then click Attachment.
11. In Choose File to Upload window, in the navigation pane, browse to E:\Labfiles\Mod09, doubleclick file EICAR.TXT, and then click Send.
12. In Outlook Web App window, click on Michael Allen, and then click Sign out.
13. In Internet Explorer, on the Outlook Web App logon page, sign in as Adatum\Mark with the
password Pa$$w0rd. Click Save.
14. In the Outlook Web App window, open the new message from Michael Allen. Double-click the
attachment, click Open and then click Open again.
15. Verify that the code that was in the file has been deleted and replaced by the custom text you
configured.
16. In the Outlook Web App window, click on Mark Bebbington, and then click Sign out.
Task 2: Validate anti-spam configuration

1.
Switch to LON-DC1.
2.
3.
4.
5.

You should receive the response: 250 2.1.0 Sender OK
6.
Type rcpt to: michael@adatum.com, and press Enter.

Response: 250 2.1.5 Recipient OK
7.

8.
Type Subject: Information for you and then press Enter twice.
9.
Type Please find below poker results, and press Enter.
10. Press the period (.) key, and then press Enter.
11. Verify that following message is displayed: Your message was rejected by our spam filter. Contact
your administrator. Type Quit, and press Enter.
When you finish the lab, revert the virtual machines to their initial state by performing the following steps:
1.
2.
3.
4.
Repeat steps 2 and 3 for 20341B-LON-CAS1 and 20341B-LON-MBX1.
5.
6.
7.
8.
a.
b.
Password: Pa$$w0rd
Results: After completing this exercise you should have validated antimalware scanning when sending
test message with malware simulation attachment, where the attachment will be deleted by the Exchange
Server 2013 antimalware feature. You should have also validated anti-spam content filtering when
sending a simulation of a spam message, where the message will be stored in the recipients junk email
folder by the Exchange Server 2013 content filtering feature.
L10-63
Module 10: Planning and Configuring Administrative

Security and Auditing
Lab: Configuring Administrative Security

and Auditing
Exercise 1: Configuring Exchange Server Permissions
Task 1: Configure Exchange server permissions for the IT administrators group
1.
On LON-MBX1, open Server Manager, click Tools, and then click Active Directory Users and
Computers.
2.
In the left pane, expand Adatum.com, click Microsoft Exchange Security Groups, and then on
right pane, double-click Server Management.
3.
In Server Management Properties, click the Members tab, and then click Add.
4.
In the Enter the object names to select field, type IT, and then click OK twice.
5.
Close Active Directory Users and Computers.
Task 2: Configure permissions for the Support Desk and HelpDeskAdmins groups
1.
2.
In the Exchange Management Shell, at the PS prompt, type the following command, and then press
Enter:
New-RoleGroup -Name HelpDeskAdmins -roles Mail Recipients
3.
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.
Click to the Start screen, and then click Internet Explorer, connect to
https://LON-CAS1.adatum.com/ecp. Sign in as Adatum\Administrator using the password
Pa$$w0rd.
5.
In the EAC, in the feature pane, click permissions.
6.
On tabs, click admin roles, and then double-click SupportDesk in the list view.
7.
In the Role Group window, under Members, click Add.
8.
On the Select Members page, select Ryan Spanton, click add, and then click ok.
9.
In the Role Group window, click save.
10. In the list view, double-click HelpDeskAdmins.

11. In the Role Group window, under Members, click Add.
12. On the Select Member page, select Carol Troup, click add, and then click ok.
13. In the Role Group window, click save.
Task 3: Verify the permissions for the three role groups created
L10-64 Planning and Configuring Administrative Security and Auditing
1.
On LON-MBX1, open Internet Explorer, and connect to https://LON-CAS1.adatum.com/ecp. Sign

in as Adatum\Tony using the password Pa$$w0rd.
2.
In the feature pane, click servers.
3.
In tabs, click databases.
4.
In the list view, double-click Research.
5.
On the Mailbox database dialog box, in the left pane, click limits, then click the Issue a warning at
(GB) drop-down list, select unlimited, and then click save.
6.
In the feature pane, click unified messaging. Verify that you can see the UM dial plans, but not
create or modify them. Remember that Tony is part of the IT group, and therefore is able to modify
server properties but not unified messaging settings.
7.
8.
Open Internet Explorer, and connect to https://LON-CAS1.adatum.com/ecp. Sign in as

Adatum\Ryan using the password Pa$$w0rd. Recognize that in the feature pane, there are no
servers. This is because Ryan does not have permissions to manage servers.
9.
In the feature pane, click recipients.
10. In the list view, double-click Alan Steiner.

11. In the User Mailbox window, in the left pane, click organization.
12. In the Department field, type IT, and then click save.
13. In tabs, click groups.
14. In the list view, double-click Research. Verify that you cannot modify the group properties by typing
a group description and then click save.
15. An error window appears that shows you that you do not have sufficient permissions to modify the
group, click ok, and then in the Security Group window, click cancel.
16. In tabs, click mailboxes, and then click New in toolbar.
17. In the User Mailbox window, type Test in the Alias field, and then click New user.
18. Type Test in the First name field, and then type Test in Last name field. Type Test in the User
logon name field, and Pa$$word in the New password and Confirm password fields, and then
click save. This confirms that Ryan is able to create new mailboxes.
20. Open Internet Explorer, and connect to https://LON-CAS1.adatum.com/ecp. Sign in as
Adatum\Carol using the password Pa$$w0rd.
21. In the feature pane, click recipients. Note that there is no New user button on the toolbar.
22. In the list view, double-click Alan Steiner.
23. In the User Mailbox window, in the left pane, click organization.
24. In the Department field, type Customer Service, and then click save.
25. Verify that groups is not available in tabs as Carol does not have permission to manage groups.
Results: After completing this exercise, the students will have configured RBAC roles and verified that the
permissions are granted accordingly.
Exercise 2: Configuring Audit Logging

Task 1: Configure audit logging on the Info@Adatum.com mailbox
1.
2.
In the Exchange Management Shell, at the PS prompt, type the following:
Set-Mailbox -Identity "Info" -AuditDelegate SendAs,SendOnBehalf -AuditEnabled $true
3.
Minimize the Exchange Management Shell.
Task 2: Perform SendAs activity on the Info@Adatum.com mailbox

1.
Switch to LON-CAS1, open Internet Explorer, type https://LON-CAS1.adatum.com/owa, and then

press Enter.
2.
Sign in to the Outlook Web Access Application as Adatum\Tony using the password Pa$$w0rd.
3.
Click new mail to create a new message, click more options, and then click show from.
4.
Right-click From, click edit, and in the From field, type Info@adatum.com, and in the To field type
Tony Smith. In the Subject field type Testing Send As logging.
5.
In the message body, type some text, and then click Send. Verify that the message is sent.
6.
Task 3: Verify that the activity is logged

1.
On LON-MBX1, open Internet Explorer, and then type https://LON-CAS1.adatum.com/ecp.
2.
Sign in as Adatum\Administrator using the password Pa$$w0rd.
3.
In the EAC, in the feature pane, click compliance management.
4.
On tabs, click auditing.
5.
Click Run a non-owner mailbox access report.
6.
In the Search for access by drop-down box, select All non-owners, and then click Search.
7.
In the search results, click Info, and view the report that shows that Tony Smith accessed the Info
mailbox.
8.
Click close, and then close Internet Explorer.
Results: After completing this exercise, the students will have configured mailbox audit logging and
verified that audit logging works correctly.
Exercise 3: Configuring RBAC Split Permissions on Exchange Server 2013

Task 1: Create a new role group called HRAdmins, and assign permissions
1.
2.
In the Exchange Management Shell, at the PS prompt, type the following cmdlets, and then press
Enter.
New-RoleGroup "HRAdmins" -Roles "Mail Recipient Creation", "Security Group Creation
and Membership"
New-ManagementRoleAssignment -Role "Mail Recipient Creation" -SecurityGroup
"HRAdmins" -Delegating
New-ManagementRoleAssignment -Role "Security Group Creation and Membership" SecurityGroup "HRAdmins" -Delegating
3.
L10-66 Planning and Configuring Administrative Security and Auditing
In the Exchange Management Shell, at the PS prompt, type the following command, and then press
Enter.
Add-RoleGroupMember "HRAdmins" -Member Tony
4.
Open Server Manager, click Tools, and then click Active Directory Users and Computers.
5.
In the left pane, click Microsoft Exchange Security Groups, and then double-click HRAdmins.
6.
Click the Managed By tab, click Change and type HRAdmins, and then click OK.
7.
Select the Manager can update membership list check box, and then click OK.
8.
In the right pane, double-click Recipient Management.
9.
Click the Members tab, click Add and type HRAdmins, and then click OK. This is required to assign
the HRAdmins group the necessary permissions to be able to create a mailbox. Click OK.
10. Close the Active Directory Users and Computers console.
Task 2: Remove the permission to create AD DS objects from other Exchange Server
administrator groups
1.
On LON-MBX1, open the Exchange Management Shell.
2.

Get-ManagementRoleAssignment -Role "Mail Recipient Creation" | Format-Table Name,
Role, RoleAssigneeName Auto
3.
After you see which groups have delegated role assignments for this role, run the following cmdlet to
remove all groups except HRAdmins:
Get-ManagementRoleAssignment -Role "Mail Recipient Creation" | Where {
$_.RoleAssigneeName -NE "HRAdmins" } | Remove-ManagementRoleAssignment
4.
At the prompt, type A, and press Enter.
5.
Get-ManagementRoleAssignment -Role "Security Group Creation and Membership" | Where {

$_.RoleAssigneeName -NE "HRAdmins" } | Remove-ManagementRoleAssignment
6.
At the prompt, type A, and press Enter.
7.
Task 3: Validate RBAC split-permissions functionality

1.
On LON-MBX1, open Internet Explorer, connect to https://LON-CAS1.adatum.com/ecp. Sign in as

Adatum\Administrator using the password Pa$$w0rd.
2.
In the feature pane, click recipients.
3.
Click the mailboxes tab, click New in toolbar, and then click User mailbox.
4.
In the User Mailbox window, type New in the Alias field, and then click New user. Note that all
fields required to create a new user are greyed out. This is because you do not have the permission to
create a new user account in AD DS.
5.
Click cancel, and then close Internet Explorer.
6.
Open Internet Explorer, connect to https://LON-CAS1.adatum.com/ecp. Sign in as Adatum\Tony

using the password Pa$$w0rd.
7.
Click the mailboxes tab, click New in toolbar, and then click User mailbox.
8.
In the User Mailbox window, type Test2 in the Alias field, and then click New user.
9.
Type Test2 in First name field, and Test2 in Last name field. Type Test2 in the User logon name
field, and Pa$$word in the New password and Confirm password fields, and then click Save. This
confirms that Tony is able to create user accounts for new mailboxes.
following steps:
1.
2.
3.
4.
5.
6.
7.
8.
Password: Pa$$w0rd
Results: After completing this exercise, students will have created a new role group, configured RBAC split
permissions, and validated that RBAC split permissions are working as expected.
L11-69
Module 11: Monitoring and Troubleshooting Microsoft

Lab: Monitoring and Troubleshooting

Exercise 1: Monitoring Exchange Server
Task 1: Create a new data collector set named Exchange Monitoring
1.
On LON-MBX1, click on the Server Manager tile.
2.
In the Server Manager window, click on the Tools menu, and then click Performance Monitor.
3.
In the Performance Monitor window, in the navigation pane, expand Data Collector Sets, and then
click User Defined.
4.
Click the Action menu, click New, and then click Data Collector Set.
5.
In the Create new Data Collector Set Wizard, in the Name box, type Exchange Monitoring, select
Create manually (Advanced), and then click Next.
6.
Select the Performance Counter check-box, and then click Finish.
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, click Next, and then click Add.
3.
In the Available counters object list, expand Processor, and then click % Processor Time. Press and
hold the Ctrl key, click % User Time, click % Privileged Time, and then click Add.
4.
In the Available counters object list, expand Memory, and then click Available Mbytes. Press and
hold the Ctrl key, click the following items, and then click Add:
5.
Page Reads/sec
Pages Input/sec
Pages/sec
Pages Output/sec
Pool Paged Bytes
Transition Pages Repurposed/sec
In the Available counters object list, expand MSExchange ADAccess Domain Controllers, and
then click LDAP Read Time. Press and hold the Ctrl key, click the following items, and then click Add:
o
LDAP Search Time
LDAP Searches Timed Out per Minute
Long Running LDAP Operations/min
L11-70 Monitoring and Troubleshooting Microsoft Exchange Server 2013
6.
In the Available counters object list, expand System, click Processor Queue Length, click Add, and
then click OK.
7.
In the Create New Data Collector Wizard, in the Sample interval box, type 1, in the Units drop-down
list, select Minutes and then click Finish to create the data collector.
Task 3: Create a new performance-counter data collector set for monitoring Mailbox
server role performance
1.
In the 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, click Next, and then click Add.
3.
In the Available counters object list, expand LogicalDisk, and then click Avg.Disk sec/Read. Press
and hold the Ctrl key, click the following items, and then click Add:
4.
Avg.Disk sec/Transfer
Avg.Disk sec/Write
In the Available counters object list, expand MSExchangeIS Store, and then click RPC Average
Latency. Press and hold the Ctrl key, click the following items, and then click Add:
o
RPC Operations/sec
RPC Requests
Messages Delivered/sec
5.
Click OK.
6.
In the Create New Data Collector Wizard, in the Sample interval box, type 1 in the Units drop-down
list, select Minutes, and then click Finish to create the data collector set.
Task 4: Verify that the data collector set works properly

1.
In the Performance Monitor, in the navigation pane, click Exchange Monitoring, click the Action
menu, and then click Start.
2.
Wait 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
LON-MBX1_DateTime-Number, and then review the report.
4.
Close the Performance Monitor.
Results: After this exercise, you should have created a data collector set for monitoring LON-MBX1 that
uses the recommended performance counters.
Exercise 2: Troubleshooting Database Availability

Task 1: Identify the scope of the problem
1.
On LON-MBX1, open the Exchange Management Shell. At the prompt, type

c:\scripts\Lab11Prep1.ps1, and then press Enter. This script will simulate database failure.
2.
On LON-MBX1, if the Start screen is not displayed, move the mouse to the lower right corner of the
screen, click Start.
3.
On the Start screen, open Internet Explorer.
4.
In the Internet Explorer window, type https://lon-cas1.adatum.com/ecp, and then press Enter.
5.
On the Outlook Web App web page, in the Username box, type Adatum\Administrator. In the
Password box, type Pa$$w0rd and then click Sign In.
6.
On the Exchange Administration Center, on the feature pane, click on servers, and then click on the
databases tab.
7.
In the list view, click on MailboxDB100 database, and then in the details pane, verify that it is
Dismounted.
8.
In the toolbar, click More, and then click Mount.
9.
In the warning window, click the yes button.
10. Another warning window appears, displaying message that at least one database file is missing. In
the warning window, click cancel.
Task 2: Review the event logs

1.
On LON-MBX1, click on Server Manager.
2.
In Server Manager window, click on the Tools menu, and then click Event Viewer.
3.
In Event Viewer, in the navigation pane, expand Windows Logs, click 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 System, and then in the Content pane, review recent events. Notice that
notable events are present.
5.
Close Event Viewer.

Problem
Possible solution
Disk errors are preventing access to

the database.
Replace disks and restore from

backup.
Database path is incorrect because

of storage changes.
Change storage or database

configuration.
Task 4: Review the database configuration
1.
On LON-MBX1, in the Exchange Administration Center, in the list view, verify that MailboxDB100
database is selected, and then on the toolbar, click on the Edit button.
2.
Take note of the Database path.
3.
Click the File Explorer icon on the Taskbar, and then in the navigation pane, expand Computer,
expand Local Disk (C:), expand Program Files, expand Microsoft, expand Exchange Server, expand
V15, expand Mailbox, and then verify that the folder MailboxDB100-newpath does not exist. This is
the specified location for MailboxDB100.edb.
4.
In the navigation pane, click the MailboxDB100 folder, and locate the MailboxDB100.edb database
file. This is the actual location of the database and transaction log files. The configuration is pointing
to the wrong path.
5.
Close the File Explorer window.
Task 5: Reconfigure and mount the database

1.
On LON-MBX1, switch to the Exchange Management Shell, and then type the follow cmdlet, and
then press Enter:
Move-DatabasePath MailboxDB100 LogFolderPath C:\Program Files\Microsoft\Exchange
Server\V15\Mailbox\MailboxDB100 EdbFilePath C:\Program Files\Microsoft\Exchange
Server\V15\Mailbox\MailboxDB100\MailboxDB100.edb ConfigurationOnly force
2.
Type Y, and then press Enter.
3.
In the Exchange Management Shell, type the following cmdlet:

Mount-Database MailboxDB100
4.
Press Enter.
5.
In the EAC, on the features pane, click on servers, and then click on the databases tab.
6.
In the list view, click on MailboxDB100 database, and then in the details pane, verify that it is
Mounted.
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

Task 1: Use the Test cmdlets to verify server health
1.
On LON-MBX1, in the Exchange Management Shell, at the prompt, type c:\scripts\Lab11Prep2.ps1,

2.
3.
On LON-MBX1, if the Start screen is not displayed, move the mouse to the lower right corner of the
screen, and click Start.
4.
On the Start screen, click Exchange Management Shell.
5.
In the Exchange Management Shell, type the following Test cmdlet:

Test-ServiceHealth
6.
Press Enter. Verify that the output does not return any errors.
7.
In the Exchange Management Shell, type the following Test cmdlet, and then press Enter:
Test-OwaConnectivity URL https://LON-MBX1.adatum.com/OWA -TrustAnySSLCertificate
8.
Note the authentication errors.
9.

Problem
Possible solution
Internet Information Server (IIS)

Configuration is not configured correctly
Modify the IIS configuration.
Microsoft Outlook Web App authentication

is not configured correctly.
Modify Outlook Web App

authentication configuration.
Task 3: Check the Outlook Web App configuration

1.
On LON-MBX1, if Start screen is not displayed, move the mouse to the lower right corner of the
screen, click on Start.
2.
On the Start screen, open the Internet Explorer.
3.
In the Internet Explorer window, type https://lon-cas1.adatum.com/ecp, and then press Enter.
4.
On the Outlook Web App web page, in the Username box, type Adatum\Administrator, in the
Password box, type Pa$$w0rd and then click the Sign In button.
5.
Verify that you cannot sign in to the EAC.
6.
In the Exchange Management Shell, type following cmdlet, and then press Enter.
Get-OwaVirtualDirectory Identity lon-cas1\owa (Default Web Site)" | ft name,
*authentication
7.
Verify that all authentication methods are set to False.
8.
In the Exchange Management Shell, type following cmdlet, and then press Enter.
Set-OwaVirtualDirectory Identity lon-cas1\owa (Default Web Site)"
FormsAuthentication $true
9.
In the Exchange Management Shell, type following command, and then press Enter.
iisreset
10. In the Internet Explorer window, type https://lon-cas1.adatum.com/ecp, and then press Enter.
11. On the Outlook Web App web page, in the Username box, type Adatum\Administrator, and in
the Password box, type Pa$$w0rd and then click on the Sign In button.
12. Verify that now you can sign in to EAC. If you receive a navigation error in Internet Explorer, close and
reopen Internet Explorer and repeat the process from step 10.
Note: If you receive an error indicating that the service did not start, start the World Wide
Web Publishing Service in the Services management console.
Task 4: Verify that you resolved the problem

1.
Open Internet Explorer, and connect to https://LON-CAS1.adatum.com/owa.
2.
Log on to Outlook Web App as Adatum\Administrator with 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.

20341B ENU TrainerHandbook PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

20341B ENU TrainerHandbook PDF

Uploaded by

Copyright:

Available Formats

M I C R O S O F T

Core Solutions of Microsoft Exchange

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED

ii Core Solutions of Microsoft Exchange Server 2013

Product Number: 20341B

MCT USE ONLY. STUDENT USE PROHIBITED

MICROSOFT LICENSE TERMS

MCT USE ONLY. STUDENT USE PROHIBITED

a. If you are a Authorized Learning Center:

MCT USE ONLY. STUDENT USE PROHIBITED

b. If you are a MPN Member.

MCT USE ONLY. STUDENT USE PROHIBITED

d. If you are a MCT.

2.3 Reproduction/Redistribution Licensed Content. Except as expressly provided in the applicable

MCT USE ONLY. STUDENT USE PROHIBITED

survive this agreement.

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED

This limitation applies to

MCT USE ONLY. STUDENT USE PROHIBITED

x Core Solutions of Microsoft Exchange Server 2013

MCT USE ONLY. STUDENT USE PROHIBITED

Core Solutions of Microsoft Exchange Server 2013 xi

Stan Reimer Content Developer

Damir Dizdarevic Course Designer/Content Developer

Siegfried Jagott Content Developer

Vladimir Meloski Content Developer

Robert Genes Content Developer

MCT USE ONLY. STUDENT USE PROHIBITED

xii Core Solutions of Microsoft Exchange Server 2013

Chris Crandall Tech Reviewer

MCT USE ONLY. STUDENT USE PROHIBITED

Core Solutions of Microsoft Exchange Server 2013 xiii

Lesson 2: Exchange Server 2013 Deployment

Lesson 3: Managing Exchange Server 2013

Lab: Deploying and Managing Exchange Server 2013

Module 2: Planning and Configuring Mailbox Servers

Lesson 2: Planning the Mailbox Server Deployment

Lesson 3: Configuring the Mailbox Servers

Lab: Configuring Mailbox Servers

Module 3: Managing Recipient Objects

Lesson 2: Managing Other Exchange Recipients

Lesson 3: Planning and Implementing Public Folder Mailboxes

Lesson 4: Managing Address Lists and Policies

Lab: Managing Recipient Objects

Module 4: Planning and Deploying Client Access Servers

Lesson 2: Configuring the Client Access Server Role

Lesson 3: Managing Client Access Services

Lab: Deploying and Configuring a Client Access Server Role

Module 5: Planning and Configuring Messaging Client Connectivity

Lesson 2: Configuring Outlook Web App

Lesson 3: Planning and Configuring Mobile Messaging

Lesson 4: Configuring Secure Internet Access for Client Access Server

Lab: Planning and Configuring Messaging Client Connectivity

Module 6: Planning and Implementing High Availability

Lesson 2: Configuring Highly Available Mailbox Databases

Lesson 3: Configuring Highly Available Client Access Servers

Lab: Implementing High Availability

Module 7: Planning and Implementing Disaster Recovery

Lesson 2: Planning and Implementing Exchange Server 2013 Backup

Lesson 3: Planning and Implementing Exchange Server 2013 Recovery

Lab: Implementing Disaster Recovery for Exchange Server 2013