10165A ENU TrainerHandbook

M I C R O S O F T
L E A R N I N G
P R O D U C T
10165A
Updating Your Skills from Microsoft
Exchange Server 2003 or Exchange Server
2007 to Exchange Server 2010 SP1
MCT USE ONLY. STUDENT USE PROHIBITED
O F F I C I A L
Updating Your Skills from Microsoft Exchange Server 2003 or Exchange Server 2007 to Exchange Server 2010 SP1
ii
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.
2011 Microsoft Corporation. All rights reserved.
Microsoft, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries.
All other trademarks are property of their respective owners.
Product Number: 10165A

Part Number: X17-66519
Released: 06/2011
iii
iv
vi
vii
viii
ix
Acknowledgments
Microsoft Learning would like to acknowledge and thank the following for their contribution towards
developing this title. Their effort at various stages in the development has ensured that you have a good
classroom experience.
Damir DizdarevicContent Developer
Damir Dizdarevic, MCT, MCSE, MCTS, and MCITP, is a manager of the Learning Center at Logosoft d.o.o.,
in Sarajevo, Bosnia and Herzegovina. Damir specializes in Windows Server and Microsoft Exchange
Server. He has worked as a subject matter expert and technical reviewer on several Microsoft Official
Curriculum (MOC) courses and has published more than 350 articles in various IT magazines, including
Windows IT Pro. Additionally, he is a Microsoft Most Valuable Professional (MVP) for Windows Server
Infrastructure Management.
Siegfried JagottContent Developer
Siegfried Jagott is a Principal Consultant and Team Lead for the Messaging and Collaboration team at
Siemens IT Solutions, located in Munich, Germany. He is the author of Microsoft Exchange Server 2010
Best Practices (Microsoft Press) and Microsoft Official Curriculum (MOC) #10135 Configuring, Managing
and Troubleshooting Microsoft Exchange Server 2010, and he has coauthored various other Windows and
Exchange books. 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 is a Microsoft Certified Systems Engineer (MCSE) since 1997.
Vladimir MeloskiContent Developer
Vladimir Meloski is an MVP for Exchange Server, and a Microsoft Certified Trainer (MCT), community
leader and consultant, providing messaging and infrastructure solutions based on the Microsoft Exchange
Server and Microsoft System Center family. With a bachelor degree in computer sciences, Vladimir has
devoted 15 years of professional experience in IT. Vladimir has been involved in Microsoft conferences in
Europe and in the United States as a speaker, BOF moderator, proctor for hands-on labs, and technical
expert. As a skilled IT professional and trainer, Vladimir shares his best practices, real-world experiences,
and knowledge with his students and colleagues. He is also devoted to community development and
growth.
Stan ReimerContent Developer
Stan Reimer is president of S. R. Technical Services Inc., and he works as a consultant, trainer, and author.
Stan has extensive experience in consulting on Active Directory Domain Services 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 seven years, Stan has been writing courseware for
Microsoft Learning, specializing in Active Directory and Exchange Server courses. Stan has been an MCT
for 11 years and is an Exchange MVP.
Claudia WoodsMCT Technical Reviewer
Claudia Woods has worked as a LAN administrator, IT Pro Consultant, and technology instructor for more
than twenty years. She has designed and implemented technology solutions for an international customer
base. Claudia also holds instructor certifications for CompTIA CTT+, VMware VCI (3.x/4.x), and Microsoft
MCT (NT - 2008). Her Microsoft specialities include Windows Server, Active Directory, and Exchange
messaging.
Contents
Module 1: Introducing Microsoft Exchange Server 2010
Lesson 1: New Exchange Server 2010 Features for Exchange Server 2003
Administrators
Administrators
Lesson 3: Upgrading to Exchange Server 2010
Lab: Planning the Hardware Requirements for Exchange Server 2010
1-3
1-21
1-33
1-41
Module 2: Deploying Microsoft Exchange Server 2010

Lesson 1: Installing Exchange Server 2010
Lab A: Installing Exchange Server 2010 SP1
Lesson 2: Verifying the Exchange Server 2010 Installation
Lab B: Verifying the Exchange Server 2010 SP1 Installation
2-3
2-26
2-32
2-44
Module 3: Configuring Mailbox Servers

Lesson 1: Upgrading the Mailbox Server Role
Lesson 2: Configuring Mailbox Server Roles
Lesson 3: Configuring Public Folders and Public
Folder Databases in Exchange Server 2010
Lab: Configuring Mailbox Servers
3-3
3-8
3-23
3-31
Module 4: Managing Recipient Objects

Lesson 1: Managing Mailboxes in Exchange Server 2010
Lesson 2: Configuring Mail Users, Mail Contacts, and
Distribution Groups in Exchange Server 2010
Lesson 3: Configuring Email Address Policies and Address
Lists in Exchange Server 2010
Lesson 4: Performing Bulk Recipient Management
Tasks in Exchange Server 2010
Lab: Managing Exchange Server Recipients
4-3
4-21
4-27
4-37
4-42
Module 5: Managing Client Access

Lesson 1: Upgrading the Client Access Server Role
Lesson 2: Configuring the Client Access Server Role
Lab A: Upgrading and Configuring Client Access Servers
Lesson 3: Configuring Client Access Servers for Outlook Clients
Lesson 4: Configuring Microsoft Outlook Web App
Lesson 5: Configuring Mobile Messaging
Lab B: Configuring Client Access Servers for Outlook Web App and
Exchange ActiveSync
5-3
5-17
5-34
5-39
5-56
5-65
5-74
xi
Module 6: Managing Message Transport

Lesson 1: Overview of Message Transport
Lesson 2: Configuring Message Transport
Lab: Migrating and Managing Message Transport
6-3
6-20
6-38
Module 7: Implementing Messaging Security

Lesson 1: Deploying Edge Transport Servers
Lesson 2: Deploying an Antivirus Solution
Lab A: Configuring Edge Transport Servers and Forefront Protection 2010
for Exchange Server
Lesson 3: Configuring an Anti-Spam Solution
Lesson 4: Configuring Secure SMTP Messaging
Lab B: Configuring Anti-Spam Filtering
7-3
7-18
7-26
7-33
7-45
7-51
Module 8: Implementing High Availability

Lesson 1: Configuring Highly Available Mailbox Databases
Lesson 2: Deploying Highly Available Non-Mailbox Servers
Lesson 3: Deploying High Availability with Site Resilience
Lab: Implementing High Availability
8-3
8-21
8-29
8-40
Module 9: Implementing Backup and Recovery

Lesson 1: Planning Backup and Recovery
Lesson 2: Backing Up Exchange Server 2010
Lesson 3: Recovering from Disasters
Lab: Implementing Backup and Recovery
9-3
9-9
9-21
9-34
Module 10: Configuring Messaging Policy and Compliance

Lesson 1: Introducing Messaging Policy and Compliance
Lesson 2: Configuring Transport Rules
Lesson 3: Configuring Journaling and Multi-Mailbox Search
Lab A: Configuring Transport Rules, Journal Rules, and
Multi-Mailbox Search
Lesson 4: Configuring Archive Mailboxes
Lesson 5: Configuring Retention and Archive Policies
Lab B: Configuring Archive Mailboxes and Retention Policies
10-3
10-8
10-32
10-44
10-51
10-59
10-73
Module 11: Securing Microsoft Exchange Server 2010

Lesson 1: Configuring Role Based Access Control
Lesson 2: Configuring Audit Logging
Lesson 3: Configuring Secure Internet Access
Lab: Securing Exchange Server 2010
11-3
11-29
11-35
11-46
xii
Module 12: Monitoring and Troubleshooting Microsoft Exchange Server 2010

Lesson 1: Monitoring Exchange Server 2010
Lesson 2: Troubleshooting Exchange Server 2010
Lab: Monitoring and Troubleshooting Exchange Server 2010
12-3
12-20
12-26
Module 13: Upgrading from Microsoft Exchange Server 2007 to Exchange Server 2010
Lesson 1: Upgrading from Exchange Server 2007 to Exchange Server 2010 13-3
Lab: Upgrading from Exchange Server 2007 to Exchange Server 2010
13-17
Appendix A: Understanding and Planning for Microsoft Exchange Online

Lesson 1: Planning for Exchange Online
Lesson 2: Migrating to and Managing Exchange Online
Lesson 3: Implementing Federated Delegation
Lab Answer Keys
A-3
A-18
A-25
xiii
xiv
About This Course
About This Course
This section provides you with a brief description of the course, audience, suggested prerequisites, and
course objectives.
Course Description
This course provides the following benefits:
This course provides IT professionals, who have experience with and are running Microsoft
Exchange Server 2003 or Exchange Server 2007, a fast track method to upgrade their skills and enable
them to upgrade to Exchange Server 2010 SP1 and promote that technology adoption.
This course will help accelerate the student skills upgrade path and provide additional support for the
two Exchange Server 2010 exams. This course is not a direct mapping to the exams; however, it is
intended as additional support for elements within these exams.
Audience
This course is intended for IT professionals who are experienced with Exchange Server 2003 or Exchange
Server 2007 technologies. Students wishing to take this course should have a Technology Specialist or
equivalent certification or equivalent knowledge and experience, and want to upgrade their skills to
Exchange Server 2010.
This IT professional is the senior administrator, or engineer who acts as a technical lead over a team of
administrators. This person is a third level of support behind the Exchange Recipient Administrator, who is
the first level, and the Exchange Server Administrator, who is the second level. To ensure that end users
have the best possible messaging experience, this person also evaluates new technologies and tools.
Student Prerequisites
The prerequisites for the course are as follows:
MCSE in Windows Server 2003 or TS qualification in Exchange 2007 with Exam 70-236 : TS : Exchange
Server 2007, Configuring
Windows Server 2008 Technology Specialist Skills
At least two years administering Exchange 2003 or Exchange 2007
Course Objectives
After completing this course, students will be able to:
Describe the new Exchange Server 2010 features, as compared with Exchange Server 2003 and
Install and deploy Exchange Server 2010 in an Exchange Server organization.
Configure Mailbox servers and Mailbox server components.
Manage recipient objects, including migrating recipients from previous versions of Exchange Server
to Exchange Server 2010.
Migrate client access services from previous versions of Exchange Server, and configure the Client
Access server role in Exchange Server 2010.
Migrate message transport from previous versions of Exchange Server, and configure message
transport in Exchange Server 2010.
About This Course
ii
Configure the secure flow of messages between the Exchange Server organization and the Internet.
Implement a high availability solution for Mailbox servers and other server roles in Exchange Server.
Plan and implement a disaster recovery solution for Exchange Server 2010 servers.
Plan and configure messaging compliance.
Migrate Exchange Server permissions to Exchange Server 2010, and configure Exchange Server
security.
Monitor and maintain the messaging system.
Upgrade an existing Exchange Server 2007 organization to Exchange Server 2010.
Course Outline
This section provides an outline of the course:
Module 1, Introducing Microsoft Exchange Server 2010, describes the new Exchange Server 2010
features as compared to the Exchange Server 2003 and Exchange Server 2007 features.
Module 2, Deploying Microsoft Exchange Server 2010 SP1, teaches students how to install and deploy
Exchange Server 2010 in an Exchange Server organization.
Module 3, Configuring Mailbox Servers, describes how to configure Mailbox servers and Mailbox server
components.
Module 4, Managing Recipient Objects, explains how to manage recipient objects, including migrating
recipients from previous versions of Exchange Server to Exchange Server 2010.
Module 5, Managing Client Access, teaches students how to migrate client access services from Exchange
Server 2003 and configure the Client Access server role in Exchange Server 2010.
Module 6, Managing Message Transport, describes how to migrate message transport from previous
versions of Exchange Server, and configure message transport in Exchange Server 2010.
Module 7, Implementing Messaging Security, teaches students how to configure the secure flow of
messages between the Exchange Server organization and the Internet.
Module 8, Implementing High Availability, explains how to implement a high availability solution for
Mailbox servers and other server roles in Exchange Server 2010.
Module 9, Implementing Backup and Recovery, describes planning and implementing a disaster recovery
solution for Exchange Server 2010 servers.
Module 10, Configuring Messaging Policy and Compliance, describes planning and configuring
messaging compliance.
Module 11, Securing Microsoft Exchange Server 2010, teaches students how to configure Exchange
Server security.
Module 12, Monitoring and Troubleshooting Microsoft Exchange Server 2010, describes how to monitor
and maintain the messaging system.
Module 13, Upgrading from Microsoft Exchange Server 2007 to Exchange Server 2010, explains how to
upgrade an Exchange Server 2007 organization to Exchange Server 2010.
Appendix A, Understanding and Planning for Microsoft Exchange Online, introduces Exchange Online,
and provides an overview of migrating to and managing Exchange Online.
Course Materials
The following materials are included with your kit:
About This Course
iii
Course Handbook A succinct classroom learning guide that provides all the critical technical
information in a crisp, tightly-focused format, which is just right for an effective in-class learning
experience.
Lessons: Guide you through the learning objectives and provide the key points that are critical to
the success of the in-class learning experience.
Labs: Provide a real-world, hands-on platform for you to apply the knowledge and skills learned
in the module.
Module Reviews and Takeaways: Provide improved on-the-job reference material to boost
knowledge and skills retention.
Lab Answer Keys: Provide step-by-step lab solution guidance at your finger tips when its
needed.
Course Companion Content on the http://www.microsoft.com/learning/companionmoc/ Site:

Searchable, easy-to-navigate digital content with integrated premium on-line resources designed to
supplement the Course Handbook.
Modules: Include companion content, such as questions and answers, detailed demo steps and
additional reading links, for each lesson. Additionally, they include Lab Review questions and answers
and Module Reviews and Takeaways sections, which contain the review questions and answers, best
practices, common issues and troubleshooting tips with answers, and real-world issues and scenarios
with answers.
Resources: Include well-categorized additional resources that give you immediate access to the most
up-to-date premium content on TechNet, MSDN, Microsoft Press.
Student Course files on the http://www.microsoft.com/learning/companionmoc/ Site: Includes the

Allfiles.exe, a self-extracting executable file that contains all the files required for the labs and
demonstrations.
Course evaluation At the end of the course, you will have the opportunity to complete an online
evaluation to provide feedback on the course, training facility, and instructor.
To provide additional comments or feedback on the course, send e-mail to

support@mscourseware.com. To inquire about the Microsoft Certification Program, send e-mail
to mcphelp@microsoft.com.
About This Course
Virtual Machine Environment
iv
This section provides the information for setting up the classroom environment to support the business
scenario of the course.
Virtual Machine Configuration

In this course, you will use Microsoft Virtual Server 2005 R2 with SP1 to perform the labs.
Important At the end of each lab, you must close the virtual machine and must not save
any changes. To close a virtual machine without saving the changes, perform the following
steps: 1. On the virtual machine, on the Action menu, click Close. 2. In the Close dialog box,
in the What do you want the virtual machine to do? list, click Turn off and delete changes,
and then click OK.
The following table shows the role of each virtual machine used in this course:
Note The revision letters represent the same virtual machine in different installation
states.
Virtual machine
Role
10165A-NYC-DC1-A
Domain controller in the contoso.com domain.
10165A-NYC-CL1-A
Windows 7 client in the contoso.com domain.
10165A-NYC-DC1-B
Domain controller in the contoso.com domain.
10165A-NYC-EX03-A
Exchange 2003 SP2 server in the contoso.com domain.
10165A-NYC-EX03-B
Exchange 2003 SP2 server in the contoso.com domain.
10165A-NYC-EX10-A
Member server in the contoso.com domain.
10165A-NYC-EX10-B
Exchange 2010 server in the contoso.com domain.
10165A-NYC-EX11-B
Exchange 2010 server in the contoso.com domain.
10165A-NYC-CL1-B
Windows 7 computer in the contoso.com domain.
10165A-NYC-SVR1-B
Stand-alone server.
10165A-ROM-DC1-C
Domain controller in the adatum.com domain.
10165A-ROM-EX07-C
The Exchange 2007 server in the adatum.com domain.
10165A-ROM-EX1-C
Member server in the Exchange Server 2007 migration lab.
Software Configuration
The following software is installed on each VM:
Windows Server 2003 SP2
Windows Server 2008 R2
Exchange Server 2003 SP2
Windows 7
Microsoft Office 2010
Classroom Setup
Each classroom computer will have the same virtual machine configured in the same way. All of the
aforementioned virtual machines are deployed on each student computer.
Course Hardware Level
About This Course
To ensure a satisfactory student experience, Microsoft Learning requires a minimum equipment

configuration for trainer and student computers in all Microsoft Certified Partner for Learning Solutions
(CPLS) classrooms in which Official Microsoft Learning Product courseware are taught.
Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) processor
Dual 120 gigabyte (GB) hard disks 7200 RAM SATA or better*
8 GB RAM
DVD drive
Network adapter
Super VGA (SVGA) 17-inch monitor
Microsoft Mouse or compatible pointing device
Sound card with amplified speakers
*Striped
In addition, the instructor computer must be connected to a projection display device that supports SVGA
1024 x 768 pixels, 16-bit colors.
About This Course

vi
Introducing Microsoft Exchange Server 2010
1-1
Module 1
Contents:
Administrators
1-3
Administrators
1-21
Lesson 3: Upgrading to Exchange Server 2010
1-33
1-42
Module Overview
1-2
Microsoft Exchange Server 2010 provides many new features and functionalities that can improve how
you manage messaging and collaboration in your organization. As you upgrade from Exchange Server
2003 or Exchange Server 2007, it is important to understand the upgrades that are available with
Exchange Server 2010. This module introduces the new features, and provides information about how to
plan your migration to Exchange Server 2010.
Objectives
After completing this module, you will be able to:
Identify new features and enhancements in Exchange Server 2010 for Exchange Server 2003
administrators.
Identify new features and enhancements in Exchange Server 2010 for Exchange Server 2007
administrators.
Plan an upgrade of your existing Exchange Server organization to Exchange Server 2010.
Lesson 1
New Exchange Server 2010 Features for Exchange Server

2003 Administrators
As compared to Exchange Server 2003, Exchange Server 2010 provides many new features, such as role
based access control (RBAC), and server roles. Before upgrading to Exchange Server 2010, you should
understand how your Exchange Server 2010 organization will differ from your Exchange Server 2003
organization.
In this lesson, you will learn about the important new features in Exchange Server 2010 as compared to
Objectives
After completing this lesson, you will be able to:
Describe server roles in Exchange Server 2010.
Describe how to combine server roles, depending on the deployment scenario, availability
requirements, and organization size.
Describe changes to administrative groups and routing groups in Exchange Server 2010.
Describe Exchange Server 2010 administrative tools.
Describe the Windows PowerShell command-line interface.
Describe the Exchange Management Shell.
Identify the new features for configuring messaging compliance.
Describe Exchange Server 2010 editions and licensing.
1-3
Overview of Server Roles in Exchange Server 2010
1-4
Exchange Server 2003 employs a monolithic architecture that you could optionally configure to support
two distinct server functionalities: front-end and backend. Additionally, you could also configure Exchange
2003 servers as bridgehead servers for various connectors. Exchange Server 2010, however, provides
functionalities that fall into five separate logical groupings, called server roles. These role-based
functionalities are required for Exchange Server 2010.
When you install Exchange Server 2010, you can select one or more server roles for installation on the
server. Large organizations might deploy several servers with each role, whereas a small organization
might combine several server roles on one computer.
Exchange Server 2010 Server Roles

The following server roles are included in Exchange Server 2010:
Mailbox server role. The Mailbox server role is responsible for managing mailbox and public folder
databases. Mailboxes and public folders reside in databases on the Mailbox servers. Mailbox servers
contain mailbox and public folder databases. Additionally, as of Exchange Server 2010 Service Pack 1
(SP1), the Mailbox server can host separate mailbox databases for archive mailboxes. You can enable
high availability by adding Mailbox servers to a database availability group (DAG). Because Mailbox
servers require Active Directory Domain Services (AD DS) access, you must install this role on a
member server in an Active Directory domain.
Note You can install Exchange Server 2010 on domain controllers, but this is not
recommended.
In Exchange Server 2003, the server hosts all functionality by default. In Exchange Server 2010, the
Mailbox server is responsible for managing mailbox and public folder databases. The other server
roles provide client connectivity or message transport to support the Mailbox server role.
Note DAGs are described more in depth in Lesson 2.
1-5
Hub Transport server role. The Hub Transport server role is responsible for message routing and
message policy processing. The Hub Transport server performs message categorization and routing,
and handles all messages that pass through an organization. You must configure at least one Hub
Transport server in each Active Directory site that contains a Mailbox server. To enable high
availability for the Hub Transport server role, you just need to deploy multiple servers in the same
Active Directory site. The server running the Hub Transport server role must be a member of an
Active Directory domain. From an Exchange Server 2003 perspective, the Hub Transport role is
equivalent to a bridgehead server, although it provides more functionality that will be discussed later.
Client Access server role. The Client Access server role enables connections from all available client
protocols to the Exchange Server mailboxes. You must deploy at least one Client Access server in each
Active Directory site that contains a Mailbox server. To provide high availability for the Client Access
server role, you need to deploy multiple servers with the role installed in the same site, and then
configure load balancing. Client protocols that connect through a Client Access server include:
Messaging Application Programming Interface (MAPI) clients.
Microsoft Outlook Web App clients. In Exchange Server 2003, Outlook Web App was known as
Outlook Web Access.
Post Office Protocol version 3 (POP3) and Internet Message Access Protocol version 4 (IMAP4)
clients.
Outlook Anywhere, which is known as remote procedure call (RPC) over Hypertext Transfer
Protocol (HTTP) in Exchange Server 2003.
Microsoft Exchange ActiveSync clients.
Exchange Web Services clients.
Note In Exchange Server 2003, MAPI clients connect directly to the Information Store
service on the Mailbox servers. In Exchange Server 2010, all clientsincluding MAPI clients
connect to the RPC Client Access service on the Client Access servers for mailbox data. MAPI
clients connect to the RPC Client Access service on Mailbox servers when accessing public
folders. This is a significant architecture change in Exchange Server 2010.
Edge Transport server role. The Edge Transport server role is the Simple Mail Transport Protocol
(SMTP) gateway server between your organization and the Internet. To ensure security, the Edge
Transport server role was designed to not be a member of your internal Active Directory forest. You
should deploy the Edge Transport server in a perimeter network.
The Edge Transport role does not use Active Directory to store configuration information. Instead, it
uses Active Directory Lightweight Directory Services (AD LDS) on Windows Server 2008 computers to
store recipient and configuration information.
On the Edge Transport server, you create connectors to define message-flow paths into, and out of,
your organization. You can implement multiple Edge Transport servers to provide load balancing and
high availability.
Note The Hub Transport servers and Edge Transport servers both provide message routing
and delivery capabilities to, and from, the Internet. However, some advanced transport
features are available only on Edge Transport servers.
1-6
Unified Messaging server role. The Unified Messaging server role provides the foundation of services
that integrate voice messages into the messaging infrastructure of your organization. This role
requires the presence of three other server roles: Hub Transport, Client Access, and Mailbox. The
Unified Messaging server provides access to voice messages and enables users to access their
mailboxes by using analog, digital, or cellular telephones.
Question: Which role or roles provide completely new functionalities in Exchange Server
2010?
Combining Server Roles in Exchange Server 2010
1-7
In Exchange Server 2003, we recommended separating the front-end server from the backend server. In
Exchange Server 2010, the Client Access server role represents the front end, while the Mailbox server role
represents the back end. In addition, you must have a Client Access server whenever you have a Mailbox
server. You can install these roles together on one server or virtual machine, or separately. Many
organizations locate the Hub Transport server with the Client Access server.
In Exchange Server 2010, your decision to combine server roles will depend on your deployment scenario,
availability requirements, and organization size. Some smaller organizations might decide to locate all
Exchange 2010 server roles on a single computer, while others might install each role on a separate
computer. Still others might use a mixed approach in which some rolessuch as the Client Access server
and the Hub Transport serverare installed together, while the Mailbox server is installed separately.
Important You cannot combine the Edge Transport server role with any other role on the
same computer.
The following sections describe typical deployment scenarios for your Exchange 2010 server roles.
Note for Exchange Server 2007 administrators In Exchange Server 2007, you could not
combine any role with a clustered Mailbox server role. Exchange Server 2010 does not have
this limitation, which means that you now have additional flexibility when combining server
roles.
Small Organization: All Server Roles on One Server
In a small organization, you will most likely install the Mailbox, Hub Transport, and Client Access server
roles on a single computer. In some cases, the Edge Transport server might not be deployed at all,
because the Hub Transport server role can perform Edge Transport functionality. Not deploying an Edge
1-8
Transport server might be more cost effective for some smaller organizations. However, we recommend
using an SMTP gateway to ensure that messages are scanned for spam and viruses before the messages
enter the Exchange Server organization.
An organization that is not deploying an SMTP gateway server or Edge Transport server can also consider
using Exchange Online, which is described in a later topic. In Exchange Server 2010, you can administer
both Exchange Online and on-premises Exchange services from the same administrative console. This is a
new feature for Exchange Server 2003 and Exchange Server 2007 administrators.
Medium Organization: Three Exchange Server Computers
Medium-sized organizations should consider installing the required services and Exchange server roles on
multiple computers. A typical deployment scenario for a medium-sized organization may include:
Two domain controllers that are also configured as global catalog servers for each domain.
Two Exchange servers configured with the Mailbox server role and other server roles (Hub and Client
Access), except the Edge Transport server role. In this scenario, Mailbox servers are connected in a
DAG, which provides high availability for this role.
One Exchange server configured with the Edge Transport server role.
If the organization is also deploying Unified Messaging, we recommend that this server role be
deployed on a dedicated server.
As your organization expands, you should consider adding dedicated servers for roles like the Hub
Transport server, the Client Access server, and the Unified Messaging server. This provides scalability and
redundancy.
Enterprise Organization: Server Role Separation
A large or complex organization may need to deploy dedicated servers for each server role, and may have
to deploy multiple servers for each role. A typical deployment scenario for a large organization can
include:
Two domain controllers and global catalog servers for each organizational domain. If the
organization includes multiple Active Directory sites, and you are deploying Exchange servers in a site,
you should deploy global catalog servers in the site.
One or more Exchange servers configured with the Mailbox server role. You can deploy multiple
Mailbox servers in each Active Directory site.
One or more Exchange servers dedicated to each of the other server roles. You must deploy at least
one Hub Transport server and one Client Access server in each Active Directory site that includes a
Mailbox server.
If the organization has a smaller branch office, you can deploy multiple Exchange servers hosting all
the server roles except for the Edge Transport server role and the Unified Messaging server role, and
configure the Mailbox servers to be part of a DAG.
One or more Exchange servers configured with the Edge Transport server role. Multiple servers
provide redundancy and scalability.
Question: What is the main reason for role separation?
1-9
Changes to Administrative Groups and Routing Groups in Exchange Server

2010
Two basic architectural concepts in Exchange Server 2003 are no longer used in Exchange Server 2010:
administrative groups and routing groups. In Exchange Server 2003, one of the reasons for configuring
administrative groups was to delegate permissions. In Exchange Server 2010, this functionality is provided
by RBAC, and the Active Directory site topology replaces routing groups.
Administrative groups and routing group objects are still created, regardless of whether they are for a
new installation or an existing organization upgrade. However, these objects now exist exclusively to
provide backward compatibility with Exchange Server 2003.
Note In Exchange Server 2010, administrative groups and routing groups exist so that mail
can be exchanged between Exchange 2003 and Exchange 2010 servers in a coexistent
environment.
Role Based Access Control

Note
RBAC is new for Exchange Server 2007 and Exchange Server 2003 administrators.
Exchange Server 2010 does not use administrative groups to delegate permissions. Instead, Exchange
Server 2010 uses RBAC. RBAC enables you to assign granular permissions to administrators, and to more
closely align the permissions that you assign to users and administrators, to the actual job roles they hold
within your organization. In Exchange Server 2010, RBAC controls both the administrative tasks that you
can perform and the extent to which users can perform their own administrative tasks. RBAC controls who
can access what, and where, through management roles, assignments, and scopes.
For backward compatibility, Exchange 2010 servers are displayed in the Exchange System Manager for
Exchange Server 2003 as members of a single administrative group that is called the Exchange
1-10
Administrative Group (FYDIBOHF23SPDLT). The Exchange Administrative Group is discussed in detail in

Module 2.
Active Directory Site Topology
The Exchange Server 2003 transport and routing functionality was completely revised beginning with
Exchange Server 2007, and it was further enhanced in Exchange Server 2010. Rather than using routing
groups, Exchange Server 2007 and Exchange Server 2010 use the Active Directory site topology to
determine how messages are transported in the organization.
Exchange Server 2010 takes advantage of the existing Active Directory site topology and eliminates the
need to define a separate routing topology. By default, Exchange Server 2010 uses the Active Directory IP
site links and the costs associated with them to calculate the least costly route between Hub Transport
servers in different Active Directory sites. You can modify the default settings by configuring Exchangespecific routing costs to the site connectors. For coexistence between Exchange Server 2003 and Exchange
Server 2010, you must consider the link state routing functionality. This is discussed in detail in Module 2.
Exchange Server 2010 Administrative Tools
1-11
Exchange Server 2010 has several administrative tools that can help you manage your Exchange Server
organization. These tools differ from those that are available in Exchange Server 2003.
The Exchange Management Console is the primary tool that Exchange administrators use to manage
the Exchange Server 2010 organization. This tool replaces the Exchange Server 2003 Exchange System
Manager.
The Exchange Management Shell is an Exchange Server-specific command-line management

interface for Windows PowerShell 2.0.
The Exchange Control Panel is a web-based administrative interface. This feature is new for Exchange
Server 2007 and Exchange Server 2003 administrators.
Exchange Management Console
The Exchange Management Console uses the Microsoft Management Console 3.0 (MMC) model of a
four-pane environment. It is organized differently from Exchange System Manager in Exchange Server
2003. The four main components of Exchange Management Console are:
Console tree. This area provides a hierarchical view of the Exchange Server organization and servers,
which you use to locate the objects that you want to manage.
Results pane. This area displays the objects available under the object you select in the console tree.
Work pane. This area presents child objects of the results pane. You can use the links in the Actions
pane to manage the objects in the work pane.
Actions pane. This area displays different administrative tasks in response to your selections within
the results and work panes. The tasks that the Actions pane lists also are available when you rightclick the object in the results or work pane.
The root node of the console tree includes two tabs: Organizational Health and Customer Feedback.
The Organizational Health tab displays a report on the overall status of the Exchange Server
1-12
organization. This report includes information about the number of deployed databases, servers, and
Client Access Licenses. Use the Customer Feedback tab to enable the Customer Experience Improvement
Program, and to access Exchange Server documentation.
Additionally, the console tree displays four main nodes: Organization Configuration, Server Configuration,
Recipient Configuration, and Toolbox. These four nodes have four distinct functions.
Organization Configuration Node
The Organization Configuration node contains the configuration options for each Exchange server role
that affects the messaging system functionality. This node allows you to configure database management,
Exchange ActiveSync policies, journal and transport rules, message-formatting options, and email domain
management.
Server Configuration Node
The Server Configuration node contains the configuration options for each Exchange server in the
organization. Settings that you can manipulate include server diagnostic-logging settings, product-key
management, and the per-server configuration of Outlook Web App.
Recipient Configuration Node
The Recipient Configuration node contains the configuration and creation tasks for mailboxes, distribution
groups, and contacts. You also can use it to move or reconnect mailboxes.
Toolbox Node
The Toolbox node contains utilities and tools that you can use to monitor, troubleshoot, and manage
Exchange Server 2010. These tools include the Exchange Best Practices Analyzer, Public Folder
Management Console, messaging tracking, and Database Recovery Management.
Exchange Management Shell
Exchange Server 2010 is based on the Windows PowerShell scripting language. The graphical user
interface (GUI)-based Exchange Management Console represents only a subset of the options available
with Windows PowerShell. In Exchange Management Shell, you can perform every task that can be
performed by the Exchange Management Console and the Exchange Control Panel interface, plus
additional tasks that are not available from those interfaces, such as advanced searches with filters and
bulk management of Exchange Server objects. In fact, when you perform a task in Exchange Management
Console or Exchange Control Panel, those interfaces use Exchange Management Shell to perform the task
and RBAC to enforce user permissions.
Exchange Control Panel
Exchange Control Panel is a new feature in Exchange Server 2010. It enables Exchange Server specialists to
manage many aspects of the messaging environment from a secure webpage, including inbox rules,
public groups, account information, call-answering rules, and retention policies. Additionally, Exchange
Control Panel enables users to run some basic tasks with their mailboxes that were previously dedicated
to administrators, such as message tracking.
Exchange Control Panel uses a web-based interface that is similar to Outlook Web App. Moreover, users
can easily switch between Outlook Web App and Exchange Control Panel after they are authenticated by
the Client Access server. This feature is described in more detail in Lesson 2.
What Is Windows PowerShell?
1-13
Exchange Server 2003 administrators may not be familiar with Windows PowerShell, which is an important
underlying tool for Exchange Server 2010. Windows PowerShell is an extensible scripting and commandline technology that developers and administrators use to automate tasks in a Windows operating
system environment. Windows PowerShell uses a set of small commands called cmdlets that each perform
a specific task. You also can combine multiple cmdlets to perform complex administrative tasks.
In Exchange Server 2010, Exchange Management Console provides GUI access to the Windows PowerShell
cmdlets. When you perform an action in Exchange Management Console, the cmdlet runs by using
Windows PowerShell.
Windows PowerShell is accessible directly through a new command shell, called PowerShell.exe. When
you run Windows PowerShell from this command shell, you can perform many of the tasks you could
perform by using the traditional command shell (cmd.exe), plus many more.
Some of the most important features of Windows PowerShell are:
Simple cmdlets. Cmdlets are small executable files, written in Microsoft Visual C# or any other
Microsoft .NET Framework-compliant language, that provide a standard procedure for performing
certain actions. All cmdlets are in format verb-noun, for example: get-user, set-mailbox, and so on.
The syntax is very similar to the English language, so it can be easily adopted.
Aliases. You also can alias cmdlets. If you commonly run a specific cmdlet, you can assign an alias to
the cmdlet to make it easier to remember. These aliases are stored in the default user profile on a
computer or in the user-specific profile. For example, if you want to replace the Get-ChildItem
cmdlet with the show alias, you would run New-Alias show Get-ChildItem.
Variables. As with most programming languages, Windows PowerShell supports the concept of a
variable to which you can assign a value. Variables in Windows PowerShell are named starting with a
dollar sign ($) character; for example, $date and $servername. Variables can have a data type formally
defined. To display the value of a variable, just type the variable name (including the $). You can also
perform normal variable manipulation.
1-14
Pipelining. Pipelining enables you to string cmdlets together and make the output of one cmdlet the
input of the next cmdlet. Windows PowerShell provides a pipeline, but instead of passing raw text to
the next cmdlet, it passes managed objects. For example, in one cmdlet, you can use a filter to locate
a set of Exchange Server recipients based on one or more parameters, and then apply an action to
that set of recipients.
Exchange Management Shell also provides a robust and flexible scripting platform that can reduce the
complexity of current Microsoft Visual Basic scripts. Tasks that previously required many lines in Visual
Basic scripts can now be performed by using as little as one line of code.
What Is Exchange Management Shell?
1-15
Exchange Server 2003 administrators may ask why a command-line interface was introduced to Exchange
Server 2007 and Exchange Server 2010. It is important to understand that Exchange Management Shell is
actually a step forward for Exchange Server administration because it provides you with more capabilities
for performing tasks, and it facilitates managing large numbers of objects.
In Exchange Management Shell, there are approximately 700 cmdlets that perform Exchange Server
management tasks, and even more non-Exchange Server cmdlets that are in the basic Windows
PowerShell command-line interface design. Because of this, Exchange Management Shell offers a complex
and extensible scripting engine that has sophisticated looping functions, variables, and other
programmatic features so that you can create powerful administrative scripts quickly.
In Exchange Server 2010, if your user account is enabled for remote PowerShell, you can also connect to a
remote session on a remote Exchange Server 2010 computer to perform commands on that remote
computer. Whether you use Exchange Management Shell to administer a server you are physically
connected to, or to administer a server across the country, the Windows PowerShell Remoting feature
performs the operation in Exchange Server 2010. Only the Edge Transport server role does not use these
remote Windows PowerShell capabilities. Remote Windows PowerShell is described in the next lesson.
Examples
The following example uses two pipelined cmdlets with a filter between them. The first cmdlet, Get-user,
retrieves all users from AD DS and pipes the results to the filter. The filter, which is based on the
distinguished name, selects among these users, and leaves only those located in the Sales organizational
unit (OU) and its child OUs. These results are piped to the Enable-Mailbox cmdlet, which will create a
mailbox for these users, and then place them in Mailbox Database 1.
Get-User | Where-Object {$_.distinguishedname ilike "*ou=sales,dc=contoso,dc=com"} |
Enable-Mailbox database Mailbox Database 1"
1-16
The following example shows how to set a size limit for receiving messages for multiple users who are
members of one distribution group. The first cmdlet finds the distribution group, called RemoteUsers. The
second cmdlet enumerates the members of this distribution group. The third cmdlet limits their mailbox
sizes to 10 megabytes (MB) for receiving messages.
Get-DistributionGroup "RemoteUsers" |Get-DistributionGroupMember |
Set-Mailbox MaxReceiveSize 10MB
The following example filters all users with the City attribute set to Brisbane, and creates mailboxes for
these users on the SYD-DC1 server, in the Mailbox Database database. However, because this command
uses the WhatIf parameter, this cmdlet will not be executed. Instead, it only displays objects that are
affected by this command.
Get-User Filter{(RecipientType eq user) and (City eq Brisbane)} | Enable-Mailbox

Database Mailbox Database
WhatIf
New Features for Configuring Messaging Compliance
1-17
The requirements for message compliance have changed since Exchange Server 2003 (and Exchange
Server 2007) were released. Increasingly, organizations need an application-specific approach to coping
with a growing number of legal, regulatory, and internal policy and compliance requirements.
Administrators must filter, process, and store email exchanged between users in the organization, to or
from the Internet, or between partner organizations. Exchange Server 2010 provides a broad set of email
policy and compliance features to meet this requirement to protect and control the flow of information.
The most important features for messaging compliance in Exchange Server 2010 are:
Transport rules. Transport rules are used to apply rules to messages in transport. Transport-based
policies are configured on computers with Hub Transport and Edge Transport server roles. A
collection of transport agents allows you to configure rules and settings that are applied to messages
as they enter and leave the transport components. You can create policy and rule settings that meet
the regulations that apply to your organization, and that can easily be changed to adapt to your
organizations requirements. The Edge Rules agent processes messages that are sent to or received
from the Internet. The Transport Rules agent applies rules to messages that are sent between users in
the same organization.
Most rules are composed of conditions, actions, and exceptions. Actions determine how a message is
processed when a specified condition is true. Possible actions include applying a message
classification, redirecting the message to an address, removing the message header, or logging an
event. Optional exceptions exempt particular messages from having an action applied.
Disclaimers. You can also configure transport rules to add disclaimer text to the start or end of the
message body. The Exchange Server administrator customizes disclaimers to meet your organizations
requirements. These disclaimers may contain text that refers to accidental disclosure of the message
contents, or proprietary or confidential information.
Address rewriting. You configure the Address Rewriting agent on the Edge Transport server role to
enable the modification of SMTP addresses on inbound and outbound messages. Address rewriting is
especially useful when an organization that has several domains wants to present a consistent
appearance of email addresses to external message recipients.
1-18
Journaling. The Journaling agent acts on messages in transit to enforce retention of messages that
meet specified criteria. You configure journal rules on the Hub Transport server. Transport-based
journaling provides more flexibility than the store-based configuration of Exchange Server 2003, and
it reduces duplication of journal reports.
Messaging records management (MRM). MRM is the records management technology in Exchange
Server 2010 that helps organizations reduce legal risks associated with email and other
communications. It is a toolset that enables organizations to manage messages in the user mailbox,
including options such as retention policies, archive polices, and managed folders.
Multi-Mailbox Search. Multi-Mailbox Search helps organizations manage legal discovery

requirements as part of organizational policy, compliance requirements, or lawsuits. You can use this
feature to search for relevant content in Exchange Server mailboxes across the entire organization.
Litigation hold. You can place mailboxes on litigation hold to protect against intentional, policy-based
or accidental message deletion. This allows deleted messages to be indexed by the Exchange Search
feature. As a result, these messages are returned when you use Multi-Mailbox Search to search a
mailbox. After a mailbox is placed on litigation hold, any changes made to messages are also
preserved as different versions.
Personal Archives. The Personal Archives feature provides users with a second mailbox for historical
messaging data. Using Microsoft Outlook 2007 with the latest updates, Outlook 2010, and Outlook
Web App, users have seamless access to their archive mailboxes. Using either of these client
applications, users can view a personal archive, and move or copy messages between their primary
mailbox and the archive. They can also use archive policies to automatically move messages from the
primary mailbox to the archive. The Personal Archives feature allows you to present your users with a
consistent view of their messaging data, and it eliminates the overhead that comes with managing
.pst files. Eliminating the use of .pst files may also significantly reduce your organizations exposure to
security risks, because all messaging data is stored in a secure location.
Question: Which features for messaging compliance were you using with Exchange Server
2003?
1-19
Exchange Server 2010 Editions
Exchange Server 2010 is available in two editions for an on-premise deployment: Standard Edition and
Enterprise Edition. Exchange Server 2010 Standard Edition should meet the messaging needs of smallsized and medium-sized organizations, and may also be suitable for specific server roles or branch offices.
Exchange Server 2010 Enterprise Edition is for large enterprise organizations, and it enables you to mount
up to 100 additional databases.
Note Microsoft provides a third Exchange Server 2010 edition called the Coexistence
Edition. This is a free version designed to help legacy Exchange Server organizations migrate
to Exchange Online.
These are licensing editions that are defined by a product key. When you enter a valid license product
key, the supported edition for the server is established.
You can use a valid product key to move from the Exchange Server 2010 evaluation version (Trial Edition)
to either Standard Edition or Enterprise Edition. You can also use a valid product key to move from
Standard Edition to Enterprise Edition. The following table enumerates the differences between the two
editions.
Feature
Standard Edition
Enterprise Edition
Maximum number of
mounted databases
5 databases
100 databases
Database storage limit
1,024 gigabytes (GB). Can be

raised by using Registry
Editor.
No software storage limit; storage limit is

hardware-dependent
DAG (high availability)

membership
Supported
Supported
Exchange Server 2010 Licenses
1-20
Exchange Server 2010 on-premises is licensed in the Server/client access license (CAL) model in the same
way that Exchange Server 2007 was licensed. There are three types of licenses:
Server Licenses. A license must be assigned for each instance of the server software that is being run.
The server license is sold in two server editions: Standard Edition and Enterprise Edition.
CALs. Exchange Server 2010 also comes in two CAL editions: Standard CAL and Enterprise CAL.
Enterprise CAL provides users with additional features, such as Personal Archives, Multi-Mailbox
Search, voice mail, and IRM protection. You can mix and match the server editions with the CAL types.
For example, you can use Enterprise CALs with Exchange Server 2010 Standard Edition. Similarly, you
can use Standard CALs with Exchange Server 2010 Enterprise Edition.
External Connector Licenses. This license type allows an unlimited number of clients to access an
Exchange server in scenarios where the number of CALs is uncertain.
Lesson 2
New Exchange Server 2010 Features for Exchange Server

2007 Administrators
The differences between Exchange Server 2010 and Exchange Server 2007 are more subtle than those
between Exchange Server 2010 and Exchange Server 2003. However, there are still some important
changes with remote management and database architecture. Additionally, Exchange Server 2010
provides new solutions for high availability, administration, and mailbox management.
In this lesson, you will learn about the most important features that are new for Exchange Server 2007
administrators.
Objectives
Describe the changes and enhancements in Exchange Server 2010.
Describe remote Windows PowerShell.
Describe Exchange Control Panel.
Describe the Exchange Server 2010 database architecture and storage improvements.
Describe high availability options for Mailbox servers in Exchange Server 2010.
Explain how Exchange Online Services integrates with Exchange Server 2010.
1-21
Discussion: Changes and Enhancements in Exchange Server 2010
Discuss the following areas with your instructor.

Question: What are some of the issues that you have with your current Exchange Server
2007 organization?
Question: If you could choose what to improve in Exchange Server 2007, what would you
pick?
Question: Name the three most important changes in Exchange Server 2010 that you know
about.
1-22
Remote Windows PowerShell
1-23
In Exchange Server 2007, the Exchange Management Shell consists of a Windows PowerShell host, a
Windows PowerShell snap-in that contains all Exchange cmdlets, and additional custom scripts. Loading
all three components enables you to run Exchange Server cmdlets on the Exchange server from which you
opened Exchange Management Shell.
When you open Windows PowerShell on a computer, you create a local session. Cmdlets, variables, and
other Windows PowerShell components within the same session can share data with each other. In
Exchange Server 2007, cmdlets are always run in the local session on the local Exchange 2007 server. Even
if you change an object that resides on a different server, you always run the cmdlet on the local
Exchange server.
Except for the Edge Transport server role, Exchange Server 2010 does not use the local session. Instead, it
uses remote Windows PowerShell.
Remote Windows PowerShell performs almost like Exchange Management Shell in Exchange Server 2007.
Other than feature changes that occurred between versions, you are likely to continue using Exchange
Management Shell as you did in Exchange Server 2007.
In Exchange Server 2010, when you click the Exchange Management Shell shortcut, Windows PowerShell
opens. Unlike in Exchange Server 2007, a Windows PowerShell snap-in for Exchange Server does not load.
Instead, Windows PowerShell connects to the closest Exchange 2010 server by using a newly required
component called Windows Remote Management 2.0. This component performs authentication checks,
and then creates a remote session for you to use. When the remote session is created, you are given
access only to the cmdlets and the parameters associated with the RBAC management roles assigned to
you. RBAC is discussed in more detail later in this course.
A benefit of remote PowerShell is that you do not need to install Exchange Server-specific tools on your
computer. With just Windows PowerShell and Windows Remote Management installed on any client
computer running either the Windows Vista operating system with SP1, Windows 7, or Windows Server
2008, you can connect to a remote Exchange Server 2010 computer and administrate it. However, while it
1-24
is possible to manage an Exchange 2010 server with just Windows PowerShell and Windows Remote
Management, we recommend that you install the Exchange management tools on any computer that you
use to manage Exchange Server 2010. Without the Exchange management tools installed, you need to
connect to the remote Exchange 2010 server manually, and you do not have access to the additional
capabilities that the Exchange management tools provide, such as the additional tools in the Exchange
Management Console toolbox.
1-25
As introduced in Lesson 1, Exchange Control Panel is a web-based administrative interface accessed by

any supported Internet browser, which you can use to perform administrative and management tasks.
Exchange Control Panel runs on Client Access servers, and you access it from the Options menu in
Outlook Web App or by accessing the /ecp virtual directory on the Client Access server.
Exchange Control Panel usage is based on RBAC, which means that it provides a different set of options
based on the users assigned RBAC permissions levels. You can assign permissions to Exchange Control
Panel users by assigning and customizing one of the preconfigured RBAC groups. Additionally,
administrators do not need to be mailbox-enabled users any more to use Exchange Control Panel.
Exchange Control Panel can be helpful when remote administrator access is needed and the Exchange
Server 2010 management tools are not or cannot be loaded on the computer from which the
administrator is working. For example, this might be when the administrator is at a conference and is
connecting from a kiosk computer.
When using Exchange Control Panel, end users can perform the following tasks.
Configure Outlook Web App options.
Manage email subscriptions.
Perform message tracking.
Manage group membership requests.
Manage mobile phones.
Exchange Server administrators and specialists with delegated rights can also perform the following tasks:
Create and manage mailboxes.
Manage distribution groups.
Perform legal discovery.
Track messages.
Use the role-assignment user interface.
Use Multi-Mailbox Search, which is not available through the Exchange Management Console.
1-26
In Exchange Server 2010 SP1, the scope of tasks and options for administrators is extended, as follows:
Create and configure transport rules.
Create and configure journaling rules.
Manage Exchange ActiveSync policies.
Manage RBAC role groups and user roles.
Create and manage resource mailboxes.
Create and manage security groups.
Create and manage Allow, Block, and Quarantine policies for mobile devices that support the
Exchange ActiveSync protocol.
1-27
Exchange Server 2010 Database Architecture and Storage Improvements
Exchange Server 2010 includes many improvements to the Exchange Server database architecture and
Extensible Storage Engine (ESE). These improvements provide better performance, and enhanced stability
and availability.
As compared to Exchange Server 2007, one of the most important changes is that databases are no
longer associated with storage groups. Storage groups have been removed in Exchange Server 2010.
In Exchange Server 2010, you manage mailbox and public folder databases in the Organization
Configuration node of the Exchange Management Console. In Exchange Server 2007, you perform
database management in the Server Configuration node. Although public folder database management
was moved from the Server Configuration node to the Organization Configuration node along with the
mailbox databases, public folder database functionality did not change for Exchange Server 2010.
In Exchange Server 2010, the Microsoft Exchange Information Store was updated to remove the
dependency of mailbox databases on the server object. The new store schema was also improved to help
reduce database input/output (I/O) by refactoring the tables used to store information. Refactoring the
tables allows higher logical contiguity and locality of reference. These changes eliminate the stores
reliance on the secondary indexes maintained by ESE. As a result, the store is no longer sensitive to
performance issues related to the secondary indexes. Investments in store schema and other ESE
optimizations have reduced input/output operations per second (IOPS) by up to 70 percent over
Exchange Server 2007 and up to 91.5 percent over Exchange Server 2003.
Header data for all mailbox items is stored in a single database table. This change makes the database
more efficient because it can process a single table for a mailbox during a client session, instead of
accessing different tables for different mailbox folders. A side effect of this schema change is that
Exchange Server no longer uses single instance storage (SIS) to keep just one copy of message content
per database. Most servers support multiple databases, so the efficiency gained from SIS is less and less as
time goes on. Also, there is a new database compression technology in Exchange Server 2010 that can
compensate for SIS removal.
1-28
Another ESE goal is to reduce the capital and operational costs of deploying Exchange Server 2010, and to
provide large mailboxes at a low cost. Disk space is inexpensive, and IT can take advantage of larger,
cheaper disks to reduce overall costs while providing larger mailboxes to users.
You can also potentially reduce storage costs and optimize for commodity storage by using just a bunch
of disks (JBOD) and Serial ATA (SATA) class hard disks. These options should only be considered if you are
deploying a sufficient number of mailbox database copies to provide redundancy for disaster recovery
scenarios.
High Availability Options for Mailbox Servers in Exchange Server 2010
1-29
High availability for Mailbox servers is one of the top priorities for messaging administrators to ensure
that user mailboxes are available as much as possible, and that data is not lost. Exchange Server 2007
decreased the costs of high availability and made site resilience more economical by introducing new
technologies such as local continuous replication (LCR), cluster continuous replication (CCR), and standby
continuous replication (SCR). Still, some challenges remained:
Some administrators were intimidated by the complexity of Windows failover clustering.
Each type of continuous replication was managed differently and separately.
Recovering from a failure of a single database on a large Mailbox server could result in a temporary
disruption of service to all users on the Mailbox server.
Site resilience solutions were not seamless.
Exchange Server 2010 includes significant core changes that integrate high availability, making it less
costly and easier to deploy and maintain than Exchange Server 2007. Organizations can now deploy a
fully redundant Exchange Server 2010 organization with just two Exchange servers, and can benefit from
database-level failovers. The organization can benefit from automatic, database-level failover capabilities
without requiring that the Exchange administrators become experts in Windows failover clustering.
Moreover, you can add site resilience to your existing high availability deployments with less complexity.
These improvements to Exchange Server 2010 over Exchange Server 2007 (and Exchange Server 2003)
were achieved by introducing the new DAG technology for highly available Mailbox servers.
A database availability group (DAG) is a collection of servers that provide the infrastructure for replicating
and activating database copies. The DAG uses continuous replication to maintain passive database copies
within the DAG, which:
Requires the failover clustering feature, although all installation and configuration tasks occur with
the Exchange Server management tools. Although a DAG requires the failover clustering feature,
Exchange Server 2010 does not use Windows failover clustering to handle individual database
1-30
failover; instead, it uses the Exchange Server 2010 Active Manager feature to control failover. Failover
clustering is used in some failure detection scenarios, such as server failure.
Uses an enhanced version of the continuous replication technology that was available in Exchange
Server 2007.
Can be created after you install the Mailbox server. You can set up a Mailbox server to host active
mailboxes, and add it to the DAG later.
Note You can only install the failover clustering feature on Windows Server 2008, or on
Windows Server 2008 R2 Enterprise Edition or Datacenter Edition. This means that you must
deploy Exchange Server 2010 on one of these server editions if you are planning to add the
servers to a DAG.
Allows you to move a single database between servers in the group without affecting other
databases. Failover clustering occurs per mailbox database, not for an entire server, which makes
Exchange Server 2010 more flexible than previous Exchange Server versions.
Allows up to 16 copies of a single database on separate servers. You can add up to 16 servers to a
DAG. This 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 VAN-EX1, then you must also store it in D:\Mailbox\DB
\Mailbox Database 1\ on all other servers that host Mailbox Database 1 copies.
Defines the boundary for replication, because only servers within the DAG can host database copies.
You cannot replicate database information to Mailbox servers outside the DAG.
Exchange Server 2010 extends and improves upon the continuous replication technology that Exchange
Server 2007 uses. The new high availability model using the DAG is a more flexible and resilient solution
than previous high availability solutions.
The Exchange Server 2010 database high availability model:
Enables a Mailbox server deployment that has no single point of failure.
Supports backups.
Allows up to 16 copies of a database. One or more of the database copies can be configured with up
to a 14-day lag time.
Can have multiple servers roles run on the same server as the Mailbox server.
Allows you to move a single database between servers.

Question: List some issues that you face with cluster continuous replication (CCR) in
Integration of Exchange Online Services with Exchange Server 2010
1-31
Both Exchange Server 2003 and Exchange Server 2007 administrators will discover a new deployment
option that is available in Exchange Server 2010. You can now integrate your messaging system with
Exchange Online Services. Exchange Online Services is part of the Business Productivity Online services
that Microsoft offers, and that was not available with previous Exchange Server versions.
Business Productivity Online
Business Productivity Online services is a set of Microsoft-hosted messaging and collaboration solutions,
including Microsoft Exchange Online, Microsoft SharePoint Online, Microsoft Office Live Meeting, and
Microsoft Office Communications Online. These services are available on a subscription basis.
Exchange Online Services

When you subscribe to Exchange Online Services, you can take advantage of the following features:
Email and calendar functions. Exchange Online delivers email services, including spam filtering,
antivirus protection, and mobile-device synchronization. Through Office Outlook 2007 and Outlook
Web App, you can use the advanced email, calendar, contact, and task management features of
Exchange Online.
Email coexistence and migration tools. The Business Productivity Online Standard Suite includes email
coexistence and migration tools. If you have AD DS and Exchange Server, the Microsoft Online
Services Directory Synchronization tool synchronizes your user accounts, contacts, and groups from
your local environment to Microsoft Online Services. This tool also makes your Microsoft Exchange
Global Address List (GAL) available in Exchange Online.
Exchange Online Services and Exchange Server 2010
Exchange Server 2010 provides additional functionality with Exchange Online Services. With Exchange
Server 2010, you can host some of the mailboxes in an internal Exchange Server organization, which is
displayed as the On-Premise Exchange organization in the Exchange Management Console. Additionally,
you can host some of your organizations mailboxes on Exchange Online. You can use Exchange
Management Console to move mailboxes to Exchange Online Services, and then manage those
mailboxes.
1-32
Lesson 3
Upgrading to Exchange Server 2010
1-33
When you decide to implement an Exchange Server 2010 messaging system in your organization, you
may need to maintain both your previous Exchange Server version and Exchange Server 2010, until you
ensure that the new implementation works correctly. While you upgrade the system, users will need to
continue to send email and schedule meetings. Any disruptions to normal business processes by the
Exchange Server 2010 upgrade should be minimal, if at all.
In this lesson, you will learn about upgrade paths from Exchange Server 2003 and Exchange Server 2007,
Objectives
Describe the options for upgrading the Exchange Server organization.
Plan and prepare for an Exchange Server upgrade.
Describe the order for Exchange Server 2010 role deployment.
Describe the migration preparation tools.
Options for Upgrading the Exchange Server Organization
1-34
Upgrading from Exchange Server 2003 and Exchange Server 2007 organizations requires you to perform
preparation steps prior to completing the organization upgrade and moving all resources to the new
organization. Prior to these steps, you need to decide which upgrade scenario and strategy will work best
for your organization.
You can only upgrade to Exchange Server 2010 from either Exchange Server 2003 or Exchange Server
2007, or from an organization that includes both Exchange Server 2003 and Exchange Server 2007.
Upgrading from earlier versions of Exchange server is not supported. Similarly, in-place upgrades are also
not supported, so the upgrade procedure will always include installing Exchange Server 2010 into an
existing organization, and then migrating the mailboxes and resources.
Reminder This course does not discuss migrations from non-Exchange Server messaging
systems to Exchange Server 2010.
Exchange Server Deployment Scenarios

The following terminology describes the options for deploying Exchange Server 2010 in organizations
with an existing messaging system:
Upgrade. In this scenario, you upgrade an existing Exchange Server organization to Exchange Server
2010. To perform the upgrade, install Exchange 2010 servers into an existing Exchange 2003 server or
Exchange Server 2007 organization, and then move the data and functionality from the existing
Exchange servers to the new Exchange 2010 servers. This is the easiest and least disruptive scenario
for integrating Exchange Server-based messaging systems, because the different Exchange Server
versions share configuration and recipient information automatically. However, you can implement
this option only if your organization is currently running Exchange Server 2003 or Exchange Server
2007.
1-35
Migration. In this scenario, you migrate from an existing Exchange Server organization to a new
Exchange Server organization without retaining any of the existing organizations Exchange Server
configuration data. In a migration, you install a new Exchange Server 2010 system, and then migrate
the previous Exchange Server versions data and services to Exchange Server 2010.
The term, migration, is also used to describe scenarios where you are migrating from another
messaging system to Exchange Server 2010.
If you use a migration scenario, it becomes significantly more complicated to configure

interoperability, as opposed to configuring coexistence in an upgrade. By default, the two messaging
systems share no information. Therefore, you must configure all connections between the systems.
Important When you perform a migration from one Exchange Server organization to
another, you also need to deploy a second AD DS forest, and then migrate all user accounts
to the second forest. Each Exchange Server organization requires a unique Active Directory
forest.
Single-Phase or Multiphase Upgrade Strategy
After you have decided to perform an upgrade, you must select the appropriate upgrade strategy. You
can choose between two options. The selection you make depends on your current environment, your
organizations requirements for data migration, and your project timeline.
Your need to decide whether to use a single-phase or multiphase upgrade:
Single-phase upgrade. In a single-phase upgrade, you replace your existing messaging system with
Exchange Server 2010, and then move all required data and services to the new system. In this type of
upgrade, you do not need to plan for an extended period of coexistence between the two systems.
Typically, you perform a single-phase upgrade over a short period, perhaps a weekend. This enables
you to shut down the entire messaging system, and then replace it with Exchange Server 2010. This
way, by Monday morning when users return to work, the new messaging system is operational. In this
scenario, the period of coexistence or interoperability is quite short.
While this upgrade is the fastest option, it also introduces a significant risk if the upgrade fails. This
scenario is feasible only for small organizations that must replace just a few servers, with only a small
number of users to migrate.
Multiphase upgrade with coexistence. In a multiphase upgrade, you upgrade one server or site at a
time to Exchange Server 2010. Because you spread this incremental upgrade over a longer period,
you decrease your organizations risk. However, in this scenario, you also must plan for coexistence or
interoperability. This is the best approach for medium-to-large organizations, because of their
complex messaging requirements.
In a coexistence scenario, where either Exchange Server 2003 or Exchange Server 2007 is still present,
multiple versions of Exchange Server communicate with each other and share data resources,
recipient information, and configuration information. Parts of the organization still use Exchange
2003 or Exchange Server 2007 functionality, while other parts have completed the upgrade to
If Exchange Server 2010 is coexisting with Exchange Server 2007, both versions of the servers will be
visible. However, Exchange Server 2003 coexistence with Exchange Server 2010 requires some
preparatory tasks that are described later in this course.
Question: What is the main difference between an upgrade and a migration? What
approach will your organization choose?
1-36
Planning for an Exchange Server Upgrade
1-37
Exchange Server deployment requires detailed planning, no matter which scenario you choose to utilize
(migration or upgrade). Proper planning reduces downtime and protects data from accidental failure
during migration. You should identify all necessary preparation tasks that you will need to perform before
you begin the deployment procedure.
Planning Considerations
For planning purposes, the most important decisions that you must make include:
Site order upgrade. When planning a multisite organization upgrade, you must remember that
Exchange Server 2010 does not support the upgrade of internal sites before you have upgraded
Internet-facing sites; this is because Client Access server-to-Client Access server proxying is only
supported from Exchange Server 2010 to Exchange Server 2007, and not the other way.
Consequently, you must upgrade Internet-facing sites first.
Active Directory upgrade. You need to add new attributes and extensions to your Active Directory
schema, and you need to prepare legacy Exchange objects for upgrade. Active Directory preparation
is discussed in Module 2.
Support for older clients. If you have older Office Outlook clients such as Office Outlook 2003, you
must enable support for them from within the Exchange Installation Wizard. You should also consider
upgrading clients to Office Outlook 2007 or Outlook 2010, so users can use the full set of Exchange
Server features, such as online archive and retention tags.
Service packs on legacy systems. Exchange Server 2010 deployment into existing Exchange Server
organizations is supported only if Service Pack 2 (SP2) is deployed on Exchange Server 2003 or on
Exchange Server 2007. In addition, the organization must be in Exchange native mode.
Order for Exchange Server 2010 Role Deployment
1-38
When you are installing Exchange Server 2010 into an existing Exchange Server 2003 or Exchange Server
2007 organization, it is important to perform the deployment and migration tasks in a specific order.
Otherwise, you might experience impaired functionality during the coexistence period.
Deploying Exchange Server 2010 in an Existing Exchange Server 2003 Organization

If an organization has only one Active Directory site, use the following process for deploying Exchange
Server 2010:
1.
Update all the Exchange 2003 servers to Exchange Server 2003 Service Pack 2 (SP2). Exchange Server
2010 Setup checks the server versions of all Exchange servers, and the requirement checks fail if a
server is not updated.
2.
Install the Exchange 2010 Client Access server. After you install the Client Access server, you should
use this as the primary connection point for all client connections. The Client Access server can
replace Exchange 2003 front-end servers as the initial connection point for Outlook Web App clients.
Note that clients will continue to connect to Exchange Server 2003 until the user mailboxes are
migrated to Exchange Server 2010.
3.
Install the Exchange 2010 Hub Transport server. When you install the Hub Transport server in an
Exchange Server 2003 environment, you are prompted for the name of an Exchange Server 2003
computer that will be the routing-group bridgehead server between the Exchange Server 2003
routing group and the Exchange Server 2010 legacy routing group.
4.
Install Exchange 2010 Unified Messaging servers (optional).
5.
Install the Exchange 2010 Mailbox servers. After the rest of the infrastructure is in place, you can
deploy the Exchange 2010 Mailbox servers, and then start moving mailboxes and public folders to the
new servers.
Note When you deploy Exchange Server 2010 in an existing organization, you can perform
a typical installation, and simultaneously install the Client Access server role, Hub Transport
server role, and the Mailbox server role.
1-39
Deploying Exchange Server 2010 in an Existing Exchange Server 2007 Organization

Complete the following steps to deploy Exchange 2010 servers in an existing Exchange Server 2007
organization:
1.
Update all the Exchange 2007 servers to Exchange Server 2007 SP2 or later. Exchange Server 2010
setup checks the server versions of all Exchange servers, and the requirement checks fail if a server is
not upgraded. Exchange Server 2007 SP2 includes several schema updates that are required for
interoperability with Exchange Server 2010.
If an organization only has one Active Directory site, use the following process for deploying
2.
Install the Exchange 2010 Client Access server. After you complete this installation, you should use
this as the primary connection point for all client connections. This means that you should modify the
Autodiscover settingsboth internally and externallyto point to the Exchange 2010 Client Access
server.
Note Later modules include more information on how to configure the client-access
settings, including the Autodiscover settings.
3.
Install the Exchange 2010 Hub Transport server. Both Exchange Server 2007 and Exchange 2010
Mailbox servers must use a Hub Transport server that is the same version as the Mailbox server for
routing messages in the same site.
4.
Install Exchange 2010 Unified Messaging servers. If you have deployed Unified Messaging in
Exchange Server 2007, add the Exchange 2010 Unified Messaging server to one of your organizations
dial plans.
5.
Install the Exchange 2010 Mailbox servers. After the rest of the infrastructure is in place, you can
deploy the Exchange 2010 Mailbox servers, and then start moving mailboxes and public folders to the
new servers.
6.
Install the Exchange 2010 Edge Transport servers. Exchange 2010 Edge Transport servers can
synchronize only with Exchange 2010 Hub Transport servers.
For organizations with multiple sites, there are typically two types of Active Directory sites: Internetaccessible sites, and non-Internet accessible sites. A single Exchange Server organization may have one or
more Internet-accessible sites. When upgrading Active Directory sites, you must begin your upgrade by
upgrading Internet-accessible sites, followed by non-Internet accessible sites.
Migration Preparation Tools
1-40
Microsoft provides several tools that can help you prepare your existing environment for deployment and
help you deploy Exchange Server 2010. We recommend that you run these tools prior to the Exchange
Server 2010 installation.
Exchange Server Best Practices Analyzer
Run the Exchange Server Best Practices Analyzer in the current Exchange Server 2003 or Exchange Server
2007 messaging environment. It is freely available as a download from the Microsoft Download Center.
Use this tool to compare your Exchange Server organization configuration against the current Microsoft
list of best practices. After performing a scan, this tool provides you with a detailed report about issues
that were identified on the current platform.
Exchange Deployment Assistant
The Exchange Deployment Assistant is a Web-based tool that can help you deploy Exchange Server 2010
in the existing environment. The Exchange Deployment Assistant wizard lists a series of questions about
your current environment, and based on your answers, provides instructions on how to deploy Exchange
Server 2010. Besides providing instructions on how to deploy Exchange Server 2010 on-premise, it can
also help you deploy Exchange Server 2010 in the cloud, or in coexistence between the cloud and onpremise. You can find this tool at http://go.microsoft.com/fwlink/?LinkId=213767.
Exchange Pre-Deployment Analyzer
You can use the Exchange Pre-Deployment Analyzer (ExPDA) to perform an overall topology readiness
scan of your environment. When you run ExPDA, it provides a detailed report that alerts you if there are
issues within your organization that could prevent you from deploying Exchange Server 2010. For
example, the ExPDA notifies you if you have not deployed the minimum required Exchange Server service
pack on all of your existing Exchange servers.
The checks performed by ExPDA are similar to the prerequisite checks implemented by Exchange Best
Practices Analyzer in the Exchange Server 2010 Setup program. In fact, ExPDA is based on the Exchange
1-41
Best Practices Analyzer engine. However, unlike Exchange Server 2010 Setup, this tool focuses only on
overall topology readiness, and not on the ability to run Exchange Server 2010 on the local computer.
Exchange 2010 Mailbox Server Role Requirements Calculator
The Exchange 2010 Mailbox Server Role Requirements Calculator is an Excel-based tool that you use
before deploying the Mailbox server role. Because the Mailbox server role is critical for your deployment,
Microsoft provides the calculator to help you determine the Mailbox Server role requirements for your
organization. The calculator allows you to input all the relevant information regarding your intended
designinformation such as database size, high availability, and number of serversand provides
recommendations for your Mailbox server role requirements.
Lab: Planning the Hardware Requirements for Exchange

Server 2010
Lab Setup
1-42
For this lab, you will use the available virtual machine environment. Before you begin the lab, complete
the following steps:
1.
On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.
2.
Right-click 10165A-NYC-CL1-B, and then click Start.
3.
10165A-NYC-CL1-B: Windows 7 computer in the contoso.com domain
Connect to the virtual machine. Log on to the virtual machine as Contoso\Administrator, with the
password, Pa$$w0rd.
Lab Scenario
You are working as a messaging administrator for Contoso, Ltd. Your organization is currently running
Exchange Server 2003, and is preparing to install Exchange Server 2010. As part of the project plan, you
need to identify the hardware requirements for the Exchange Server deployment. You must also include
the organizations requirements regarding key aspects of the Exchange Server 2010 deployment.
Exercise: Identifying the Hardware Requirements

Scenario
1-43
There are several goals for your Exchange Server 2010 deployment. Contoso wants to improve the current
messaging infrastructure, increase system availability, and avoid single points of failures as much as
possible.
The main tasks for this exercise are as follows:
1.
Review the Exchange Server 2010 design and requirements.
2.
Use the Mailbox Role Calculator to identify the hardware requirements.
Task 1: Review the Exchange Server 2010 design and requirements

While making an implementation plan, consider the following:
Contoso, Ltd. has several office locations across the world. These offices are connected to each other
with wide area network (WAN) links.
You need to ensure that if a single server fails, or if a single component on a server fails, the failure
affects as few users as possible.
You need to ensure that if the primary data center fails, the failure will affect as few users as possible,
and cause minimal data loss and downtime.
You must anticipate that office locations will grow by 30 percent over the next three years.
On some locations, the current storage area network (SAN) system will be used for mailbox storage.
These SAN systems already have redundancy implemented. On other locations, only direct access
storage (DAS) will be used.
You must provide high availability at the server level and on-site level.
Contoso is using Microsoft Office 2003 and Office 2010 on client computers.
Contoso wants to set up a mailbox size limit of 250 MB for all users, and a 500 MB limit for executives
or other exceptional cases. About 25 percent of the users will fall into the exceptional category. In
addition, for users, the organization wants to create archive mailboxes that are double the size of
their mailboxes to eliminate the use of .pst files.
According to the service level agreement (SLA) that Contoso has in place, Contoso is supposed to
restore any failed database within an hour of failure. However, the current backup system does not
have that capacity on all locations.
For the server design statistics, the following information is a standard profile that you can use for all
Mailbox servers. Based on the number of users in each location, it is possible to vary the amount of
random-access memory (RAM) and the size of the storage.
Server Hardware Characteristics
Processor: 2 x quad core processor, 3.3 gigahertz (GHz) per core
Database disks: 1,000 GB, 7.2K revolutions per minute (RPM) SATA 3.5
Log disks: 1,000 GB, 7.2K RPM SATA 3.5
Restore logical unit number (LUN) disks: 1,000 GB, 7.2K RPM SATA 3.5
Tier 1: User Messaging Statistics
Number of mailboxes: 25 percent of total on each Mailbox server
Messages sent/received per day: 20 sent/80 received
Average message size: 50 KB
Tier 2: User Messaging Statistics
Number of mailboxes: 75 percent of the total on each Mailbox server
Messages sent/received per day: 10 sent/40 received
Average message size: 25 KB
Task 2: Use the Mailbox Role Calculator to identify the hardware requirements
1.
On NYC-CL1, open the C:\Labfiles\E2010MailboxRoleCalculator1.2.xlsx spreadsheet.
2.
Enter the following data on the Input tab:
Exchange Environment Configuration
Server Multi-Role Configuration: No
High Availability Deployment: Yes
Number of Mailbox Servers hosting Active Mailboxes / DAG: 4
Number of Database Availability Groups: 1
Server Configuration
Exchange Data Configuration
Data Overhead Factor: 20%
Mailbox Moves / Week Percentage: 1%
Dedicated Maintenance / Restore LUN: Yes
LUN Free Space Percentage: 20%
Exchange I/O Configuration
I/O Overhead Factor: 20%
Additional I/O Requirement / Server: 0
Site Resilience Configuration
Site Resilient Deployment : Yes
Database Configuration
Mailbox Servers: Use the data from Task 1.
Maximum Database Size Configuration: Default
Tier 1 User Mailbox Configuration
Total Number of Tier- 1 User Mailboxes / Environment: 1,000
Projected Mailbox Number Growth Percentage: Use the data from Task 1.
Total Send/Receive Capability / Mailbox / Day: Use the data from Task 1.
1-44
3.
Average Message Size (KB): Use the data from Task 1.
Mailbox Size Limit (MB): Use the data from Task 1.
Personal Archive Mailbox Size Limit (MB): Use the data from Task 1.
Deleted Item Retention Window (Days): 14
Single Item Recovery: Enabled
Calendar Version Storage: Enabled
IOPS Multiplication Factor: 1
Desktop Search Engines Enabled (for Online Mode Clients): No
Predict IOPS Value: Yes
Total Number of Tier 2 User Mailboxes: Use the data from Task 1.
Primary Datacenter Server Disk Configuration
Database + Log: Use the data from Task 1
Restore LUN: Use the data from Task 1
1-45
Browse the Role Requirements, Activation Scenarios, LUN Requirements, Backup Requirements,
and other tabs to view the results, based on the data that you entered.
Results: After this exercise, you should have determined the hardware configuration for the Mailbox
server, based on available data.
To prepare for the next module
When you complete the lab, revert the virtual machines to their initial state and start the virtual machines
required for the next module. To do this, complete the following steps:
1.
On the host computer, start Hyper-V Manager.
2.
Right-click 10165A-NYC-CL1-B in the Virtual Machines list, and then click Revert.
1-46
3.
In the Revert Virtual Machine dialog box, click Revert.
4.
Right-click 10165A-NYC-DC1-A, and then in the Actions pane, click Start. Connect to the virtual
machine.
Important Start the 10165A-NYC-DC1-A virtual machine first, and ensure that it is fully
started before starting the other virtual machines.
5.
Wait for 10165A-NYC-DC1-A to start, and then start 10165A-NYC-EX03-A. Connect to the virtual
machine.
6.
Wait for 10165A-NYC-EX03-A to start, and then start 10165A-NYC-EX10-A. Connect to the virtual
machine.
7.
Wait for 10165A-NYC-EX10-A to start, and then start 10165A-NYC-CL1-A. Connect to the virtual
machine.
1-47
Module Review and Takeaways
Review Questions
1.
Which tools can you use to manage Exchange Server 2010?
2.
What is the main difference between Exchange Server 2010 Standard Edition and Exchange Server
2010 Enterprise Edition?
3.
What factors should you consider when purchasing new servers for your Exchange Server 2010
deployment?
Common Issues Related to Exchange Server 2010 Deployments
Identify the causes for the following common issues related to Exchange Server 2010 deployment, and fill
in the troubleshooting tips. For answers, refer to relevant lessons in the module.
Issue
The organization is currently running
Exchange 2000 Server.
You cannot migrate from Exchange
Server 2007 to Exchange Server 2010.
After deploying Exchange Server 2010
in an Exchange Server 2003
environment, new administrative and
routing groups with weird names
appear in the Exchange Server 2003
System Manager.
Troubleshooting tip
Real-World Issues and Scenarios
1-48
1.
Your organization would like to automate the creation of user mailboxes for employees based on
their status in your organizations human resources system. What can you use to perform this
automation?
2.
Your organization wants to reduce administrative costs. One suggestion is to give department heads
and administrative assistants the necessary access to manage departmental and project-based
groups. What can you use to accomplish this task?
Tools
Tool
Use for
Where to find it
Exchange
Management Console
Administration of Exchange
Server organization
Start menu
Exchange
Management Shell
Management and
administration of Exchange
Server organization, and for
bulk management tasks
Start menu
Exchange Control
Panel
Common administrative tasks
Exchange Control Panel URL
Deploying Microsoft Exchange Server 2010
2-1
Module 2
Contents:
Lesson 1: Installing Exchange Server 2010
2-3
2-26
Lesson 2: Verifying the Exchange Server 2010 Installation
2-32
2-44
Module Overview
2-2
Regardless of your current Exchange Server version, one of the most important tasks in preparing for a
Microsoft Exchange Server 2010 installation is to ensure that your Active Directory Domain Services
(AD DS) environment is ready. As with previous Exchange Server versions, AD DS stores almost all
configuration and recipient information that Exchange Server 2010 uses. In addition, to ensure that the
upgrade and coexistence process works smoothly, you must correctly integrate Exchange Server 2010
with your current Exchange Server messaging environment.
To correctly perform installation and integration, you should be aware of the infrastructure, hardware, and
software requirements for introducing Exchange Server 2010 into your current messaging environment.
Finally, you should know how to verify, troubleshoot, and secure the installation.
This module describes how to prepare for, and perform an installation of Exchange Server 2010 Service
Pack 1 (SP1) in your Exchange Server 2003 or Exchange Server 2007 environment.
Note This module does not describe the entire process for upgrading an existing Exchange
Server organization to Exchange Server 2010. This module covers only the deployment of
Exchange 2010 servers in the organization. Subsequent modules provide more details about
the additional steps that must be taken to complete the upgrade.
Objectives
Perform an Exchange Server 2010 SP1 installation.
Verify Exchange Server installation and integration with Exchange Server 2003 and Exchange Server
2007 environments.
Lesson 1
Installing Exchange Server 2010
2-3
Prior to Exchange Server 2010 installation, the most important requirement is the Active Directory
deployment. However, you should also be aware of the Exchange Server 2010 infrastructure and server
requirements before you perform an installation. Because virtualization is one choice for deploying new
Exchange servers, you should also consider the options for deploying Exchange Server 2010 as a virtual
machine. Exchange Server 2010 allows you to perform unattended installations, which is described at the
end of this lesson.
Objectives
Describe how Exchange Server 2010 integrates with an Exchange Server 2003 organization.
Use the Exchange Pre-Deployment Analyzer tool.
Describe the infrastructure requirements for Exchange Server 2010.
Describe the software and hardware requirements for Exchange Server 2010.
Prepare AD DS for Exchange Server 2010.
Describe the considerations for deploying Exchange Server 2010 as a virtual machine.
Describe the process for installing Exchange Server 2010.
Describe the options for an unattended installation.
How Exchange Server 2010 Integrates with an Exchange Server 2003

Organization
2-4
During coexistenceuntil all of your resources are moved to Exchange Server 2010you must support
both your older Exchange Server version and Exchange Server 2010. Because Exchange Server 2007 and
Exchange Server 2010 are quite similar, their coexistence is relatively easy to achieve. However, Exchange
Server 2003 and Exchange Server 2010 coexistence requires more preparation, because of the many
architectural and administrative changes between these two versions.
Note Remember that you can only deploy Exchange Server 2010 in an Exchange Server
2003 organization that operates in native mode.
Exchange Server 2010 Integration with Administrative and Routing Groups in

Exchange Server 2003
As discussed in Module 1, Exchange Server 2003 uses administrative groups and routing groups to
manage administrative privileges and message routing. Role based access control (RBAC) and the Active
Directory site routing topology replace these features in Exchange Server 2010. To support coexistence
between Exchange Server 2003 and Exchange Server 2010, all Exchange 2010 servers are placed in a
single administrative group automatically when you install Exchange Server 2010. This administrative
group is recognized in the Exchange System Manager as Exchange Administrative Group
(FYDIBOHF23SPDLT).
Note You must use Exchange System Manager and utilities to manage the Exchange 2003
servers. In Exchange Server 2010, you must manage the Exchange 2010 servers and
mailboxes by using Exchange Management Console or Exchange Management Shell.
However, you can use Exchange Management Console to view some attributes on the
Exchange 2003 servers.
2-5
Additionally, the Exchange Server 2010 routing group is recognized in Exchange System Manager as
Exchange Routing Group (DWBGZMFD01QNBJR) within the Exchange Administrative Group
(FYDIBOHF23SPDLT). The names in brackets are actually the shift replacement ciphers for the phrase
Exchange12ROCKS.
The new administrative group provides coexistence between Exchange Server 2003 and Exchange Server
2010 only. You can maintain your Exchange Server 2003 administrative groups during the migration to
Exchange Server 2010. The functionality provided by these administrative groups does not change, but
you cannot add any Exchange 2010 servers to existing administrative groups.
During the installation of the first Exchange 2010 Hub Transport server, you must specify an Exchange
2003 bridgehead server on which to establish the first routing group connector. We recommend that you
select a bridgehead server located in a hub routing group, or in a routing group that has many mailboxes.
The routing group connector links the routing group where the Exchange 2003 server resides with the
Exchange Server 2010 routing group. The Exchange Server 2010 routing group includes all Exchange 2010
servers, regardless of the Active Directory site in which they reside.
Note Do not move the Exchange 2010 servers out of Exchange Routing Group
(DWBGZMFD01QNBJR), and do not rename Exchange Routing Group
(DWBGZMFD01QNBJR) by using a low-level directory editor. Neither action is supported.
Exchange Server 2010 must use this routing group for communication with Exchange Server
2003.
Suppressing the Propagation of Minor Link State Updates
When connecting the Exchange Server 2010 routing group to the Exchange Server 2003 organization, you
must consider the performance of link state routing. The Exchange 2003 servers maintain a link state
routing table that is updated through communication with the routing group master. Each connector that
has been created between Exchange Server 2003 routing groups is considered a link. The Exchange 2003
servers determine how a message is routed inside the organization by using the cost assigned to these
links. If a particular routing group is inaccessible by using the lowest-cost route, the link state table is
updated by the routing group master to show the state of that link as down. This data is communicated
to every routing group in the Exchange Server 2003 organization. When the data is received, the link state
table is updated, and another route is calculated.
The Exchange 2010 Hub Transport servers do not use link state routing. Thus, Exchange Server 2010
cannot propagate link state updates, and it does not recalculate routes. Hub Transport servers always try
to communicate directly with other Hub Transport servers. Exchange Server 2010 takes advantage of the
existing Active Directory site topology to eliminate the need to define a separate routing topology. It uses
the Active Directory IP site links and the costs associated with them to calculate the least costly route
between Hub Transport servers in different Active Directory sites.
Because of the differences in how the two Exchange versions implement message routing, there is the
potential that message routing loops could be created between Exchange Server 2003 and Exchange
Server 2010. To ensure that this does not happen, you must suppress the propagation of minor link state
updates by adding the SuppressStateChanges registry key on the Exchange 2003 bridgehead servers for
the routing group connector to the Exchange Server 2010 routing group. You should navigate to
HKLM\System\CurrentControlSet\Services\RESvc\ Parameters, create a DWORD value,
SuppressStateChanges, and then set it to 1.
2-6
You do not need to suppress minor link state updates if your organization only has one routing group. It
is also not required if the organization uses hub and spoke routing topology. However, it is required when
an organization has multiple routing groups with multiple routes between locations.
Some administrators may require more control over Exchange Server routing. You can modify the default
direct relay behavior so that an Active Directory site acts as a hub site. This means that all messages to be
relayed through the Hub Transport servers are forced to pass through the Active Directory site. For even
more control over message routing behavior, you can assign an Exchange Server-specific cost to Active
Directory IP site links.
In Exchange Server 2010, messages are never transported between Mailbox servers directly. When a user
sends a message, it first goes from the Mailbox server to the Hub Transport server. The Hub Transport
server then decides if the message should be delivered to another Hub Transport server in another site,
delivered to the same or another Mailbox server in the same site, or forwarded to a next hop server for
Internet delivery.
Exchange Server 2010 relies on the underlying network infrastructure to transport a message. In the
Exchange Server 2010 organization, messages are relayed directly from the source server to the target
server, reducing the number of hops a message takes during delivery.
Exchange Server 2010 Namespace Integration with the Exchange Server 2003
Namespace
An important part of the upgrade process is configuring a legacy host name for Microsoft Outlook Web
Access and other web-based services, and then associating that host name with your Exchange Server
2003 infrastructure. This is a necessary step if your organization has a significant number of mailboxes that
cannot all be moved from Exchange Server 2003 to Exchange Server 2010 during the downtime
scheduled for the upgrade, and if your Exchange Server 2003 organization supports Outlook Web Access
for Internet users.
If your organization has a small number of mailboxes, and you can schedule downtime over an evening or
a weekend to move all the mailboxes, you do not need to configure a legacy host name.
After you configure a legacy host name and associate it with your Exchange Server 2003 infrastructure,
and then associate your current host name with your Exchange Server 2010 infrastructure, users will
experience a seamless transition because of single sign on between the two Exchange versions. Exchange
Server 2010 will redirect users from the Exchange 2010 Client Access server to the Exchange 2003 frontend server. Users will not have to learn a new URL to access Microsoft Outlook Web Access (which is now
named Outlook Web App in Exchange Server 2010) or reconfigure their Microsoft Exchange ActiveSync
devices. Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4), and
Outlook Anywhere users can also continue to access their mailboxes without interruption.
Demonstration: Microsoft Exchange Pre-Deployment Analyzer Tool
2-7
You can use Microsoft Exchange Pre-Deployment Analyzer to verify that your current Exchange Server
environment is ready for you to deploy Exchange Server 2010. Exchange Pre-Deployment Analyzer
provides a detailed report that alerts you if there are any issues within your organization that could
prevent you from deploying Exchange Server 2010.
The checks performed by Exchange Pre-Deployment Analyzer are similar to the prerequisite checks
implemented with Exchange Best Practices Analyzer in the Exchange Server 2010 Setup program.
However, unlike Exchange Server 2010 Setup, this tool focuses only on overall topology readiness and not
the ability to run Exchange Server 2010 on the local computer. The scan also performs a deep analysis of
each existing Exchange 2003 or Exchange 2007 server to verify that it has the necessary updates and
configuration in-place to support the upgrade to Exchange Server 2010.
In addition to running Exchange Pre-Deployment Analyzer, you can also use Exchange Deployment
Assistant to create an initial set of implementation instructions for deploying Exchange Server 2010.
Exchange Deployment Assistant provides a series of questions about your current environment and about
your deployment goals. You can use Exchange Deployment Assistant to plan for both an on-premise
upgrade to Exchange Server 2010 and a migration to Exchange Online.
Note You can download the Exchange Pre-Deployment Analyzer tool from
http://go.microsoft.com/fwlink/?LinkId=213764. The Exchange Deployment Assistant tool
can be accessed at http://go.microsoft.com/fwlink/?LinkId=213765.
Demonstration Steps
2-8
1.
From All files (E:), access ExPDA.msi to open the Microsoft Exchange Server Pre-Deployment
Analyzer Installation Wizard.
2.
After the installation, use the Exchange Server Pre-Deployment Analyzer Wizard to configure and run
a new scan.
3.
Review the report for critical items.
Infrastructure Requirements for Exchange Server 2010
2-9
Before you upgrade to Exchange Server 2010, you need to ensure that your organization meets Active
Directory and Domain Name System (DNS) requirements for implementation of Exchange Server 2010.
These requirements differ from those for Exchange Server 2003 and Exchange Server 2007, so you must
check them all before starting your deployment.
Active Directory Requirements
You must meet the following Active Directory requirements before you can upgrade to Exchange Server
2010:
The domain controller that is the schema master must have Windows Server 2003 SP1 or newer,
Windows Server 2008, or Windows Server 2008 R2 or later installed. By default, the schema master
runs on the first Windows domain controller installed in a forest.
In each of the sites where you deploy Exchange Server 2010, at least one global catalog server must
be installed, and must be running Windows Server 2003 SP1 or newer, Windows Server 2008, or
Windows Server 2008 R2 or later.
The Active Directory domain and forest functional levels must run Windows Server 2003 or newer.
If you have a resource forest configuration, or multiple forests, and users from different forests need
to access mailboxes in an Exchange Server 2010 organization, you must configure a trust between the
forests. In this case, the minimum forest functional level must be Windows Server 2003.
DNS Requirements
Before you install Exchange Server 2010, you must configure DNS correctly in your Active Directory forest.
All servers that run Exchange Server 2010 must be able to locate Active Directory domain controllers,
global catalog servers, and other Exchange servers.
Software Requirements for Exchange Server 2010
Besides checking infrastructure requirements, Exchange Server 2010 also requires a specific software
before you can upgrade your Exchange Server organization.
Important Exchange Server 2010 is available only in 64-bit versions, which means that you
can install all componentsincluding the Exchange Management toolsonly on 64-bit
operating systems.
All Exchange 2010 servers must have the following software installed:
Microsoft .NET Framework 3.5 SP1 or later
Windows Remote Management (WinRM)
Windows PowerShell Version 2
Hotfixes for Windows Server 2008 and Windows Server 2008 R2
Note You need to download and install Microsoft .NET Framework 3.5 SP1 or later, WinRM,
and Windows PowerShell Version 2 only if you are installing Exchange Server 2010 on a
Windows Server 2008 SP2 server. These components are included with Windows Server 2008.
Additionally, all updates required for Exchange Server 2010 SP1 are included with Windows
Server 2008 R2 SP1.
Important If you are installing Exchange Server 2010 on Windows Server 2008 SP2, the
NET TCP Port Sharing service must be configured to start automatically before starting the
Exchange Server 2010 installation. This service is required by the Exchange Mailbox
Replication service. In Windows Server 2008 R2, this service is configured to start
automatically.
2-10
Server Role Installation Requirements
2-11
Each server role in Exchange Server 2010 has different installation requirements. All server roles, except for
the Edge Transport server role, require some web server components, such as Internet Information
Services (IIS).
The following table summarizes the requirements for each server role.
Server role
Software requirements
Mailbox server role
Microsoft Office 2010 Filter Pack

The default Web Server (IIS) server role along with the following role
services:
IIS 6 metabase compatibility
IIS 6 Management Console
Basic authentication
Windows authentication
.NET Framework extensibility
Client Access server

role
The default Web Server (IIS) server role and the following role services:
ISAPI extensions
Digest authentication
Dynamic content compression
Windows Communication Foundation (WCF) Hypertext Transfer Protocol
(HTTP) Activation feature
Remote procedure call (RPC) over HTTP Proxy feature
Hub Transport server

role
Edge Transport server

role
A configured DNS suffix

The Active Directory Lightweight Directory Services (AD LDS) server role
Unified Messaging
server role
The Desktop Experience feature. This feature installs the required Windows
Media Player audio/video codecs.
Microsoft Office 2010 Filter Pack

Note Starting with Exchange Server 2010 SP1, administrators can choose to install the
Windows Server roles and features during the Exchange Server installation. Additionally, be
aware that installing Exchange Server 2010 on a Windows Server 2008 computer might add
additional roles or role services to the server. For example, when you perform a typical
Exchange Server 2010 installation, the File Server role is added along with additional Web
Server (IIS) role services.
Installation Requirements for Installing Management Tools on Windows Vista or

Windows 7
2-12
You can install the Exchange Server 2010 management tools on computers running 64-bit versions of the
Windows Vista or Windows 7 operating systems. Before installing the management tools, ensure that
the following components are installed:
.NET Framework 3.5 SP1 or later
WinRM
Windows PowerShell Version 2
Note The .NET Framework 3.5 SP1 or later, WinRM, and Windows PowerShell Version 2
components are included with Windows 7, but must be downloaded and installed for
Windows Vista.
Hardware Requirements for Exchange Server 2010
2-13
Determining the hardware requirements for Exchange Server 2010 is more complex than simply reading
the specifications provided by Microsoft. Besides the general specifications that provide information
about minimum supported hardware configuration, many other factors can influence the Exchange Server
hardware design.
First, the server role that will be installed has a significant influence on hardware specifications. For
example, the Mailbox server will probably require more powerful hardware than the Hub Transport server.
Second, many organizations combine Exchange Server roles on a single computer, and in that case, you
must merge hardware requirements for various roles.
Processor
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. Be aware that Intel Itanium IA64 processors are not supported.
Memory
We recommend that you consider the server maximum memory configuration when deciding on the
amount of RAM memory that you need for Exchange Server 2010. Different server architectures have
different memory limits. Check the following technical specifications for the server to determine the most
cost-efficient maximum memory configuration for your servers:
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 could
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
2010 is compatible in terms of speed.
Memory module size. Consider the largest memory module size that the server will support.
Generally, the larger the memory module, the more expensive. For example, two 2 GB DDR SDRAM
2-14
memory modules generally cost less than one 4 GB DDR SDRAM memory module, and two 4 GB DDR
SDRAM memory modules generally cost less than one 8GB DDR SDRAM memory module. Make sure
the maximum memory module size allows you to meet your target memory requirements for
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 must sometimes be
installed in pairs.
Be aware that 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.
The following table describes the minimum requirements and recommended maximum configurations
where these terms are defined as follows:
Minimum supported. This is the minimum memory configuration suitable for Exchange 2010 servers.
The minimum hardware requirements must be met to receive support from Microsoft Customer
Service and Support.
Recommended maximum. This is the recommended memory configuration for specific server roles.
Recommended maximum is defined as the upper limit of viable processor and memory
configurations based on price and performance. The recommended maximum configuration is a
guideline. It is not a support criterion, and it does not take into account the resource requirements of
third-party applications that might access or be installed on the server. The recommended maximum
configuration may change over time, based on price changes and technology advancements.
Exchange Server role
Minimum supported
amount of memory
Maximum recommended amount of

memory
Edge Transport
4 GB
1 GB per core (4 GB minimum)
Hub Transport
4 GB
Client Access
4 GB
Unified Messaging
4 GB
Mailbox
4 GB
4 GB plus 3-30 MB additional memory per

mailbox:
Client Access/Hub Transport

combined role (Client Access
and Hub Transport server
roles running on the same
physical server)
4 GB
Multiple roles (combinations

of Hub Transport, Client
Access, and Mailbox server
roles)
8 GB
4 GB plus 3-30 MB additional memory per

mailbox
Note The Edge Transport and Hub Transport server roles do not require substantial
quantities of memory to perform well in optimal conditions. Generally, 1 GB of RAM per
processor core (4 GB minimum total) is sufficient to handle all but the most demanding
loads. Most deployments will be optimally configured with the recommended memory
configuration of 1 GB per processor core (4 GB minimum total). In general, memory
utilization on Client Access servers has a linear relationship with the number of client
connections and the transaction rate. Based on the current recommendations of 2 GB per
core processor and memory configurations, a Client Access server will be balanced in terms
of memory and processor utilization, and it will become processor-bound at approximately
the same time it becomes memory-bound.
Disk Drive Space
2-15
When choosing and configuring disk drives for an Exchange Server 2010 installation, you should consider
following:
You need at least 1.2 GB on the drive on which you install Exchange Server 2010.
All partitions that Exchange Server 2010 will use must be formatted with the NTFS file system.
An additional 500 MB of available disk space for each Unified Messaging 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 an Edge Transport server or Hub Transport
server with at least 500 MB of free space.
Space required for the Mailbox server role cannot be determined without knowing the number of
mailboxes, mailbox sizes, high availability requirements, and so on. 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:
You should plan for a minimum of two processor cores. The recommended number of processor
cores is eight, while 24 is the maximum recommended number.
You should 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 and Hub Transport server roles.
You should 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.
To accommodate the Client Access and Hub Transport server roles on the same server as the Mailbox
server role, you should reduce by 20 percent the number of mailboxes per core calculation, based on
the average client profile.
You can deploy multiple Exchange server roles on a Mailbox server that is a DAG member. This means
that you can provide full redundancy for the Mailbox, Hub Transport, and Client Access server roles
on just two Exchange 2010 servers.
Preparing Active Directory for Exchange Server 2010
2-16
Before upgrading to Exchange Server 2010, you must prepare AD DS by extending the schema partition
with new classes and attributes, and by making additional changes to groups and permissions in the
Active Directory domain partition.
To do this, you need to run the Exchange Server 2010 Setup command to prepare the Active Directory
forest for installation. You can use the Setup command with the switches listed in the following table.
Note For upgrades from Exchange Server 2003, you must run Exchange Server 2010 Setup
by using the /PrepareLegacyExchangePermissions parameter and the /PrepareAD parameter.
For upgrades from Exchange Server 2007, you only need the /PrepareAD parameter.
Setup parameter
Explanation
/PrepareAD
/OrganizationName:
organizationname
Prepares the global Exchange Server objects in AD DS, creates the Exchange
Universal Security Groups in the root domain, and prepares the current
domain.
The OrganizationName parameter is only required when installing Exchange
Server 2010 in a new organization. It is not required in an upgrade scenario.
Must be run by a member of the Enterprise Admins group.
/PrepareLegacy
ExchangePermissions
Required for upgrades from Exchange Server 2003.

Modifies the permissions assigned to the Enterprise Exchange Servers group
to allow the Recipient Update Service to run.
Must be run by a member of the Enterprise Admins group. Exchange Server
2003 administrators must also have Full Administrator permissions.
/PrepareSchema
Prepares the schema for the Exchange Server 2010 installation. Connects to
the schema master and imports Lightweight Directory Access Protocol Data
Interchange Format (LDIF) files to update the schema with Exchange Server
Setup parameter
Explanation
2-17
2010 specific attributes.

Must be run by a member of the Enterprise Admins and Schema Admins
groups.
/PrepareDomain
/PrepareDomain
domainname
/PrepareAllDomains
Prepares the domain for Exchange Server 2010 by creating a new global
group called Exchange Install Domain Servers, and adding the group to the
Exchange Servers universal security group in the forest root domain.
Not required in the domain where /PrepareAD is run.
Can prepare specific domains by adding the domains fully qualified domain
name (FQDN), or prepare all domains in the forest.
Must be run by a member of the Enterprise Admins and Domain Admins
groups.
Important You must first prepare the Active Directory forest root domain.Administrators
with rights to the Schema Admins and the Enterprise Admins group do not need to run
/PrepareLegacyExchangePermissions and /PrepareSchema before running /PrepareAD. If
your account has the right permissions, you can run /PrepareAD instead of the other
parameters. With the right permissions, /PrepareAD also configures the legacy permissions
and makes the required schema changes.
Changes Made by the PrepareLegacyExchangePermissions Parameter
Exchange Server 2003 administrators must use the /PrepareLegacyExchangePermissions parameter so that
the Exchange Server 2003 Recipient Update Service functions correctly after they update the Active
Directory schema for Exchange Server 2010. In Exchange Server 2003, the Recipient Update Service
updates some mailbox attributessuch as the proxy addresson mail-enabled user objects. It does this
because the computer account for the server on which the Recipient Update Service runs is in the
Exchange Enterprise Servers group.
When you extend the Active Directory schema in preparation for Exchange Server 2010, the schema is
modified so that the server running Recipient Update Services no longer has the required permissions to
update the recipient properties. Running setup with the /PrepareLegacyExchangePermissions parameter
modifies the permissions to ensure that the server can continue to modify recipient properties.
Note For more information about the /PrepareLegacyExchangePermissions setup

parameter, see the Prepare Legacy Exchange 2003 Permissions page on the Microsoft
TechNet website at http://go.microsoft.com/fwlink/?LinkId=213766
Note You can run Exchange Server 2010 Setup with the
/PrepareLegacyExchangePermissions parameter on a computer running Windows Server
2008 or newer, or on a computer running the Windows Vista operating system with SP2 or
newer.
Changes Made by the PrepareAD Parameter
2-18
The /PrepareAD parameter makes the following changes to enable coexistence between Exchange Server
versions:
Creates the Active Directory universal security group, ExchangeLegacyInterop. This group receives
permissions that allow the Exchange 2003 servers to send email to the Exchange 2010 servers.
Creates the Exchange Server 2010 administrative group, called Exchange Administrative Group
(FYDIBOHF23SPDLT).
Creates the Exchange Server 2010 routing group, called Exchange Routing Group
(DWBGZMFD01QNBJR).
Additionally, running Setup with the /PrepareAD parameter performs the following actions:
Prepares the schema if /PrepareSchema has not been run, and if the command is run by a Schema
Admins group member
Prepares the permissions if /PrepareLegacyExchangePermissions has not been run, and if the
command is run by an Enterprise Admins group member
Creates the Microsoft Exchange container in the Configuration partition in AD DS, and populates the
container with all the child containers required to install Exchange Server 2010 computers
Creates a new organizational unit (OU) in the Active Directory domain named Microsoft Exchange
Security Groups, and then creates the security groups that are used to assign permissions in the
Exchange Server organization.
Note The security groups that are created in the Microsoft Exchange Security Groups OU
are management role groups that use RBAC to assign permissions in the Exchange Server
organization.
Question: Why should you run Setup with the /PrepareLegacy ExchangePermissions
parameter in environments where Exchange Server 2003 is present?
2-19
Considerations for Deploying Exchange Server 2010 as a Virtual Machine
Exchange Server 2010 allows you to deploy all server roles, except the Unified Messaging server role, as
virtual machines. Using virtualization for deploying servers greatly improves resource usage, and simplifies
deployment and management. Along with the benefits, you should consider the issues for deploying
virtual machines in your current Exchange Server environment.
Benefits of Using Virtual Machines
Deploying Exchange 2010 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.
The benefits of deploying Exchange Servers as virtual machines are:
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 just 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 maturity to provide a critical
service like messaging in a virtual environment. Implementing virtualization does introduce an
additional level of complexity because you now need 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.
Note Microsoft supports Exchange Server 2010 running as virtual machines on Windows
Server 2008 Hyper-V and for solutions that have been validated through the Windows
Server Virtualization Validation Program. See http://go.microsoft.com/fwlink/?LinkId=179865
for more details.
Considerations for Deploying Exchange Server 2010 Servers as Virtual Machines

While running Exchange Server 2010 as a virtual machine provides some benefits, you should also
consider the following issues:
2-20
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 of the benefits of running virtual machines is that you can configure high availability within the
virtual machine environment. For example, you can deploy Quick Migration in Windows Server 2008
Hyper-V, or Live Migration in Windows Server 2008 R2 Hyper-V. However, Microsoft does not
support running both database availability groups (DAGs) and a virtual machine-based high
availability solution. If you require high availability, you should use the Exchange Server 2010 solution.
DAGs provide failover features that are not available in virtual machine-based, high-availability
solutions. Some of the DAG features include multiple copies of the database, backing up the database
on the passive node, and application-aware failovers.
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 an 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. Network attached storage is not supported.
You must allocate sufficient storage space for each Exchange Server guest machine on the host
machine 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. Additionally, for
each Exchange Server guest machine, you must allocate sufficient storage for the message queues on
Hub Transport and Edge Transport servers, and sufficient storage for the databases and log files on
Mailbox servers. You should host the storage that Exchange Server uses in disk spindles that are
separate from the storage that hosts the guest virtual machines operating system.
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 applicationssuch as Exchange Server, Microsoft SQL Server, or AD DSon the root
machine. The root machine should be dedicated to running guest virtual machines.
Running Exchange servers as virtual machines can complicate performance monitoring. The
performance data between the host and virtual machine is not consistent, because the virtual
machine uses only some part of the hosts resources.
One of the most common performance bottlenecks for Mailbox servers is network input/output (I/O).
When you run Mailbox servers in a virtual environment, the virtual machines have to share 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
2-21
can consume all of the available I/O bandwidth, which makes it impractical to host additional virtual
machines on the physical server.
If you are planning to deploy Exchange Server 2010 as a virtual machine, ensure that you plan the
virtual hardware requirements carefully. Running Exchange Server 2010 as a virtual machine does not
change the hardware requirements for the Exchange server. You must assign the same hardware
resources to the Exchange Server virtual machine as you would assign to a physical server running the
same workload.
If Exchange Server 2010 is deployed inside a virtual machine that runs on a Windows Server 2008 R2
SP1 host, we recommend that you do not use the Dynamic Memory feature on the virtual machine.
Instead, configure static RAM allocation.
Important Do not use virtual machine snapshots with Exchange Server deployed inside a
virtual machine in a production environment. You should never use snapshots because using
them can result in unexpected performance.
Question: Why is using snapshots with Exchange Server virtual machines not recommended?
Question: Why is Unified Messaging not supported as a role for virtualization?
Process for Installing Exchange Server 2010
2-22
The Exchange Server 2010 Setup program guides you through the installation process. Similar to
Exchange Server 2007 (but not Exchange Server 2003), this setup program provides you with all necessary
options to install and configure critical Exchange Server services. The following steps provide a high-level
installation overview:
1.
Install the prerequisite software. If you install Exchange Server 2010 on Windows Server 2008 R2, the
correct versions of Windows PowerShell and WinRM are installed already.
2.
To start the installation, run setup.exe from the installation source. The Setup program verifies that
the correct software is installed on the computer. You can also use setup.com if you want to perform
the installation from the command line.
3.
After you finish installing all the required software, you can proceed with installing Exchange Server
2010.
Important If you are installing Exchange Server 2010 SP1, you can add all the necessary
Windows components during the setup process, instead of installing them manually before
setup.
4.
Exchange Server 2010 allows you to install additional language packs. You can decide to install the
language packs during the installation.
5.
The Installation Type page of the wizard presents you with the option to perform either a Typical
Exchange Server Installation, or a Custom Exchange Server Installation. The typical installation installs
the Hub Transport server role, the Client Access server role, the Mailbox server role, and the
corresponding Exchange Management tools. Custom installation allows you to determine which roles
you want to install.
6.
2-23
If you are installing Exchange Server 2010 SP1 as a first messaging server, you will be offered the split
permissions security model for your organization. This model is used by organizations that separate
the management of Exchange Server 2010 objects from Active Directory objects. Split permissions
enable organizations to assign specific permissions and related tasks to specific groups within the
organization.
This split permissions model helps maintain standards and workflows, and helps control change in the
organization. Split permissions typically make a distinction between the creation of security principals
in AD DSsuch as users and security groupsand the subsequent configuration of those objects.
This reduces the chance of unauthorized access to the network by controlling who can create objects
that grant access to it. Most often, only Active Directory administrators can create security principals,
while Exchange Server administrators can manage specific attributes on existing Active Directory
objects.
7.
Normally, you would be prompted for the Exchange organization name if this is the first Exchange
2010 server in the deployment, and you do not run Setup with the /PrepareAD parameter. However,
because Exchange Server 2003 and Exchange Server 2007 organizations already have an organization
name, you will not be prompted for the organizations name when upgrading the Exchange
organization.
8.
If you chose the Mailbox server role, the Exchange Setup program asks you whether you have any
Office Outlook 2003 clients in the organization. If you select Yes, Exchange Setup creates the public
folders required by these clients for the offline address book, and for sharing Free/Busy information.
9.
If you opt to install the Client Access server role, you can also configure the external domain name for
the Client Access server. Clients use this external domain name to connect to the server from the
Internet.
Note Exchange Server 2010 supports Office Outlook 2003 SP1 or newer clients. The only
Entourage version supported by Exchange Server 2010 is Entourage 2008, Web Services
Edition. Previous versions of Entourage used WebDAV, a feature that is no longer available in
Unattended Installation Options
2-24
You can use the command line to perform an unattended Exchange Server 2010 installation. When you
use the command line, you can use parameters to install specified roles or configure other setup options.
The following table lists some of the command-line setup.com parameters.
Parameter
Options
/mode, /m
/roles, /r
The following list are valid

role names:
HubTransport, HT, H
ClientAccess, CA, C
EdgeTransport, ET, E
Mailbox, MB, M
UnifiedMessaging, UM, U
ManagementTool, MT, T
/PrepareAD, /p
Install (the default)

Upgrade
Uninstall
RecoverServer
None
/OrganizationN
ame
organizationna
me
/targetdir, /t
Description
Controls what the setup program does.

You can use the Upgrade mode only to upgrade
from Exchange Server 2010 RTM to Exchange
Server 2010 SP1.
Specifies which roles you want to install. If you

specify multiple roles, separate them with commas.
You cannot combine the Edge Transport role with
any other server role.
Prepares AD DS for installation.
Specifies the name to give the new Exchange Server

organization.
This parameter is required if you are installing the
first server in an organization.
A valid path
Specifies into which folder to install Exchange

Server 2010. Default: %%programfiles%%\
Microsoft\Exchange Server.
2-25
Parameter
Options
Description
/DomainControl
ler, /dc
The name of a suitable

domain controller
Specifies which domain controller setup will be read

and written from, during installation.
/NewProvisione
d
Server, /nprs
Server name
Creates a placeholder server object in AD DS so that

you can delegate the setup of a server.
/ServerAdmin
User or group
Specifies an account that will have permissions to a

provisioned Exchange server.
Note To run an unattended installation with setup parameters, you must run setup.com or
setup, rather than setup.exe. To see all the parameters available for use with setup.com, run
the command with the /? parameter.
The syntax for the setup.com command is as follows.
Setup.com [/roles:<roles to install>] [/mode:<setup mode>] [/console]
[/?][/targetdir:<destination folder>] [/prepareAD] [/domaincontroller]
For example, if you want to install Exchange Server 2010 into the default path and specify the Hub
Transport, Client Access, and Mailbox server roles, you would enter the following command.
Setup.com /r:H,M,C
Lab Setup
2-26
For this lab, you will use the available virtual machine environment. Before you begin the lab, perform the
following steps:
1.
2.
Ensure that the 10165A-NYC-DC1-A, 10165A-NYC-EX03-A, 10165A-NYC-EX10-A, and 10165A-NYCCL1-A virtual machines are running.
3.
10165A-NYC-DC1-A: Domain controller in the contoso.com domain
10165A-NYC-EX03-A: Exchange 2003 SP2 server in the contoso.com domain
10165A-NYC-EX10-A: Member server in contoso.com domain
10165A-NYC-CL1-A: Windows 7 client workstation
If required, connect to the virtual machines. Log on to the virtual machines as

Contoso\Administrator, with the password, Pa$$w0rd.
Lab Scenario
You are a messaging administrator at Contoso, Ltd. Your organization is currently running Exchange
Server 2003, and is preparing to install Exchange Server 2010 SP1.
Before installing Exchange Server 2010 SP1, you must verify that the AD DS environment and the
Exchange Server 2003 deployment are ready for the installation.
The server administration team has deployed a Windows Server 2008 R2 server that you can use to deploy
the first Exchange 2010 SP1 server in the test organization. You need to verify that the server meets all
prerequisites for installing Exchange Server 2010 SP1.
2-27
If you identify any prerequisites that are not met in the current AD DS and server configuration, you need
to update the environment to meet them.
After you prepare the environment, continue with the Exchange 2010 server installation. You should also
install Exchange Management tools on a Windows 7 client computer.
2-28
Exercise 1: Evaluating the Requirements for an Exchange Server Installation

Scenario
The server administration team has deployed a Windows Server 2008 R2 server that you can use to deploy
the first Exchange 2010 SP1 server in the test organization.
You need to verify that the Active Directory environment and the server meet all prerequisites for
installing Exchange Server 2010 SP1. Use the checklist in the following table to verify that the prerequisites
are met.
Prerequisite
Achieved?
Active Directory domain controllers: Windows Server 2003

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

Windows Server 2003 or newer
Yes or No
DNS requirements
Yes or No
Exchange Server 2010 schema changes
Yes or No
AD DS management tools
Yes or No
.NET Framework 3.5 or newer
Yes or No
WinRM
Yes or No
Windows PowerShell version 2
Yes or No
Microsoft Filter Pack 2.0
Yes or No
Web Server (IIS) server role along with the following role
services:
ISAPI extensions
Digest authentication
Dynamic content compression
Yes or No
Windows Server 2008 features

WCF HTTP activation
RPC over HTTP Proxy
Yes or No

1.
Evaluate the Active Directory requirements.
2.
Evaluate the DNS requirements.
3.
Evaluate the Exchange Server 2003 prerequisites.
4.
Evaluate the server requirements.
Task 1: Evaluate the Active Directory requirements

1.
On NYC-DC1-A, evaluate whether the domain controller requirements are met by verifying the
operating system version.
2.
Evaluate whether the domain and forest functional level requirements are met.
3.
Use Adsiedit.msc to evaluate the AD DS configuration partition, and to examine the current
Exchange Server 2003 entries.
Task 2: Evaluate the DNS requirements
2-29
Use Ipconfig, Ping, and NSLookup to evaluate DNS name resolution functionality from NYC-EX10-A
to domain controller NYC-DC1-A.
Task 3: Evaluate the Exchange Server 2003 prerequisites
On NYC-EX10-A, browse to C:\Labfiles and run the Exchange Pre-Deployment Analyzer to verify that
there are no issues that can block Exchange Server 2010 deployment.
Task 4: Evaluate the server requirements

1.
On NYC-EX10-A, evaluate whether the required Windows Server 2008 features, including the required
AD DS administration tools, are installed.
2.
Evaluate whether the IIS components are installed.
3.
Evaluate whether the prerequisite software is installed.
Results: After this exercise, you should have evaluated requirements for the Exchange Server 2010 SP1
installation in your existing Active Directory environment.
Exercise 2: Preparing for an Exchange Server 2010 SP1 Installation

1.
Prepare Exchange Server 2003 for the Exchange Server 2010 SP1 installation.
2.
Prepare AD DS for the Exchange Server 2010 SP1 installation.
2-30
Task 1: Prepare Exchange Server 2003 for the Exchange Server 2010 SP1 installation
Based on the report that the Exchange Pre-Deployment Analyzer generated, make the necessary
changes on Exchange Server 2003 to support the Exchange Server 2010 SP1 deployment as follows:
On NYC-EX03-A, run registry editor, and navigate to

HKLM\System\CurrentControlSet\Services\RESvc\Parameters.
a.
Create a DWORD value named, SuppressStateChanges, and configure it with the decimal
value 1.
b.
Close the registry editor, and then restart the Simple Mail Transfer Protocol (SMTP), the
Microsoft Exchange Routing Engine, and the Microsoft Exchange MTA Stacks services
for the change to take effect.
Task 2: Prepare AD DS for the Exchange Server 2010 SP1 installation

1.
In Hyper-V Manager, connect C:\Program Files\Microsoft

Learning\10165\Drives\Exchange2010SP1.iso as the DVD drive for NYC-DC1-A.
2.
Install the AD DS Administration tools feature on NYC-EX10-A by using Server Manager.
3.
ON NYC-DC1-A, from a command prompt, run the Exchange Server Setup program with the
/PrepareAD parameter.
Results: After this exercise, you should have prepared your organization for the Exchange Server 2010 SP1
installation.
Exercise 3: Installing Exchange Server 2010 SP1

1.
Install the Exchange Management Console on a Windows 7 client computer.
2.
Install Exchange Server 2010 SP1 with the typical configuration.
2-31
Task 1: Install the Exchange Management Console on a Windows 7 client computer

1.

Learning\10165\Drives\Exchange2010SP1.iso as the DVD drive for NYC-CL1-A.
2.
Start the Exchange installation Wizard, and install the Exchange Management Console.
Task 2: Install Exchange Server 2010 SP1 with the typical configuration
1.
On NYC-EX10-A, start the Exchange Server 2010 installation.
2.
Click to install only the languages on the DVD.
3.
Perform a Typical Exchange Server Installation.
4.
Enable the option that allows Setup to install necessary Windows roles and features.
5.
On the Mail Flow Settings page, configure NYC-EX03 as the Exchange 2003 server.
Results: After this exercise, you should have installed the Exchange Management Console and Exchange
Server 2010.
Lesson 2
Verifying the Exchange Server 2010 Installation
2-32
After you install the necessary Exchange 2010 server roles in your Exchange Server 2003 or Exchange
Server 2007 organization, you should verify the installation and perform post-installation tasks. These
include securing Exchange Server 2010, and installing additional third-party software, if necessary. This
lesson describes the post-installation tasks that you should perform.
Objectives
After completing this lesson you will be able to:
Verify an Exchange Server 2010 installation.
Verify Exchange Server 2010 integration with Exchange Server 2003 and Exchange Server 2007.
Describe the tools for managing Exchange Server 2010 coexistence with Exchange Server 2003 or
Use the Microsoft Exchange Server Best Practices Analyzer (ExBPA) tool.
Troubleshoot an Exchange Server 2010 installation.
Verifying the Exchange Server 2010 Installation
2-33
After the Exchange Server 2010 installation completes, you must verify that the installation completed
correctly. Complete the verification before you configure Exchange Server 2010, to ensure that everything
you configure will work as expected.
First, run the Get-ExchangeServer cmdlet in Exchange Management Shell. This cmdlet displays all the
Exchange 2010 server roles that are installed on the specified server. This allows you to verify that all roles
are installed.
Next, complete the following steps:
1.
Review the Exchange setup log files. The installation process creates several log files that the
C:\ExchangeSetupLogs directory stores. Review the setup logs for errors that may have occurred
during installation. Logs files that you can review are :
ExchangeSetup.msilog. This file contains information about the extraction of the Exchange Server
2010 code from the installer file.
Install-AdminToolsRole-[date and time].ps1. Setup generates this file, which contains the steps
that Exchange Server 2010 used to install the Exchange administration tools.
Install-BridegeheadRole-[date and time].ps1. Setup generates this file, which contains the steps
that Exchange Server 2010 used to install the Hub Transport server role.
Install-ClientAccessRole-[date and time].ps1. Setup generates this file, which contains the steps
that Exchange Server 2010 used to install the Client Access server role.
Install-ExchangeOrganization-[date and time].ps1. Setup generates this file, which contains the
steps that Exchange Server 2010 used to create the Exchange Server organization.
Install-MailboxRole-[date and time].ps1. Setup generates this file, which contains the steps that
Exchange Server 2010 used to install the Mailbox server role.

2.
2-34
InstallSearch.msilog. This file contains information about the extraction of the Search service that
Exchange Server 2010 uses.
Review the Exchange Server 2010 folder structure. Browse to the location where you installed
Exchange Server 2010, and check for the following folders:
Bin. Contains the applications and extensions that you can use to manage Exchange Server 2010.
ClientAccess. Contains the configuration files for the Client Access server role.
ExchangeOAB. Contains the Exchange Offline Address book files that Exchange Web Services
makes available.
GroupMetrics. Contains information about distribution groups and distribution-group

membership that MailTips uses.
Logging. Contains various log files.
Mailbox. Contains schema files, .dll files, database files, and database log files for the mailbox
databases and public folder databases.
Public. Contains several .dll and .xml files.
RemoteScripts. Contains a script used only by the Exchange Management Console.
Scripts. Contains Exchange Management Shell scripts that you can use to retrieve anti-spam
statistics and perform other tasks.
Setup. Contains .xml configuration files and data.
TransportRoles. Contains folders and files that the Hub Transport Server role uses.
Working. Contains an empty folder.
3.
Ensure that the Exchange Management Console opens and displays the installed Exchange 2010
server.
4.
Create a user account with a mailbox, and connect to that mailbox by using an Outlook client or
Outlook Web App.
5.
Check for the status of Exchange Server 2010 services. The following table describes the services that
belong to Exchange Server 2010, and their default startup mode.
Service name
Default startup
mode
Description
Microsoft Exchange
Active Directory
Topology
Automatic
Provides Active Directory topology information to several

Exchange Server 2010 components.
Microsoft Exchange
Address Book Service
Automatic
Manages the client address book connections for

Microsoft Exchange Anti- Automatic

Spam Update
Provides Forefront Protection 2010 for Exchange Server

anti-spam update service.
Microsoft Exchange
EdgeSync
Provides synchronization services between the Hub

Transport and Edge Transport server roles. It connects to
an AD LDS instance on the subscribed Edge Transport
servers over a secure LDAP channel to synchronize data
between with a Hub Transport server.
Automatic
Service name
Default startup
mode
2-35
Description
Microsoft Exchange File

Distribution
Automatic
Provides offline address book replication between

Mailbox servers and Client Access servers.
Microsoft Exchange
Forms-Based
Authentication Service
Automatic
Provides forms-based authentication for Outlook Web

App, and the Exchange Control Panel.
Microsoft Exchange
IMAP4
Manual
Provides IMAP4 services.
Microsoft Exchange
Information Store
Automatic
Manages the Exchange store process, and the mailbox

and public folder databases.
Microsoft Exchange Mail

Submission
Automatic
Submits messages from the Mailbox server to the Hub

Transport server.
Microsoft Exchange
Mailbox Assistants
Automatic
Provides background processing of mailboxes in a

mailbox database.
Microsoft Exchange
Mailbox Replication
Automatic
Processes mailbox moves and move requests.
Microsoft Exchange
Monitoring
Manual
Enables monitoring tools to interact with the diagnostic

cmdlets.
Microsoft Exchange
POP3
Manual
Provides POP3 services to clients.
Microsoft Exchange
Protected Service Host
Automatic
Provides a host for several services that must be

protected from other services.
Microsoft Exchange
Replication
Automatic
Provides replication services used for continuous

replication.
Microsoft Exchange RPC

Client Access
Automatic
Manages MAPI connections from Outlook clients on the

Client Access server.
Microsoft Exchange
Search Indexer
Automatic
Provides indexing for the mailbox content.
Microsoft Exchange
Server Extension for
Windows Server Backup
Manual
Enables the use of Windows Server Backup to back up

and restore Exchange databases.
Microsoft Exchange
Service Host
Automatic
Provides a host for several Exchange services.
Microsoft Exchange
System Attendant
Automatic
Provides services for legacy Outlook clients, and manages

address lists and address books.
Microsoft Exchange
Throttling
Automatic
Limits the number of user operations.
Microsoft Exchange
Transport
Automatic
Provides SMTP server and message transport

functionality.
2-36
Default startup
mode
Description
Microsoft Exchange
Transport Log Search
Automatic
Provides remote search capability for the transport logs.
Microsoft Search
(Exchange Server)
Manual
Provides indexing services for the mailbox and public

folder databases.
Service name
Question: What should you do if some of the Exchange Server 2010 services do not start?
Verifying Exchange Server 2010 Integration with Previous Versions of

Exchange Server
2-37
One of the most important aspects of your upgrade is the coexistence of Exchange Server 2010 with
Exchange Server 2003 or Exchange Server 2007. To ensure that all of your resources successfully transition
to Exchange Server 2010, both systems must work in parallel with minimum-to-zero downtime for users.
You must check the coexistence functionality after the Exchange Server 2010 installation is complete.
Exchange Server 2003 administrators should complete the following tasks:
Verify that the legacy routing and administrative group was created, and that the Exchange Server
2010 object is present.
Verify that the routing group connector between the Exchange Server 2003 routing group and the
legacy Exchange Server 2010 routing group was created.
Both Exchange Server 2003 and Exchange Server 2007 administrators should complete the following
tasks:
Create a test mailbox on Exchange Server 2010, and then send an email message to a mailbox that
resides on Exchange Server 2003. If the email message arrives on the Exchange Server 2003 side, reply
to it, and then verify that the reply message appears in the Exchange Server 2010 test mailbox.
Create a mailbox on Exchange Server 2003, and then try to move it to Exchange Server 2010.
Check that both Outlook Web Access and Outlook Web App are working for users with mailboxes on
Exchange Server 2003 and Exchange Server 2010, respectively. At this point, you will need to check
each service separately because the integration of the services has not yet been configured.
Try to send a message to the Internet from an Exchange Server 2010 mailbox, and from the Internet
to a user with a mailbox on Exchange Server 2010, and to a user on the older Exchange Server
version.
Check that any public folders are accessible for all users in the organization by using Outlook.
2-38
If these checks complete successfully, it is very likely that your coexistent Exchange Server infrastructure is
working properly.
Question: If you cannot send an email message between Exchange Server 2003 and
Exchange Server 2010, what is the first thing that you should check?
Tools for Managing the Different Versions of Exchange Server During

Coexistence
2-39
Each version of Exchange Server provides its own tools for managing an Exchange Server organization.
While Exchange Server 2003 administrators use Exchange System Manager and scripts, Exchange Server
2007 and Exchange Server 2010 administrators can utilize a variety of administrative tools, such as
Exchange Management Console and Exchange Management Shell. As described in Module 1, Exchange
Server 2010 also provides the Exchange Control Panel.
Using these management tools in a mixed Exchange Server environment can be a tricky job. In general,
we recommend using the management tool that corresponds with the Exchange Server version you are
using at the moment. However, there are some exceptions to this general rule.
For example, although routing groups and routing group connectors are a feature in Exchange Server
2003, in a mixed environment with Exchange Server 2010, you cannot use Exchange System Manager to
manage the Exchange Server 2010 routing group or any routing group connectors that include an
Exchange 2010 Hub Transport server as either a source server or a target server. You must use Exchange
Management Shell to create and manage routing group connectors; they are not visible through
Exchange Management Console.
As another example, Exchange Server 2010 now creates system address lists in a new container. Recipients
that are created or modified by using the Exchange Server 2003 or Exchange Server 2007 management
tools are not stamped with these system address lists. As a result, they are not seen by the Exchange
Server 2010 Get-Recipient cmdlet.
To fix this issue, you must enable Active Directory virtual list view (VLV). After you have completed the
upgrade of an existing Exchange Server 2003 or Exchange Server 2007 organization to Exchange Server
2010, and have decommissioned your Exchange 2003 or Exchange 2007 servers, you must enable Active
Directory VLV. To enable VLV for Exchange Server 2010, run the Enable-AddressListPaging cmdlet.
You can only view and manage the Exchange Server 2010 configuration objects by using Exchange
Management Console in Exchange Server 2010.
Demonstration: Microsoft Exchange Server Best Practices Analyzer
2-40
Microsoft Exchange Server Best Practices Analyzer (ExBPA) automatically examines an Exchange Server
deployment, and then determines whether the configuration meets with Microsoft best practices.
Microsoft performs periodic updates on the definitions that ExBPA uses, so they typically reflect the latest
version of the Microsoft best practices recommendations. We recommend running ExBPA after you install
a new Exchange 2010 server, upgrade an existing Exchange server, or make configuration changes. You
can find ExBPA in the Toolbox node of Exchange Management Console.
ExBPA provides four types of health check scans:
Health Check. This test checks for errors, warnings, nondefault configurations, recent changes, and
other configuration information. This scan checks the health of your Exchange Server organization,
and you can use it for troubleshooting. When you select the Performance check option, a sampling of
performance data is taken over a two-hour period.
Permission Check. This test verifies that permissions are properly configured on the selected servers.
Connectivity Check. This test verifies that network connectivity is available to the selected servers.
Baseline. This scan allows you to select specific properties, configure baseline values for those
properties, and then scan for servers to find deviations from the baseline values.
In this demonstration, your instructor will run ExBPA and review the generated reports.
Note For more information about ExBPA, see Exchange Server Best Practices Analyzer Help
that is available with the Exchange Server Best Practices Analyzer Tool.
Demonstration Steps
2-41
1.
On NYC-EX10-A, open Exchange Management Console, and then click Toolbox.
2.
Start the Best Practices Analyzer, clear the options to check for updates and to join the customer
improvement program, and then proceed to the Welcome page.
3.
Start a new scan. Click to perform a Health Check scan on the server that you just installed.
4.
When the scan completes, view the following tabs and reports:
Critical Issues
All Issues
Recent Changes
Informational Items
Tree reports
Other reports
Troubleshooting an Exchange Server 2010 Installation
2-42
The Exchange Server 2010 installation should complete successfully if you meet all prerequisites. However,
if the installation does not complete properly, it is important for you to follow a consistent
troubleshooting process.
Troubleshooting Process
Each time you troubleshoot any application or service, you should follow a consistent process. This
ensures that you do not miss steps, and that problems are resolved quickly.
1.
Identify the problem. Before you begin applying fixes to your Exchange Server 2010 installation, be
sure that you identify the exact problem. Applying inappropriate fixes could create additional
problems. To identify an installation problem, check the setup and event logs for errors.
2.
Identify potential fixes for the problem. You cannot always fix problems by using the most obvious
solution. Your search for potential fixes should be methodical and include multiple sources, such as
Microsoft TechNet, the Microsoft Knowledge Base, forums and newsgroups, and suggestions in event
logs.
3.
Prioritize the potential fixes. After identifying a list of potential fixes, prioritize them based on how
likely they are to fix the problem, and how long implementation will take. In most cases, try quick
fixes before long and involved fixes, even if the longer fix is more likely to resolve the problem.
4.
Test only one fix at a time. It is essential that you test only one fix at a time. Do not implement three
fixes, and then see if the problem is fixed. Implementing one fix at a time ensures that you
understand which solution fixed the problem. When you implement multiple fixes, the first fix may
resolve the problem, while a second fix may introduce additional problems.
When you implement a fix, be sure to record the changes you make. Then, if the fix does not resolve
the problem, you can undo the changes before trying another solution.
5.
2-43
Record the problem resolution. Documentation is an essential part of problem resolution. If the same
problem occurs later, documentation of the previous solution makes it easier to resolve the current
issue. Disseminating that knowledge to others in the organization may prevent the problem from
occurring again.
Potential Problems and Resolutions

Some common installation problems and solutions are:
.Net Framework TCP Port Sharing Service not set to start automatically. You must set this service to
start automatically on Windows Server 2008 R2.
Insufficient disk space. Your server might not have the necessary disk space to install Exchange Server
2010. To resolve this, either increase your servers disk space or remove unnecessary files to create
more free space.
Missing software components. Your server might not have all of the required software components
for the server roles you want to implement. To resolve this, determine the required software
components, download them if necessary, and then install them.
Incorrect DNS configuration. Exchange Server 2010 relies on global catalog servers to perform many
operations, and uses DNS to find global catalog servers. If the DNS configuration is incorrect, your
server might not be able to find a global catalog server. To verify the problem, use tools such as
ipconfig, nslookup and dcdiag. To resolve the problem, ensure that the Exchange 2010 server and
domain controllers are all using the appropriate internal DNS servers.
Incorrect domain functional level. All domains with Exchange Server 2010 recipients or servers must
be at Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003 functional level. To
resolve this problem, raise the domain functional level to the appropriate functional level.
Insufficient Active Directory permissions. When you install Exchange Server 2010, you need sufficient
permissions to extend the Active Directory schema and modify the Active Directory configuration
partition. To perform the initial schema extension, you must be a member of the Enterprise Admins
and Schema Admins groups.
Insufficient Exchange Server permissions. To install Exchange Server 2010 into an Exchange Server
2003 or Exchange Server 2007 organization, you must be a member of the Exchange Admins group.
You also must run Setup.com with the /PrepareLegacyExchangePermissions parameter. Wait for
replication throughout the Exchange Server organization before you continue.
2-44
Lab Setup
following steps:
1.
2.
Ensure that the 10165A-NYC-DC1-A, 10165A-NYC-EX03-A, 10165A-NYC-EX10-A, and 10165A-NYCCL1-A virtual machines are running.
3.
10165A-NYC-DC1-A: Domain controller in the contoso.com domain
10165A-NYC-EX03-A: Exchange 2003 SP2 server in the contoso.com domain
10165A-NYC-EX10-A: Member server in contoso.com domain
10165A-NYC-CL1-A: Windows 7 client workstation

Lab Scenario
You have completed the installation of the first Exchange 2010 server at Contoso, Ltd. You now need to
verify that the installation completed successfully. You should also ensure that the installation meets the
best practices recommended by Microsoft. Additionally, you need to verify the integration between
Exchange Server 2003 and Exchange Server 2010.
Exercise 1: Verifying an Exchange Server 2010 Installation

Scenario
2-45
In this exercise, you will perform a series of tests to ensure that the Exchange Server 2010 installation
completed successfully.
1.
View the Exchange Server 2010 services.
2.
View the Exchange Server 2010 folders.
3.
View the configuration partition of AD DS for Exchange Server 2010 objects and values.
4.
Create a new user, send a test message, and review the delivery report.
5.
Run the ExBPA tool.
Task 1: View the Exchange Server 2010 services

1.
On NYC-EX10-A, open the Services console.
2.
Review the status for each Exchange Server service.
Task 2: View the Exchange Server 2010 folders
Using a Windows Explorer window, browse to C:\Program Files\Microsoft\Exchange Server\v14.

Verify that the ClientAccess, Mailbox, and TransportRoles folders are displayed. The roles are installed
as part of the typical setup.
Task 3: View the configuration partition of AD DS for Exchange Server 2010 objects
and values
1.
On NYC-DC1-A, run the ADSIEDIT console.
2.
Connect to the configuration partition.
3.
Expand the following containers:
4.
CN=Configuration
DC=Contoso, DC=com
CN=Services
CN=Microsoft Exchange
CN=ContosoOrg.
Review the values in the Administrative Groups container, the CN=RBAC container, and the CN=Role
Assignments container. Ensure that objects from both Exchange Server 2003 and Exchange Server
2010 are present.
Task 4: Create a new user, send a test message, and review the delivery report
1.
On NYC-EX10-A, open Exchange Management Console.
2.
Under Recipient Configuration - Mailbox, create a new mailbox with a new user account named,
TestUser, and the password, Pa$$w0rd.
3.
Using Windows Internet Explorer, open https://NYC-EX10/owa.
4.
Log on as Contoso\TestUser, and then send a message to the TestUser account.
5.
Ensure that that message arrives in the Inbox.
6.
Select Sent Items, expand the test message conversation node, right-click the message, and then
click Open Delivery Report.
Task 5: Run the ExBPA tool

1.
On NYC-EX10-A, start ExBPA.
2.
Run a Health Check scan with the name of Post-Installation Test. Scan only
NYC-EX10.
3.
Review the information in the ExBPA report.
Results: After this exercise, you should have verified Exchange Server 2010 installation.
2-46
Exercise 2: Verifying Exchange Server Version Interoperability

Scenario
2-47
After successful deployment of Exchange Server 2010, you must ensure that Exchange Server 2003 and
Exchange Server 2010 coexist properly.
1.
Send a test message between Exchange Server versions.
2.
Test a mailbox move between Exchange Server versions.
Task 1: Send a test message between Exchange Server versions

1.
On NYC-CL1, open Outlook Web App by using Internet Explorer, Log on as Contoso\TestUser, with
the password, Pa$$w0rd.
2.
Send a test email message to Candy Spoon.
3.
Open Outlook Web Access on NYC-EX03. Open an Internet Explorer window, and then type
http://nyc-ex03/exchange/candy. Log on as Candy, with the password, Pa$$w0rd, and verify that the
message arrived.
4.
Reply to the message.
5.
Re-open Outlook Web App on NYC-CL1, and then verify that the reply from Candy Spoon arrived.
Task 2: Test a mailbox move between Exchange Server versions

1.
On NYC-EX10, open Exchange Management Console.
2.
Run a New Local Move request to move Candy Spoons mailbox from NYC-EX03 to NYC-EX10.
3.
Verify that the move request completed successfully.
4.
On NYC-EX10, log on to Outlook Web App as Candy, with the password, Pa$$w0rd.
Results: After this exercise, you should have verified the Exchange Server version interoperability.
When you complete the lab, revert the virtual machines to their initial state. To do this, complete the
following steps:
1.
2.
Right-click 10165A-NYC-DC1-A in the Virtual Machines list, and then click Revert.
3.
4.
Repeat the steps for 10165A-NYC-EX03-A, 10165A-NYC-EX10-A, and 10165A-NYC-CL1-A.
5.
Right-click 10165A-NYC-DC1-B, and then in the Actions pane, click Start. Connect to the virtual
machine
Important Start the 10165A-NYC-DC1-B virtual machine first, and ensure that it is fully
2-48
6.
Wait for 10165A-NYC-DC1-A to start, and then start 10165A-NYC-EX03-B. Connect to the virtual
machine.
7.
Wait for 10165A-NYC-EX03-A to start, and then start 10165A-NYC-EX10-B. Connect to the virtual
machine.
8.
Wait for 10165A-NYC-EX10-A to start, and then start 10165A-NYC-EX11-B. Connect to the virtual
machine.
2-49
Review Questions
1.
The Exchange Server 2010 installation fails. What information sources can you use to troubleshoot the
issue?
2.
What factors should you consider while purchasing new servers for your Exchange Server 2010
deployment?
3.
How would the deployment of additional Exchange 2010 servers vary from the deployment of the
first server?
Common Issues Related to Deploying Exchange Server 2010
Identify the causes for the following common issues related to deploying Exchange Server 2010, and
explain the troubleshooting tips. For answers, refer to relevant lessons in the module.
Issue
You start the Exchange Server 2010
installation and receive an error
message stating that you do not have
sufficient permissions.
You start the installation and the
prerequisite check fails.
You run setup with the /PrepareAD
parameter, and receive an error
message.
Troubleshooting tip
2-50
1.
An organization has a main office and multiple smaller branch offices. What criteria would you use to
decide whether to install an Exchange 2010 server in a branch office? What additional factors should
you consider if you decide to deploy an Exchange 2010 server in the branch office?
2.
An organization has deployed AD DS within two different forests. What issues will this organization
experience when they deploy Exchange Server 2010?
3.
An organization is planning to deploy Exchange 2010 servers as virtual machines running on Hyper-V,
in Windows Server 2008 R2. What factors should the organization consider in their planning?
Best Practices Related to Deploying Exchange Server 2010

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

Unified Messaging server
Mailbox server
You can deploy the Edge Transport server at any time, but it does not integrate automatically with
your organization until you deploy a Hub Transport server.
Configuring Mailbox Servers
3-1
Module 3
Contents:
Lesson 1: Upgrading the Mailbox Server Role
3-3
Lesson 2: Configuring Mailbox Server Roles
3-8
Lesson 3: Configuring Public Folders and Public

Folder Databases in Exchange Server 2010
3-23
3-31
3-2
Module Overview
This module describes how to configure the Microsoft Exchange Server 2010 Mailbox server role after
you install it in an Exchange Server 2003 or 2007 organization. As in previous versions, the Mailbox server
role in Exchange Server 2010 stores all of the mailbox and public folder data, and it is a critical component
in an Exchange Server messaging system. You will learn about databases and database storage
considerations. You will also learn how to manage the number and size of databases in Exchange Server
2010.
Objectives
Understand the coexistence of Exchange 2010 Mailbox server role with previous versions of Exchange
Server during the upgrade process.
Configure the Exchange 2010 Mailbox server role.
Configure public folders and public folder databases.
Lesson 1
Upgrading the Mailbox Server Role
3-3
When you install Exchange Server 2010 in an Exchange Server 2003 or Exchange Server 2007
organization, we refer to that scenario as coexistence. Coexistence is supported even if all three versions of
Exchange Server (Exchange Server 2003, Exchange Server 2007, and Exchange Server 2010) are running in
one Exchange organization.
Objectives
Describe how the Exchange Server 2010 Mailbox server role coexists with previous versions of
Exchange Server.
Describe how Exchange Server 2010 public folders coexist with previous versions of Exchange Server.
3-4
Exchange Server 2010 Mailbox Role Coexistence with Previous Versions
Administration of the Exchange Organization During Coexistence
During coexistence, the different versions of Exchange Server communicate with each other. Because the
Exchange servers are in the same Exchange organization, many features such as sending and receiving
email, accessing recipient information, and sharing configuration data and settings are implemented
automatically. For example, users with mailboxes located on previous versions of Exchange Server will be
able to send to and receive email from users with mailboxes located on Exchange Server 2010. Users can
also locate each other in the global address list (GAL) and access each others calendar information.
During coexistence, you manage Exchange Server 2010 servers by using Exchange Server 2010
management tools, and manage Exchange Server 2003 or Exchange Server 2007 servers by using their
specific management tools. The management tools are installed by default on each Exchange Server
version, but they can also be installed on client computers running Windows Vista or Windows 7.
Moving Mailboxes from Previous Exchange Server Versions to Exchange Server 2010
During Coexistence
After you confirm that the Exchange 2010 servers have installed successfully and that you can create and
use test mailboxes on the Exchange 2010 Mailbox servers, you may begin to move mailboxes from older
versions of Exchange Server to the Exchange 2010 Mailbox server by using the Exchange Management
Console or the Exchange Management Shell.
Note The process of moving mailboxes is explained in detail in Module 4, Managing

Recipient Objects.
Deleting Mailbox Databases Located on Previous Exchange Server Versions
3-5
After you have moved all mailboxes to the Exchange 2010 Mailbox servers, you may now safely remove
mailbox databases located on older Exchange Server versions. To do so, you must use either the Exchange
Server 2003 version of Exchange Management Console or the Exchange Management Shell, or the
Exchange System Manager on Exchange Server 2003. Because this process does not physically remove
databases from disk drives, you should delete the database files from the file system manually.
3-6
Exchange Server 2010 Public Folders Coexistence with Previous Versions
When you install Exchange Server 2010 in an Exchange Server 2003 or 2007 organization, and you
indicate that you have Outlook 2003 in your organization, the setup process by default creates the
public folder database to provide backward compatibility.
In Exchange Server 2007, you can use continuous replication to make public folder databases highly
available. This functionality is no longer available in Exchange Server 2010. In Exchange Server 2007, you
could also deploy only a single public folder database in a cluster continuous replication (CCR) cluster. In
Exchange Server 2010, you can deploy a public folder database on any or all Database Availability Group
(DAG) members.
Administration of Public Folders During Coexistence
As you implement public folders on Exchange Server 2010, public folders databases and public folders
should be managed and administered using their own version-specific tools. However, during coexistence,
you may continue to administer public folders located on previous Exchange Server versions, where all
changes will replicate to public folders located on Exchange Server 2010.
Replicating and Moving Public Folders During Coexistence
During coexistence, you should configure public folder replication between the different versions of
Exchange Server. In organizations where Microsoft Outlook 2003 is used, to replicate offline address book
(OAB) and Schedule+ free/busy information, you should configure replication of the OFFLINE ADDRESS
BOOK and SCHEDULE+ FREE BUSY public folders located in the System Public Folders container.
If your organization uses public folders and will continue to use them in Exchange Server 2010, you
should replicate all of the required public folders to Exchange Server 2010. For users to access public
folders through Outlook Web App during migration, a replica of the public folders must be located on an
Exchange 2010 Mailbox server.
If your organization uses legacy applications that are designed only for public folders for previous
Exchange Server versions, you will need to retain those public folders on the older Exchange servers. After
your organization upgrades your applications to support Exchange Server 2010, you will then
decommission previous Exchange Server versions.
3-7
Before removing public folder databases, you should move public folder replicas from Exchange Server
2003 by using the Exchange System Manager console by right-clicking a specific public folder database
and then clicking Move all Replicas. In the Exchange Server 2007 and Exchange Server 2010 coexistence
scenario, you move public folder replicas by using the Moveallreplicas.ps1 Exchange Management Shell
script.
You can verify the replicas of all public folders in the public folder tree by running the following command
in the Exchange Management Shell in Exchange Server 2010:
Get-PublicFolder -Recurse | Format-List Name,Replicas
You can verify the replicas of all system folders by running the following command in the Exchange
Management Shell in Exchange Server 2010:
Get-PublicFolder \NON_IPM_SUBTREE | Format-List Name,Replicas
Removing Public Folder Databases from Previous Exchange Server Versions
After you have moved all public folder replicas from the older Exchange Server versions to Exchange
Server 2010, you need to associate the mailbox database client settings with public folders on the
Exchange Server 2010 servers. After you have done this, you may safely remove the public folder
databases located on older Exchange Server versions. Because this process does not physically remove
databases from disk drives, you must manually delete the database files from the file system.
Note Moving public folder replicas is time-consuming, and can take even days to
complete.
3-8
Lesson 2
Configuring the Mailbox Server Role
Exchange Server 2010 includes many changes to the mailbox databases, such as store schema changes,
reduction of disk input/output (I/O) by 70 % compared with Exchange Server 2007, optimization for lowcost disks, and removal of Single Instance Storage.
Objectives
Describe mailbox and public folder database changes in Exchange Server 2010.
Describe Exchange Server 2010 storage improvements.
Describe Exchange Server 2010 database file types.
Create mailbox databases.
Configure mailbox databases.
Describe database storage options in Exchange Server 2010.
Plan mailbox database deployment.
Plan mailbox server deployment.
Mailbox and Public Folder Database Changes in Exchange Server 2010
3-9
As in Exchange Server 2003 and Exchange Server 2007, Exchange Server 2010 stores mailbox and public
folder contents in databases. Mailbox servers contain mailbox databases and public folder databases, and
each database consists of a single rich-text database (.edb) file and its associated log stream.
Storage groups no longer exist, so now each database has a set of transaction log files attached to it.
Exchange Server 2010 mailbox servers store all messages in this database, regardless of which type of
client sends or reads the messages. Like Exchange Server 2007, Exchange Server 2010 does not have a
streaming database (.stm) file.
In Exchange Server 2010, mailbox and public folder databases are associated with the Exchange Server
organization level, as compared to previous Exchange Server versions, where databases were associated
with individual Exchange servers. Therefore, mailbox and public folder databases must have unique names
within the entire Exchange Server organization.
By default, all databases and transaction logs are stored in one folder within the Exchange Server directory
(C:\Program Files\Microsoft\Exchange Server\v14\Mailbox), and each database has its own folder. We
recommend that you move database and transaction log files from the default location to other logical
disks, according to your storage design and Microsoft best practices.
In previous Exchange Server versions, best practice was to separate databases and transaction log files on
different logical disks because of performance and recovery reasons. For Exchange Server 2010, the same
best practice still applies with the following exception: in organizations where DAGs are deployed and
sufficient copies of databases have been deployed to provide redundancy, it is not necessary to separate
databases and transaction log files, so they may be located on the same logical disk.
Note
You will learn about DAGs in Module 8, Implementing High Availability.
Note For more information on Exchange Server 2010 disk architecture, see the article
Understanding Exchange 2010 LUN Architecture at
http://go.microsoft.com/fwlink/?LinkID=212662.
3-10
Exchange Server 2010 Storage Improvements
The Exchange Server 2010 database technology has changed significantly to improve its performance
over previous Exchange Server versions. Due to these changes, Exchange Server 2010 has a 70 percent I/O
reduction compared with Exchange Server 2007, and a 90 percent reduction compared with Exchange
Server 2003. Furthermore, the new database technology is now optimized for Serial ATA (SATA) disks,
which allows organizations to significantly lower the cost on their Exchange server solutions.
Since the storage I/O per second (IOPS) are lower in Exchange Server 2010, more storage options are
available. Still, you should ensure that your storage technology meets the business and technical
requirements for the Exchange Server 2010 deployment. Tools such as Load Generator 2010 and JetStress
2010 are available to approximate usage patterns, and you can use these tools to test various hardware
configurations in your environment.
Some of the changes included in Exchange Server 2010 are:
New store schema and sequential disk input/output. The store schema has been updated to
reduce the store's reliance on the secondary indexes. As a result, the store is no longer sensitive to
performance issues related to the secondary indexes. In addition, the database page size has
increased from 8 to 32 kilobytes (KB). This provides increased performance because the larger page is
cached in memory, and the server needs to read or write the pages from the disk less frequently. In
addition, the data in the databases is stored sequentially rather than randomly as in previous versions
of Exchange. Sequential access means that the disk head movement is more efficient.
Support for lower performance disks and RAID-less (JBOD) deployments. Because of the
reduced I/O, it is now possible to deploy Exchange Server 2010 mailboxes on inexpensive and lowerperforming disks such as SATA drives. In addition, you can use DAGs to provide redundancy at the
database level, which reduces the requirement for redundancy at the storage level and makes it
feasible to deploy RAID-less or JBOD storage. JBOD configurations are recommended only in
organizations that have deployed DAGs with at least three DAG members and with at least three
database copies of each database.
3-11
Support for large mailboxes and databases. To meet the users continuous requirements for larger
mailboxes, storage improvements now provide organizations the option to deploy large mailboxes
and large databases.
Database defragmentation runs continuously. Online defragmentation has improved performance

and runs in the background continuously. You do not need to schedule this process, because it was
moved out of the Mailbox database maintenance process.
Improved online database scanning. Online database scanning calculates the checksum of the
database and corrects potential issues that can occur when a database crashes. If lost space in the
database is found due to a crash, online database scanning finds the lost space and recovers it. By
default, online database scanning runs in the background continuously.
Removal of Single Instance Storage and reduced database size with database compression.
Unlike previous Exchange server versions, Exchange Server 2010 does not provide Single Instance
Storage,. However, removal of Single Instance Storage does not mean that the databases will be
larger than in previous versions, because Exchange Server 2010 provides database compression for
HTML/Plain Text messages.
Note For more information on Exchange Server 2010 database changes, see the article
New Exchange Server Store Core Functionality at
3-12
Exchange Server 2010 Database File Types
As in previous versions of Exchange Server, a database in Exchange Server 2010 consists of a collection of
file types, each of which performs different functions. These basic file types have changed very little from
previous Exchange Server versions.
The following table describes each file type, and any changes (if applicable) in Exchange Server 2010.
File type
Purpose
<Log Prefix>.chk
Checkpoint file. This checkpoint file determines which transactions require

processing to move the checkpoint file from the transaction log file to the
database. Each databases log prefix determines its checkpoint file name.
For example, the checkpoint file name for a database with prefix E00 would
be E00.chk. This checkpoint file is several KB in size, but does not grow.
<Log Prefix>.log
Current transaction log file. This is the databases current transaction log
file. An example is E00.log. The maximum amount of data storage for this
file is 1 megabyte (MB). When this file reaches its maximum storage of 1
MB, Exchange Server renames it, and then creates a new current
transaction log.
<Log Prefix>xxxxxxxx.log
Transaction log file that was already renamed and filed. Log files use
sequential hexadecimal names. For example, the first log file for the first
database on a server would be E0000000001.log. Each transaction log file is
always 1 MB.
<Log Prefix>res00001.jrs
<Log Prefix>res00002.jrs
Reserved transaction logs. These are the reserved transaction logs for the
database. Exchange Server 2010 uses these only as emergency storage
when the disk becomes full and it can no longer write new transactions to
disk. An example is E00res00001.jrs. When Exchange Server 2010 runs out
of disk space, it writes the current transaction to disk, 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 1 MB
each.
3-13
File type
Purpose
Tmp.edb
Temporary workspace for processing transactions. This temporary

workspace is for processing transactions. Exchange Server 2010 deletes the
contents of this file when it dismounts the database, or when the Microsoft
Exchange Information Store service stops. This file typically is a few MB in
size.
<Log Prefix>tmp.log
Transaction log file for the temporary workspace. This is the transaction log
file for the temporary workspace. An example is E00tmp.log. This file does
not exceed 1 MB.
<File Name>.edb
Rich text database file that stores content for mailbox and public folder
databases. This is the rich-text database file that stores content for mailbox
and public folder databases. An example is Database.edb. Each mailbox or
public folder database is contained in a single file. Database files can grow
very large, depending on the content that the database stores.
3-14
Demonstration: Creating Mailbox Databases
In previous versions of Exchange Server, mailbox databases are directly associated with a particular
Exchange server. In Exchange Server 2010, mailbox databases are now global, organization-level objects
and no longer child objects of the servers on which they were created. Therefore, every mailbox database
should have unique name within the Exchange organization.
You can create mailbox databases in Exchange Server 2010 using either the Exchange Management
Console or the Exchange Management Shell. In this demonstration, you will see how to create mailbox
databases using both the Exchange Management Console and the Exchange Management Shell.
Demonstration Steps
Create a mailbox database by using the Exchange Management Console

1.
Open the Exchange Management Console.
2.
In the console tree, expand Microsoft Exchange On-Premises, expand Organization

Configuration, and then click Mailbox.
3.
Select the Database Management tab, and in the Actions pane, click on New Mailbox Database
task.
4.
On the NYC-EX10 server, name the new database HR.
5.
Select the default options for Database Path and Log Folder Path.
6.
Confirm that the new mailbox database created successfully.
Create a mailbox database by using the Exchange Management Shell

1.
Open the Exchange Management Shell.
2.
Create database with name Marketing and database file name Marketing.edb on server NYC-EX10.
Place database file and transaction log files on c:\Mailbox\Marketing folder.
Demonstration: Configuring Database Options
You can set several properties for each mailbox database. Three management tabsMaintenance,
Limits, and Client Settingscontain these options.
Maintenance Tab
3-15
You use the Maintenance tab to configure mailbox database settings, including specifying a journal
recipient, setting a maintenance schedule, and mounting the database at startup. However, we
recommend using journaling rules for journaling in Exchange Server 2010, configured on a Hub Transport
server role.
Note Journaling in Exchange Server 2010 will be covered in greater detail in Module 10,
Configuring Messaging Policy and Compliance.
The maintenance schedule is the period of time in which Exchange Server 2010 performs database
maintenance. In Exchange Server 2010, online defragmentation occurs continually, when compared with
previous Exchange Server versions where you had to configure database maintenance interval (typically
after business hours).
The Maintenance tab has a check box that you select to keep the database from mounting at startup.
You select this check box in addition to a second check box that allows the database to be overwritten by
a restore, during recovery or database-maintenance tasks. The check box for enabling circular logging
sets the transaction-logging mode so that Exchange Server 2010 overwrites the transaction logs after they
are committed to the database.
3-16
Important Circular logging does not allow you to recover a database to a point in time
other than when the last full backup was completed. In Exchange Server 2010, you should
only configure circular logging if you have implemented Exchange Native Data Protection,
where backups are not performed. You will learn about backup and restore procedures in
Module 9, Implementing Backup and Recovery. For more information about Exchange Native
Data Protection, see Understanding Backup, Restore and Disaster Recovery at
Limits Tab
As in previous Exchange Server versions, use the Limits tab to set the maximum size for mailboxes that
the database stores, and to specify the notification schedule for sending messages to users who are
approaching these limits.
The deletion settings specify how long the database stores deleted items and mailboxes after the user
deletes them. You can use the dumpster to recover items that users have deleted and purged from their
Deleted Items folder, without having to perform a restore from a backup.
Client Settings Tab

Use the Client Settings tab to configure the default public folder, if necessary, and the default offline
address book for all mailboxes in the database.
In the following demonstration, you will review the three key management tabs, and see how you can use
them to configure your database options.
Demonstration Steps
Configure database options
1.
2.

3.
Select the Database Management tab, and then view the properties of a mailbox database.
4.
View the properties on the General, Maintenance, Limits, and Client Settings tabs.
5.
Run the Move Database Path wizard to move the database files.
Question: When would you need to move the path of the transaction logs or databases?
Question: When might you use circular logging?
Database Storage Options in Exchange Server 2010
3-17
Exchange Server 2010 now supports several disk storage options, including Serial ATA (SATA), solid-state
disk (SSD), and Serial Attached Small Computer System Interface (SCSI), or SAS. When selecting which
storage solution to use, the goal is to ensure that the storage will provide the performance that your
environment requires.
Directly Attached Storage (DAS) Options in Exchange Server 2010
DAS is any disk connected to a server or workstation without a storage network in between. This includes
hard disks inside the server, or those that connect by using an external enclosure. Some external
enclosures include hardware-based RAID. For example, external disk enclosures can combine multiple
disks in a RAID 5 set that presents itself to the server as a single large disk.
In general, DAS provides good performance, but it provides less scalability than a Storage Area Network
(SAN) because of the units physical size. You must manage DAS on a per-server basis. Exchange Server
2010 performs well with the scalability and performance characteristics of DAS.
DAS provides the following benefits:
Lower cost Exchange Server solution. DAS usually provides a substantially lower purchase cost than
SAN technologies.
Easy implementation. DAS 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
Exchange server does not affect the entire Exchange organization negatively, assuming that you
configure your Exchange servers for high availability by implementing DAGs.
SAN Options in Exchange Server 2010
A SAN is a network dedicated to providing servers with access to storage devices. A SAN provides
advanced storage and management capabilities, and high performance. SANs are complex and require
specialized knowledge to design, operate, and maintain. Most SANs are also more expensive than DAS.
3-18
SANs use either Fibre Channel or iSCSI to provide fast and reliable connectivity between storage and host
servers. 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.).
When implementing SANs, you should consider the following factors:
Avoid sharing physical disks that contain Exchange databases or transaction logs with other disk
intensive applications.
Use dedicated storage networks with redundant network components to connect the Exchange 2010
Mailbox servers to the SAN.
SANs provide the following benefits:
A large random access memory (RAM) cache that keeps disk access from becoming a bottleneck. The
reduced I/O requirements of Exchange Server 2010 mean that an iSCSI-based SAN will meet your
requirements in small and medium-sized deployments. However, you should test all hardware
configurations thoroughly before deploying them 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 storage needs increase, a SAN allows you to add disks to your storage. If
you use a SAN, you can connect multiple computers running Exchange Server 2010, and then divide
the storage among them.
Enhanced backup, recovery, and availability. Because SANs allow multiple connections, you can
connect high-performance back-up devices to the SAN. SANs also allow you to designate different
RAID levels to different storage partitions.
For cost-conscious SAN implementations, iSCSI may be a better 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.
Note Exchange Server 2010 does not support Network attached storage (NAS).
Considerations for Planning Mailbox Databases
3-19
Before upgrading to Exchange Server 2010, it is important that you plan your mailbox databases and
storage solutions carefully. 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 2010 Mailbox Server
Role Requirements Calculator recommends 200 GB limit for databases without DAGs.
Database and transaction log locations. With a single copy of the databases, it is important that
the database and transaction logs be stored on separate drives, for performance and recovery
reasons.
3-20
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 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 on larger time intervals or can even remove backup procedures
completely.
Mailbox database size. Because of the decreased importance of backup and recovery, the primary
consideration for database size becomes how long it would take to reseed the database if one copy is
lost. As such, the databases can be much larger. The Exchange 2010 Mailbox Server Role
Requirements Calculator recommends up to 2 terabytes (TB) for databases when DAGs are used.
Database and transaction log locations. With multiple database copies, separating the databases
and transaction log files is less important. Companies may still choose to do so for performance
reasons, but it is not required for redundancy and recovery reasons. If backup is not performed in the
organization, you should enable circular logging to prevent transaction logs from filling up the disks.
Storage solution. With multiple database copies that provide redundancy, it is less important to
consider an expensive disk system, such as SAN. You will more likely use DAS because of its lower
cost. Furthermore, if your organization has three or more copies of the databases, then you will more
likely use Just a bunch of disks (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.
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, Marketing, etc. 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:
Server name
Active Directory site name (for the site resilience case)
Physical data center name (for the site resilience case)
Exchange organization name
Question: When would you want or need to create multiple databases?
3-21
3-22
Considerations for Planning Mailbox Servers
In addition to planning the number of mailbox databases, you will also need to plan how many Mailbox
servers you will deploy. Some organizations deploy Exchange 2010 servers in multiple locations through
the organization. By placing Mailbox servers, along with Hub Transport and Client Access servers, in
locations closer to the users, you to improve the client performance and experience, and/or reduce
bandwidth requirements between company locations. In addition, some organizations with branch offices
might choose to deploy multiple Mailbox servers in different branch office locations, because of number
of the users, specific administrative needs, or compliance policies.
However, some companies have centralized Exchange Server deployment, so they choose to have the
server infrastructure deployed in one datacenter. With this deployment, it is important that Outlook is
configured in cached mode so that network bandwidth issues and network latency are largely transparent
to users. As an alternative, you can also have users connect to Exchange using Outlook Web App.
You will also need to deploy multiple Exchange 2010 servers if you need to provide high availability for
messaging in your organization. These scenarios are explained in Module 8, Implementing High
Availability.
Before you deploy Exchange 2010 Mailbox servers, we recommend that you use the Exchange 2010
Mailbox Server Role Requirements Calculator to plan server hardware and to validate your design in a test
environment by using tools such as JetStress 2010 and LoadGen 2010.
Lesson 3
3-23
Configuring Public Folders and Public Folder Databases in

This lesson covers public folders, and details how you can configure them. Public Folders are fully
supported in Exchange Server 2010. It is essential to understand when to use public folders, and how to
configure them properly.
Objectives
Configure public folders and public folder databases.
Configure public folder replication.
Describe how clients access public folders in an Exchange Server coexistence scenario.
Apply best practices for planning public folder deployment.
3-24
Demonstration: Configuring Public Folders and Public Folder Databases
Public Folder Database configuration options are set at the public folder database level by using tabs in
the properties window of the specific Public Folder database. These tabs include the General,
Replication, Limits, and Public Folder Referral tabs, which remain unchanged between Exchange Server
2007 and Exchange Server 2010.
Public Folders Properties tabs are unchanged in Exchange Server 2010, with the exception of the Client
Permissions tab. The Client Permissions tab is new with Exchange Server 2010 Service Pack 1 (SP1). You
use the tab to configure user permissions for the selected public folder
As compared with Exchange Server 2003, only the Default Public Folder tree is available in Exchange
Server 2010, and support for network news transfer protocol (NNTP) no longer exists.
In this demonstration, you will review how to use the Public Folder Management Console, and Microsoft
Office Outlook to configure public folders. You will see how to:
Use the Public Folder Management Console to create a public folder.
Use the Public Folder Management Console to add permissions to a public folder.
Use Office Outlook to view the permissions for the public folder.
Demonstration Steps
Use the Public Folder Management Console to create a public folder

1.
2.
Open the Public Folder Management Console, and then connect to a Mailbox server.
3.
Create a new public folder named Sales.
4.
View the properties of the Sales public folder, and then view the options on the General, Statistics,
Replication, Limits, and Permissions tabs.
3-25
Use the Public Folder Management Console to add permissions to a public folder
Use the Public Folder Management Console to add EditAllItems permission to the Sales public folder
for user Don Roessler.
Use Office Outlook to view public folder permissions

1.
Open Office Outlook.
2.
View the permissions for the Sales public folder.
3-26
Demonstration: Configuring Public Folder Replication
As in previous Exchange Server versions, public folder content replication is an email-based process for
copying public folder content between computers running Exchange Server. When you modify a public
folder or its contents, the public folder database containing the replica of the public folder that you
change sends a descriptive email message to the other public folder databases that host a replica of the
public folder. To reduce network traffic, Exchange Server includes information about multiple changes in
one email message. If any message exceeds the specified size limit, that message is sent as a separate
replication message. Exchange Server routes these replication messages the same way that it routes other
email messages. By default, public folder content replicates every 15 minutes, and you cannot set
replication to less than every minute.
Because Active Directory Domain Services (AD DS) stores the public folder configuration objects, AD DS
and Active Directory replication must be working correctly to ensure that the configuration is available to
all Exchange servers.
When you create a public folder, only one replica of that public folder exists within the Exchange Server
organization.
Using multiple replicas allows you to place public folder content in the physical server locations where
users are located. This results in faster access to public folder content, and reduced communication across
wide area network (WAN) links between physical locations. Public folder replication also provides fault
tolerance for public folders.
Note If public folder contents are updated frequently, you may choose to not replicate the
public folder to ensure users are accessing the latest version of the public folder messages,
and to reduce public folder replication network traffic.
You may configure public folder replicas using either the Public Folder Management Console or the
Exchange Management Shell.
3-27
For moving public folder replicas, you use Exchange Management Shell scripts, (located in the Scripts
folder of an Exchange Server), such as:
MoveAllReplicas.ps1. This script moves all public folders in a public folder database on one server to
a public folder database on another server
ReplaceReplicaOnPFRecursive.ps1. This script is used to move replicas of a public folder subtree

from one server to another server.
Demonstration Steps
Use the Exchange System Manager on Exchange Server 2003 to add replicas on a
public folder
1.
Open the Exchange System Manager on NYC-EX03-B.
2.
Navigate to the Research Public Folder.
3.
Configure replication with the public folder database located on NYC-EX1.
3-28
How Clients Access Public Folders in an Exchange Server Coexistence

Scenario
The public folder connection process for messaging API (MAPI)-based clients is:
1.
If the public folder is located on the default public folder database configured for the users mailbox
database, Exchange Server directs the client to connect to the RPC Client Access service on the
Mailbox server hosting the public folder replica.
2.
If the public folder contents are not stored in the default public folder database, Exchange Server
redirects the client to the RPC Client Access service on any Mailbox server that hosts the public folder
replica in the local Active Directory site.
3.
If no computer running Exchange Server 2010 or Exchange Server 2007 on the local Active Directory
site has a copy of the public folder contents, Exchange Server redirects the client to a Mailbox server
that has a replica of the public folder in the Active Directory site with the lowest-cost site link.
4.
If there is no computer running Exchange Server 2010 or Exchange Server 2007 that has a replica of
the public folder contents, Exchange Server redirects the client to a computer running Exchange
Server 2003 that has a copy of the public folder contents, using the cost assigned to the routing
group connector(s). Exchange Server 2010 does not enable this by default. Rather, you must enable it
with the Set-RoutingGroupConnector cmdlet.
5.
If no public folder replica exists on the local Active Directory site, on a remote Active Directory site, or
on a computer running Exchange Server 2003, the client cannot access the contents of the requested
public folder.
Note For Microsoft Outlook Web App clients to view public folders, a replica of the public
folder must be available on an Exchange 2010 Mailbox server.
Best Practices for Public Folder Deployment
3-29
When planning public folder deployment in Exchange Server 2010, you should consider following best
practices:
Some organizations make little use of public folders, while others use them extensively, and may have
manual or automated business processes that require public folders. Because of the variation in public
folder use, you should start your public folder design by analyzing your organizations business
requirements for public folders.
If your organization uses public folders extensively, you might need to deploy one or more dedicated
public folder servers. Dedicated public folder servers may have different hardware requirements than
servers that are both Mailbox and public folder servers, depending on both the number of users using
the public folders, and the size of the public folder store. Because a Mailbox server can host only one
public folder database, the hardware requirements for the dedicated public folder server are likely to
be significantly less than a Mailbox server that has multiple mailbox databases.
Schedule public folder replication during non-peak hours. In cases of limited bandwidth, and if users
do not need access to a current copy of the public folder contents, you can schedule public folder
replication to occur during non-business hours.
If the network bandwidth and latency between company locations is not a significant issue, then the
primary considerations for using replication or referrals are server capacity, client performance, and
enabling high availability for public folders. If you have a Mailbox server in a remote site, or if you are
deploying a dedicated public folder server, you should enable public folder replication. This provides
users with a more positive experience as compared to accessing public folders across a WAN
connection. If you do not have a Mailbox server with the capacity to host public folder replicas in the
remote site, then use public folder referrals. If public folder availability is an important consideration
in your organization, then the only way you can provide high availability is through configuring
multiple replicas.
3-30
If you have Office Outlook 2003, you should enable replication for the system folders that these
clients require. These folders include the Schedule+ free/busy folders, and the OAB folders. The OAB
folder includes up to three different versions of the OAB. Only replicate the OAB versions that the
Office Outlook clients in your organization require.
Note For Outlook Web App clients to view public folders, a replica of the public folder
must be available on an Exchange 2010 Mailbox server.
Lab Setup
3-31
1.
2.
Ensure that the 10165A-NYC-DC1-B, 10165A-NYC-EX03-B, 10165A-NYC-EX10-B and 10165A-NYCEX11-B virtual machines are running.
3.
10165A-NYC-DC1-B: Domain controller in the contoso.com domain
10165A-NYC-EX03-B: Exchange Server 2003 server with Service Pack 2 (SP2) in the contoso.com
domain
10165A-NYC-EX10-B: Exchange Server 2010 Server in the contoso.com domain
10165A-NYC-EX11-B: Exchange Server 2010 Server in the contoso.com domain

Lab Scenario
You are a messaging administrator at Contoso, Ltd. Your manager has left instructions for you to create
and configure a mailbox database for the Executives group, and then to move the existing database for
the Accounting group to a new location. You also need to add an additional public folder database, and
then replicate public folders from Exchange Server 2003 to Exchange Server 2010. As part of the
migration, you must also replicate all required system public folders from Exchange Server 2003 to
3-32
Exercise 1: Configuring Mailbox Databases

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

1.
On NYC-EX10-B, open the Exchange Management Console.
2.
Create a new database named Executives on NYC-EX10.
3.
Store database files in C:\Mailbox\Executives.
4.
Store log files in C:\Mailbox\Executives.
Task 2: Configure the Executives mailbox database with appropriate limits
Configure the limits on the Executives database:
Prohibit send and receive: 1024
Issue warning: 850
Task 3: Move the existing Accounting database to a new location
Move the Accounting database files:
Store database files in C:\Mailbox\Accounting.
Store log files in C:\Mailbox\Accounting.
Results: After this exercise, you should have created and set the specified limits for a new Executives
database, and moved the existing Accounting database to a new location.
Exercise 2: Configuring Public Folders

Scenario
Before creating a new public folder database and replicating public folders, you must document the
numbers of items and size in the Research public folder so that you can later verify that the replication
was successful.
1.
Verify Research public folder statistics.
2.
Create a public folder database on NYC-EX11.
3.
Add a replica of the Research public folder on NYC-EX11.
4.
Replicate system folders from NYC-EX03 to NYC-EX11
5.
Verify replication between NYC-EX03 and NYC-EX11.
Task 1: Verify Research public folder statistics
3-33
1.
On NYC-EX03-B, open the Exchange System Manager, expand Administrative Groups, expand
First Administrative Group, expand Folders, expand Public Folders, and then click the Research
public folder.
2.
On right pane of the console, click the Status tab.
Write down number of Items __________________
Write down Size (KB) ________________________
Task 2: Create a public folder database on NYC-EX11
Create a new public folder database on NYC-EX11 named PF-NYC-EX11.
Store database files in C:\Mailbox\PF-NYC-EX11\PF-NYC-EX11.edb.
Store log files in C:\Mailbox\PF-NYC-EX11.
Task 3: Add a replica of the Research public folder on NYC-EX11
From NYC-EX03, add PF-NYC-EX11 as a replica for the Research public folder, and then wait for
replication to complete.
Note
It can take up to 15 minutes for replication to complete.
Task 4: Replicate system folders from NYC-EX03 to NYC-EX11
Add PF-NYC-EX11 as a replica for the NYC-EX03 system folders on NYC-EX11, and then wait for
replication to complete. The system folder to replicate should include the OFFLINE ADDRESS BOOK
and SCHEDULE+FREE BUSY.
Note
It can take up to 15 minutes for replication to complete.
Task 5: Verify replication between NYC-EX03 and NYC-EX11
Verify that the number and size of items in the Research public folder on NYC-EX11 match the
numbers you recorded from NYC-EX03-B.
Results: After this exercise, you should have created a new public folder database on NYC-EX11, and
added replicas for each public folder, including system folders.

When you finish the lab, revert the virtual machines to their initial state. To do this, complete the
following steps:
1.
2.
Right-click 10165A-NYC-DC1-B in the Virtual Machines list, and then click Revert.
3.
3-34
4.
Repeat the steps for 10165A-NYC-EX03-B, 10165A-NYC-EX10-B, and 10165A-NYC-EX11-B.
5.
machine.
6.
Wait for 10165A-NYC-DC1-B to start, and then start 10165A-NYC-EX03-B. Connect to the virtual
machine.
7.
Wait for 10165A-NYC-EX03-B to start, and then start 10165A-NYC-EX10-B. Connect to the virtual
machine.
8.
Wait for 10165A-NYC-EX10-B to start, and then start 10165A-NYC-CL1-B. Connect to the virtual
machine.
3-35
Review Questions
1.
What is coexistence in an Exchange organization?
2.
What configuration can you make on mailbox databases?
3.
In which situation you would not upgrade public folders to Exchange Server 2010?
Common Issues Related to Designing Mailbox Databases
Identify the causes for the following common issues related to designing mailbox databases, and fill in the
troubleshooting tips. For answers, refer to relevant lessons in the module.
Issue
You are planning to deploy an Exchange
2010 Mailbox server on a different server
and storage platform. What tools would
you use to validate your design in the test
environment?
After applying limits on each of the
mailbox databases and completing the
upgrade of the Mailbox server role to
Exchange Server 2010, some of the users
are exceeding these limits. What should
you do?
You are migrating from Exchange Server
2003, and none of the users with Exchange
Server 2010 mailboxes can access legacy
public folders via Outlook Web App. What
should you do?
Troubleshooting tip
3-36
Best Practices Related to Upgrading and Configuring Mailbox Servers

When configuring mailbox server roles in coexistence, always start by analyzing your organizations
business requirements, and current messaging and collaboration infrastructure.
Based on the analysis information, carefully plan the database design process. Create a step-by-step
plan for creating and configuring mailbox and public folder databases.
Simulate the coexistence scenario first in a virtual environment.
Deploy several users at a time from different departments as a pilot project for moving mailboxes and
public folders to Exchange Server 2010. Then analyze client behavior and mailbox server role
performance and health to determine if any issues exist.
After moving all mailboxes and public folders to the Exchange Server 2010 mailbox role, and before
you start the decommission process, determine whether any user or application is still using previous
Exchange Server versions.
4-1
Module 4
Managing Recipient Objects
Contents:
Lesson 1: Managing Mailboxes in Exchange Server 2010
4-3
Lesson 2: Configuring Mail Users, Mail Contacts, and

Distribution Groups in Exchange Server 2010
4-21
Lesson 3: Configuring Email Address Policies and Address

Lists in Exchange Server 2010
4-27
Lesson 4: Performing Bulk Recipient Management

Tasks in Exchange Server 2010
4-37
4-42
4-2
Module Overview
Microsoft Exchange Server 2010 introduces new tools for managing recipient objects, email address
policies, and offline address books, and it also introduces several new recipient objects compared to
Exchange Server 2003. Recipient management in Exchange Server 2010 is very similar to Exchange Server
2007.
In Exchange Server 2010, you perform bulk management of recipient objects using Exchange
Management Shell, which is more efficient than the scripts used in Exchange Server 2003.
Objectives
Manage mailboxes in Exchange Server 2010.
Configure mail users, mail contacts, and distribution groups in Exchange Server 2010.
Configure email address policies and address lists in Exchange Server 2010.
Perform bulk recipient management tasks in Exchange Server 2010.
Lesson 1
Managing Mailboxes in Exchange Server 2010
Exchange Server 2010 has user mailboxes, room and equipment mailboxes and linked and remote
mailboxes. Exchange Server 2007 administrators will be familiar with resource mailboxes and linked
mailboxes, but Exchange Server 2003 administrators will not be familiar.
4-3
In Exchange Server 2010, managing mailboxes is also similar to doing so in Exchange Server 2007.
However, there are differences in management tools and configuration settings as compared to Exchange
Server 2003.
For every Active Directory User Mailbox, you may optionally create an Archive Mailbox. This is a new
feature in Exchange Server 2010. Archive Mailboxes are covered in more detail in Module 10: Configuring
Messaging Policy and Compliance.
Objectives
Describe recipient objects in Exchange Server 2010.
Manage mailboxes in Exchange Server 2010.
Configure mailbox settings in Exchange Server 2010.
Configure mailbox permissions in Exchange Server 2010.
Move mailboxes in Exchange Server 2010.
Move a mailbox by using Exchange Management Console.
Describe resource mailboxes in Exchange Server 2010.
Design resource booking policies in Exchange Server 2010.
Manage resource mailboxes.
4-4
Discussion: Recipient Objects in Exchange Server 2010
In Microsoft Exchange Server 2003, you use the Active Directory Users and Computers functionality to
perform all individual recipient management tasks. However, in Exchange Server 2010 and Microsoft
Exchange Server 2007, you do not use Active Directory Users and Computers to manage Exchange Server
recipients. You must configure all Exchange Server-specific recipient settings in the Exchange
Management Console or the Exchange Management Shell. In addition, in Exchange Server 2010, you can
configure many recipient properties by using the Exchange Control Panel.
Exchange Server 2010 supports the following recipient objects:
User mailbox. You assign a user mailbox to an individual user in your Exchange Server organization.
The mailbox typically contains messages, calendar items, contacts, tasks, documents, and other
important business data.
Remote mailbox. A remote mailbox consists of a mail-enabled user account that exists in the onpremises Active Directory, and an associated mailbox that exists in the cloud-based service. The
remote mailbox is new in Exchange Server 2010.
Mail users or mail-enabled Active Directory users. Same as in previous Exchange versions. Users whose
mailboxes are located outside the companys Exchange Server organization, and who have an
external email address. All messages sent to the mail user are routed to their external email address. A
mail user has Active Directory logon credentials, and can access resources.
Resource mailboxes (Room mailboxes and Equipment mailboxes). Introduced in Exchange Server 2007,
resource mailboxes are mailboxes that you can assign to a meeting location, or to a resource such as
a projector. You can include resource mailboxes as resources in meeting requests, which provides a
simple and efficient way of scheduling resource usage. A resource mailbox has a disabled Active
Directory account by default.
4-5
Mail contact or mail-enabled contacts. Same as in previous Exchange versions. These contacts contain
information about people or organizations that exist outside an Exchange Server organization and
that have an external email address. Exchange Server routes all messages that are sent to the mail
contact to this external email address. A mail contact is similar to a mail user, except that a mail
contact does not have Active Directory logon credentials.
Mail-enabled security and distribution groups. Same as in previous Exchange versions. Use a mailenabled Active Directory security group object to grant access permissions to Active Directory
resources, and to distribute messages. Use a mail-enabled Active Directory distribution group object
to distribute messages to a group of recipients.
Dynamic distribution groups. Same as in previous Exchange versions. These groups were called querybased distribution groups in Exchange Server 2003. A distribution group that uses recipient filters and
conditions to derive its membership at the time messages are sent.
Linked mailboxes. You can assign a linked mailbox to an individual user in a separate, trusted forest.
Linked mailboxes are new in Exchange Server 2010.
In Exchange Server 2010 and Exchange Server 2007, you can only mail-enable universal security groups,
universal distribution groups, and public folders.
Question: How is a resource mailbox different from a user mailbox?
4-6
Demonstration: How to Manage Mailboxes
Once you have installed Exchange Server 2010, you must locate user mailboxes during both coexistence
and the upgrade process. To do this, you will need to know the location of user mailboxes on each server
before you begin moving the user mailboxes from previous Exchange Server versions to Exchange Server
2010.
In this demonstration, you will see how to manage mailboxes in Exchange Server 2010 by performing
common operations such as creating, deleting, and removing mailbox user accounts.
Note When managing multiple mailboxes, it is always more efficient to use Exchange
Management Shell. Use Exchange Management Console when managing only few
mailboxes.
Demonstration Steps
Create a new user mailbox with the Exchange Management Console

1.
Open Exchange Management Console.
2.
In the console tree, expand Microsoft Exchange On-Premises, expand Recipient Configuration,
and then select the Mailbox node.
3.
Run the New Mailbox wizard, and create a new user account and mailbox for Kim Akers in the
Accounting mailbox database.
Locate user mailboxes in the Exchange Management Console

1.
If needed, open Exchange Management Console.
2.
and then select the Mailbox node.
4-7
3.
Notice that in Exchange Server 2010 Management Console, user mailboxes located on Exchange
Server 2010 servers are labeled as User Mailbox, and user mailboxes located on Exchange Server
2003 servers are labeled as Legacy Mailbox.
4.
User mailboxes located on Exchange Server 2007 are also labeled as User Mailbox. Therefore, create
a filter for users by database name to determine which users mailboxes are located on Exchange
Server 2007.
Note Virtual machine environment for this demonstration does not have Exchange Server
2007, so you will only create filter by database name. In addition, you may also consider
adding Database column in the result pane of Exchange Management Console, and sort user
mailboxes by Database information.
Use the Exchange Management Shell to mailbox-enable an existing user

1.
Open Active Directory Users and Computers, and ensure that Daniel Brunner exists in the Users
container.
2.
Open Exchange Management Shell, and run the following cmdlet:
Enable-Mailbox Daniel Brunner alias Daniel Database Accounting
3.
Verify the cmdlet was successful by typing following command in Exchange Management Shell:
Get-Mailbox Daniel Brunner | ft Alias, Database
This cmdlet will display alias Daniel and the database name Accounting for the user mailbox Daniel
Brunner.
Use the Exchange Management Shell to disable a user mailbox

1.
Open Active Directory Users and Computers, and ensure that Daniel Brunner exists in the Users
container.
2.
Disable-Mailbox Daniel Brunner
3.
When the confirmation question displays, press Enter.
4.
In Exchange Management Shell, run the following cmdlet:
Get-Mailbox Daniel Brunner
The cmdlet will display an error stating that the object cannot be found.
5.
In Active Directory Users and Computers, verify that the Daniel Brunner user account still exists.
Note Disabling a user mailbox in Exchange Server 2010 and 2007 is equivalent to deleting
a mailbox in Exchange 2003. This action removes the mailbox, but leaves the user account
enabled. In Exchange Server 2010, if the user has a personal archive, disabling the user
mailbox also disables the users personal archive.
4-8
Use the Exchange Management Shell to remove a user mailbox

1.
Open Exchange Management Console, and ensure that Kim Akers is listed in the Users container.
2.
Remove-Mailbox Identity Kim Akers
3.
When the confirmation question displays, press Enter.
4.
In Exchange Management Shell, run the following cmdlet:
Get-Mailbox Kim Akers
The cmdlet displays an error stating that the object cannot be found.
5.
In Active Directory Users and Computers, verify that the Kim Akers user account does not exist.
Note Removing a user mailbox in Exchange Server 2010 and 2007 is equivalent to deleting
a mailbox-enabled user in Exchange 2003 from Active Directory. This action removes the
user account and its associated mailbox. In Exchange Server 2010, if the user has a personal
archive, removing the users mailbox also removes the users personal archive.
Question: What tools do you prefer to use for managing mailbox users?
Demonstration: Configuring Mailbox Settings
4-9
Mailbox settings in Exchange Server 2010as in Exchange Server 2007are configured by using
Exchange Management Console and Exchange Management Shell. In addition, you can configure many
mailbox settings by using the Exchange Control Panel in Exchange Server 2010.
Exchange Server 2010 provides several options for configuring a single mailbox. Many of these options
are similar to those available for managing an Active Directory Domain Services (AD DS) environment, and
similar to previous Exchange Server versions. Exchange Server 2010 mailbox configuration options include:
General
User Information
Address and Phone
Organization
Account
Member Of
There are additional Exchange Server version-specific mailbox configuration options. Most of the options
are the same as in previous Exchange Server versions. However, in Exchange Server 2010, these options
are located on different tabs in the mailbox properties window, such as:
Mail Flow Settings. Exchange Server 2010 has three mail-flow settings: delivery options, message-size
restrictions, and message-delivery restrictions.
You use the delivery options to set:
Who can send an email message from that mailbox.
A recipient to whom all messages are forwarded.
The maximum number of recipients to which the mailbox can send a single message.
4-10
You use the message-size restrictions options to specify the maximum size for the messages that the
mailbox sends or receives.
You use the message delivery restrictions options to control the recipients that can send messages to
the mailbox.
Mailbox Features. Use these options to configure the mailboxs specific features, such as Microsoft
Outlook Web App, Microsoft Exchange ActiveSync, Unified Messaging, Post Office Protocol version
3 (POP3), Internet Message Access Protocol version 4 (IMAP4), and the Archive mailbox.
Calendar Settings. This option is new for Exchange Server 2003 administrators. Use this option to
configure how a mailbox processes meeting requests.
Mailbox Settings. There are four mailbox settings: messaging records management, federated sharing,
storage quotas, and archive quota. Use these options to configure a retention policy for the mailbox,
enable legal hold for the mailbox, set a sharing policy for the mailbox, set the user mailbox and
archive mailbox quota, and apply a role assignment policy for the user.
Email Addresses. Use this option to configure the email addresses assigned to the mailbox.
Demonstration Steps
Display a users mailbox properties in the Exchange Management Console
1.
Open Exchange Management Console, and then expand Recipient Configuration.
2.
In Mailbox container, select Andrea Dunker mailbox, and then in the Actions pane, click
Properties.
3.
Explore each of the tabs to familiarize yourself with the User Mailbox properties in Exchange
Management Console.
4.
In Exchange Management Shell, run the following cmdlet to demonstrate user mailbox properties
in Exchange Management Shell:
Get-Mailbox Identity Andrea Dunker | fl
Demonstration: Configuring Mailbox Permissions
4-11
In Exchange Server 2010 and in Exchange Server 2007, you use the Exchange Management Console and
Exchange Management Shell to configure Full Access and Send As Mailbox Permissions. In Exchange
Server 2003, administrators used Active Directory Users and Computers.
In this demonstration, you will see how to assign Full Access and Send As permissions to a mailbox.
Demonstration Steps
Assign Send As permissions to a mailbox

1.
Open the Exchange Management Console, and then expand Recipient Configuration.
2.
In the Mailbox container, select Adam Carter mailbox, and then start the Manage Send As
Permission wizard.
3.
Select Don Roessler as a user that will have Send As permissions on Adam Carters mailbox.
Assign Full Access permissions to a mailbox

1.
In the Mailbox container, select the Adam Carter mailbox, and then start the Manage Full Access
Permission wizard.
2.
Select Spencer Low as a user that will have Full Access permission on Adam Carters mailbox.
4-12
Moving Mailboxes in Exchange Server 2010
Microsoft Exchange Server 2010 introduces new technology for moving mailboxes, called move request.
While a move request is in progress, user mailboxes stay online, allowing users to continue sending and
receiving email, assuming that source mailbox databases are located on Exchange Server 2010 or
Exchange Server 2007 Service Pack 2 (SP2) or later, and the target mailbox databases are located on
In a coexistence scenario, when you move mailboxes from Exchange Server 2007 to Exchange Server 2010,
the mailboxes also stays online, and users can continue to send and receive mail. However, when you
move mailboxes from Exchange Server 2003 to Exchange Server 2010, users mailboxes are disconnected.
To create a move request, you need to run a series of cmdlets or use a wizard to initiate the move request.
Mailbox move request technology has the following features:
Moving the mailboxes is asynchronous, and the Mailbox Replication Service (MRS) carries out the
move.
Mailboxes are kept online during the asynchronous moves.
The mailboxs Recoverable Items folder moves with the mailbox when you move it between Exchange
Server 2010 Mailbox servers. Deleted items that have not been purged from the mailboxes are also
moved from Exchange Server 2003 and Exchange Server 2007.
Fast search is available upon completion. As soon as the mailbox begins to move, content indexing
starts to scan the mailbox so that fast searching is available upon the moves completion.
You can configure throttling for each MRS instance, each mailbox database, or each mailbox server.
You can move mailboxes over the Internet, and you can manage them from anywhere within the
organization.
The mailbox maintains the mailboxs move history.
4-13
You can view the move request status in the Exchange Management Console and Exchange Management
Shell. During the move request process, the following actions are performed by Mailbox Replication
Service on mailbox server role:
Active Directory is updated with an information that mailbox move is initiated. From that point, the
move request has the status Queued.
Mailbox Replication Service will start to move the mailbox from source database to target database.
Now, the move request has the status In Progress.
Just before ending the mailbox move process, the move request will lock the mailbox while the final
mailbox synchronization is completed. During this time, the move request has the status Completion
in Progress.
When the move is complete, the mailbox on target database will be activated, and the mailbox on the
source location will be soft deleted. The move request status will now change to Completed, and the
user is notified that the mailbox configuration has been changed and that the clientsuch as
Microsoft Office Outlook 2010should be restarted so that the user may continue to work.
After verifying that the move was successful, you should delete the move request by using the
Exchange Management Console or Exchange Management Shell.
Note If both Exchange 2010 Mailbox servers are running Exchange Server 2010 Service
Pack 1 (SP1) Update Rollup 2, and the RPCClientAccessServer attribute for the source and
destination mailbox database is the same, you do not need to restart Outlook clients to
connect to the moved mailbox.
Note In Exchange Server 2010, there are two types of move requests: local move requests,
when move requests are performed between Exchange Servers in same forest, and remote
move requests, when move requests are performed between Exchange Servers in different
forests.
Note Before you can move mailboxes from Exchange Server 2003 to Exchange Server 2010,
you have to make sure that the object is compatible with Exchange Server 2010. For
example, if mailbox aliases have spaces or other illegal characters in Exchange Server 2003,
the objects must be updated and spaces removed in Exchange Server 2003 before they can
be moved to Exchange Server 2010.
4-14
Demonstration: How to Move a Mailbox by Using Exchange Management

Console
In this demonstration, you will see how to move mailboxes by using the Exchange Server 2010 Exchange
Management Console.
The mailboxes will be located on both Exchange Server 2003 and Exchange Server 2010.
Demonstration Steps
Move Parna Khots mailbox located on Exchange Server 2010 to Mailbox Database 1
1.
If required, open Exchange Management Console.
2.
Locate the Parna Khot mailbox, and start the New Local Move Request wizard.
3.
Select Mailbox Database 1 as a target database.
Move Bart Duncans mailbox located on Exchange Server 2003 to Mailbox Database
1
1.
If required, open Exchange Management Console.
2.
Locate the Bart Duncan mailbox, and notice that it is Legacy Mailbox.
3.
Start the New Local Move Request wizard.

Question: What is the benefit of mailbox move requests?
What Are Resource Mailboxes?
4-15
Resource mailboxes are specific types of mailboxes that you can use to represent meeting rooms or
shared equipment, and you can include them as resources in meeting requests. The Active Directory user
associated with a resource mailbox is a disabled account. Resource mailboxes are also available in
Exchange Server 2007, but not in Exchange Server 2003.
There are two types of resource mailboxes:
Room mailboxes. Room mailboxes are resource mailboxes that you can assign to meeting rooms, such
as conference rooms, auditoriums, and training rooms.
Equipment mailboxes. Equipment mailboxes are resource mailboxes that you can assign to nonlocation-specific resources, such as portable computer projectors, microphones, or company cars.
After creating the resource mailbox, you must configure mailbox properties, such as location and size.
Then, you must define the resource booking policy, and enable the Resource Booking Attendant. Users
can include both types of resource mailboxes as resources in meeting requests.
Resource mailboxes provide a simple and efficient way to utilize resources for your users. You can
configure resource mailboxes to automatically process incoming meeting requests based on the resource
booking policies that are defined by the resource owners. For example, you can configure a conference
room to accept incoming meeting requests automatically, with the exception of recurring meetings, which
you can make subject to approval by the resource owner.
Note You may also add custom resource properties that will provide additional information
for a resource mailbox. For example, you may define custom resource property named
Building Number that will identify all room mailboxes located in same building. For more
information on custom resource properties, see
http://go.microsoft.com/fwlink/?LinkId=214421.
4-16
Designing Resource Booking Policies
Exchange Server 2010 provides several optionsor, booking policiesthat you can use for configuring
resource mailbox settings and for customizing the resource mailbox to meet your organizations needs.
Booking polices define how resources are allowed to be automatically scheduled.
A resource booking policy specifies:
Who can schedule a resource.
When the resource can be scheduled.
What meeting information will be visible on the resources calendar.
The response message that meeting organizers will receive.
Options for Configuring Automated Booking Policies
In Exchange Server 2010, as a meeting organizer, you automate booking policies to allow meetings sent
to resource mailboxes to be processed automatically. When you send a meeting request to a resource
mailbox, the meeting request can be processed automatically, and depending on the resource availability,
the request may be approved or declined.
There are two types of meeting requests sent to the resource mailbox:
In-policy meeting requests. These are meeting requests that don't violate any of the resource
scheduling options.
Out-of-policy meeting requests. These are meeting requests that violate any of the resource
scheduling options, such as those which conflict with an existing resource reservation or that occur
outside the regular business hours.
4-17
In Exchange Server 2010, you can also use the Set-CalendarProcessing command in the Exchange
Management Shell to configure resource booking policies. The following table lists the settings that you
can configure.
Setting
Description
AllowConflicts
Specifies whether to allow conflicting meeting requests. The

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

default setting is True, which allows you to books rooms and
equipment for recurring meetings such as weekly status
meetings.
AllRequestInPolicy
Specifies whether to allow all users to submit in-policy requests.

The default setting is True, which allows all users to request
appointments with the resource, if the request meets all specified
requirementssuch as no conflicts. A resource mail delegate still
must approve all requests, unless AllBookInPolicy is True.
AllBookInPolicy
Specifies whether to approve automatically in-policy requests

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

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

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

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

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

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

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

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

meeting requests.
RequestInPolicy
Specifies a list of users who are allowed to submit in-policy

meeting requests.
4-18
Setting
Description
RequestOutOfPolicy
Specifies a list of users who are allowed to submit appointment

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

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

calendar. The default setting is True, which marks appointment
requests as tentative until they are approved. When this setting is
False, pending appointments do not display on the calendar.
MaximumDurationInMinutes
Specifies the maximum length of the appointment that the

resource will accept.
Considerations for Developing a Resource Booking Policy

When designing the resource booking policy, you should consider:
Who can schedule a resource, and whether all users should be able to book a resource for a meeting.
You might accept the default settings for most resources in the organization, but consider restricting
who can book heavily-used or important resources. For example, if you use a resource room mailbox
to manage the schedule for a large conference room, you may want to restrict who can book
meetings in the conference room.
When users can schedule the resource. You may want to set restrictions on the time of day when
meetings can be booked with a resource, or restrict the meeting length or meeting recurrence.
The automatic acceptance policy for the meeting resource. By default, all resource mailboxes are
configured to accept all new appointment requests as tentative, until a user approves the request.
Because the meeting is set to tentative, this also enables other users to book the meeting resource for
the same time. By changing the Automate Processing attribute for the resource mailbox, you can
modify the default behavior. The default value is configured as Auto Update. If you set the value to
Auto Accept, the resource mailbox accepts all meetings automatically from authorized users, and
prevents other users from booking the resource at the same time.
Question: How will you use resource mailboxes in your environment?
Demonstration: How to Manage Resource Mailboxes
4-19
In this demonstration, you will see how to use the Exchange Server 2010 Exchange Management Console
to create a resource mailbox, configure it to accept appointments, and then create a delegate for the
resource.
Demonstration Steps
Create and configure a resource mailbox

1.
Click Start, click All Programs, click Microsoft Exchange Server 2010, and then click Exchange
Management Console.
2.
and then click Mailbox.
3.
Create a new room mailbox with the following information:
Name: Conference Room 1
User logon name (User Principal Name): ConferenceRoom1
Alias: ConferenceRoom1
4.
After creating the room mailbox, open the properties dialog box, and then enable the resource
booking attendant.
5.
Open Windows Internet Explorer, and then log on to Outlook Web App as
6.
In Outlook Web App, create a new Meeting Request.
7.
In the Untitled Meeting window, type the following information in the displayed fields, and then click
the Scheduling Assistant tab.
In the Subject: field: Sales Meeting
4-20
In the To field: Administrator
In the Location: field: Conference Room 1
Set a Start time and an End time.
8.
Click the down arrow next to Select Rooms, and then click More.
9.
In the Address Book window, double-click Conference Room 1, and then click OK.
10. Send the meeting request, and then verify that the resource accepted the invitation.
Question: How does your organization use resource mailboxes?
Question: Which attributes are useful for your resource mailboxes?
Lesson 2
Configuring Mail Users, Mail Contacts, and Distribution

Groups in Exchange Server 2010
4-21
Exchange Server 2010 also includes other recipient types, such as mail users, mail contacts and
distribution groups, that existed in previous Exchange Server versions. Managing these objects is similar to
doing so in Exchange Server 2007, but is substantially different compared to Exchange Server 2003.
In this lesson, you will be introduced to the other types of Exchange Server 2010 recipients, such as
contacts and distribution groups.
Objectives
Configure mail users and mail contacts in Exchange Server 2010.
Configure distribution groups in Exchange Server 2010.
Manage public distribution groups using the Exchange Control Panel.
4-22
Demonstration: Configuring Mail Users and Mail Contacts in Exchange

Server 2010
Exchange Server 2010 Mail Users and Mail Contact functionality did not change from previous Exchange
Server versions. As with User Mailboxes, Exchange Server 2010 administrative tools differ from Exchange
Server 2003. In both Exchange Server 2010 and Exchange Server 2007, you perform Mail Users and Mail
Contacts administrative tasks by using Exchange Management Console and Exchange Management Shell.
In Exchange Server 2010, some tasks are performed using Exchange Control Panel.
In this demonstration, you will see how to display the mail user properties window in Exchange
Management Console.
Demonstration Steps
Display the mail user properties window in Exchange Management Console and
1.
Open Exchange Management Console, and then expand Recipient Configuration.
2.
In Mail Contact container, select mail user Maurice Taylor, and then in the Actions pane, click
Properties.
3.
Review each of the tabs to familiarize yourself with the mail user properties in the Exchange
Management Console.
4.
In Exchange Management Shell, run following cmdlet to demonstrate user mailbox properties in
Exchange Management Shell:
Get-MailUser Identity Maurice Taylor | fl
Options for Configuring Distribution Groups in Exchange Server 2010
4-23
Distribution groups in Exchange Server 2010 have similar functionality as in previous versions of Exchange
Server, but there are some new features. Similar to other recipient objects, administrative tools differ from
Exchange Server 2003. In both Exchange Server 2010 and Exchange Server 2007, administration of
distribution groups is performed using the Exchange Management Console and Exchange Management
Shell, and in Exchange Server 2010, some tasks are performed using the Exchange Control Panel.
Changes in Exchange Server 2010 distribution groups include:
Distribution groups scope and type. Distribution groups in Exchange Server 2010 can only be
Universal Security Groups.
Public Groups. In Exchange Server 2010, you can assign permission to your users to create and
manage distribution groups using the Exchange Control Panel. Those distribution groups are called
Public Groups.
Note To provide users with permission to create Public Groups, you should create a new
role group with Security Group Creation and Membership role using the NewRoleGroup cmdlet in Exchange Management Shell, and add users to this group.
Joining and leaving Public Groups. In Exchange Server 2010, users with no administrative permissions
can join or leave Public Groups by choosing the appropriate option in Exchange Control Panel, such
as Join or Leave. Message moderation. Use these options to assign moderators permissions to review
all messages that are sent to the distribution list. You also can configure a list of users that do not
require moderation. Additionally, you can configure notifications to alert the message originators if
their message is approved or not.
Membership approval. Use these options to control if and how users can join or leave the group.
4-24
Choose whether owner approval is required to join the group. If you select Open, users can join this
distribution group without the approval of the distribution group owners. If you select Closed, only
distribution group owners can add members to the group. Requests to join this distribution group
will be rejected automatically. If you select Owner Approval, users can request membership on this
distribution group. The distribution group owner must approve requests to join the group before the
user can join.
Choose whether the group is open to leave. If you select Open, users can leave this distribution group
without the approval of the distribution group owners. If you select Closed, only distribution group
owners can remove members from this distribution group. Requests to leave this distribution group
will be rejected automatically.
Note Distribution groups in Exchange Server 2010 do not support spaces in aliases as was
possible in Exchange Server 2003. During the upgrade, if you use the Exchange Management
Console on Exchange Server 2010 to manage distribution groups that were created in
Exchange Server 2003 that have spaces in their aliases, an error will be displayed. To manage
these distribution groups in Exchange Server 2010, you should remove spaces from the
aliases where you will be prompted to confirm the upgrade of the distribution groups
objects. After you confirm the upgrade, you will be able to manage distribution groups only
from Exchange Server 2010 management tools.
4-25
Demonstration: Managing Public Groups by Using the Exchange Control

Panel
Public groups are a new Exchange Server 2010 feature that enables users who have the requisite
permissions to add distribution groups, manage membership, and moderate content.
In this demonstration, you will see how to add users to the Recipient Management role group, use the
Exchange Control Panel to both create a new group and request to join a group, and approve a users
request to be added to a group.
Demonstration Steps
Add a user to the Recipient Management role group
In Active Directory Users and Computers, add Ed Meadows to the Recipient Management role
group.
Use the Exchange Control Panel to create a new group

1.
Log on to Exchange Control Panel as Ed Meadows, and create a new Sales Group.
2.
Add the following members:
3.
Manoj Syamala
Rohinton Wadia
Paul West
Expand Membership Approval, and then select Owner Approval.
Use the Exchange Control Panel to request to join a group
Log on to the Exchange Control Panel as Wei Yu to request to join the Sales group.
4-26
Approve a users request to be added to a Group

1.
Log on to Outlook Web App as Contoso\Ed, with the password, Pa$$w0rd.
2.
In the Request to Join Distribution Group message pane, click Approve.
3.
Close Outlook Web App.

Question: When would you use public groups?
Lesson 3
Configuring Email Address Policies and Address Lists in

4-27
In Exchange Server 2010as in previous Exchange Server versionsyou can create and apply email
address policies to ensure that recipients have appropriate email addresses. In Exchange Server 2010 and
Exchange Server 2007, you use Exchange Management Console and Exchange Management Shell for
administration of email address policies and address lists.
This lesson introduces email address policies, and how to configure them in Exchange Server 2010. The
lesson also describes address lists and how to manage them.
Objectives
Configure email address policies in Exchange Server 2010.
Configure email address lists in Exchange Server 2010.
Configure offline address books in Exchange Server 2010.
Upgrade email address policies and address lists to Exchange Server 2010.
4-28
Email Address Policies in Exchange Server 2010
As in previous Exchange Server versions, email address policies in Exchange Server 2010 generate the
primary and secondary email addresses for your recipients. However, you must create an accepted
domain so that a domain in an email address policy functions properly. An accepted domain is an SMTP
namespace that you can configure Exchange servers to send messages to, or from which they can receive
messages. You will learn more about accepted domains in Module 6, Managing Message Transport.
Creating an Email Address Policy
Exchange Server applies an email address policy to a recipient group based on an OPATH filter. OPATH is
a querying language designed to query object-data sources, which was introduced in Exchange Server
2007, and it replaces the LDAP syntax in Exchange Server 2007.The OPATH filter defines the search scope
in the Active Directory forest, and the attributes to match.
The New Email Address Policy wizard provides the following list of recipient scope filters which may be
applied to an entire domain or to a specific organizational unit:
All recipient types.
Users with Exchange mailboxes.
Users with external email addresses.
Resource mailboxes.
Contacts with external email addresses.
Mail-enabled groups.
After you define the recipient scope for the new email address policy in the New E-Mail Address Policy
Wizard, you may define additional conditions such as:
Recipient is in a State or Province.
Recipient is in a Department.
Recipient is in a Company.
Custom Attribute equals Value.
4-29
Finally, in the New E-Mail Address Policy Wizard, you define the email addresses, where you can use the
following email address types:
Predefined SMTP email address. Predefined SMTP email addresses are commonly used email address
types provided by this wizard, such as:
Alias
First name.Last name
First name and last name initial
Custom SMTP email address. If you do not want to use one of the pre-defined 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.
Note You may choose criteria other than what is available in the Exchange Management
Shell by using the Exchange Management Shell command Set-EmailAddressPolicy with the
-recipientfilter attribute.
NonSMTP email address. Exchange Server 2010 supports a number of non-SMTP address types.
When you upgrade from Exchange Server 2003, you need to complete an upgrade process to allow
Exchange Server 2010 administrative tools to manage the legacy Recipient policies as Email Address
policies.
4-30
Demonstration: How to Configure Email Address Policies
In this demonstration, you will see how to create a new email address policy, and verify that the policy has
been applied.
Demonstration Steps
Create a new email address policy for Fourth Coffee recipients

1.
2.

Configuration, and then select Hub Transport.
3.
Create a new email address policy with the following attributes:
Name: Fourth Coffee
Display Name: Fourth Coffee
Included recipient types: All Recipient types
4.
Use the user Alias as the local part of the email address.
5.
Select fourthcoffee.com as the accepted domain.
6.
Apply the email address policy immediately.
Verify that the email address policy has been applied

1.
and then select Mailbox.
2.
In the results pane, double-click Jane Dow.
3.
View the current Email addresses that have been assigned.
Demonstration: How to Configure Email Address Lists
4-31
As in previous Exchange versions, an address list is a collection of Exchange Server recipient objects.
Address lists are displayed in Outlook clients and are used to simplify the user experience when viewing
the global address list.
In this demonstration, you will see how to create and configure address lists, and verify that the new email
address list is operational.
Demonstration Steps
Create a new email address list for Fourth Coffee recipients

1.
2.

Configuration, and then select Mailbox.
3.
Create a new address list with the following attributes.
Name: Fourth Coffee
Display Name: Fourth Coffee
Container: \
Included recipient types: All Recipient types
4.
Use the Recipient is in a Company condition to apply this policy to only recipients that list Fourth
Coffee as their company attribute.
5.
Preview the address list.
6.
Apply the email address list immediately.
4-32
Verify that the new email address list is operational

1.
Log on to Outlook Web App as Contoso\George, with the password, Pa$$w0rd.
2.
Open the Address book, and view the members of the Fourth Coffee address list.
3.
Close Outlook Web App.
Configuring Offline Address Books in Exchange Server 2010
4-33
Exchange Server 2010 provides several configuration options for deploying offline address books.
Microsoft Office Outlook uses the offline address book when you configure it to use a cached mode
Outlook profile, or when it is in offline mode. The default offline address book contains the entire GAL,
but does not include any additional GALs that have been created.
By default, the offline address book generates only once each day. This means that any additions,
deletions, or changes made to mail-enabled recipients are only committed to the offline address book
once each day, unless you modify the schedule to generate the offline address book more often. In many
environments, you would need to modify the offline address book generation schedule to accommodate
the rate of change in a particular Exchange Server organization.
The process of generating and distributing the Offline Address Book (OAB) consists of following
components:
OAB generation process. This process creates and updates the OAB. To create and update the OAB,
the OABGen service runs on the OAB generation server, which must be a Mailbox server.
Microsoft Exchange File Distribution service. The Microsoft Exchange File Distribution service runs
on Client Access servers. This service gathers the OAB and keeps the content synchronized with the
content on the OAB generation server.
OAB virtual directory. The OAB virtual directory is the distribution point needed by the web-based
distribution used by Microsoft Office Outlook 2007 and newer clients. By default, when Exchange is
installed, a new virtual directory named OAB is created in the default internal Web site in Internet
Information Services (IIS). For users that work outside your company, you can add an external website.
Autodiscover service. Autodiscover service was introduced in Exchange Server 2007 as a feature
where Microsoft Office Outlook 2007 or newer clients, as well as some mobile devices, automatically
configure their profile to access Exchange Server. This service runs on a Client Access server and
returns the correct OAB URL for a specific client connection.
4-34
As a best practice, whether you use a single offline address book or multiple offline address books,
consider the following factors as you plan and implement your offline address book strategy:
Size of each offline address book in your organization.
Number of offline address book downloads. How many clients will need to download the offline
address book?
Overall number of changes made to the directory. If a large number of changes are made, the size of
the differential offline address book downloads also will be large.
Offline Address Book Size Considerations
In some large organizations that have large directories, or for organizations that have deployed Office
Outlook in cached mode, the size of the offline address book may be a concern. Offline address book
sizes can vary from a few megabytes (MBs) to a few hundred MBs. The following factors can affect the size
of the offline address book:
Usage of certificates in a company. The higher the number of public key infrastructure (PKI)
certificates, the larger the size of the offline address book. PKI certificates range from 1 kilobyte (KB)
to 3 KB. They are the single largest contributor to the offline address book size.
Number of Active Directory mail recipients.
Number of Active Directory distribution groups.
Information that a company adds to AD DS for each mailbox-enabled or mail-enabled object. For
example, some organizations populate the address properties for each user; others do not. The offline
address book size increases as the number of attributes used increases.
Options for Deploying Offline Address Books
Public folder distribution is the distribution method by which Microsoft Office Outlook 2003 accesses the
offline address book. With public folder distribution, the generation process for the offline address book
places the files directly in one of the system public folders, and then, if multiple replicas of the public
folder are configured, Exchange Server store replication copies the data to other public folder distribution
points.
Microsoft Office Outlook 2007 and newer clients that are working in cached mode can also use the
public folder as the source for the OAB. In addition, these clients can use web-based distribution to access
the offline address book. Web-based distribution does not require the use of public folders. Instead, after
the offline address book generates the files, the Client Access server replicates them. Web-based
distribution uses Secure Hypertext Transfer Protocol (HTTPS) and Background Intelligent Transfer Service
(BITS). If you require redundancy, you can use multiple Client Access servers as publishing points.
Note During the coexistence, one of the tasks you should perform is to move the offline
address book generation server from previous Exchange Server version to Exchange 2010
Mailbox Server by using Exchange Management Console or Exchange Management Shell.
Demonstration: Upgrade Email Address Policies and Address Lists to

4-35
In a coexistence scenario where Exchange Server 2010 is installed in an Exchange Server 2003 or Exchange
Server 2007 organization, email address policies and address lists created in the previous Exchange Server
version display, but cannot be managed by using Exchange Server 2010 Exchange Management Console
or Exchange Management Shell.
During the upgrade process, you should also upgrade email address policies and address lists to Exchange
Server 2010.
Email address policies and address lists that exist in Exchange Server 2003 use Lightweight Directory
Access Protocol (LDAP) syntax filters, which are not supported in Exchange 2010. To edit these email
address policies and address lists by using Exchange Server 2010 management tools, you must upgrade
these LDAP filters to the OPATH syntax.
In this demonstration, you will see how to upgrade LDAP filters to OPATH syntax for email address
policies and address lists.
Demonstration Steps
Use Exchange Management Shell to upgrade email address policies

1.
Open Exchange Management Shell.
2.
Run the following cmdlet:
Set-EmailAddressPolicy "Default Policy" -IncludedRecipients AllRecipients
3.
After the command completes, ensure that you can now edit the Default Policy email address policy
by using Exchange Management Console.
4-36
Use Exchange Management Shell to upgrade email address lists

1.
Open Exchange Management Shell.
2.
Run the following cmdlets:
Set-AddressList "All Users" -IncludedRecipients MailboxUsers

Set-AddressList "All Groups" -IncludedRecipients MailGroups
Set-AddressList "All Contacts" -IncludedRecipients MailContacts
Set-GlobalAddressList "Default Global Address List" -RecipientFilter {(Alias -ne $null and (ObjectClass -eq 'user' -or ObjectClass -eq 'contact' -or ObjectClass -eq
'msExchSystemMailbox' -or ObjectClass -eq 'msExchDynamicDistributionList' -or
ObjectClass -eq 'group' -or ObjectClass -eq 'publicFolder'))}
3.
After the command completes, ensure that you can now edit the upgraded address lists by using
Important After you complete the upgrade process, you will not be able to edit either
email address policies or address lists by using Exchange System Manager in Exchange Server
2003.
Lesson 4
Performing Bulk Recipient Management Tasks in

4-37
Managing a large number of Exchange Server recipients can be time-consuming. Manual changes are also
prone to error. You can use the Exchange Management Shell in Exchange Server 2010 to create scripts
that automate these management tasks.
Exchange Management Shell was not present in Exchange Server 2003, so administrators used VB scripts
to accomplish many of the bulk recipient tasks.
In this lesson, you learn how to use Exchange Management Shell to manage multiple recipients, and
complete many of the bulk recipient tasks.
Objectives
Describe the benefits of managing recipients in bulk.
Explain how to manage multiple recipients.
4-38
Discussion: Benefits of Bulk Recipient Management
Exchange Server 2010 Exchange Management Shell cmdlets are powerful tools that you can use to
manage multiple recipients simultaneously. The cmdlets use features such as pipelining and filtering to
sort the results of one cmdlet, and then apply the result to another cmdlet. Exchange Management Shell
also is a scripting tool for managing multiple recipients in bulk. In smaller organizations, you might not
need to manage multiple recipients simultaneously. However, in medium or large organizations, you may
often need to manage multiple users simultaneously, and it is useful to know how to use Exchange
Management Shell for this purpose.
Question: Describe situations where you need to create multiple recipients.
Question: Describe situations where multiple recipients may need to be modified.
Demonstration: How to Manage Multiple Recipients
4-39
Exchange Server 2010 Exchange Management Shell provides several features that you can use to perform
bulk recipient management. For relatively simple tasks, you can pipe output between cmdlets to retrieve a
list of appropriate objects, and then you can modify those objects. You can use scripting for complex
tasks, such as creating users from a .csv file.
Piping Output Between Cmdlets
For relatively simple tasks, pipe output from one cmdlet to another to perform bulk management tasks.
The most common structure is to use one cmdlet to gather a list of recipients or Active Directory objects,
and then pipe that list to a second cmdlet that performs the necessary action.
In the following example, the first cmdlet gathers the list of Marketing organizational unit (OU) users, and
then you pipe that list of users to a second cmdlet that moves those users to the Accounting mailbox
database.
Get-User OrganizationalUnit Marketing | New-MoveRequest TargetDatabase "Accounting"
All cmdlets that gather lists of objects for manipulation begin with Get. Some cmdlets that gather a list of
recipients or Active Directory objects are:
Get-User. Gathers a list of user objects from AD DS.
Get-Recipient. Gathers a list of recipients.
Get-Mailbox. Gathers a list of mailboxes.
Get-MailUser. Gathers a list of mail-enabled users.
Get-Contact. Gathers a list of contacts.
Get-Group. Gathers a list of groups from AD DS.
4-40
Custom Filters
You must specify a filter string if you are running various Exchange Management Shell cmdletssuch as
Get-Userand you want to create a custom filter by using the Filter or RecipientFilter parameter.
Windows PowerShell uses OPATH for the filtering syntax as follows:
Syntax: -Filter {(attribute operation 'value') operation (attribute operation 'value')}
The following cmdlet selects users with the Company attribute defined as Adventure Works, and who are
not working in the IT department.
Get-User -Filter {(Company eq 'Adventure Works') -and (Department ne 'IT')}
Common operations are:
-and
-or
-not
-eq (equals)
-ne (does not equal)
-lt (less than)
-gt (greater than)
-like (string comparison)
-notlike (string comparison)
Scripts
Create scripts to perform advanced bulk-management tasks that are not possible with piping. Scripts can
create more complex structures, and consequently enable you to perform more complex tasks.
Using scripts, you can:
Define variables.
Use loops.
Read data files to obtain user names and passwords.
In this demonstration, you will use pipelining to perform bulk management tasks to manage multiple
recipients.
Demonstration Steps
Use pipelining to manage multiple recipients
1.
Run the following cmdlets:
Get-User filter {Company eq "Fourth Coffee"}

Disable-mailbox Jane
Get-User filter {Company eq "Fourth Coffee"} | Enable-Mailbox database "Mailbox
Database 1"
4-41
Results: The first cmdlet displays all users whose company attribute in Active Directory is Fourth
Coffee. The second cmdlet will disable user mailbox Jane. The third cmdlet will display all users whose
company attribute in Active Directory is Fourth Coffee, and create a user mailbox for all users from that
list that do not have a mailbox. Therefore, the cmdlet output will display an error for users that already
have a user mailbox, and will display information regarding mailboxes created for users that did not have
a mailbox.
2.
Run the following script to create mailboxes based on information provided in a .csv file.
## Section 1
## Define Database for new mailboxes
$db="Mailbox Database 1"
## Define User Principal name
$upndom="Contoso.com"
## Section 2
## Import csv file into variable $users
$users = import-csv $args[0]
## Section 3
## Function to convert password string to secure string
function SecurePassword([string]$plainPassword)
{
$secPassword = new-object System.Security.SecureString
Foreach($char in $plainPassword.ToCharArray())
{
$secPassword.AppendChar($char)
}
$secPassword
}
## Section 4
## Create new mailboxes and users
foreach ($i in $users)
{
$sp = SecurePassword $i.password
$upn = $i.FirstName + "@" + $upndom
$display = $i.FirstName + " " + $i.LastName
New-Mailbox -Password $sp -Database $db DisplayName $display -UserPrincipalName $upn Name $i.FirstName -FirstName $i.FirstName -LastName $i.LastName -OrganizationalUnit
$i.OU
}
3.
In Exchange Management Console, verify that the users listed in the .csv file have been
created.Question: Which tasks will you automate with Windows PowerShell scripts?
4-42
Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, you must:
1.
2.
Ensure that the 10165A-NYC-DC1-B, 10165A-NYC-EX10-B, 10165A-NYC-EX03-B, and 10165A-NYCCL1-B virtual machines are running.
3.
10165A-NYC-DC1-B: Domain controller in the Contoso.com domain.
10165A-NYC-EX10-B: Exchange Server 2010 in the Contoso.com domain.
10165A-NYC-EX03-B: Exchange Server 2003 in the Contoso.com domain.
10165A-NYC-CL1-B: Client computer in the Contoso.com domain.
If required, connect to the virtual machines. Log on to the computers as Contoso\Administrator,

with the password, Pa$$w0rd.
Lab Scenario
You are the messaging administrator for Contoso, Ltd. You have deployed Exchange Server 2010 in an
Exchange Server 2003 organization, and you are now ready to start migrating mailboxes and recipients
from Exchange Server 2003 to Exchange Server 2010. Additionally, your company is purchasing a new
company called Adventure Works. Adventure Works recipients will need to maintain a separate email
domain and address list. You also must create new mailboxes for the Adventure Works employees.
Adventure Works maintains a distinct identity for customers, but some functions, such as accounting, are
integrated with Contoso, Ltd. To ensure that users receive all email properly, they must be able to receive
email at all domains, but use their own domain as the reply-to address.
4-43
Your company has configured several address lists, including custom address lists in Exchange Server
2003. Your task is to upgrade the address lists to Exchange Server 2010, and create a new address list for
Adventure Works users.
Finally, to speed up the process for managing recipient objects, you need to use scripts to manage
multiple user objects. You will use Exchange Management Shell commands and modify a script for use to
manage multiple user accounts more efficiently.
4-44
Exercise 1: Managing Recipients

Scenario
Your manager wants you to complete several tasks in preparation for the Adventure Works acquisition
project.
The main tasks for this exercise are:
1.
Move mailboxes from Exchange Server 2003 to Exchange Server 2010.
2.
Create and configure a mailbox called Adventure Works Questions.
3.
Create a moderated recipient account for the company president George Schaller, and designate a
moderator role to the company presidents administrative assistant, Parna Khot.
4.
Create a resource mailbox, and configure auto-accept settings for the Adventure Works Project
Room.
5.
Create a moderated distribution list for the Adventure Works Project, and delegate an administrator.
6.
Administratively set an Out of Office auto-reply for a user by using Exchange Control Panel.
7.
Configure and manage public distribution lists by using Exchange Control Panel.
8.
Upgrade distribution groups whose aliases contain spaces.
Task 1: Move mailboxes from Exchange Server 2003 to Exchange Server 2010
1.
On NYC-EX10, open the Exchange Management Console.
2.
Move Bobby Moores user mailbox from Exchange Server 2003 NYC-EX03, to Mailbox Database 1
on Exchange Server 2010, NYC-EX10.
Task 2: Create and configure a mailbox called Adventure Works Questions

1.
On NYC-EX10, if necessary, open the Exchange Management Console.
2.
Create a new mailbox in the Mailbox Database 1 database named Adventure Works Questions.
Configure a user logon name of AdventureWksQ, and a password of Pa$$w0rd.
3.
Assign George Schaller full access to the Adventure Works Questions mailbox.
Task 3: Create a moderated recipient account for the company president George
Schaller, and designate a moderator role to the company presidents administrative
assistant, Parna Khot
1.
On NYC-EX10, open the Exchange Management Shell.
2.
Designate Parna Khot as a moderator role for the George Schaller mailbox.
Task 4: Create a resource mailbox, and configure auto-accept settings for the
Adventure Works Project Room
1.
In Exchange Management Console, in the Mailbox Database 1 database, create a new room mailbox
named ProjectRoom. Configure a user logon name of ProjectRoom.
2.
Enable the Booking Attendant on ProjectRoom.
4-45
Task 5: Create a moderated distribution list for the Adventure Works Project, and
designate an administrator
1.
In Exchange Management Console, create a new Distribution group called Adventure Works
Project, with an alias of AdventureWorksProject.
2.
Add the following recipients to the Adventure Works Project group:
3.
George Schaller
Ian Palangio
Wei Yu
Paul West
Specify George Schaller as the group moderator, and enable moderation of all messages.
Task 6: Administratively set an Out of Office auto-reply for a user by using Exchange
Control Panel
1.
Open Internet Explorer and browse to https://NYC-EX10.contoso.com/ecp. Log on as

2.
Configure an Out of Office auto-reply for George Schaller using Exchange Control Panel.
Task 7: Configure and manage public distribution groups by using Exchange Control
Panel
1.
On NYC-EX10, click Start, click All Programs, and then click Internet Explorer.
2.
Type https://NYC-EX10.contoso.com/ecp in the Internet Explorer address bar and then press Enter.
3.
Log on to Exchange Control Panel as Contoso\Administrator, with the password, Pa$$w0rd.
4.
Use Exchange Control Panel to create the distribution group Sales, and configure membership for
the following users:
Manoj Syamala
Rohinton Wadia
Paul West
5.
Configure owner approval.
6.
Log on to Exchange Control Panel as Contoso\Wei, and send request to join the Sales group.
7.
As the Contoso\administrator, log on to Outlook Web App and approve Wei Yus request to be
added to the Sales Group.
Task 8: Upgrade distribution groups whose aliases contain spaces

1.
On NYC-EX10, if necessary, open the Exchange Management Console
2.
Double-click the All Company distribution group to edit its properties.
3.
Read the warning message which is displayed because All Company is a distribution group created in
Exchange Server 2003 whose alias contains a space.
4-46
4.
Upgrade the All Company distribution group to manage it with Exchange Server 2010 management
tools.
Results: After this exercise, you should have used the following Exchange Server 2010 management tools:
Exchange Management Console, Exchange Management Shell, and Exchange Control Panel. Using these
tools, you should have moved mailboxes from Exchange Server 2003 to Exchange Server 2010, and you
should have created the following: a mailbox on Exchange Server 2010, a resource mailbox, a moderated
distribution group, and a moderated recipient account. Using the Exchange Control Panel, you should
have set Out of Office replies, and established public distribution groups. You also should have edited a
distribution group created in Exchange Server 2003 and upgraded the distribution group to Exchange
Server 2010.
Exercise 2: Configuring Email Address Policies and Address Lists

Scenario
4-47
Adventure Works maintains a distinct identity for customers, but some functionssuch as accounting
are integrated with Contoso, Ltd. To ensure that users receive all email properly, they must be able to
receive email at all domains, but use their own domain as the reply-to address.
Contoso, Ltd is upgrading from Exchange Server 2003 to Exchange Server 2010, and email address
policies, address lists, and offline address books must be moved to Exchange Server 2010.
1.
Create an email address policy for Adventure Works users.
2.
Verify that addresses are applied correctly.
3.
Upgrade the email address policy from Exchange Server 2003 to Exchange Server 2010.
4.
Upgrade the default address lists from Exchange Server 2003 to Exchange Server 2010.
5.
Create a new address list for Adventure Works recipients.
6.
Verify the new address list is available in Office Outlook.
7.
Move the Default Offline Address Book generation server from Exchange Server 2003 to Exchange
Server 2010.
8.
Create a new offline address book for the Adventure Works address list to support both Office
Outlook 2003 and Office Outlook 2007 clients.
Task 1: Create an email address policy for Adventure Works users

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

1.
In the Exchange Management Console, view the properties for George Schaller, and modify his
company description to Adventure Works.
2.
Confirm that George Schaller has an email address by using the adventure-works.com email
address.
Task 3: Upgrade the email address policy from Exchange Server 2003 to Exchange
Server 2010
1.
On NYC-EX10, upgrade the default email address policy using Exchange Management Shell.
2.
Ensure that you can now edit the default email address policy by using Exchange Management
Console.
4-48
Task 4: Upgrade the default address lists from Exchange Server 2003 to Exchange
Server 2010
1.
On NYC-EX10, upgrade the default address lists by using Exchange Management Shell.
2.
Ensure that you can now edit the default address lists by using Exchange Management Console.
3.
On the Address Lists tab, create a new address list called Companies. Do not include any recipient
types. This will be used as a container for the next task.
Task 5: Create a new address list for Adventure Works recipients
On NYC-EX10, create a new address list for Adventure Works in the Companies container. Include
all recipients that have Adventure Works as their company setting.
Task 6: Verify the new address list is available in Office Outlook

1.
Start 10165A-NYC-CL1-B and log on as Contoso\Administrator, with the password, Pa$$w0rd.

Open Microsoft Outlook 2010.
2.
Verify that the address book contains the address lists for Adventure Works.
3.
Log off of NYC-CL1.
Task 7: Move the Default Offline Address Book generation server from Exchange
Server 2003 to Exchange Server 2010
1.
2.
Move the default offline address book from NYC-EX03 to NYC-EX10, and enable distributions
through web-based distribution and public folders. Use the OAB folder on NYC-EX10 for Web-based
distribution.
Task 8: Create a new offline address book for the Adventure Works address list to
support both Office Outlook 2003 and Outlook 2007 clients
1.
2.
Create a new offline address book named Companies by using the Adventure Works address list, and
enable distribution through web-based distribution and public folders. Use the OAB folder on NYCEX10 for web-based distribution.
3.
Close the Exchange Management Console.
Results: After this exercise, you should have created and verified an address list for the Adventure Works
users, moved email address policy, address lists and an offline address book from Exchange Server 2003 to
Exchange Server 2010, and created an offline address book for Adventure Works users on Exchange
Server 2010.
Exercise 3: Performing Bulk Recipient Management Tasks

Scenario
4-49
Your manager left you a number of recipient management tasks to complete for the new Adventure
Works users:
Add a header line to the .csv file exported from the Human Resources system.
Modify the CreateUsersLab.ps1 script, and import Adventure Works users from a .csv file.
Define mailbox limits for all users in the Adventure Works company.

1.
Add a header line to the .csv file exported from the Human Resources system.
2.
Modify the CreateUsersLab.ps1 script to import Adventure Works users from a .csv file.
3.
Create the AdventureWorks Organizational Unit.
4.
Run CreateUsersLab.ps1 to import the Adventure Works users.
5.
Set mailbox limits for all Adventure Works users.
Task 1: Add a header to the .csv file exported from the Human Resources system
1.
On NYC-EX10, open D:\Labfiles\Users.csv in Notepad.
2.
Add a header line that defines each column:
3.
FirstName
LastName
Password
Save the changes to Users.csv, and close Notepad.
Task 2: Modify the CreateUsersLab.ps1 script to import Adventure Works users from
a .csv file
1.
Open D:\Labfiles\CreateUsersLab.ps1 in Notepad.
2.
Modify CreateUsersLab.ps1 as required to:
3.
Configure the database as Mailbox Database 1.
Configure the user principal name to be Contoso.com.
Place users in the AdventureWorks OU.
Configure the .csv import file to be D:\Labfiles\Users.csv.
Configure the $pwd to be based on the password field in the Users.csv.
Configure the first and last name.
Configure the UPN as first name@Contoso.com.
Configure the alias to be the first name and last name, with no space between the names.
Configure the display name to be the first name and last name, with a space between the names.
Save the changes to CreateUsersLab.ps1, and close Notepad.
4-50
Task 3: Create the AdventureWorks Organizational Unit

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

1.
2.
Run D:\Labfiles\CreateUsersLab.ps1.
Task 5: Set mailbox limits for all Adventure Works users

1.
Run the Get-Mailbox cmdlet to retrieve a list of all Adventure Works users:
2.
OrganizationalUnit: AdventureWorks
Set mailbox limits by piping the list of mailboxes to the Set-Mailbox cmdlet:
IssueWarningQuota: 100MB
ProhibitSendQuota: 150MB
Results: After this exercise, you should have created all of the additional Adventure Works users with an
Exchange Management Shell script and set the storage quota.

When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the
following steps:
1.
2.
Right-click the virtual machine name in the Virtual Machines list, and then click Revert.
3.
4.
machine.
5.
machine.
6.
machine.
7.
machine.
8.
machine.
4-51
Review Questions
1.
How would you ensure that meeting requests to room mailboxes are validated manually before being
approved?
2.
What should you consider when configuring offline address book distribution?
Common Issues related to Configuring Offline Address Books
Identify the causes for the following common issues related to configuring offline address books, and fill
Issue
Troubleshooting tip
The offline address book is not upto-date with changes made during
the day.
Outlook 2003 clients are not able
to download the offline address
book.
Real-world Issues and Scenarios

1.
An organization has a large number of projects that leverage distribution groups. Managing group
members takes considerable time. How will you reduce the time the help desk spends in managing
groups so that they can work on other issues?The IT department is considering implementing
moderation on selected users or groups in order to provide information protection and control. What
should you do before implementing this technology? You are an administrator of an Exchange Server
2003 organization. During previous years, you have developed VB scripts for the bulk management of
Exchange Server 2003 recipient objects. Now, you are planning the upgrade process, and you are
considering the most efficient way for the bulk management of recipient objects after your
4-52
organization upgrades to Exchange Server 2010. What technology you should use for bulk
management of Exchange Server 2010 recipient objects? You are an administrator of an Exchange
Server 2003 organization where you have developed custom LDAP filters for your email address lists.
Because LDAP filters are not supported in Exchange Server 2010, what should you do to avoid
rewriting filters in OPATH?
Best Practices Related to Managing Recipient Objects

Define clear naming conventions and adhere to them. Naming conventions help identify location and
purpose of recipient objects, and help both end users and administrators locate recipients easily.
Test global changes prior to making them in production. Changes to global settings, like email
address policies, should be tested in a lab environment before you make changes in production. This
prevents configuration errors.
During the upgrade process, when moving user mailboxes from Exchange Server 2003, choose an
appropriate schedule because local move requests will disconnect users from their mailboxes.
When creating distribution groups in Exchange Server 2010, ensure that they will be used for
receiving mail from anonymous or authenticated users. As in Exchange Server 2007, distribution
groups created on Exchange Server 2010 by default will accept messages only from authenticated
users. Distribution groups upgraded from a previous Exchange Server version will inherit their
settings.

5-1
Module 5
Managing Client Access
Contents:
Lesson 1: Upgrading the Client Access Server Role
5-3
Lesson 2: Configuring the Client Access Server Role
5-17
5-34
Lesson 3: Configuring Client Access Servers for Outlook Clients
5-39
Lesson 4: Configuring Microsoft Outlook Web App
5-56
Lesson 5: Configuring Mobile Messaging
5-65
Lab B: Configuring Client Access Servers for Outlook Web App and
Exchange ActiveSync
5-74
Module Overview
5-2
Microsoft Exchange Server 2010 provides access to user mailboxes for various clients. All messaging clients
access Exchange Server 2010 mailboxes through a Client Access server. Because of the importance of this
server role, you must understand how to configure it to support all different client types. This module
provides details on how to upgrade and implement the Client Access server role in Exchange Server 2010.
Objectives
Upgrade the Client Access server role.
Configure the Client Access server role.
Configure Client Access servers for Microsoft Office Outlook Clients.
Configure Microsoft Outlook Web App.
Configure mobile messaging.
Lesson 1
Upgrading the Client Access Server Role
5-3
As you already learned in previous modules, when you install Exchange Server 2010 in an Exchange Server
2003 or Exchange Server 2007 organization, we refer to that scenario as coexistence. During coexistence,
you should provide users with access to their mailboxes regardless of whether they are located on
previous versions of Exchange Server, or on Exchange Server 2010. To provide users with continuous
access to their mailboxes during the upgrade process, you should know how different versions of
Exchange Server communicate with the Exchange Server 2010 client access role.
Objectives
Compare virtual directories between Exchange Server 2010 and previous Exchange Server versions.
Understand client access server behavior during coexistence.
Describe the certificate requirements for enabling coexistence.
Configure certificates for coexistence.
Upgrade the Client Access server to Exchange Server 2010.
5-4
Comparing Virtual Directories Between Exchange Server 2010 and Previous

Exchange Versions
To ensure that you understand how the Exchange Server versions coexist, it is very important that you
identify which virtual directories changed, were decommissioned, or are new in Exchange Server 2010.
The following table lists comparisons for virtual directories and namespaces used in Exchange 2003 FrontEnd server, Exchange 2007 Client Access server, and Exchange 2010 Client Access server.
Office Outlook Web Access (OWA)

/exchange
/exchweb
/public
Outlook Web Access

/owa
Outlook Web App

/owa
Microsoft Exchange
ActiveSync
/microsoft-server-activesync
Exchange ActiveSync
Exchange ActiveSync
Outlook Anywhere
/rpc
Outlook Anywhere
/rpc
Outlook Anywhere
/rpc
Outlook Mobile Access

/oma
Discontinued
Discontinued
Not present in this version
Exchange Web Services

/ews

/ews
Offline Address Book (OAB)

/oab
OAB
/oab
Unified Messaging
/unifiedmessaging
Unified Messaging
/unifiedmessaging
Autodiscover
/autodiscover
Autodiscover
/autodiscover

/ecp
5-5
Client Access Server Behavior During Coexistence
When the client connects to a Client Access server in Exchange Server 2010 during coexistence, the
following actions occur depending on the type of client and user mailbox location:
1.
5-6
Outlook Web App in Exchange Server 2010 and Outlook Web Access in Exchange Server 2003
coexistence:
If a user mailbox is located on an Exchange 2003 server, Outlook Web App on an Exchange 2010
Client Access server will redirect the Hypertext Transfer Protocol/Secure (HTTPS) traffic to an
Exchange 2003 Front-End server with Single Sign On (SSO) Forms-based authentication. The URL that
is used to redirect clients to the Exchange 2003 server must be configured on the OWA virtual
directory on the Exchange 2010 Client Access server. You will notice that the URL will change
automatically from a name such as https://mail.contoso.com/owa to a name such as
https://legacy.contoso.com/exchange.
2.
Outlook Web App in Exchange Server 2010 and Outlook Web Access in Exchange Server 2007
coexistence:
If a user mailbox is located on an Exchange 2007 Mailbox server in the same Internet-facing Active
Directory Domain Services (AD DS) site, Exchange Server 2010 will redirect the HTTPS traffic to an
Exchange 2007 Client Access server with Single Sign On Forms-based authentication. You will notice
that the URL will change from a name such as https://mail.contoso.com/owa to a name such as
https://legacy.contoso.com/owa.
If a user mailbox is located on an Exchange 2007 Mailbox server in a different Internet-facing site
such as branch office siteExchange 2010 Client Access server will manually redirect the HTTPS traffic
to an Exchange 2007 Client Access server. This means that the browser will display a notice that the
wrong URL is being used, and that the correct URL is a name like https://mail2.contoso.com/owa,
where mail2.contoso.com is the external URL Exchange 2007 Client Access server in the branch office
Internet-facing site. Users should then click on the https://mail2.contoso.com/owa link, where they
5-7
will be asked to enter their credentials in the forms-based authentication webpage, and authenticate
against the Exchange 2007 Client Access server 2007 in that branch office Internet-facing site.
If a user mailbox is located on an Exchange 2007 Mailbox server in a different non-Internet-facing
Active Directory site, the Exchange 2010 Client Access server will proxy the HTTPS traffic to an
Exchange 2007 Client Access server. The URL (for example, https://mail.contoso.com/owa) will not
change.
To allow an Exchange 2010 Client Access server to proxy Outlook Web App requests to an Exchange
2007 Client Access server in another Active Directory site, you must copy the highest-versioned folder
from an Exchange 2007 Client Access server in the destination Active Directory site from the
%installpath%\ClientAccess\OWA\ folder to the same path on the Exchange 2010 Client Access server
that is making the proxy request..
3.
Exchange ActiveSync in Exchange Server 2010 and Exchange Server 2003 coexistence:
If the user's mailbox is on an Exchange 2003 server, the incoming request is proxied directly to the
Exchange 2003 server that hosts the user's mailbox and the Exchange ActiveSync virtual directory. By
default, in Exchange Server 2003, the Exchange ActiveSync virtual directory was installed on all
mailbox servers. The Active Directory site of the user's mailbox is not applicable in this case because
Exchange Server 2003 does not use Active Directory sites to determine location. The connection is
always made directly from the Exchange 2010 Client Access server to the Exchange 2003 Mailbox
server.
Note Users who have mailboxes on an Exchange 2003 server who try to use Exchange
ActiveSync through an Exchange 2010 Client Access server will receive an error and will be
unable to synchronize unless Integrated Windows authentication is enabled on the
Microsoft-Server-ActiveSync virtual directory on the Exchange 2003 server. Integrated
Windows authentication enables the Exchange 2010 Client Access server and the Exchange
2003 back-end server to communicate.
4.
Exchange ActiveSync in Exchange Server 2010 and Exchange Server 2007 coexistence:
If the users mailbox is on an Exchange 2007 Mailbox server, the Exchange 2010 Client Access server
locates an Exchange 2007 Client Access server in the same Active Directory site as the user's Mailbox
server. This may be the same Active Directory site or a different site. The Exchange 2010 Client Access
server determines whether the Exchange 2007 Client Access server has the ExternalURL property
configured on the Exchange ActiveSync virtual directory. If so, The Exchange 2010 Client Access
server issues the client an HTTP error code 451 that contains the ExternalURL value and instructs the
client to redirect to the location specified in the ExternalURL property. If no ExternalURL value is set,
the connection will be proxied to the Exchange 2007 Client Access server using the Fully-Qualified
Domain Name (FQDN) specified by the InternalURL property, specifically to the /Proxy virtual
directory, This virtual directory is located beneath the Exchange ActiveSync virtual directory in
Internet Information Services (IIS) and, by default, has Integrated Windows authentication enabled on
it.
5.
Outlook Anywhere in Exchange Server 2010 and Exchange Server 2003 coexistence:
If a user mailbox is located on an Exchange 2003 server, Outlook Anywhere on Exchange 2010 Client
Access server will proxy the HTTPS traffic to the Exchange 2003 server.
6.
Outlook Anywhere in Exchange Server 2010 and Exchange Server 2007 coexistence:
If a user mailbox is located on Exchange Server 2007, the Exchange 2010 Client Access server will
proxy the HTTPS traffic to the Exchange 2007 Mailbox server.
7.
OAB in Exchange Server 2010 and Exchange Server 2003 coexistence:
5-8
If a user mailbox is located on Exchange Server 2003, the OAB on the Exchange 2010 Client Access
server will proxy the connection to the Exchange 2003 Back-End server.
8.
OAB in Exchange 2010 Client Access server and Exchange 2007 Client Access server coexistence:
If a user mailbox is located on an Exchange 2007 Mailbox server, OAB on the Exchange 2010 Client
Access server will proxy the connection to the Exchange 2007 Mailbox server.
9.
Exchange Web Services in Exchange Server 2010 and Exchange Server 2007 coexistence:
Exchange Web Services provides the Autodiscover feature, the Availability Service and the Out of
Office reply feature. Exchange Web Services was not available in Exchange Server 2003. If a user
mailbox is located on an Exchange 2007 server, Exchange Web Services on the Exchange 2010 Client
Access server will proxy the connection to the Exchange 2007 Mailbox server.
10. POP3/IMAP4 in Exchange Server 2010 and Exchange Server 2003 coexistence:
If a user mailbox is located on an Exchange 2003 server, Post Office Protocol version 3 (POP3)/
Internet Message Access Protocol (IMAP4) on the Exchange 2010 Client Access server will proxy the
connection to the Exchange 2003 server hosting the user mailbox.
11. POP3/IMAP4 in Exchange Server 2010 and Exchange Server 2007 coexistence:
If a user mailbox is located on an Exchange 2007 server, POP3/IMAP4 on the Exchange 2010 Client
Access server proxies the connection to an Exchange 2007 Client Access server in the same site as the
users mailbox.
The following table describes Client Access server interaction between Exchange Server 2010 and previous
Exchange Server versions in a coexistence scenario.
Exchange 2010 Client Access
Server Service
Outlook Web App
Exchange Server 2003/Exchange Server 2007 mailbox treatment

Exchange Server 2003: SSO Forms-based authentication redirect
Exchange Server 2007 Same Active Directory Site: SSO Forms-based
authentication redirect
Exchange Server 2007 Externally-Facing Active Directory Site:
Manual redirect
Exchange Server 2007 Internally Facing Active Directory Site: Proxy
Exchange ActiveSync
Exchange Server 2007: Autodiscover and redirect (Windows Mobile

6.1 and newer), Proxying (Windows Mobile 6 and older, all nonMicrosoft mobile devices)
Exchange Server 2003: Direct Client Access Server 2010 support
Clients which use new Exchange ActiveSync 2010 features need to
resync
Outlook Anywhere & OAB
Direct support
Autodiscover
Direct support
Autodiscover
POP/IMAP
Exchange Server 2007: Proxy. Exchange Server 2003: Direct support
Certificate Requirements for Enabling Coexistence
5-9
During coexistence, you must ensure that you have provided a certificate on your Exchange Client Access
Server 2010 that will support the coexistence scenario. To secure your clients access to Exchange Client
Access Server 2010, you should replace the default self-signed certificate with a new certificate from a
public Certification Authority (CA).
Before you request a certificate, you should carefully plan the namespace that will be associated with the
certificate. In order to provide seamless transition of the user mailboxes during coexistence, you should
not change the namespace your clients use.
For example, if users accessed the URL https://mail.contoso.com to connect to OWA in the previous
Exchange Server version, you should ensure that they can continue to use the same URL during
coexistence, and after the upgrade is completed. Once you deploy the Exchange 2010 Client Access
server, you should redirect users to connect to Outlook Web App on the Exchange 2010 Client Access
server using the same URL https://mail.contoso.com, and you should provide different name for your
previous Exchange Server version; for example, legacy.contoso.com.
Reconfiguring the namespace will vary for every organization, and may require changes to the internal
Domain Name System (DNS), firewall and reverse proxy configurations, as well as Internet service
providers.
Typically, during coexistence, your organization will use at least three host names when connecting from
the Internet. For example, Contoso, Ltd might use the following names:
mail.contoso.com. This name will connect users to the Exchange 2010 Client Access server.
autodiscover.contoso.com. This name will connect users to the Autodiscover service of the
Exchange 2010 Client Access server.
5-10
legacy.contoso.com. This is the name to where users with mailboxes located on previous Exchange
Server versions will be redirected, once they initially connect to the Exchange 2010 Client access
server using the mail.contoso.com name. When all users mailboxes are moved to Exchange Server
2010, this name will no longer be used.
Because you will use multiple names for your Client Access server, you should also have certificates
assigned with those names. We recommend that you obtain a subject alternative name certificate that will
contain multiple names (such as the variations listed above), instead of obtaining a separate certificate for
each name, because it is more efficient to administer one certificate than several certificates. 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. Most public certification authorities (CAs) support the use of multiple
names in the certificates subject alternative name extension.
Furthermore, you should optimize your namespace and assign fewer names for Exchange services. The
names will be administered more efficiently, and will lower the expenses related to purchasing certificates.
Exchange Server 2010 also supports wildcard certificates, which means that you will need only one
certificate for the *.contoso.com namespace. We do not recommend using wildcard certificates, because it
is considered a security risk in many organizations. If this certificate is compromised, because the
certificate can be used for any server name in the domain, all host names for the organization are also
compromised.
Another recommended scenario to reduce the number of host names is to use split DNS. Using split DNS
(also known as split-brain DNS) allows your clients to connect to Exchange Server 2010 through the same
host name, whether they are connecting from the Internet or from the intranet. Split DNS provides a
different IP address for requests that originate from the intranet, compared to requests that originate
from the Internet.
Finally, using the Exchange Certificate Wizard to request certificates is best practice. The Exchange
Certificate Wizard describes all of the scenarios for client access, and recommends host names to be
included in the certificate request. After you complete the wizard, it generates a certificate request file, on
which basis the CAs issue the certificate. The Exchange Certificate Wizard then imports the certificate and
assigns it to appropriate services, such as IIS for Outlook Web App.
Demonstration: Configuring Certificates for Coexistence
5-11
In this demonstration, you will see how to use the New Exchange Certificate Wizard to request a subject
alternative name certificate for both Exchange 2010 Client Access server and Exchange 2003 Front-End
server. Finally, you will see how to install that certificate on both of these Exchange Server versions.
Demonstration Steps
Use the Exchange Management Console to configure the external domain name for
Client Access servers in the organization
1.
Open the Exchange Management Console, select Server Configuration, and then click Client
Access.
2.
Click Configure External Client Access Domain, and then configure the external domain name for
Client Access servers in the organization.
Use the New Exchange Certificate Wizard in Exchange Server 2010

1.
In the Actions pane, click New Exchange Certificate to open the New Exchange Certificate
Wizard. This wizard helps you determine what type of certificates you need for your Exchange
organization during coexistence.
2.
Complete the wizard with following options:
Select a user-friendly name for your certificate.
Do not select the wildcard for this certificate.
Configure the certificate request to include:

a.
b.
Outlook Web App on the Internet and intranet, Exchange ActiveSync, Autodiscover, and
Legacy host name.
Accept the names that will be added to the certificate request.
c.
d.
5-12
Enter information about your Exchange organization. Click the Browse button to select a
location for the certificate request file, and then enter the desired file name.
Verify that all the information you have entered is correct, and then complete the wizard.
Request a certificate
1.
Provide the certificate request file to your internal CA.
2.
After the certificate has been issued, complete the certificate installation process.
Install a certificate with a subject alternative name on Exchange Server 2003 and
1.
On the Exchange Management Console, select Server Configuration.
2.
In the Actions pane, click Complete Pending Request.
3.
Import the certnew.cer file.
4.
In the Actions pane, click Assign Services to Certificate.
5.
Assign the certificate to IIS on NYC-EX10.
6.
On NYC-EX10, export the Contoso Mail certificate to Users\Administrator\Downloads using the

name contosomail.pfx.
7.
On NYC-EX03, access the exported certificate contosomail.pfx, and then install it on NYC-EX03.
Question: What would you need to change in this procedure if you were also enabling
secure access to IMAP4 by using a server name of IMAP4?
Upgrading the Client Access Server to Exchange Server 2010
5-13
In Exchange Server 2010 all clients connect to the Client Access server role for mailbox data, and as such,
you should configure all your clients to connect to the Exchange 2010 Client Access server role. The
Exchange 2010 Client Access server role will then redirect or proxy the connection to the appropriate
Exchange Server version and server role, depending on which Exchange Server version and on which
Active Directory site the user mailbox is located. After all mailboxes are moved to the Exchange 2010
Mailbox servers, the Client Access server role will communicate with the Exchange 2010 Mailbox servers
only.
The Client Access server upgrade process contains the following steps:
1.
Configure the Exchange 2010 Client Access server.
2.
Configure the Exchange Server 2003 environment
3.
Request and install certificates for the Client Access server during coexistence.
4.
Make changes in the DNS namespace.
5.
Verify the coexistence between Exchange 2010 Client Access server and Exchange 2003 Front-End
server or Exchange 2007 Client Access server.
1. Configure the Exchange 2010 Client Access server
As you learned in Module 2, during the graphical setup of the Client Access server, you are prompted to
enter an external Client Access domain, such as mail.contoso.com. Entering an external client access
domain configures the virtual directories for the OAB, Exchange Web Services, Exchange ActiveSync,
Outlook Web App, and the Exchange Control Panel.
5-14
If you did not enter an external Client Access domain during setup, you can configure these settings using
the Exchange Management Console, or by using the following cmdlets in the Exchange Management
Shell:
OAB
Set-OABVirtualDirectory NYC-EX10\OAB* -ExternalURL https://mail.contoso.com/OAB

Set-WebServicesVirtualDirectory NYC-EX10\EWS* -ExternalURL
https://mail.contoso.com/ews/exchange.asmx
Exchange ActiveSync
Set-ActiveSyncVirtualDirectory -Identity NYC-EX10\Microsoft-Server-ActiveSync ExternalURL https://mail.contoso.com
Outlook Web App

Set-OWAVirtualDirectory NYC-EX10\OWA* -ExternalURL https://mail.contoso.com/OWA

Set-ECPVirtualDirectory NYC-EX10\ECP* -ExternalURL https://mail.contoso.com/ECP
To enable Outlook Anywhere, run the following cmdlet:

Enable-OutlookAnywhere -Server:NYC-EX10 -ExternalHostName:mail.contoso.com SSLOffloading $false
Part of configuring an Exchange 2010 Client Access server is changing the Offline OAB generation server
and enabling web distribution on the Exchange Server 2010 Client Access server. This information was
discussed in Module 4, Managing Recipient Objects.
2. Configure the Exchange Server 2003 environment
If you are upgrading from Exchange Server 2003, you should configure the Exchange Server 2003 URL
property in the /owa virtual directory to provide coexistence. You perform this configuration by running
the following cmdlet in the Exchange Server Management Shell:
Set-OWAVirtualDirectory NYC-EX10\OWA* -Exchange2003URL
https://legacy.contoso.com/exchange
You must also enable forms-based authentication on the Exchange 2003 front-end server to allow your
users to access their mailboxes through a single sign-on during the coexistence period.
Furthermore, you should enable Integrated Windows authentication on the Microsoft-Server-ActiveSync

virtual directory on the Exchange 2003 server. This allows the Exchange 2010 Client Access server and the
Exchange 2003 server to communicate by using Kerberos authentication.
This configuration is done by using one of following procedures:
Install the hotfix located at http://go.microsoft.com/fwlink/?LinkID=212679, and then use Exchange

System Manager to adjust the authentication settings of the Exchange ActiveSync virtual directory.
OR
5-15
Set the msExchAuthenticationFlags attribute to a value of 6 on the Microsoft-Server-ActiveSync

object within the configuration container on each Exchange 2003 Mailbox server.
Important On the server where Exchange Server 2003 is installed, do not use IIS Manager
to change the authentication setting on the Exchange ActiveSync virtual directory, because
the Directory Service to Metabase (DS2MB) process within the System Attendant will
overwrite the settings that are stored in AD DS.
3. Request and install certificates for Client Access server during coexistence
In order to secure your clients connections to the Client Access server, you must issue a certificate, and
then install it on the Client Access server. This information was discussed in the previous topic Certificate
Requirements for Enabling Coexistence. The certificate may also need to be installed on the legacy
Exchange servers and on reverse proxies to support Internet access.
4. Make changes in DNS namespace
In order to provide seamless transition for your users to Exchange Server 2010, you should make changes
in both your internal and Internet DNS namespace. These changes allow your users to continue using the
same client configuration while you are performing the process of moving mailboxes.
If the Exchange 2003 Front-End server or Exchange 2007 Client Access server name is mail.contoso.com,
you would make the following changes to the internal and Internet DNS namespace:
1. Create a new A record in both internal and Internet DNS namespace, which will point to the IP
address of your Exchange 2003 Front-End server or Exchange 2007 Client Access server. The name of
the A record will not be used by users, but should reference the legacy Exchange 2003 Front-End
server or Exchange 2007 Client Access servers. Therefore, you might name the A record
legacy.contoso.com.
2.
Modify the existing A record mail.contoso.com in both internal and Internet DNS namespace,
(which previously pointed to your Exchange 2003 server or Exchange 2007 server), to now point to
the IP address of your Exchange 2010 Client Access server or to a shared virtual IP if you have
implemented load balancing.
3.
Configure your firewall or reverse proxy to create a rule that will publish your Exchange 2003 FrontEnd server or Exchange 2007 Client Access server using name legacy.contoso.com.
5. Verify the coexistence between Exchange 2010 Client Access server and Exchange
2003 Front-End server 2003 or Exchange 2007 Client Access server
In order to verify your configuration, perform following steps:
1.
Navigate to https://mail.contoso.com/owa, and verify that you can access Outlook Web App for a
user whose mailbox is on the Exchange Server 2010 Mailbox server.
2.
If you are upgrading from Exchange Server 2003, navigate to

https://legacy.contoso.com/exchange, and verify that you can access Outlook Web Access for a
user whose mailbox is on the Exchange 2003 server.
5-16
If you are upgrading from Exchange Server 2007, navigate to https://legacy.contoso.com/owa, and
verify that you can access Outlook Web Access for a user whose mailbox is on the Exchange 2007
Mailbox server.
3.
Navigate to https://mail.contoso.com/owa, and verify that you can access Outlook Web Access for
a user whose mailbox is on the Exchange 2003 server, or the Exchange 2007 Mailbox server.
Lesson 2
Configuring the Client Access Server Role
5-17
In the previous lesson, you have learned how Client Access server works during the coexistence scenario.
In this lesson you will learn how to deploy and secure a Client Access server, and how to configure the
Exchange 2010 Client Access server role after you have upgraded from Exchange Server 2003 or Exchange
Server 2007.
You can implement the Client Access server role on an Exchange server that has other roles except for the
Edge Transport server role, or you can deploy the Client Access server role on one or more dedicated
servers, similar to Exchange Server 2007. In many organizations, the Client Access server is accessible from
the Internet, thus securing the Client Access servers is a critical part of deployment.
Objectives
Explain how client access works in Exchange Server 2010.
Explain how client access works with multiple sites.
Describe the deployment options for the Client Access server.
Configure a Client Access server.
Secure a Client Access server.
Configure the Client Access server for secure Internet access
Configure throttling policies
Explain Client Access server deployment considerations.
How Client Access Works in Exchange Server 2010
In Exchange Server 2010, all messaging clients connect to a Client Access server when accessing an
Exchange Server mailbox. For users to have access to their mailbox, you must deploy a Client Access
server in the same site as the Mailbox server.
Important In older Exchange Server versions, Messaging Application Programming

Interface (MAPI) clients such as Microsoft Office Outlook connect directly to the Information
Store on Mailbox servers. In Exchange Server 2010, MAPI clients no longer connect directly
to the Information Store on Mailbox servers for mailbox access. Instead, they connect to the
Remote Procedure Call (RPC) Client Access service on a Client Access server. For public folder
access, MAPI clients connect to the RPC Client Access service on the Mailbox server
containing the public folder database used by the client.
How Client Access Servers Work
5-18
The following steps describe what happens when a messaging client connects to the Client Access server
to access mailbox data:
1.
If the client connects from the Internet using a non-MAPI connection, then the client connects to the
Client Access server using the client protocol. For example, an Outlook Web App client will connect to
the Client Access server using only HTTPS. Only the protocol ports for client connections must be
open on the external firewall.
2.
If the client connects from the internal network by using Office Outlook configured as a MAPI client,
the client connects to the RPC Client Access service on the Client Access server by using MAPI RPC
connections.
3.
The Client Access server connects to AD DS on a domain controller by using Kerberos to authenticate
the user. IIS or the RPC Client Access service on the Client Access server performs the authentication.
5-19
The Client Access server uses a Lightweight Directory Access Protocol (LDAP) request to a global
catalog server to locate the Mailbox server that manages the users mailbox.
4.
The Client Access server connects to the Mailbox server by using a MAPI RPC connection to submit
messages to the mailbox database, or to read messages.
How Client Access Works with Multiple Sites in Exchange Server 2010
5-20
In the previous lesson, you learned how Client Access servers work in an environment with multiple Active
Directory sites and different Exchange Server versions. In this topic, you will learn how client access works
in an Exchange Server 2010only environment. A multiple sites environment adds complexity to
deployment planning.
How Client Access Works With Multiple Internet-Facing Sites
If you have multiple Active Directory sites, you can provide Internet access to each sites Client Access
servers. To enable this option, you must configure an external URL for each Client Access server or
configure an RPC Client Access array in each site. You also must ensure that clients can resolve the URL
name on the Internet DNS servers, and can connect to the Client Access server by using the appropriate
protocol.
When a user from the Internet uses Outlook Web App to connect to the Client Access server in this
scenario, the Client Access server authenticates the user, and then queries a global catalog server for the
user mailbox location. At this point, the Client Access server has two options:
1.
If the users mailbox is located in the same site as the Client Access server, the Client Access server
connects to the Mailbox server to fulfill the client request.
2.
If the users mailbox is located in a different site from the Client Access server, the Client Access server
contacts a domain controller to locate the Client Access server in the site where the user mailbox is
located. If you configure the Client Access server with an external URL, the Client Access server
redirects the Outlook Web App client request to the Client Access server in the site containing the
user mailbox. If you do not configure an external URL for the Client Access server in the site that
contains the user mailbox, the Client Access server receiving the request proxies the client request to
the Client Access server in the appropriate site.
Note Exchange Server 2010 can redirect only Outlook Web App and Exchange ActiveSync
clients to another Client Access server in a different site. Exchange ActiveSync clients can only
be redirected if the client mobile device supports this feature. In all other cases, the Client
Access server proxies the client requests to a Client Access server in the same site as the user
mailbox. To optimize access for non-Outlook Web App clients, you must configure the
clients to connect directly to a Client Access server in the users home site.
How Client Access Works With a Single Internet-Facing Site
5-21
The Client Access server in the site that contains the user mailbox might not be accessible from the
Internet, or it might not have an external URL configured. In this scenario, when the user connects to a
Client Access server in a site that does not contain the user mailbox, the Client Access server proxies the
client request to the Client Access server in the site where the users mailbox is located. This proxy process
uses the same protocol as the client. In the destination site, the Client Access server uses RPC to connect
to the Mailbox server managing the user mailbox.
For the Client Access server to proxy the client request, you must configure the Client Access servers that
are not accessible from the Internet to use Integrated Windows authentication.
Exchange Server supports proxying for clients that use Outlook Web App, Exchange ActiveSync, Exchange
Web Services, POP3, and IMAP4.
Best Practice: To optimize user mailbox access, you should consider enabling Internet access to the Client
Access servers in each site. This access is particularly important if you have a large number of users in an
Active Directory site location, or if the network latency between locations is high.
Deployment Options for a Client Access Server
5-22
When planning your Client Access server deployment, you must meet certain requirements to ensure a
successful deployment. Additionally, there are options for deploying Client Access servers in scenarios
where servers require higher availability, or where you have multiple sites.
Requirements for Client Access Server Deployment

When you deploy Client Access servers, you must meet these requirements:
You must have at least one Client Access server in each Active Directory site where you have Mailbox
servers deployed.
Client Access servers should have a fast network connection to:
Mailbox servers to support RPC connectivity.
Domain controllers and global catalog servers
If users need to access their mailboxes from the Internet through the Client Access server, the server
must be accessible from the Internet through Hypertext Transfer Protocol (HTTP) or HTTPS, IMAP4, or
POP3.
Best Practice: Because the server running the Client Access server role must be a member server in an
Active Directory domain, you should not deploy the Client Access server role in a perimeter network.
Instead, use an application layer firewall, such as Microsoft Forefront Threat Management Gateway, to
publish the Client Access server services to the Internet.
Options for Client Access Server Deployment
5-23
The Client Access server role performs a critical function in your Exchange Server organization. You have
the following options when deploying the Client Access server role:
Deploy the Client Access server role on the same computer as all other Exchange Server 2010 server
roles, except for the Edge Transport server role. However, installing all server roles on a single server
does not provide additional availability.
Deploy the Client Access server role on a dedicated server. This deployment provides additional
scalability and performance benefits.
Deploy multiple servers running the Client Access server role. To provide high availability for Client
Access servers, you can deploy Network Load Balancing (NLB), or deploy a hardware NLB to manage
connections to the Client Access servers. In Exchange Server 2010, you also can configure Client
Access arrays to provide a single name for connecting to all Client Access servers in the site.
Note You can install Client Access servers on Mailbox servers that are DAG members.
However, just adding the Client Access server to a DAG member does not provide high
availability for the Client Access server. To provide high availability for Client Access servers,
you need to implement a Client Access array and deploy a load-balancing solution. For more
information on Client Access arrays, see Module 8, Implementing High Availability.
Demonstration: How to Configure a Client Access Server
5-24
In this demonstration, you will see how to configure the global Client Access server settings, as well as the
settings for each Client Access server in the organization.
Demonstration Steps
Configure Client Access server settings

1.
2.
In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand

Organization Configuration, and then click Client Access. Apply settings to all Client Access servers
and mailboxes while in the Organization Configuration node.
3.
Review the default polices on the Outlook Web App Mailbox Policies and Exchange ActiveSync
Mailbox Policies tabs.
4.
In the left pane, expand Server Configuration, and then click Client Access.
5.
Examine the properties of one of the listed Client Access servers. These properties display information
only, and cannot be used to configure the server settings.
6.
In the results pane, review the settings available on each of the tabs. These settings configure the
Client Access server settings for the Client Access server virtual directories.
Question: Why would you modify the server settings on one Client Access server to be
different from those on another Client Access server?
Securing a Client Access Server
5-25
In most organizations, Outlook Anywhere, Outlook Web App, or Exchange ActiveSync clients access the
Client Access server from the Internet. Therefore, as in previous Exchange Server versions, it is critical that
you ensure that the Internet-facing Client Access server 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 by using Secure Sockets Layer (SSL). To configure the Client Access server to use SSL,
complete the following steps:
1.
Obtain and install a server certificate on the Client Access server. Ensure that the certificate name
matches exactly the server name that users will use to access the Client Access server. Also ensure that
the certificate that the CA issues is trusted by all of the client computers and mobile devices that will
be accessing the server.
2.
Configure the Client Access server virtual directories in IIS to require SSL.
Configuring Secure Authentication
Exchange Server 2010 provides several authentication options for clients communicating with the Client
Access server. If the server has multiple authentication options enabled, it negotiates with the client to
determine the most secure authentication method that both support.
Standard Authentication Options

The following standard authentication options are available on the Client Access server:
Integrated Windows authentication. Integrated Windows authentication is the most secure standard
authentication option.
Note If you deploy Client Access servers in Active Directory sites that are not Internetfacing, you must enable Windows Integrated authentication on all of the Client Access
servers that are not Internet accessible. For example, the Internet-facing Outlook Web App
server can use forms-based authentication, but you must configure the internal Client Access
servers to allow Integrated Windows authentication.
5-26
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.
Forms-Based Authentication
Forms-based authentication is available for Outlook Web App and Exchange Control Panel. 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.
The time required before an inactive session times out varies depending on the computer type selected
during logon. If you choose a public or shared computer, the session times out after 15 minutes of
inactivity. If you choose a private computer, the session times out after 12 hours of inactivity.
Note You can configure the time-out values for public and private computers by
modifying the Client Access server registry. You can do this by using the Regedit utility, or
the Set-ItemProperty cmdlet. For more information about how to configure these settings,
see the Set the Forms-Based Authentication Private Computer Cookie Time-Out Value
topic in Exchange Server 2010 Help.
Forms-based authentication is enabled by default for Outlook Web App, and for Exchange Control Panel.
Protecting the Client Access Server with an Application Layer Firewall
To provide an additional layer of security for network traffic and to protect the Client Access server,
deploy an application-layer firewall or reverse proxy, such as Microsoft Internet Security and Acceleration
(ISA) Server 2006 or Forefront Threat Management Gateway, between the Internet and the Client Access
server.
Application layer firewalls provide the following benefits:
You can configure the firewall as the endpoint for the client SSL connection.
You can offload SSL decryption to the firewall.
If you use Microsoft ISA Server 2006 or Microsoft Forefront Threat Management Gateway 2010 as the
application layer firewall, you can configure the firewall to pre-authenticate all client connections. In
that situation, you should configure Exchange 2010 Client Access server for basic authentication.
Important If you use certificate-based authentication for Exchange ActiveSync, you must
configure a server-publishing rule that forwards the client traffic to the Exchange Server
computer without decrypting the packets on the ISA Server computer.
Question: In which situations might you need to change the default authentication options?
5-27
Configuring the Client Access Server for Secure Internet Access
5-28
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 serverbased 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,
you should configure the external URL to use the name published in the externally accessible DNS for
that Active Directory site. The external URL should also use a name that is included in the server
certificate. For Client Access servers that will not have an Internet presence, the setting should remain
blank. If you are enabling Outlook Anywhere access from the Internet, you must also configure the
Outlook Anywhere URL on the Internet-facing Client Access servers.
2.
Configure external DNS name resolution. For each Client Access server that you are exposing to the
Internet, you need to verify that the name used in the external URL can be resolved on the Internet. If
you are using a load balancer between the Internet and the Client Access servers, ensure that the
external DNS name resolves to the shared virtual IP address for the load balancer.
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 required 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, ensure that
the SSL certificates that you deploy on each Client Access server have the required namespaces listed
in the subject alternative name extension.
5.
5-29
Plan for Client Access server access with multiple sites. If your organization has multiple locations and
Active Directory sites, and you are deploying Exchange servers in each site, your first decision is
whether you will make the Client Access servers in each site accessible from the Internet. If you
choose not to make the Client Access server accessible, you should not configure an external URL. All
client requests to that server will then be proxied from an Internet-accessible Client Access server.
Configuring Throttling Policies
Client throttling is new technology in Exchange Server 2010, designed to ensure that users do not
overload the Exchange Server 2010 messaging system. Client throttling also helps ensure that users
connected to Exchange Server from a variety of client types share system resources equitably.
5-30
Exchange Server provides a default client throttling policy that may be sufficient for most organizations.
However, you can create additional client throttling policies or modify the default policy as your
organizational needs dictate.
Client throttling tracks resource consumption on a per-user basis, which enables you to createif
necessarya per-user throttling policy. Additionally, if you are hosting multiple tenants within your
Exchange Server organization, you can configure a per-tenant client throttling policy.
You can configure the following components to adhere to a client throttling policy:
Exchange ActiveSync
IMAP4
POP3
Outlook Web App
Windows PowerShell
For each of these components, you can configure the following client throttling policy parameters:
MaxConcurrency. Indicates how many concurrent connections a user can have against an Exchange
server. If a user tries to make more connections than allowed by the policy, the new connection
attempts fail. Use a value between 0 and 100. To unthrottle this component, specify the value $NULL.
Important Do not set throttling policy parameters to $NULL unless you have a business
need to do so. Unthrottled users are not limited in their ability to intentionally or
inadvertently place a high load on the server. In most cases, you will change the throttling
policy only for specific service accounts that require this setting.
5-31
PercentTimeInCAS, PercentTimeInAD, PercentTimeInMailboxRPC. For each of these parameters,

define a percentile value. For example, if you use the value 100, then in each minute, a client can
consume 60 seconds of resource time. To configure no limit for these components, specify the value
$NULL.
PowerShellMaxConcurrency. Defines the maximum number of remote shell sessions that a user can
have open at one time, or in the context of web services, this defines the number of concurrent
cmdlets that a user can have running at the same time.
PowerShellMaxCmdlets. Defines the maximum number of cmdlets that a user can run over the time
period.
PowerShellMaxCmdletsTimePeriod. Defines the time period, in seconds, that the user can run the
maximum number of cmdlets as defined by the PowerShellMaxCmdlets parameter.
PowerShellMaxCmdletQueueDepth. Defines the number of operations that a user can run at the same
time. This value directly affects the behavior of the PowerShellMaxCmdlets and
PowerShellMaxConcurrency parameters. For example, the PowerShellMaxConcurrency parameter will
use up at least two of the operations defined by the PowerShellMaxCmdletQueueDepth parameter,
but additional operations will also be counted against the throttling limit each time the cmdlet is run.
The number of operations that count toward the throttling limit depends on the cmdlets that are run.
We recommend that the value for the PowerShellMaxCmdletQueueDepth parameter be at least three
times larger than the value of the PowerShellMaxConcurrency parameter. This parameter won't affect
operations that are run using the Exchange Control Panel or operations that are run through
Exchange Web Services.
You can use the performance monitor to examine how throttling affects the overall usage of system
resources.
Considerations for Planning Client Access Server Deployment
5-32
The Client Access servers design can have a significant impact on users satisfaction with the messaging
system. All clientsincluding MAPI clients such as Microsoft Outlook 2010connect to a Client Access
server to access mailbox data on an Exchange 2010 Mailbox server. Office Outlook 2007 or newer clients
also connect to Client Access servers to download OABs, to access the Availability services, and to use the
Autodiscover feature. This means that substandard Client Access server performance directly affects users.
Information Required to Design Client Access Servers

When designing the Client Access server configuration, you will need to collect the following data:
Total number and type of client connections. The total number of clients affects the Client Access
server design. Although the Client Access server can handle thousands of client connections
simultaneously, the number of connections is still an important consideration when you are planning
the server hardware and the number of servers to deploy. Additionally, the types of clients you deploy
are important, because each client access type may have unique requirements.
Client usage profiles. Along with the total number of clients, you also need to consider how the
clients use the messaging system. This information should include a typical client profile that lists the
number of messages read and sent, and the average size of messages and attachments.
Client locations. Consider the client locations when designing the Client Access server deployment.
Collect information that includes whether all clients are located on an internal network only, whether
clients are also connecting from the Internet, and whether clients will be connecting from branch
offices. When planning where to locate Client Access servers, ensure that they have a fast network
connection to domain controllers and Mailbox servers.
Security requirements. All organizations should be using SSL to secure client connections to the Client
Access servers. SSL encryption and decryption requires additional resources on the Client Access
server, so you may need to increase the server hardware resources.
5-33
Availability requirements. In addition to planning the Client Access server deployment from a capacity
perspective, also consider the availability requirements for the organization. If your organization
requires that all services continue to be available during a single-server failure, then you need to
deploy at least two Client Access servers in a Client Access server array, and ensure that each server
can handle the client access load if the other server fails. If you need to provide site resiliency, you will
need to deploy Client Access servers along with the other server roles in a secondary data center.
Question: What business requirements will you have in your organization for Client Access
server deployment?
Lab Setup
5-34
1.
On the host computer, click Start, point to Administrative Tools, and click Hyper-V Manager.
2.
Ensure that the 10165A-NYC-DC1-B, 10165A-NYC-EX10-B, 10165A-NYC-EX11-B, 10165A-NYC-EX03B, and the 10165A-NYC-CL1-B virtual machines are running.
3.
10165A-NYC-EX10-B: Exchange Server 2010 server in the contoso.com domain
10165A-NYC-CL1-B: Client computer in the contoso.com domain
If required, connect to the virtual machines. Log on to NYC-DC1, NYC-EX10, NYC-EX03, and NYCEX11 as Contoso\Administrator, with the password, Pa$$w0rd. Do not log on to NYC-CL1 at this
point.
Lab Scenario
You are working as a messaging administrator at Contoso, Ltd. Your organization has decided to deploy
Client Access servers so that the servers are accessible from the Internet for a variety of messaging clients.
To ensure that the deployment is as secure as possible, you must secure the Client Access server, and
configure a certificate on the server that will support the messaging client connections.
You also need to ensure that users with mailboxes in Exchange Server 2003 and Exchange Server 2010
have a consistent experience with accessing email during coexistence. You need to ensure that all users
can use a single URL to access email using a web browser.
Exercise 1: Configuring Client Access Servers

1.
Configure an external client access domain for NYC-EX11.
2.
Prepare a Server Certificate request for NYC-EX11.
3.
Request the certificate from the CA.
4.
Import and assign the new certificate to the IIS Exchange service.
5.
Verify Outlook connectivity to the Exchange Server 2010 server.
Task 1: Configure an external client access domain for NYC-EX11
5-35
1.
On NYC-EX11, open the Exchange Management Console, and configure an external client access
domain named mail.contoso.com.
2.
Apply the external domain name just to NYC-EX11.
3.
Verify that the External Client Access Domain was applied to the owa (Default Web Site) virtual
directory.
Task 2: Prepare a Server Certificate request for NYC-EX11

1.
2.
On NYC-EX11, run the New Exchange Certificate Wizard by using the following configuration
options:
Friendly name: Contoso Mail Certificate
Outlook Web App is on the intranet
mail.contoso.com as the server name for all external services
Outlook Web App is on the Internet
Exchange ActiveSync is enabled
Autodiscover is used on the Internet
Long URL is used for Autodiscover, and the URL to use should only be autodiscover.contoso.com
legacy.contoso.com is used for legacy domain
Organization: Contoso
Organizational Unit: Messaging
Country/region: United States
City/locality: New York
State/province: NY
Save the file by using the name CertRequest.req.
Task 3: Request the certificate from the CA

1.
Open a Windows Explorer window, and browse to the Documents folder. Open the CertRequest.req
file in Notepad, and then copy the text to the clipboard.
5-36
2.
Open Windows Internet Explorer, connect to http://nyc-dc1.contoso.com/certsrv, and create a

new web server certificate request by using the contents of the certificate request file. Use an
advanced certificate request by using a base-64-encoded CMC or PKCS#10 file. When prompted for
credentials, log on as Administrator, with the password, Pa$$w0rd.
3.
Copy and paste the contents of the CertRequest.req file into the Saved Request field. Request a
web server certificate.
4.
Download the certificate and save it.
5.
View the certificate. Verify that the certificate includes several subject alternative names, and then
click OK.
Task 4: Import and assign the new certificate to the IIS Exchange service
1.
In the Exchange Management console, use the Complete Pending Request Wizard to import the
Contoso Mail certificate.
2.
In the Exchange Management Console, use the Assign Services to Certificate Wizard to assign the
Contoso Mail certificate to the Internet Information Services service on NYC-EX11.
Task 5: Verify Outlook connectivity to the Exchange 2010 server

1.
On NYC-CL1, log on as Alan, with the password, Pa$$w0rd.
2.
Open Microsoft Outlook 2010, and verify that a profile is automatically created for Alan.
3.
In Microsoft Outlook 2010, click the File tab, and then click Account Settings. In the drop-down
menu, click Account Settings. Verify that the Outlook profile is configured to use NYCEX11.contoso.com as the mailbox server.
Results: After this exercise, you should have installed a server certificate from the internal certification
authority (CA) on the Exchange Server 2010 server. You should also have verified Outlook 2010 client
connectivity to the Exchange Server 2010 server.
5-37
Exercise 2: Upgrading Client Access Services from Exchange Server 2003 to

1.
Install the server certificate on NYC-EX03-B.
2.
Configure NYC-EX03 to use forms-based authentication.
3.
Configure the Exchange Server 2003 URL for Outlook Web App.
4.
Modify the DNS records to use the Exchange 2010 Client Access server.
5.
Verify Outlook Web App connectivity for Exchange Server 2003 and Exchange Server 2010 mailboxes.
Task 1: Install the server certificate on NYC-EX03-B

1.
On NYC-EX11, export the Contoso Mail certificate to

C:\Users\Administrator.CONTOSO\Downloads with name contosomail.pfx.
2.
From NYC-EX03, open a Windows Explorer window, and browse to

\\NYC-EX11\c$\Users\Administrator.CONTOSO\Downloads. Copy the file to the desktop on
NYC-EX03.
3.
On NYC-EX03, open Internet Information Services (IIS) Manager and import the .pfx file into the
Default Web Site. Configure the website to require SSL. Be sure that all virtual directories inherit the
SSL configuration.
Task 2: Configure NYC-EX03 to use forms-based authentication

1.
On NYC-EX03, open System Manager.
2.
Browse to the HTTP protocol on NYC-EX03, and enable forms-based authentication.
3.
Open the Services console, and restart the Microsoft Exchange Information Store service.
Task 3: Configure the Exchange 2003 URL for Outlook Web App
On NYC-EX11, open the Exchange Management Shell, and configure Exchange 2003 URL
parameter for Outlook Web App by running following cmdlet:
Task 4: Modify the DNS records to use the Exchange 2010 Client Access server
1.
On NYC-DC1, in Administrative Tools, click DNS, and then make following changes:
2.
Assign the mail.contoso.com alias to NYC-EX11.contoso.com.
3.
Assign the autodiscover.contoso.com alias to NYC-EX11.contoso.com.
4.
Assign the legacy.contoso.com alias to NYC-EX03.contoso.com.
Task 5: Verify Outlook Web App connectivity for Exchange Server 2003 and
Exchange Server 2010 mailboxes
1.
On NYC-CL1, open Internet Explorer, and then connect to Outlook Web App by using
https://mail.contoso.com/owa. Verify that you can log on as user Contoso\George whose mailbox
is located on Exchange Server 2010.
5-38
2.
https://legacy.contoso.com/exchange. Verify that you can log on as user Contoso\Bart whose
mailbox is located on Exchange Server 2003.
3.
https://mail.contoso.com/owa. Verify that you can log on as user Contoso\Bart whose mailbox is
located on Exchange Server 2003.
4.
Log off of NYC-CL1.
Results: After this exercise, you should have configured the client access interoperability between
To prepare for the next lab
When you finish this lab, do not shut down the virtual machines or revert them back to their initial
state. The virtual machines are required to complete the next lab in this module.
Lesson 3
Configuring Client Access Servers for Outlook Clients
5-39
The Client Access servers in Exchange Server 2010 provide several services for Office Outlook clients. For
the most part, these services are enabled by default for Outlook clients on the internal network, but you
may need to modify some of the settings. Additionally, you can make some of these services available to
Outlook clients connecting the Exchange servers from outside the environment. In this case, you need to
enable these features and ensure that they are configured correctly.
Objectives
Describe the services provided by a Client Access server for Outlook clients.
Describe the RPC Client Access service.
Describe Autodiscover.
Configure Autodiscover.
Describe the Availability Service.
Describe MailTips.
Configure MailTips.
Describe Outlook Anywhere in Exchange Server 2010.
Explain how to troubleshoot Outlook client connectivity in Exchange Server 2010.
Services Provided by a Client Access Server for Outlook Clients
5-40
In Exchange Server 2010, the Client Access server role provides critical services for all messaging clients,
including Office Outlook clients.
The following table lists the services provided for Outlook clients.
Service
Description
RPC Client Access service

(New in Exchange Server 2010)
Enables MAPI clients such as Microsoft Outlook 2010 to

connect to user mailboxes. The client connects to the RPC
Client Access service on the Client Access server using a MAPI
connection to access mailbox data, and it connects to the RPC
Client Access service on a Mailbox server to access Public Folder
data.
Autodiscover
The Autodiscover service configures client computers that are
(Exchange Server 2007 and Exchange running Office Outlook 2007 or newer, or supported mobile
Server 2010)
devices. The Autodiscover process configures the Outlook client
profile, including the Mailbox server, Availability service, and
OAB download locations.
Availability
(Exchange Server 2007, and
Exchange Server 2010)
The Availability service is used to make free/busy information

available for Office Outlook 2007 or newer and Outlook Web
App clients. The Availability service retrieves free/busy
information directly from the target mailbox for users on
Exchange Server 2010 and Exchange Server 2007 and can be
configured to retrieve free/busy information for users on older
versions of Exchange Server.
MailTips
The MailTips feature provides notifications for users regarding

potential issues with sending a message, before they send the
message.
Service
Description
5-41
OAB download
The Client Access server makes OAB available through a web(Exchange Server 2007, and with new based distribution point. Only Office Outlook 2007 or newer
features in Exchange Server 2010)
clients are capable of retrieving OABs from a web service.
The Exchange Control Panel is a web-based management

interface that users can use to perform self-service tasks for
mailbox users. It also enables administrators to perform specific
management tasks without having access to the entire
Exchange Server management interface.

Exchange Web Services enables client applications to
(Exchange Server 2007 and Exchange communicate with the Exchange server. You also can write
Server 2010)
applications that 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 mailbox data into line-of-business (LOB)
applications.
Outlook Anywhere (Exchange Server
2003 and Exchange Server 2007, and
with new features in Exchange Server
2010)
Outlook Anywhere enables Outlook 2003 or newer clients to

access the user mailbox by using RPCs encapsulated in an HTTP
or HTTPS packet. This enables secure access to user mailboxes
from Outlook clients located on the Internet.
Question: What are the implications for server capacity planning now that the Client Access
server role provides the RPC Client Access services?
What Is RPC Client Access Service?
5-42
One the most significant architectural changes in Exchange Server 2010 is that the Client Access server
now supports all client connections, including MAPI client connections from Office Outlook clients. In
previous Exchange Server versions, Outlook configured as a MAPI client always connects to the Mailbox
server directly, rather than connecting to a Front-End or Client Access server. In Exchange Server 2010, all
clients connect to the Client Access server role to access mailbox data, regardless of the client protocol
used.
How RPC Client Access Services Works
Because of the change in the messaging architecture, the client communication with the Mailbox server
has changed in the following way:
In Exchange Server 2010, when a MAPI client starts, it connects to a Client Access server. Exchange
Server 2010 supports Microsoft Office Outlook 2003 and newer.
When the client connects to the Client Access server, the Client Access server uses a MAPI RPC
connection to communicate with the Mailbox server.
When the client such as an Outlook Web App client requests the global address list (GAL), the Client
Access server role now provides the Microsoft Exchange Address Book Service, and this service
queries the GAL on behalf of the client. This means that all client connections for address book
lookups are now sent to the Client Access server rather than to a global catalog server.
Note If the Client Access server is located on a domain controller, Office Outlook will
communicate directly with the domain controller rather than with the Address Book Service
for address book lookups. If the user's mailbox is on Exchange Server 2007 or Exchange
Server 2003, the directory request is referred to the user's mailbox server.
RPC Client Access Services Benefits

RPC Client Access services provide a number of benefits:
5-43
All clients now use the same mailbox access architecture.
For organizations that deploy highly available Mailbox servers, client outages have been reduced in
situations where a mailbox database fails over to another server. When a mailbox fails over to another
server, the Client Access server is notified, and the client connections are redirected to the new server
within seconds.
In a failover scenario, clients in Exchange Server 2007 would be disconnected for 115 minutes. In
Exchange Server 2010, if one Client Access server in an array fails, the client will immediately
reconnect to another Client Access server in the array. If a mailbox server fails, the client remains
connected to the Client Access server.
Exchange Server 2010 supports more concurrent client connections to the Mailbox server. In
Exchange Server 2007, each Mailbox server can handle 64,000 connections. That number increases to
250,000 RPC context handle limit in Exchange Server 2010.
What Is Autodiscover?
5-44
The Autodiscover service in Exchange Server 2010 simplifies the client configuration of Office Outlook
2007 and Microsoft Outlook 2010. This feature is also in Exchange Server 2007, and provides
configuration information that Office Outlook requires to create a profile for the client. Office Outlook
clients can also use the Autodiscover service to repair Exchange Server connection settings if a profile is
corrupted, or if the user mailbox is moved to a different server. The Autodiscover service uses a users
email address and password to provide profile settings to Outlook 2007 or newer clients, and supported
mobile devices.
How Autodiscover Works in Exchange Server 2010

Microsoft Outlook 2010 connects to Exchange Server 2010 in the following manner:
1.
When you install the Client Access server role, a service connection point is configured automatically
in Active Directory for the Client Access server. This service connection point includes the Client
Access server URL. During installation, the Autodiscover virtual directory is also created in IIS on the
2.
When Microsoft Outlook 2010 starts for the first time, Outlook 2010 uses the users email address and
password to configure the MAPI profile automatically. Exchange Server 2010 uses configuration
information from AD DS to build an Outlook 2010 configuration template. The configuration
template includes information about AD DS, and the Exchange Server 2010 organization and
topology.
3.
Outlook also uses the service connection point to locate the Autodiscover service on an Exchange
Server 2010 computer with the Client Access server role installed. The information includes the
download location for the Availability web service, and the OAB.
4.
5.
Outlook downloads the required configuration information from the Autodiscover service. This
configuration information includes:
5-45
The users display name
Separate connection settings for internal and external connectivity
The location of the users Mailbox server
The URLs for various Outlook features that govern functionality such as free/busy information,
Unified Messaging, and the OAB
Outlook Anywhere server settings
Outlook then uses the appropriate configuration settings to connect to Exchange Server 2010.
Supported Clients and Protocols

Autodiscover supports the clients and protocols in the following table.
Client application
Protocol
Microsoft Outlook 2010 and Office Outlook 2007
RPC over TCP/IP
Outlook Anywhere
RPC over HTTP
Exchange ActiveSync
Exchange ActiveSync over HTTP
Entourage 2008, Exchange Web Services edition
Exchange Web Services (HTTPS)
Note Exchange Server 2010 supports Autodisover for Exchange ActiveSync clients.
However, the Exchange ActiveSync client must be running Windows Mobile 6.1 or newer
to support this feature. Support for non-Microsoft Exchange ActiveSync clients will vary, as
not all manufactures implement the same features.
Question: When is Autodiscover useful in your organization?
Configuring Autodiscover
5-46
By default, the Autodiscover settings for internal clients are automatically configured, and Office 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 need to configure the appropriate DNS
settings to ensure that external clients can locate the Client Access server that is accessible from the
Internet.
Configuring the Autodiscover Settings
To enable Autodiscover, you must have at least one Client Access server that is running the Autodiscover
service. When you install the Client Access server role, the Autodiscover virtual directory is created
automatically in IIS.
To manage Autodiscover settings, you must use the Exchange Management Shell cmdlets listed in the
following table.
Task
Exchange Management Shell cmdlet
Configure the Autodiscover service

connection point
Set-ClientAccessServer
Create a new Autodiscover virtual

directory
New-AutodiscoverVirtual Directory
Remove an Autodiscover virtual directory
Remove-AutodiscoverVirtualDirectory
Configure an Office Outlook provider
Set-OutlookProvider
Locate an Office Outlook provider (or

providers) on the virtual directory
Get-OutlookProvider
Configuring Autodiscover for Multiple Sites
5-47
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.
To configure site affinity, use a cmdlet as shown in the following example:
Set-ClientAccessServer -Identity "ServerName"
-AutodiscoverServiceInternalURI "https://NYC-EX10/
autodiscover/autodiscover.xml" AutodiscoverSiteScope "HeadOffice"
This cmdlet configures the URL for the Autodiscover service in the HeadOffice site to use the NYC-EX10
server.
Configuring DNS to Support Autodiscover
For external clients to be able to locate the appropriate Client Access servers, you must configure DNS
with the correct information. When the Office Outlook 2007 or newer client attempts to locate the Client
Access server, it first tries to locate the service connection point information in the AD DS.
If the client is outside the network, then AD DS is not available. Therefore, the client queries DNS for a
server name based on the Simple Mail Transfer Protocol (SMTP) address that the user provides. Office
Outlook queries DNS for the following URLs:
https://autodiscover.<emaildomain>/autodiscover/autodiscover.xml
https://<emaildomain>/autodiscover/autodiscover.xml
To enable Autodiscover, you must configure a DNS record on the DNS server that the client uses to
provide name resolution for that request. The DNS record should point to the reverse proxy or firewall
address that is used to publish theClient Access server that is accessible from the Internet.
Testing Autodiscover
You can use a variety of tools to test the Autodiscover settings in your organization:
You can use the Test E-mail AutoConfiguration feature in Microsoft Outlook 2010 to test whether
Autodiscover is working correctly. To access the AutoConfiguration feature, press the CTRL key, rightclick the Microsoft Outlook icon in the notification area of the task bar, and click Test E-mail
Autoconfiguration. Type in the email address that you want to test, provide a password, and then
click Test.
Use the Exchange Management Shell cmdlet Test-OutlookWebServices to test the Autodiscover
settings on a Client Access server.
Use the Exchange Server Remote Connectivity Analyzer (ExRCA) located at

http://go.microsoft.com/fwlink/?LinkId=179969 to test Outlook Anywhere connectivity from the
Internet.
What Is Availability Service?
5-48
The Availability service makes free/busy information available to Office Outlook 2007, Microsoft Outlook
2010, and Outlook Web App users. The Availability service in Exchange Server 2010 replaces the public
folders used to store free/busy information in previous Exchange Server versions.
Note Only Office Outlook 2007, Microsoft Outlook 2010, and Outlook Web App use the
Availability service. Office Outlook 2003 clients continue to use the SCHEDULE+ FREE BUSY
public folder.
How Availability Service Works

Availability service provides free/busy information by using the following process:
1.
When you start the Scheduling Assistant in Office Outlook 2007, Microsoft Outlook 2010 or Outlook
Web App, the client sends a request to the URL provided to the client during Autodiscover. The
request includes all invited users, including resource mailboxes.
2.
The Client Access server Availability service queries AD DS 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 site different from the Client Access server, the request is sent by proxy to a
Client Access server in the site where the user mailbox is located. The Client Access server in the
destination site extracts the availability information from the Mailbox server, and replies to the
requesting Client Access server.
4.
If the mailbox for one of the invited users is on a computer running Exchange Server 2003, the
Availability service queries the public folder that contains the free/busy information for the user.
5.
The Availability service combines the free/busy information for all invited users, and presents it to the
Office Outlook 2007 or Outlook Web App client.
Deploying Availability Service
5-49
Availability service is deployed by default on all Client Access servers, and does not need configuration
except in scenarios where you are integrating the free/busy information from multiple forests or when
you are configuring load balancing for multiple Client Access servers.
Autodiscover delivers the service location for the Availability service to Office Outlook 2007 or newer
clients. Availability service is located at http://<servername>/EWS.
What Are MailTips?
5-50
MailTips are a new feature in Exchange Server 2010 that displays informative messages to users before
they send a message. MailTips inform a user about issues or limitations with the message the user intends
to send, before they send it. Exchange Server 2010 analyzes the message, including the list of recipients to
which it is addressed. If it detects information that may be relevant to the user, it notifies the user with
MailTips prior to sending the message. With the help of the information provided by MailTips, senders
can adjust the message they compose to avoid undesirable situations or some nondelivery reports (NDRs).
Types of MailTips
Exchange Server 2010 provides several default MailTips, including the following examples:
Mailbox Full. This MailTip displays if the sender adds a recipient whose mailbox is full, and if your
organization has implemented a Prohibit Receive restriction for mailboxes over a specified size.
Automatic Replies. This MailTip displays the first 250 characters of the out-of-office reply configured
by the recipient, if a recipient has configured an out-of-office rule for internal senders.
Restricted Recipient. This MailTip displays if the sender adds a recipient for whom delivery restrictions
are configured, and prohibits this sender from sending the message.
External Recipients. This MailTip displays if the sender adds a recipient that is external, or adds a
distribution group that contains external recipients.
Large Audience. This MailTip displays if the sender adds a distribution group that has more than the
large audience size configured in your organization. By default, Exchange Server displays this MailTip
for messages to distribution groups that have more than 25 members.
You can also configure custom MailTips in the Exchange Management Shell. A custom MailTip can be
assigned to any recipient. For example, you could configure a custom MailTip for a recipient who is on an
extended leave, or for a distribution group where all members of the group will be out of the office.
Alternately, you can create a custom MailTip for a distribution group that explains the purpose of the
group, and thus reduces its misuse. When you configure a custom MailTip, it displays when a user
composes a message for a specified recipient.
Note MailTips are available only in Exchange Server 2010 Outlook Web App, or when using
Microsoft Outlook 2010. MailTips are not available in Office Outlook 2007.
How MailTips Work
5-51
MailTips are implemented as a web service in Exchange Server 2010. When a sender is composing a
message, the client software makes an Exchange web service call to an Exchange 2010 Client Access
server, to get the list of MailTips. The Exchange 2010 server responds with the list of MailTips that apply to
that message, and the client software displays the MailTips to the sender. Certain actions, such as adding a
recipient or adding an attachment, will result in an additional Exchange web service call to the Client
Access server.
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 AD DS and reads group metrics data.
The Client Access server queries the Mailbox server to gather the Automatic Replies and Mailbox
Full MailTips. If the recipient's mailbox is in 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. If the MailTips are returned from a
Client Access server in a remote site, then the remote Client Access server proxies the data to the local
Client Access server, which then sends it to the client.
Demonstration: How to Configure MailTips
5-52
In this demonstration, you will see how to review and configure default MailTips for an Exchange Server
2010 organization, and how to configure custom MailTips. You will also confirm that the MailTips function
as expected.
Demonstration Steps
Configure MailTips
1.
In the Exchange Management Shell, use the Get-OrganizationConfig command to review the
default configuration for MailTips.
2.
Use the Set-OrganizationConfig MailTipsLargeAudienceThreshold 10 command to modify the

large audience threshold setting.
3.
Use the Set-DistributionGroup Marketing MailTip The marketing team will be at a conference
till next week. command to configure a custom MailTip. This MailTip must be 250 characters or less
and can be localized.
4.
Log on to Outlook Web App. Prepare test messages to verify that the default and custom MailTips
work as expected.
Question: Will you leave MailTips enabled in your organization? How will you modify the
default configuration?
Outlook Anywhere in Exchange Server 2010
5-53
The Outlook Anywhere feature has been present in both Exchange Server 2003 and Exchange Server
2007. In Exchange Server 2003, this feature was called RPC over HTTP(S). When you enable Outlook
Anywhere, an Office Outlook 2003 or newer client can connect to a server running Exchange Server 2010,
or to previous Exchange Server versions using RPCs encapsulated in an HTTP or HTTPS packet.
Configuring Outlook Anywhere in Exchange Server 2010

To configure Outlook Anywhere on Exchange Server 2010, you should perform the following steps:
1.
Configure a computer running Windows Server 2008 as the RPC proxy server by installing the RPC
over HTTP Proxy feature in Server Manager. When you select this feature, the required web server
(IIS) role services are installed on the server. You should install the RPC over HTTP Proxy feature on
the Client Access server.
2.
Install a server certificate on the RPC proxy server. By default, Outlook Anywhere requires SSL
encryption. Normally, you would use a certificate from a Public CA for Outlook Anywhere. Configure
the RPC virtual directory to require SSL.
3.
Enable Outlook Anywhere in the Exchange Management Console. When you enable Outlook
Anywhere, you must configure both an external host name and authentication method.
4.
Configure the Office Outlook profile on the client to use RPC over HTTP to connect to the Client
Access server. This information is distributed through Autodiscover so it will be automatically
configured for Office Outlook 2007 and Microsoft Outlook 2010 clients.
Discussion: Troubleshooting Outlook Client Connectivity in Exchange

Server 2010
5-54
The Outlook client connectivity troubleshooting steps and procedures are similar to the steps you use
when troubleshooting Outlook with previous versions of Exchange Server. However, remember that in
Exchange Server 2010, Outlook connects to the Client Access server role for mailbox access, whereas in
previous Exchange Server versions, Outlook connects to the Information Store service.
To troubleshoot Outlook with MAPI connectivity to an Exchange Server 2010 server, use the following
steps and procedures:
1.
Identify network connectivity issues. If the Outlook client or the Exchange 2010 Client Access server
experiences problems connecting to the network, Outlook displays a status of Disconnected, and no
new messages can be transferred between the client and the server.
2.
Identify client configuration issues. A client configuration issue can occur in Outlook or the Windows
client configurations. An improperly configured client can prevent the computer from connecting to
the Exchange 2010 server, or can create intermittent connectivity problems.
3.
Identify name resolution issues. Outlook clients must be able to resolve the name of the Exchange
2010 server to which they are connecting. By default, Office Outlook 2007 and Microsoft Outlook
2010 clients use DNS host name resolution to resolve the name of the Exchange 2010 server to its IP
address. External clients must be able to resolve the name of the Exchange 2010 server to the
externally-accessible IP address on the firewall or reverse proxy used to publish the Exchange 2010
server.
4.
Identify server configuration or service-availability issues. A configuration error can prevent some or
all users from connecting to the Exchange 2010 server. Based on the symptom that the user is
experiencing, you can verify configuration by using the Exchange Server Best Practices Analyzer tool,
or you can examine server properties by using the Exchange Management Console. For external
clients, use the Exchange Server Remote Connectivity Analyzer to test and troubleshoot connectivity
to the Exchange 2010 servers.
5.
If the client computer is using Outlook Anywhere to connect to the Client Access server, the problem
may be a Client Access server certificate issue. Outlook Anywhere relies on valid server certificates to
provide secure communication with the server. Invalid names on certificates, expired certificates, or
non-trusted certificates can cause connectivity issues between these clients and a Client Access server.
Note To ensure that a valid server certificate is trusted and can be used for connecting with
Outlook Anywhere, you should connect from a web browser to the RPC virtual directory on
the Exchange server. If the user receives a prompt with a warning message about the
certificate authenticity, then there is an issue with the certificate configuration. This can cause
problems with Outlook Anywhere, Autodiscover, and Exchange ActiveSync.
6.
5-55
You can use the Test E-Mail AutoConfiguration Wizard in Office Outlook 2007 and Microsoft Outlook
2010 to test whether Autodiscover is configured correctly. When you run the wizard, it will provide
information as to whether the client could connect to the Autodiscover service on a Client Access
server, and it will display the information that it received through the Autoconfiguration process. For
external clients, use the Exchange Server Remote Connectivity Analyzer.
Lesson 4
Configuring Microsoft Outlook Web App
Exchange Server 2010 uses Outlook Web App to provide access to user mailboxes and public folders
through a web browser. Outlook Web App was previously known as Outlook Web Access in prior
Exchange Server versions.
5-56
Many organizations provide users with access to Outlook Web App from the Internet. Some organizations
also use Outlook Web App internally. Outlook Web App brings variety of new features compared to
previous Exchange Server versions. This lesson describes how to configure Outlook Web App for Exchange
Server 2010.
Objectives
Describe Outlook Web App features in Exchange Server 2010.
Configure user options using the Exchange Control Panel.
Describe the configuration options for Outlook Web App.
Describe File and Data access for Outlook Web App.
Configure Outlook Web App.
Configure Outlook Web App policies.
What Is New in Outlook Web App in Exchange Server 2010?
5-57
Outlook Web App has been redesigned and brings many new features such as new web interface, support
for MailTips, information protection and control and support for different web browsers.
New features in Outlook Web App include:
Conversation view. Groups messages from a single conversation together, and enables users to
quickly identify and manage the messages and responses from a specific conversation.
Support for different web browsers. Users can access all Outlook Web App features using different
web browsers, such as Internet Explorer, Firefox, Safari or Chrome.
Support for MailTips. Outlook Web App displays MailTips, the new feature in Exchange Server 2010
that provides informative messages to users before they send an email message.
Single page of messages. In Outlook Web App, all messages are displayed on one page, compared
to previous Exchange Server versions, where users had to advance through multiple pages.
Nickname cache. Provides users with a suggested name list as the user types the first characters of a
recipient name or address.
Filters. Filters are now applied from a drop-down menu with common options.
Search. Search in Outlook Web App has advanced queries, and search parameters can be saved.
Calendar sharing. Users can share their calendars with people inside or outside their organization.
Instant messaging (IM). Outlook Web App provides instant messaging integration with presence
indicators that show which contacts are available to chat.
SMS sync. Using Exchange ActiveSync, users can send SMS text messages to Outlook and Outlook
Web App, where incoming messages on mobile devices are available both in the usual SMS message
location and the email inbox.
Demonstration: How to Configure User Options by Using the Exchange

Control Panel
5-58
Exchange Control Panel is a new feature in Exchange Server 2010. You can use the Exchange Control
Panel to perform several different administrative functions, but users also can use the Exchange Control
Panel to modify their own mailbox settings. In this demonstration, you will see how you can configure the
Exchange Control Panel virtual directory, and you will view some of the available Exchange Control Panel
configuration options.
Demonstration Steps
Configure user options by using the Exchange Control Panel

1.
On the Client Access server, in IIS Manager, review the settings for the ecp virtual directory.
2.
In the Exchange Management Console, review the settings for the ecp (Default Web Site) virtual
directory on each Client Access server.
3.
As a user, access the Exchange Control Panel by opening Internet Explorer, and then accessing
https://servername/ecp.
4.
Log on to the Exchange Control Panel, and review the settings that a user can modify.
Question: How does the Exchange Control Panel functionality compare with the
configuration options in Microsoft Outlook 2010?
Configuration Options for Outlook Web App
5-59
Although Outlook Web App is available by default on Client Access servers, you must configure Outlook
Web App to support your users specific requirements.
Outlook Web App Configuration Tasks

When configuring Outlook Web App, you need to complete the following tasks:
Install and configure a server certificate to enable SSL for all client connections.
Configure the Outlook Web App virtual directory. When you install the Client Access server role, an
Outlook Web App virtual directory is configured in the default IIS website on the Client Access server.
In most cases, you might not need to modify the Outlook Web App virtual directory settings, other
than configuring the default website to use a CA certificate for SSL, and to set the authentication
options.
Configure segmentation settings. You can enable or disable specific Outlook Web App features for
Exchange Server 2010 Outlook Web App users. Access the Outlook Web App virtual directory
properties in the Exchange Management Console to configure the segmentation settings.
Segmentation settings define what components with Outlook Web App are accessible to users.
Modify the attachment handling settings. You can configure the attachment settings by configuring
the WebReady Document Viewing settings on the Outlook Web App virtual directory.
Configure Gzip compression settings. Gzip enables data compression, which is optimal for slow
network connections.
5-60
Configure web beacon settings. A web beacon is a file objectsuch as a transparent graphic or an
imagethat is put on a website or in an email message. Web beacons are typically used together
with HTML cookies to monitor user behavior on a website, or to validate a recipient's email address
when an email message containing a web beacon is opened.
Web beacons and HTML forms also can contain harmful code, and can be used to circumvent email
filters. By default, web beacons and HTML forms are set to UserFilterChoice. This blocks all web
beacons and HTML forms, but lets the user unblock them on individual messages. You can use the
Exchange Management Shell to change the type of filtering that is used for web beacon and HTML
form content in Outlook Web App. If you change the setting to ForceFilter, this blocks all web
beacons and HTML forms. If you change the setting to DisableFilter, this allows all web beacons and
HTML forms.
File and Data Access for Outlook Web App
5-61
File and Data Access is a feature that increases organization security by providing options for limiting
access to attachments in email messages. Furthermore, Outlook Web App provides a feature called
WebReady Document Viewing, which enables users to open some attachments as HTML content in their
Web browser, even if the client application is not installed.
Configuring Public and Private Computer File Access
By default, users can access file attachments from either public or private computers. Access to these
attachments may be managed by specifying individual file types and MIME types. Each of these file types
can be configured to:
Allow. Allows attachments with specific file extensions and MIME types to be opened from Outlook
Web App if the required application is installed on the client computer. When you configure Allow, it
overrides Block and Force Save setting.
Block. Blocks attachments with specific file extensions and MIME types from being opened from
Outlook Web App. When you configure Block, it overrides the Force Save setting.
Force Save. Forces users to save attachments with specific file extensions and MIME types to the
client computer before they may be opened.
You can configure Public and Private Computer File Access using the Exchange Management Console or
Exchange Management Shell. Although it appears that you can set the values for private and public
computer access individually, you cannot. When you specify behavior for private access, you also set it for
public access.
Configuring WebReady Document Viewing
WebReady Document Viewing allows users to view attachments with common file types, such as
Microsoft Office or .pdf files, without installing the appropriate application that is needed to open the file
on the client computer.
5-62
By default, WebReady Document Viewing is enabled when accessing file attachments from both public of
private computers. You can disable WebReady Document Viewing, or force users to use only WebReady
Document Viewing for public and private access.
Demonstration: How to Configure Outlook Web App
In this demonstration, you will see how to configure several different Outlook Web App settings.
Demonstration Steps
Configure Outlook Web App
5-63
1.
On the Client Access server, ensure that the Outlook Web App virtual directory is configured to use
SSL, and is using the correct server certificate.
2.
In the Exchange Management Console, in the owa (Default Web Site) Properties window, configure
the external URL with the required authentication and segmentation settings.
3.
In the Exchange Management Console, in the owa (Default Web Site) Properties window, review the
options available on the Public Computer File Access tab and Private Computer File Access tab.
On each tab, review the options for Direct File Access and WebReady Document Viewing.
4.
In the Exchange Management Shell, use the set-owavirtualdirectory owa (Default Web Site)
ForceSaveFileTypes .xls, cmdlet to force attachments with an .xls extension to be saved to disk
before they can be opened.
5.
Use the set-owavirtualdirectory owa (Default Web Site) GzipLevel Off, cmdlet to disable Gzip
compression for Outlook Web App.
6.
Use the Set-OwaVirtualDirectory -identity Owa (Default Web Site) FilterWebBeaconsAndHtmlForms ForceFilter cmdlet to block all web beacons.
Question: What settings will you implement in your organization?
Demonstration: How to Configure Outlook Web App Policies
5-64
One of the new features in Exchange Server 2010 is the option to configure multiple Outlook Web App
policies for different user accounts. In previous Exchange Server versions, all users receive the same
settings when they connect to Outlook Web App. With Exchange Server 2010 Outlook Web App policies,
you can configure unique policies, and then assign them to users.
Demonstration Steps
Configure Outlook Web App policies

1.
In the Exchange Management Console, in the Organization Configuration node, click Client Access.
2.
Click New Outlook Web App Mailbox Policy. Provide a name for the policy, and configure the
policy settings.
3.
After creating the policy, you can configure additional settings by accessing the policy properties.
4.
Assign the policy to a user account by accessing the Outlook Web App properties on the Mailbox
Features tab.
5.
Log on to Outlook Web App as the user, and test the policy application.
Question: How would you use Outlook Web App policies in your organization?
Lesson 5
Configuring Mobile Messaging
5-65
Exchange Server 2010 supports mobile devices as a messaging client. With Exchange Server 2010, you can
synchronize mailbox content and perform most of the same tasks with mobile devices as you can with
other messaging clients.
Exchange Server 2010 also provides administrative options for managing mobile devices. This lesson
describes how to implement and manage mobile access for Exchange Server 2010.
Objectives
Identify options for securing Exchange ActiveSync.
Configure Exchange ActiveSync policies.
Describe mobile device quarantine in Exchange Server 2010 Service Pack 1 (SP1).
Manage mobile devices.
Options for Securing Exchange ActiveSync
5-66
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. In addition, 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 are also difficult to manage by using centralized policies, because the devices might
rarelyor neverconnect to the internal network. The devices also do not require Active Directory
accounts, so you cannot use Group Policy objects (GPOs) to manage the client settings.
Implementing Exchange ActiveSync Policies
Exchange ActiveSync policies provide one option for securing mobile devices. When you apply the policy
to a user, the mobile device automatically downloads the policy the next time the device connects to the
Exchange Server 2010 Exchange ActiveSync polices can be used to configure many settings that provide
additional security for the mobile device. For example, you should configure Exchange ActiveSync policies
that require device passwords, and encrypt the data stored on the mobile device.
Managing Mobile Devices

You can manage mobile devices using either the Exchange Management Console or the Exchange
Management Shell. With these tools, you can perform the following tasks:
View a list of all mobile devices that any organization user is using.
Send or cancel remote wipe commands to mobile devices.
View the status of pending remote-wipe requests for each mobile device.
5-67
View a transaction log that indicates which administrators have issued remote-wipe commands, and
the mobile devices to which those commands pertain.
Delete an old or unused partnership between devices and users.
Note The option to manage a mobile device for a user mailbox in the Exchange
Management Console is available only after the user has synchronized with the Exchange
Server 2010 server from a mobile device. You also can manage mobile devices in the
Exchange Management Shell by using the Remove-ActiveSyncDevice and ClearActiveSyncDevice cmdlets.
Configuring Self-Service Mobile Device Management
Users also can manage their own mobile devices by accessing the Exchange Control Panel. One of the
options available is the Phone tab. From this tab, users can wipe a device that they have configured, and
can delete partnerships for devices that they no longer use.
Self-service management is enabled by default for all users who are assigned to a Microsoft Exchange
ActiveSync mailbox policy.
Enabling SSL for the Mobile Device Connections
To ensure that the communication between the mobile device and the Client Access server is secure, you
should ensure that the Microsoft Server ActiveSync virtual directory is configured to require SSL.
Installing CA Root Certificates on Mobile Devices
Just like desktop computers, you configure mobile devices to trust the root certificates for most public
CAs. However, if you choose to use an internal CA to provide certificates for your Client Access servers,
you must configure the mobile devices to trust the root CAs by installing the root certificates on the
device.
To install a CA certificate on a Windows Mobile device, you might need to copy the root certificate
directly to the mobile device, and then install the certificate. You can use an ActiveSync connection
between the device and a desktop or portable computer to copy the certificate file to the device, or to
transfer the file using a storage card.
Before you enable SSL for the Exchange ActiveSync connection, you also can email a root certificate to the
device. After copying the certificate to the device, you can install the certificate manually by doubleclicking the .cer file.
Question: What are the security concerns with Exchange ActiveSync?
Question: What level of security will your organization require?
Demonstration: How to Configure Exchange ActiveSync Policies
5-68
In Exchange Server 2010, you can manage mobile users and devices with Exchange ActiveSync mailbox
policies. Some of the options available when you create a policy include:
Allow or block nonprovisionable devices. This option permits you to specify whether devices that do
not fully support the device security settings can synchronize with the Exchange 2010 server.
Enable, disable, or limit attachment downloads. This option allows you to enable or disable
attachment downloads, and configure a maximum attachment download size.
Configure devices to require passwords. If you choose to require passwords, you also can configure
the following attributes:
Minimum password length
A requirement for alphanumeric passwords
Inactivity time before the password is required
The option to enable password recovery
A requirement for device encryption
Number of failed attempts allowed. (This option specifies whether you want the device memory
wiped after a specific number of failed logon attempts.)
Disabling removable storage, cameras, Wi-Fi, or Bluetooth.
Configuring synchronization settings, such as message size limits.
Enabling additional mobile device applications, such as web browsers, unsigned applications, or
defining allowed and blocked applications.
In this demonstration, you will see how to configure the Exchange ActiveSync policies.
Demonstration Steps
Configure Exchange ActiveSync policies
5-69
1.
In the Exchange Management Console, access the Organization Configuration node, and then click
Client Access.
2.
Create New Exchange ActiveSync Mailbox Policy, and then configure the available settings.
3.
After creating the policy, access the policy properties and configure the additional settings.
4.
Access a user mailboxs properties. Assign the appropriate Exchange ActiveSync policy.
Question: What types of Exchange ActiveSync policies will you implement in your
organization?
Mobile Device Quarantine in Exchange Server 2010 Service Pack 1
5-70
Microsoft Exchange Server 2010 provides administrators with management features for controlling which
mobile devices can have access to their respective user mailboxes. Administrators can configure lists
where mobile devices can be categorized as allowed, blocked or quarantined.
Device Access States
In order to manage your users mobile devices, you should configure their device access state. The device
access state is the status of a device and can be configured in one of the following: allowed, blocked, or
quarantined.
The Allow Access State
When a mobile device is in the allowed state, it can connect to Exchange Server and synchronize by using
Exchange ActiveSync. The device should also comply with the Exchange ActiveSync policy the
administrator has configured.
The Block Access State
When a mobile device is in the block state, it will not be allowed to connect to Exchange Server and will
receive an HTTP 403 Forbidden error. If a user tries to connect to Exchange Server using the device, he or
she will receive an automatically-generated email message indicating that the mobile device is blocked
from accessing the user mailbox. This automatically-generated message can be customized by the
administrator.
The mobile device will also be blocked when it fails to apply the Exchange ActiveSync mailbox policies. In
this case, the user will not receive any email message with information that the mobile device was
blocked. The only place the user may find information that the mobile devise is blocked due to the failure
by the device to apply the Exchange ActiveSync mailbox policies is in the mobile device information
displayed in Outlook Web App.
The Quarantine Access State
5-71
When a mobile device is in the quarantined state, the mobile device is allowed to connect to the
Exchange server, but it is given only limited access to data, such as writing to the Calendar, Contacts,
Tasks, and Notes folders. However, the server will not allow the device to retrieve any content from the
user's mailbox. The user will receive an automatically-generated email message with information that the
mobile device is quarantined. This automatically-generated message can be customized by the
administrator.
When configuring quarantine access settings, you need to specify one or more administrators who will
receive an email message the first time a quarantined device tries to connect to the Exchange server. After
receiving this message, the administrators can decide whether to release the mobile device from
quarantine, block the device completely, or create a rule that will take action on the mobile device and
other similar mobile devices.
You may also create Device Access Rules, where you may specify a family of devices, or specific model,
and apply the appropriate state (Allow, Block, or Quarantine) to them.
The Device Discovery Access State
The first time a mobile device is used to connect to Exchange Server, it is placed in the device discovery
access state. In this state, the device is quarantined until it is recognized by the server. The mobile device
can be in this state from 1 to 14 minutes, and no email messages are sent to administrators or to the user
during this period.
The Mailbox Upgrade Access State
When a mobile device is in the mailbox upgrade access state, the device is granted full access to the user
mailbox. This state is the same as the allowed state, except that it is applied in a situation after a mailbox
move from an older version of Exchange Server, and the state lasts no more than seven days. This state
gives mobile devices time to upgrade their information and communication protocols to Exchange Server
2010. As soon as a mobile device is recognized, Exchange Server applies the appropriate access based on
the Exchange Server 2010 configuration.
Demonstration: How to Manage Mobile Devices
In this demonstration, you will view the options that a user has using the Exchange Control Panel to
manage their mobile devices. You will then see how an administrator can also manage user mobile
devices.
Demonstration Steps
Manage mobile devices
5-72
1.
As a user Luca, connect to the Exchange Control Panel on a Client Access server.
2.
Log on and access the Phone tab on the user Properties page.
3.
As an Exchange administrator, access the users mailbox in the Exchange Management Console.
4.
In the Actions pane, click Manage Mobile Device.
5.
On the Manage Mobile Device page, review the options available to manage the mobile device,
including wiping the device.
6.
As a user Administrator, connect to the Exchange Control Panel on a Client Access server.
7.
Log on and access the Phone&Voice tab on the Manage My Organization page.
8.
Under Exchange ActiveSync Access settings, click on Edit.
9.
Review the configuration options in the Exchange ActiveSync Access Settings window, and then click
Cancel.
10. Under Quarantined Devices, review the information that will display when a device is in a
quarantined state.
11. Under Device Access Rules, click on New.
12. Review the configuration options in the Exchange ActiveSync Device Access Rule window, and then
click Cancel.
13. Log off the Exchange Control Panel.

Question: What are the implications of using remote wipe as an administrator or user?
Question: How will you manage mobile devices in your organization?
5-73
5-74
Lab B: Configuring Client Access Servers for Outlook Web

App and Exchange ActiveSync
Lab Setup
1.
2.
Ensure that the 10165A-NYC-DC1-B, 10165A-NYC-EX10-B, 10165A-NYC-EX11-B, and the 10165ANYC-CL1-B virtual machines are running.
10165A-NYC-CL1-B: Client computer in the contoso.com domain
3.
If required, connect to the virtual machines.
4.
If needed for performance, you can revert 10165A-NYC-EX03B.
Lab Scenario
Contoso, Ltd has several users who are frequently out of the office. Some of the users have laptop
computers, and they want to use Outlook Anywhere to connect to their Exchange Server mailboxes while
in the office or out of the office. You need to configure the Client Access server to enable Outlook
Anywhere, and then configure a client to connect to the server using RPC over HTTPS. Finally, you need to
verify that the connection works.
5-75
In addition to Outlook Anywhere, Contoso has also decided to enable client access to Exchange Server
mailboxes through both Outlook Web App and Exchange ActiveSync. The security officer at Contoso has
defined security requirements for the Outlook Web App and Exchange ActiveSync deployment, which you
need to enable. Finally, you need to verify that Outlook Web App users have access to Exchange Server
mailboxes.
Exercise 1: Configuring Outlook Anywhere

Scenario
5-76
Contoso, Ltd has several users who are frequently out of the office. These users all have laptop computers,
and they want to use Microsoft Outlook 2010 to connect to their Exchange Server mailboxes while in the
office or out of the office. You need to configure the Client Access server to enable Outlook Anywhere,
and then configure a client to connect to the server using RPC over HTTPS. Finally, you need to verify that
the connection works.
1.
Configure Outlook Anywhere on NYC-EX11.
2.
Configure the Outlook profile to use Outlook Anywhere.
3.
Verify Outlook Anywhere connectivity.
Task 1: Configure Outlook Anywhere on NYC-EX11

1.
On NYC-EX11, open Server Manager, and then verify that the RPC over HTTP Proxy feature is
installed.
2.
In the Exchange Management Console, enable Outlook Anywhere for NYC-EX11.
3.
Configure an external host name of mail.contoso.com, and then select NTLM authentication.
4.
Restart NYC-EX11.
Task 2: Configure the Outlook profile to use Outlook Anywhere

1.
On NYC-CL1, log on as Contoso\Luca, with the password, Pa$$w0rd.
2.
Modify the Outlook profile for Luca to connect to Microsoft Exchange by using HTTP.
3.
Configure the Exchange Proxy server settings as follows:
Use this URL (https://): mail.contoso.com
Connect using SSL only: enable (default)
On fast networks, connect using HTTP first, then connect using TCP/IP: enable
On slow networks, connect using HTTP first, then connect using TCP/IP: enable (default)
Proxy authentication setting: NTLM Authentication (default)
Task 3: Verify Outlook Anywhere connectivity

1.
Wait until NYC-EX11 finishes restarting, and then log on as Contoso\Administrator with
thepassword Pa$$w0rd.
2.
On NYC-CL1, open Microsoft Outlook 2010, and then verify that you are connected to the
Exchange Server 2010 server.
3.
Press and hold Ctrl, and then right-click the Microsoft Outlook icon in the Windows 7 notification
area. Click Connection Status, and confirm that the Conn column lists HTTPS as the connection
method. You may need to click the up arrow icon in the Windows 7 notification area to view the
Microsoft Outlook icon.
5-77
4.
Use the E-mail AutoConfiguration tool to review the settings that Autodiscover provided for Luca.
5.
Log off NYC-CL1.
Results: After this exercise, you should have enabled Outlook Anywhere, and configured a client profile to
use Outlook Anywhere. You also should have verified the Outlook Anywhere functionality.
Exercise 2: Configuring Outlook Web App

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

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

1.
On NYC-EX11, in Exchange Management Console, verify that the owa virtual directory is configured
to use forms-based authentication. Modify the forms-based authentication to use the user name
only, and to use the contoso.com domain automatically.
2.
Disable the Tasks and Rules displays for all users.
3.
Use the set-owavirtualdirectory owa (Default Web Site) ForceSaveFileTypes .doc cmdlet to
force all users to save Microsoft Office Word documents before opening them.
4.
Use the set-owavirtualdirectory owa (Default Web Site) GzipLevel Off cmdlet to disable GZip
compression.
5.
Use the Set-OwaVirtualDirectory -identity Owa (Default Web Site) FilterWebBeaconsAndHtmlForms ForceFilter cmdlet to block all web beacons and HTML forms.
6.
Use the IISReset /noforce command to restart IIS. If a message displays stating that the service did
not start, open the Services Microsoft Management Console (MMC), and start the World Wide
Web Publishing Service.
Task 3: Configure an Outlook Web App Mailbox Policy for branch managers
1.
Create a new Outlook Web App Mailbox policy, and configure the policy with the name Branch
Managers Policy.
2.
Configure the policy to prevent branch managers from changing their password.
3.
Apply the policy to all users in the Branch Managers organizational unit (OU).
Task 4: Verify the Outlook Web App configuration

1.
On NYC-EX10, connect to https://mail.contoso.com/owa.
2.
Log on to Outlook Web App as Contoso\Dylan, with the password, Pa$$w0rd. Dylan is not a
member of the Branch Managers OU.
5-79
3.
Verify that the Tasks folder does not display in the user mailbox, and that Dylan cannot configure a
new Inbox rule in the Exchange Control Panel.
4.
Connect to Outlook Web App again, and log on as Contoso\Ian, with the password, Pa$$w0rd. Ian
is a member of the Branch Managers OU.
5.
Verify that the Tasks folder displays in the user mailbox, but that Ian is not able to change his
password.
Results: After this exercise, you should have configured Outlook Web App on NYC-EX11. This
configuration includes verifying that the internal CA certificate is assigned to the default website, and
configuring Outlook Web App settings for all users, as well as for specific users. You also should have
verified the Outlook Web App settings.
Exercise 3: Configuring Exchange ActiveSync

Scenario
5-80
Contoso, Ltd has several users who use Windows Mobile 6.5 devices to access their mail. You need ensure
that these users can access their mailboxes using Exchange ActiveSync. To ensure that the client
connection is secure, you must configure an Exchange ActiveSync policy, and apply it to a user account.
Lastly, you need to manage the mobile device as both an administrator and a user by using the Exchange
Control Panel.
1.
Verify the Exchange ActiveSync virtual directory configuration.
2.
Create a new Exchange ActiveSync mailbox policy.
3.
Configure Exchange ActiveSync Access settings
Task 1: Verify the Exchange ActiveSync virtual directory configuration
On NYC-EX11, in the Exchange Management Console, review the configuration for the Microsoft
Server ActiveSync virtual directory.
Task 2: Create a new Exchange ActiveSync mailbox policy

1.
On NYC-EX11, in the Exchange Management Console, create a new Exchange ActiveSync Mailbox
policy with the following configuration:
Name: EAS Policy 1
Enable non-provisionable devices
Require passwords
Enable password recovery
2.
Review the other Exchange ActiveSync Mailbox policy settings.
3.
Apply the new Exchange ActiveSync Mailbox policy to Adam Carter.
Task 3: Configure Exchange ActiveSync Access settings

1.
On NYC-EX10, open Internet Explorer, and connect to the Exchange Control Panel.
2.
In the Exchange Control Panel, edit the Exchange ActiveSync Access Settings:
3.
Connection settings: Quarantine Let me decide to block or allow later
Quarantine notification emails: Administrator
Enter text to include in emails: Your device has been quarantined. Please contact your
administrator.
In the Exchange Control Panel, under Device Access Rules, create a new Device Access Rule and
review the configuration options.
Results: After this exercise, you should have configured the Exchange Server 2010 server environment to
support Exchange ActiveSync. You also should have enhanced the security configuration by creating a
more secure Exchange ActiveSync Mailbox policy, and by configuring Exchange ActiveSync Access
settings.
5-81
following steps:
1.
2.
3.
4.
machine.
5.
machine.
6.
machine.
7.
machine.
8.
Wait for 10165A-NYC-EX11-B to start, and then start 10165A-NYC-SVR1-B. Connect to the virtual
machine.
Review Questions
5-82
1.
You need to ensure that users from the Internet can connect to a Client Access server by using
Outlook Anywhere. How will you configure the firewall between the Internet and the Client Access
server?
2.
You need to ensure that the same Exchange ActiveSync policies are assigned to all users, with the
exception of the Executives group. This group requires higher security settings. What should you do?
3.
You have deployed an Exchange Server 2010 server in an organization that includes several Exchange
Server 2003 servers. How will Exchange Server 2010 obtain free\busy information for user mailboxes
on the Exchange Server 2003 servers?
Common Issues related to Client Connectivity to the Client Access Server

Identify the causes for the following common issues related to client connectivity to the Client Access
server, and fill in the troubleshooting tips. For answers, refer to relevant lessons in the module.
Issue
Clients receive certificate-related errors when
they connect to the Client Access server.
Users from the Internet are not able to
connect to the Client Access server.
Real-world Issues and Scenarios

1.
Troubleshooting tip
Your organization has two locations with an Internet connection in each location. What should you
do to ensure that when users access their email using Outlook Web App from the Internet, they will
always connect to the Client Access server in their home office?
5-83
2.
You are planning on enabling Outlook Web App, Outlook Anywhere, and Exchange ActiveSync access
to your Client Access server. You want to ensure that all client connections are secure by using SSL,
and that none of the clients receives errors when they connect to the Client Access server. You plan
on requesting a certificate from a public CA. What should you include in the certificate request?
3.
You have deployed two Client Access servers in the same Active Directory site. When one of the Client
Access servers shuts down, users can no longer access their email. What should you do?
Best Practices Related to Planning the Client Access Server Deployment
Supplement or modify the following best practices for your own work situations. When designing the
Client Access server configuration, consider the following recommendations:
The recommended processor configuration for Client Access servers is eight processor cores, and the
maximum recommended number of processor cores is 12. You should deploy at least two processor
cores for Client Access serverseven in small organizationsbecause of the additional loads placed
on the Client Access server in Exchange Server 2010.
As a general guideline, you should deploy three Client Access server processor cores in an Active
Directory site for every four Mailbox server processor cores.
The recommended memory configuration for Client Access server is 2 gigabytes (GB) per processor
core, with a maximum of 8 GB. The recommended minimum memory is 4 GB.
Deploying Client Access servers on a perimeter network is not a supported scenario. You should
deploy the Client Access server on the internal network. You must install the Client Access server role
on a member server, and it must have access to a domain controller and global catalog server, as well
as the Mailbox servers inside the organization.
Tools
Tool
Use for
Where to find it
Microsoft Exchange
Remote Connectivity
Analyzer
Troubleshooting Internet
connectivity for messaging
clients
http://go.microsoft.com/fwlink/?LinkId
=179969
Test E-Mail
AutoConfiguration
Troubleshooting Outlook
Connectivity to the Client Access
server
Open Microsoft Outlook 2010, press

and hold Ctrl, right-click the Outlook
connection object, and then click Test
E-Mail AutoConfiguration.
Internet Information
Server (IIS) Manager
Configuring SSL settings for

Client Access server virtual
directories
Administrative Tools
5-84
Managing Message Transport
6-1
Module 6
Contents:
Lesson 1: Overview of Message Transport
6-3
Lesson 2: Configuring Message Transport
6-20
6-38
Module Overview
6-2
The main purpose of Microsoft Exchange Server 2010 is reliable message transport and storage. To
implement message transport in Exchange Server 2010, you should have a thorough understanding of
message transport components, how Exchange Server 2010 routes messages, and how you can
troubleshoot message transport issues.
This module explains how to migrate message transport from Exchange Server 2003 or Exchange Server
2007 to Exchange Server 2010, and how to manage message transport in Exchange Server 2010.
This module also provides details about deploying and configuring the Exchange 2010 Hub Transport
server.
Describe message transport in Exchange Server 2010.
Explain how to configure message transport in Exchange Server 2010.
Lesson 1
Overview of Message Transport
To understand message flow, you must understand how message routing operates 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. Knowing this will enable you to
analyze an issue quickly, and solve it.
In this lesson, you will review message flow and the components that message transport requires,
especially when implementing multiple Exchange 2010 Hub Transport servers.
Exchange Server 2010 provides several tools for troubleshooting Simple Mail Transfer Protocol (SMTP)
message delivery. This lesson describes how you can use these troubleshooting tools.
Describe the Exchange Server message transport components.
Explain how an Exchange Server organization routes messages.
Describe message routing between Active Directory sites.
Describe options for modifying the default message flow.
Describe message routing between Exchange Server 2003 and Exchange Server 2010.
Describe the tools for troubleshooting SMTP message delivery.
Explain how to troubleshoot SMTP message delivery.
6-3
Components of Message Transport
6-4
Message transport in Exchange Server 2010 consists of several components that work together to route
messages. These components include the SMTP Receive connector through which messages from inside
or outside the organization enter the transport pipeline, and Agent delivery, which is a third-party agent
that directly submits messages. Other message transport components include:
Submission queue
Categorizer
Store driver
Microsoft Exchange Mail Submission service
Pickup and Replay directories
Submission Queue
When the Microsoft Exchange Transport service starts, the categorizer creates one submission queue on
each Edge Transport server and Hub Transport server. The submission queue stores all messages on a disk
until the categorizer processes them for delivery. The categorizer cannot process a message until the
transport server promotes it to the submission queue. During the time that the categorizer processes a
message, a copy of the message remains in the submission queue. After successful processing, the
message is removed from both the categorizer and the submission queue.
Messages can enter the submission queue in several ways:
Messages received by an SMTP Receive connector. This is used for inbound messages from the
Internet or from a client using Post Office Protocol version 3 (POP3) or Internet Message Access
Protocol version 4 (IMAP4).
Messages placed in the Pickup directory. This method is used for troubleshooting and legacy
applications.
6-5
Messages submitted by a transport agentsuch as a third-party connectorto a foreign messaging

system.
Messages submitted by the store driver. This method is used to retrieve messages from the senders
Outbox. This queue exists only on Hub Transport servers and not on Edge Transport servers, because
Edge Transport servers do not communicate with Mailbox servers.
Messages resubmitted after failed delivery. The categorizer resubmits messages that are not delivered
on the first attempt. You also can manually resubmit messages.
Delivery Queue
Delivery queues contain messages that the Exchange Server has yet to deliver. Messages are placed in one
of two delivery queuesmailbox delivery queue or remote delivery queuedepending on their intended
delivery route. .
Mailbox delivery queues hold messages that are being delivered to Mailbox servers located in the
same site. Messages are delivered by using encrypted Remote Procedure Calls (RPCs). Mailbox
delivery queuesone queue for each databaseexist only on Hub Transport servers.
Remote delivery queues contain messages that are being delivered to a remote server by using SMTP.
Remote delivery queues can exist on both Hub Transport servers and Edge Transport servers, and
more than one remote delivery queue can exist on each server. On Edge Transport servers, these
destinations are external SMTP domains or SMTP connectors. On Hub Transport servers, these
destinations may refer to Hub Transport servers in remote Active Directory sites, Edge Transport
servers, or non-Exchange Server SMTP connections.
Note Exchange Server 2010 has additional queues. These include the Poison message
queue, which is a queue that is used to isolate messages that could be potentially harmful to
the Exchange 2010 system after a server failure. This queue is typically empty, and if no
poison messages exist, the queue does not appear in the queue-viewing interfaces. The
Unreachable queue contains messages that cannot be routed to their destinations. Typically,
an unreachable destination is caused by configuration changes that have modified the
routing path for delivery.
Categorizer
The categorizer retrieves one message at a time from the submission queue, and it always picks the oldest
message first. On an Edge Transport server, categorization of an inbound message is a short process in
which the categorizer verifies the recipient SMTP address and places the message directly into the delivery
queue. From the delivery queue, it routes the message to a Hub Transport server or an Internet SMTP
server.
On a Hub Transport server, the categorizer performs the following tasks:
Identifies and verifies recipients. All messages must have a valid SMTP address.
Bifurcates messages that have multiple recipients. Expanding the distribution lists enables
identification of individual recipients who belong to the distribution lists. Additionally, the categorizer
processes the return path for distribution-list delivery status notifications (DSNs), and it determines
whether out-of-office messages or automatically generated replies are sent to the sender of the
original message.
Determines routing paths. As part of determining the routing path, the categorizer identifies the
destination. The possible destinations could be a users mailbox, a public folder, or an expansion
6-6
server for distribution groups. If the categorizer cannot determine a valid destination, it generates a
non-delivery report (NDR).
Converts content format. The categorizer converts messages to an appropriate format for recipients
who require varying formats. Within the Exchange Server organization, the recipient format is stored
in AD DS. Messages routed to the Internet are sent in the Multipurpose Internet Mail Extensions
(MIME) or Secure Multipurpose Internet Mail Extensions (S/MIME) format.
Applies organizational message policies. You can use organizational policies to control message size,
permissions for sending messages to specific users, the number of message recipients, and other
message characteristics.
Store Driver
The store driver is a software component that is present on each Hub Transport server. The store driver
retrieves messages from the senders Outbox, and then submits them to the submission queue. The
responding store driver mechanism places a copy of the message into the Hub Transport servers
submission queue so that the categorizer can later process the message. After the store driver adds the
messages successfully to the submission queue, it moves the message from the senders Outbox to the
senders Sent Items folder.
Messages in the Outbox are stored in Messaging Application Programming Interface (MAPI) format. The
store driver must convert them to Summary Transport Neutral Encapsulation Format (STNEF) before
placing them in the submission queue. If the store driver cannot convert the content, it generates an NDR.
Microsoft Exchange Mail Submission Service
The Microsoft Exchange Mail Submission service is a notification service that runs on Mailbox servers. It
notifies a Hub Transport server role in the local Active Directory site when a message is available for
retrieval from a senders Outbox. The store driver on the notified Hub Transport server role picks up the
message from the senders Outbox. If there are multiple Hub Transport servers in the Active Directory site,
the Microsoft Exchange Mail Submission service attempts to distribute notifications evenly between the
Hub Transport servers, and will use the first Hub Transport server that responds.
Pickup and Replay Directories
Most messages enter the message transport pipeline through SMTP Receive connectors, or by submission
through the store driver. However, messages can also enter the message transport pipeline by being
placed in the Pickup or Replay directory on a Hub Transport server or an Edge Transport server.
After a message is placed in the Pickup directory, the store driver adds the message to the submission
queue. The store driver then deletes the message from the Pickup directory. Messages from the Pickup
directory must be text files that comply with the basic SMTP message format, and have configured read
and write permissions.
The Pickup directory allows the Hub Transport server to process and deliver a properly formatted text file.
This can be useful for validating mail flow in an organization, replaying specific messages, or returning
recovered email to the message-transport pipeline. Additionally, some legacy applications may place
messages directly into the Pickup directory for delivery, rather than communicate directly with Exchange
Server SMTP Receive connectors.
How Messages Are Routed in an Exchange Server Organization
6-7
In an Exchange Server messaging environment, you must deploy a Hub Transport server role in each
Active Directory site with an installed Mailbox server role. Hub Transport servers deliver all messages in
an Exchange Server 2010 organization, including messages sent between two recipients with mailboxes
located in the same Mailbox database and on the same site, and between Active Directory sites. Therefore,
it is important to remember that if you do not have a Hub Transport server, or if a Hub Transport server is
not running, messages will not circulate within your Exchange Server 2010 organization.
Note During coexistence between Exchange Server 2007 and Exchange Server 2010, you
must retain an Exchange 2007 Hub Transport server in each Active Directory site that
contains mailboxes on Exchange 2007 Mailbox servers. Exchange 2007 Mailbox servers can
only communicate with Exchange 2007 Hub Transport servers.
The following process describes how a Hub Transport server delivers mail within a single Active Directory
site:
1.
The message flow begins when a message is submitted to the message store on an Exchange 2010
Mailbox server role.
If the client is a Microsoft Office Outlook client, the message is submitted by using MAPI, and the
message is written directly to the Outbox in the users mailbox.
2.
When the Microsoft Exchange Mail Submission service detects that a message is available and waiting
in an Outbox, it selects an available Hub Transport server and submits a new message notification to
the store driver.
3.
The store driver belonging to the selected Hub Transport server retrieves the message from the
Mailbox server role. The store driver uses MAPI to connect to the users Outbox and collect any
messages that are awaiting delivery. The store driver submits the messages to the categorizer
submission queue for processing, and places a copy of the message from the users Outbox in the
users Sent Items folder.
Note While the message is passing through the Hub Transport server role, the server can
use transport agents to modify the message or the message flow. For example, transport
agents can apply custom routing or journaling rules, or perform antivirus filtering.
6-8
4.
For messages destined to arrive at a Mailbox server in the same Active Directory site, the store driver
places the message in a local delivery queue and delivers the message through MAPI to the Mailbox
server role.
5.
For messages destined to arrive at a Mailbox server in another Active Directory site, the Hub
Transport server uses the Active Directory site-link information to determine the route to the
destination site. After determining the path, the Hub Transport server connects directly to a Hub
Transport server on the remote site. If no Hub Transport server on the destination site is available, the
store driver routes the message to a Hub Transport server that is closer to the destination site.
6.
For messages destined for the Internet, the Hub Transport server delivers the message to an Edge
Transport server, which delivers the message to the appropriate Internet email server. If the
organization does not use an Edge Transport server, a smart host or Hub Transport server can deliver
the message directly to the appropriate Internet email server using SMTP.
How Messages Are Routed Between Active Directory Sites
6-9
For remote mail-flow scenarios, the initial steps in which the message passes from the Mailbox server to
the Hub Transport server are identical to those for the local mail-flow scenario. However, remote
message delivery requires more logic for routing messages from one Active Directory site to the next.
Understanding Remote Mail Flow
A message addressed to a recipient in the same Exchange Server organization but in a different Active
Directory site is processed as follows:
1.
The local Mailbox server uses Active Directory site membership information to determine which Hub
Transport servers are located in the same Active Directory site as the Mailbox server. The Mailbox
server then submits the message to the local Hub Transport server. If more than one Hub Transport
server exists in the site, the Mailbox server load-balances message delivery to all available Hub
Transport servers.
2.
The Hub Transport server performs recipient resolution and queries AD DS to match the recipient
email address to a recipient account. The recipient account information includes the fully qualified
domain name (FQDN) of the users Mailbox server. The FQDN determines the Active Directory site of
the users Mailbox server.
3.
In a default configuration, the local Hub Transport server opens an SMTP connection to the remote
Hub Transport server in the destination site, and then delivers the message. After a Hub Transport
server in the destination Active Directory site receives the message, it forwards the message to the
appropriate Mailbox server in the destination Active Directory site.
4.
If the message has multiple recipients whose mailboxes are located in different Active Directory sites,
Exchange Server uses delayed fan-out to optimize message delivery. If the recipients share a portion
of the path, or the entire path, then Exchange Server sends a single copy of the message with these
recipients until the bifurcation point. Exchange Server then bifurcates and sends a separate copy to
each recipient.
6-10
For example, if the least-cost routes from Site1 to Site3 and Site4 both pass through Site2, then Exchange
Server sends a single copy of a message intended for recipients in Site3 and Site4 to a Hub Transport
server in Site2. The Hub Transport server in Site2 then sends two copies of the message: one each to a
Hub Transport server in Site3 and Site4.
Message Flow Characteristics

In an organization with multiple sites, message flow has the following characteristics:
Direct relay routing. The Hub Transport server delivers messages directly to a Hub Transport server on
the remote site, unless there is a communication problem or hub sites are enabled.
Queue at point of failure. The Hub Transport server uses the site-link cost assignment to determine a
routing topology only when direct communication with a Hub Transport server role on the
destination site fails. If no Hub Transport server on the destination site responds, the Hub Transport
server uses IP site-link costs to determine the closest site at which to queue the message. The process
is described in more detail later in this topic.
Delayed fan-out. As the Hub Transport server delivers messages throughout the Exchange Server
organization, the Hub Transport server delays expansion of distribution lists and message bifurcation
until messages reach a fork in the routing topology. Delayed fan-out applies when you use hub sites
to control message routing and it overrides direct relay routing when appropriate to minimize wide
area network (WAN) utilization.
Shadow redundancy. This new Exchange Server 2010 feature provides redundancy for messages for
the entire time they are in transit. With shadow redundancy, a messages deletion from the transport
databases is delayed until the transport server verifies that all of the messages next hops have
completed delivery. If any of the next hops fail before reporting that a successful delivery has
occurred, the transport server resubmits the message for delivery to that next hop. Shadow
redundancy and the transport dumpster are discussed in more detail in Module 8.
How Exchange Server 2010 Manages Message-Delivery Failure
If a Hub Transport server cannot deliver a message to a Hub Transport server in the destination site, the
Hub Transport server uses the least-cost routing path to deliver the message as close as possible to the
destination site. The source Hub Transport server attempts to deliver the message to a Hub Transport
server in the last site before the destination site, along the least-cost routing path. The Hub Transport
server continues to trace the path backward until it makes a connection to a Hub Transport server. The
Hub Transport server queues the messages in that Active Directory site, and the queue is in a retry state. If
Hub Transport servers are not available in any site along the least-cost route, the message is queued on
the local Hub Transport server. This performance is called queue at point of failure.
Question: Is Active Directory site topology the only consideration when Exchange Server
2010 makes message routing decisions?
Options for Modifying the Default Message Flow
6-11
There may be times when you want to modify the default message routing configuration. For example,
you might want to control how messages flow between your remote sites so that you can monitor traffic.
You can do this by configuring specific Active Directory sites as hub sites and assigning Exchange Serverspecific routing costs to Active Directory site links.
By default, Hub Transport servers in one site try to deliver messages to a recipient in another site by
establishing a direct connection to a Hub Transport server in the remote Active Directory site. However,
you can modify this default message-routing topology in three ways.
Configuring Hub Sites
You can configure one or more Active Directory sites in your organization as hub sites. When a hub site
exists along the least-cost routing path between two Hub Transport servers, the messages are routed to a
Hub Transport server in the hub site for processing before they are relayed to the destination server.
Important The Hub Transport server routes a message through a hub site only if it exists
along the least-cost routing path. The originating Hub Transport server always calculates the
lowest cost route first, and then determines if any of the sites on the route are hub sites. If
the lowest cost route does not include a hub site, the Hub Transport server attempts a direct
connection. Use the following command to configure a site as a hub site: Set-ADSite
Identity sitename HubSiteEnabled $true.
Configuring Exchange Server-Specific Routing Costs
You also can modify the default message-routing topology by configuring an Exchange Server-specific
cost to an Active Directory IP site link. If you assign a cost to the site link, the Hub Transport server
determines the least-cost routing path by using this attribute, rather than the Active Directory-assigned
cost.
6-12
You should consider this if you do not trust your current Active Directory site cost settings, or if the cost
setting might be misleading for messaging and the Exchange administrators do not have the
administrative power to adjust them.
Note Use the Set-AdSiteLink Identity ADsitelinkname ExchangeCost value

command to assign Exchange Server-specific routing costs. You also can use the SetAdSiteLink Identity ADsitelinkname MaxMessageSize value command to assign a
maximum message size limit for messages sent between Active Directory sites.
Configuring Expansion Servers for Distribution Groups
You can modify the default routing topology by assigning expansion servers for distribution groups. By
default, when a user sends a message to a distribution group, the first Hub Transport server that receives
the message expands the distribution list and calculates how to route the messages to each recipient in
the list. If you configure an expansion server for the distribution list, all messages sent to the distribution
list are sent to the specified Hub Transport server, which then expands the list and distributes the
messages. For example, you can use expansion servers for location-based distribution groups to ensure
that the local Hub Transport server resolves the groups.
Best Practice When you deploy Exchange Server 2010, you might need to review the
Active Directory site design 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.
Question: Will you use hub sites in your Exchange Server 2010 organization? When would
you use hub sites, and when not?
Message Routing Between Exchange Server 2003 and Exchange Server

2010
6-13
Message routing in a mixed environment with Exchange Server 2003 differs from the Exchange Server
2010 routing topology. Exchange Server 2010 does not use routing groups; instead, it uses the Routing
Group connector to communicate with Exchange Server 2003. Message flow in a mixed environment is as
follows:
1.
The Active Directory site sends a message to the Exchange 2010 Hub Transport server, and this server
is the bridgehead server on the Routing Group connector.
2.
Exchange Server 2010 sends the message through the Routing Group connector to Exchange Server
2003.
3.
If more routing groups exist in Exchange Server 2003, Exchange Server 2003 uses the Exchange Server
2003 routing topology to deliver the message to the target Exchange 2003 server.
You define the default Exchange 2003 bridgehead server during Exchange Server 2010 installation. The
first Hub Transport server that is installed is automatically added as a bridgehead server to the Routing
Group connector.
Exchange Server 2010 differs from Exchange Server 2003 in the following ways:
Exchange Server 2010 uses Active Directory sites, whereas Exchange Server 2003 uses routing groups.
Exchange Server 2010 uses IP site links, whereas Exchange Server 2003 uses Routing Group
connectors.
Exchange Server 2010 uses the Hub Transport server role, whereas Exchange Server 2003 uses a
dedicated bridgehead server.
Optimizing Message Routing Between the Messaging Systems
6-14
When you install the first Hub Transport server in the existing Exchange Server organization, you
automatically enable message routing between the two messaging systems. However, all messages flow
through the Routing Group connector that you configure during installation.
Note To enable coexistence with Exchange Server 2007, you must ensure that Hub
Transport servers for both Exchange Server 2007 and Exchange Server 2010 are installed in
each Active Directory site in which there is a Mailbox server. More information about this
topic can be found in Module 13.
When configuring the message routing topology, you should consider the following actions:
Add additional Hub Transport servers and Exchange 2003 servers as bridgehead servers to the default
Routing Group connector. This provides load balancing, and redundancy, if one of the servers is
unavailable.
Create additional Routing Group connectors. If your organization has multiple locations and multiple
routing groups, create additional Routing Group connectors to optimize message routing. If you use
only the default Routing Group connector created during the Hub Transport server installation, it will
route all messages from Exchange Server 2010 recipients to Exchange Server 2003 recipients through
the Active Directory site where the Hub Transport bridgehead server is located. The messages then
pass through the Routing Group connector, through the Exchange Server 2003 Routing group
connectors, and to recipients on Exchange 2003 servers.
To optimize message routing, consider creating a new Routing Group connector in each routing
group, as you deploy Hub Transport servers in the corresponding Active Directory sites. This will
enable you to send messages between the messaging systems without routing the messages to
another company location. You must use Exchange Management Shell to manage Routing Group
connectors.
Suppress minor link-state updates on Exchange Server 2003. If you implement multiple Routing
Group connectors between the two Exchange Server versions, you must also suppress minor link-state
updates on Exchange Server 2003. Servers running Exchange Server 2003 maintain a link-state
routing table that determines a messages routing inside the organization. If a particular routing
group is inaccessible by using the lowest cost route, the routing group master updates the link-state
table to indicate that the links state is not working.
Exchange 2010 Hub Transport servers do not use link-state routing, and Exchange Server 2010 cannot
propagate link-state updates. When no Hub Transport server in a site is available, the Hub Transport
server does not recalculate the route. If multiple paths exist between the Exchange Server 2010
routing group and any Exchange Server 2003 routing group, you must suppress minor link-state
updates to ensure that message looping does not occur.
You should suppress link-state updates for each server running Exchange Server 2003. This enables
the servers that are running Exchange Server 2003 to queue at the failure point, rather than
recalculating the route.
Note For more information about configuring link-state updates, see the Suppress Link
State Updates page on the Microsoft TechNet Web site.
Question: Do you need to consider using Routing Group connectors when you do not use
Exchange Server 2003?
6-15
Tools for Troubleshooting SMTP Message Delivery
6-16
Similar to Exchange Server 2007, Exchange Server 2010 also provides several tools for troubleshooting
SMTP message delivery.
Tip Exchange Server 2010 relies on the Active Directory site configuration for message
routing. Therefore, to troubleshoot a message-routing issue, you might need to use Active
Directory tools to validate or modify the site, site link, or IP subnet information, and to verify
Active Directory replication. You use the Active Directory Sites and Services tool to view IP
subnets and site links.
Using Exchange Server Best Practices Analyzer
You can use Exchange Server Best Practices Analyzer to check both the Exchange Server configuration and
the health of your Exchange Server topology. This tool automatically examines an Exchange Server
deployment and determines whether the configuration is in line with Microsoft best practices. You should
run Best Practices Analyzer after you install a new Exchange server, upgrade an existing Exchange server,
or make configuration changes.
Using the Mail Flow Troubleshooter

The Mail Flow Troubleshooter tool assists Exchange Server administrators in troubleshooting common
mail-flow problems.
When you start the Mail Flow Troubleshooter, the tool will prompt you to select from the symptoms that
describe the message-flow issue. Based on the symptoms, the tool suggests a troubleshooting path. The
tool also shows an analysis of possible root causes and provides suggestions for corrective actions.
The Mail Flow Troubleshooter is available in the Exchange Management Console toolbox.
Using the Queue Viewer
6-17
Similar to Exchange Server 2007, messages waiting to be processed or delivered in Exchange Server 2010
reside in message queues on the Hub Transport servers. However, unlike Exchange Server versions prior to
2007, all message queues reside in a local Exchange Server database on the server. The Queue Viewer is a
very useful diagnostic tool for locating and identifying messages that are still in the message queue and
have not yet been delivered. To manage queues, you can use either the Exchange Queue Viewer or the
Exchange Management Shell. Exchange Server 2010 features simplified queues. Hub Transport servers
maintain five queues:
Submission queue. The submission queue contains messages that the categorizer is processing. The
submission queue is typically the only queue that exists by default on an Exchange 2010 server. Other
queues are created as necessary for message delivery. This is a change from Exchange Server 2003.
Remote delivery queue. The Hub Transport server routes mail to one remote delivery queue for each
outbound SMTP domain to which the Hub Transport server routes.
Poison message queue. Contains messages that could cause the server to fail.
Mailbox delivery queue. There is one mailbox delivery queue for each Mailbox server to which the
Hub Transport server can deliver messages.
Unreachable queue. The unreachable queue contains messages that Hub Transport servers cannot
route to their destinations.
You view the queues on a Hub Transport server by accessing the Queue Viewer in the Toolbox node in
the Exchange Management Console.
To manage message queues from the Exchange Management Shell, use the following cmdlets:
Get-Queue
Get-Message
Additionally, from 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
Note For more information about the queues used by Exchange Server 2010 and the
process for troubleshooting message flow, see the Managing Queues page on the
Microsoft TechNet website.
Using Microsoft Exchange Remote Connectivity Analyzer
Microsoft Exchange Remote Connectivity Analyzer (ExRCA) can help you confirm that you can send and
receive Internet email. From the ExRCA website, you can send email to your organization by using a
specified email address, and you can check your outbound IP address settings for Reverse DNS, Sender ID,
and Real-time Block List issues that might prevent email delivery on the Internet.
Note The ExRCA website is available at https://www.testexchangeconnectivity.com.
Using Message Tracking and Tracking Log Explorer
6-18
You can also use message tracking to troubleshoot message flow. Note that in a mixed Exchange Server
2003 and Exchange Server 2010 environment, you can track only Exchange Server 2010 mail flow, and not
Exchange Server 2003 mail flow. If you want to track Exchange Server 2003 message flow, you must use
message tracking in the Exchange Server 2003 System Manager.
Unlike Exchange Server 2003, in Exchange Server 2010, message tracking plus subject tracking is enabled
by default on Hub Transport servers, and all message-tracking logs are stored in the C:\Program
Files\Microsoft\Exchange Server\v14\TransportRoles\Logs\MessageTracking folder. Message-tracking logs
are retained for 30 days, with a maximum size of 250 megabytes (MB) for all log files. You can use the
Set-TransportServer cmdlet in the Exchange Management Shell to modify the default settings.
Note To view the message-tracking logs, use the Message Tracking and Tracking Log
Explorer tools available in the Exchange Management Console toolbox. In Exchange Server
2010, users can track their messages by using the Exchange Control Panel. The Message
Tracking tool does not provide the level of detail provided by the Tracking Log Explorer. For
example, when sending a message between two Exchange servers that are in the same Active
Directory site, the Exchange server names will not display in Message Tracking, whereas
Tracking Log Explorer will provide you with this information.
Using the Routing Log Viewer

You can use the Routing Log Viewer to open a routing log file that displays how the routing topology
appears to the server. Use this information when troubleshooting message routing, either within the
organization, or to the Internet. Open the Routing Log Viewer from the Tools folder in Exchange
Management Console, and then open the desired routing log files on a specific server.
Using Protocol Logging
You can configure protocol logging to provide detailed information for troubleshooting message flow.
Protocol logging is enabled on either the SMTP Send connector or SMTP Receive connector properties.
Log files are stored in the C:\Program Files\Microsoft\Exchange
Server\v14\TransportRoles\Logs\ProtocolLog folder.
Using Telnet
The Telnet client is a Windows Server 2008 operating system feature that allows you to check whether
the SMTP port is responding, or to send an SMTP mail directly to a connector to verify that the connector
accepts it. You access the Telnet client from the command line by using the following syntax. telnet
<servername> SMTP or telnet <servername> <Port #>.
Note The Telnet feature is not installed by default in Windows Server 2008. You must add
it manually.
For example, you can use either TELNET NYC-EX10 SMTP or TELNET NYC-EX10 25. One uses SMTP,
and other uses a port number.
Demonstration: Troubleshooting SMTP Message Delivery
In this demonstration, you will see how to use Telnet, Queue Viewer, and message tracking to
troubleshoot SMTP message delivery.
Demonstration Steps
6-19
1.
Open the Command Prompt window.
2.
To start the Telnet tool, at the command prompt, type Telnet NYC-EX10 SMTP. Try to send mail by
using Telnet.
3.
In Exchange Management Console, from the Toolbox pane, start the Queue Viewer tool.
4.
Suspend and resume the Submission queue.
5.
From Christines mailbox, send a message to Alan and Christine.
6.
In the Exchange Management Console, from the Toolbox pane, start the Message Tracking tool.
7.
Track the message you just sent and take a look at the delivery report.
Lesson 2
Configuring Message Transport
6-20
To configure message transport, you must first configure the Hub Transport servers. Additionally, you also
need to know how to configure connections between organizations.
Describe the process for configuring Hub Transport servers.
Configure Hub Transport servers.
Describe accepted domains.
Describe remote domains.
Configure accepted and remote domains.
Describe SMTP connectors.
Design inbound and outbound message flow.
Configure SMTP Send and Receive connectors.
Describe the purpose and functionality of back pressure.
Process for Configuring Hub Transport Servers
6-21
By default, installing a Hub Transport server in an Exchange Server 2010 organization enables message
routing within the organization. However, you might need to configure additional options on the Hub
Transport server role, depending on the needs of your organization.
To configure a Hub Transport server, use the following process:
1.
Configure server-specific settings. These settings include internal Domain Name System (DNS)
configuration and connection limits.
2.
Configure authoritative domains and email address policies. An authoritative domain is one for which
the Exchange Server organization accepts messages and has mailboxes. By default, the Active
Directory domain is your authoritative domain. If this matches your Internet SMTP domain, you do
not need to change anything. If it does not, you must first configure an authoritative domain before
you can configure email address policies that apply email addresses to recipients, and that accept
inbound SMTP messages for those recipients. Authoritative domains are discussed later in this lesson.
3.
Configure a postmaster mailbox. For each accepted domain, you must configure a postmaster
mailbox. The postmaster mailbox must meet the requirements of RFC 2822, and receive NDRs and
DSNs. You can create a new mailbox, or you can add the postmaster alias to an existing mailbox user.
4.
Configure Internet message flow. If you are not deploying an Edge Transport server, you need to
configure the Hub Transport server to enable inbound and outbound mail flow. To enable inbound
mail flow, configure an SMTP Receive connector to accept anonymous connections on port 25 using
a network interface that is accessible from the Internet. To enable outbound mail flow, configure an
SMTP Send connector with an address space of * that can use DNS or a smart host to send
messages to the Internet.
If you are using the Hub Transport server to send and receive email messages from the Internet, you
should configure anti-spam agents on the Hub Transport server and install and configure an antivirus
product.
Note We recommend that you use an Edge Transport server role to send and receive
messages from the Internet. If you are using an SMTP gateway server other than an
Exchange 2010 Edge Transport server role, you still need to configure the SMTP Send
connector and SMTP Receive connector. The difference is that you should configure the
SMTP gateway server as the smart host on the SMTP Send connector, and accept only
connections from the SMTP gateway server on the SMTP Receive connector. As an
alternative to managing your own Edge Transport server role, you should also consider
Exchange Hosted Services.
6-22
5.
Configure messaging policies. By default, no messaging policies are applied to messages passing
through the Hub Transport server role. As part of the Hub Transport server role deployment, if your
organization requires messaging policiessuch as journaling rulesyou must configure them.
6.
Configure administrative permissions. As part of the Hub Transport server role deployment, you may
choose to delegate permissions to configure and monitor the server.
Question: What is an authoritative domain?
Demonstration: Configuring Hub Transport Servers
In this demonstration, you will review Hub Transport server configuration options.
Demonstration Steps
6-23
1.
Click Start, point to All Programs, point to Microsoft Exchange Server 2010, and then click
2.

Organization Configuration, and then click Hub Transport.
3.
On the Global Settings tab, double-click Transport Settings.
4.
In Exchange Management Console, expand Server Configuration, click Hub Transport, and then
open the Hub Transport server properties.
5.
At the Exchange Management Shell command prompt, type

Get-TransportServer -I NYC-EX10 |fl, and then press Enter.
What Are Accepted Domains?
6-24
As part of the Hub Transport server configuration process, you should configure the domains for which
the Hub Transport server will accept email, and then configure users with alternate email addresses.
When you install the first Hub Transport server in a new Exchange organization, only one accepted
domain is automatically created. This default accepted domain is the FQDN of the forest root domain. If
your organization uses a different domain name for email, you must create an accepted domain to match
your external domain name. When you install Exchange Server 2010 into an existing Exchange
organization, Exchange Server 2010 inherits all accepted domains.
Configuring Accepted Domains
The accepted domain property specifies one or more SMTP domain names for which the Exchange server
receives mail. If an SMTP Receive connector on the Exchange 2010 Hub Transport server receives a
message addressed to a domain that is not on the accepted domain list, it rejects the message and sends
an NDR.
To configure an accepted domain, access the Organization Configuration node, and then click Hub
Transport. You can view the currently accepted domains in the Accepted Domains tab, and you can
create additional domains by clicking New Accepted Domain in the Actions pane.
When you create a new accepted domain, you can choose one of the following domain types:
Authoritative domain. Select this option if the recipients using this domain name have mailboxes in
the Exchange Server organization.
Internal relay domain. Select this option if the Hub Transport or Edge Transport server should accept
the email and relay it to another messaging organization in another Active Directory forest. The
recipients in an internal relay domain do not have mailboxes in this Exchange Server organization, but
might have contacts in the global address list (GAL) or a Send connector with a defined SMTP
address. When messages are sent to the contacts, the Hub Transport server forwards the messages to
6-25
another SMTP server. If no contact is found, the message uses the Send connector with the defined
SMTP address.
External relay domain. Select this option if the Hub Transport or Edge Transport server should accept
the email and relay it to an alternate SMTP server outside the Exchange organization. In this scenario,
the transport server receives the messages for recipients in the external relay domain, and then routes
the messages to the email system for the external relay domain. This requires a Send connector from
the transport server to the external relay domain. An example for an external relay domain might be
if your company acts as an Internet service provider to another organization and must relay their
messages.
Note To configure accepted domains by using Exchange Management Shell, use the NewAcceptedDomain or Set-AcceptedDomain cmdlet.
Question: What is an internal relay domain?
What Are Remote Domains?
6-26
Remote domains define SMTP domains that are external to your Exchange Server organization. You can
create remote domain entries to define the settings for message transfer between the Exchange Server
2010 organization and domains outside your AD DS forest.
When you create a remote domain entry, you control the types of messages that are sent to that domain.
You also can apply message-format policies and acceptable character sets for messages that are sent from
your organizations users to the remote domain. The settings for remote domains determine the Exchange
Server organizations global configuration settings.
Creating Remote Domain Entries
You can create remote domain entries to define the mail-transfer settings between the Exchange Server
2010 organization and a domain that is outside your Active Directory forest. When you create a domain
entry, be sure to name the domain entry with a name that will help administrators identify the entrys
purpose when they view the configuration settings. This name is limited to 64 characters. You also provide
the domain name to which this entry and the associated settings will apply. Use a wildcard character in
the domain name to include all subdomains. The wildcard character must appear at the start of the
domain name entry. The SMTP domain name is limited to 256 characters.
Configuring Remote Domain Settings
Remote domain configuration determines out-of-office message settings, message format settings, and if
the remote domain is a Business Productivity Online Suite (BPOS) or Microsoft Office 365 tenant domain.
Out-of-Office Message Settings
The out-of-office message settings control the messages that are sent to recipients in the remote domain.
The types of out-of-office messages that are available depend on the Office Outlook client version, and
the Exchange Server version on which the users mailbox is located.
An out-of-office message is set on the Office Outlook client or in Outlook Web App, but is sent by the
Exchange server.
6-27
You can only use legacy or external classifications. For Exchange Server 2007 and newer, you can define a
different message for internal and external out-of-office messages.
In Exchange Server 2010, there are three types of out-of-office messages or automatic replies:
Legacy. Supported by Exchange Server 2003, Exchange Server 2007, and Exchange Server 2010. Can
only be configured by Office Outlook 2003 or older.
External. Supported by Exchange Server 2007 and Exchange Server 2010. Can only be set by
Microsoft Outlook 2007 or Outlook 2010, or using Outlook Web App.
Internal. Supported by Exchange Server 2007 and Exchange Server 2010. Can only be set by Outlook
2007 or Outlook 2010, or using Outlook Web App.
Note The system default setting in Exchange Server 2010 is to allow only external out-ofoffice messages. Administrators who allowed users to send out-of-office messages on
Exchange Server 2003 systems should be alerted that their users might lose this ability unless
the appropriate configuration options are selected.
Message Format Options Including Acceptable Character Sets
You can configure multiple message format options to specify message delivery and formatting policies
for messages that will be sent to recipients in the remote domain.
The first set of options on the Message Format tab apply restrictions such as types of messages that can
be sent to the remote domain, how the senders name displays to the recipient, and the column width for
message text. Other options include:
Allow automatic replies. You can configure a client email program to reply automatically to messages
being sent to a particular distribution group. If you select this option, automatic replies are sent to the
remote domain. By default, this option is not selected, and automatic replies are not sent to any
recipient in any remote domain.
Allow automatic forward. You can configure a client email program to automatically forward
particular messages to another email address. If you select this option, automatically forwarded
messages are sent to the remote domain. By default, this option is not selected, and automatic
forwards are not sent to any recipient in any remote domain.
Allow delivery reports. You can configure a client email program to notify the sender when a message
is delivered, or is read by the recipient. By default, this option is selected, and delivery reports are sent
to all recipients in any remote domain. If you clear this option, delivery reports are not sent to any
recipient in the remote domain.
Allow NDRs. When a message cannot be delivered to a recipient in the Exchange Server organization,
the Hub Transport server generates an NDR and sends it to the messages sender. By default, this
option is selected, and NDRs are sent to all email addresses in any remote domain. If you clear this
option, NDRs are not sent to any email address in the remote domain.
Display senders name on messages. A user who has a mailbox on a Mailbox server in the Exchange
Server organization also has both an email address and a display name that is associated with the
users user account. By default, the users display name is visible to the message recipient. If you clear
this option, only the email address is visible to the recipient, and not the display name. We
recommend that you leave this option selected.
6-28
Use message text line-wrap at column. To use line-wrap in message text for outgoing messages,
select this option, and then type the line-wrap size in the text box. The line-wrap size should be
between 0 and 132 characters. To set the value to unlimited, leave the field blank. The default value is
unlimited. If you select this option, the text of all email messages that are sent from your organization
to the remote domain display with the message text width that you specify.
If you do not set a value for this option, the client email application settings determine the message
text width. Some earlier email client versions require that you place a line break after the seventysixth or seventy-seventh character. If you do not configure this setting, those email clients will only
view the first 76 characters of each line. Therefore, parts of the message may not appear.
Meeting forward notification enabled. This setting is available only when you use Exchange
Management Shell. To configure this option, use the Set-RemoteDomain cmdlet with the
MeetingForwardNotificationEnabled parameter. By default, this setting is set to $true, and
meeting requests that are forwarded to recipients in the remote domain generate a meeting-forward
notification to the meeting organizer. When this parameter is set to $false, meeting requests that are
forwarded to recipients in the remote domain do not generate a meeting-forward notification.
Message Format Options
Use the Exchange rich-text format settings to determine whether email messages from your organization
to the remote domain are sent using Exchange Rich Text Format (RTF).
Exchange RTF displays colors, fonts, and formatting in the email message. However, you can read
Exchange RTF only by using Outlook. Exchange Server 2010 uses RTF for messages that are delivered
between Office Outlook clients.
The Exchange Server 2010 RTF format differs from the RTF format used by word-processing programs,
such as Microsoft Office Word. If recipients in a remote domain receive a file attachment named
Winmail.dat with their messages, that remote domain is incompatible with Exchange RTF. To work around
this issue, configure the remote domain to never use Exchange RTF.
Character Sets
The Characters Sets options let you select a MIME character set and a non-MIME character set to use
when sending messages to a remote domain. The character sets used on the Internet are registered with
the Internet Assigned Numbers Authority (IANA). The most frequently used character sets are US ASCII
and Western European (ISO-8859-1). Other character sets are used to support language settings.
Office 365 Tenant Domain
The Office 365 Tenant Domain option configures the remote domain as your Office 365 tenant domain in
the multi-tenant Office 365 environment where you host mailboxes on-premise and online by using a
service provider such as Microsoft. This feature was added in Exchange Server 2010 SP1.
Note To configure remote domains by using the Exchange Management Shell, use the
New-RemoteDomain or Set-RemoteDomain cmdlet.
Question: When do you need to configure remote domains?
Demonstration: Configuring Accepted and Remote Domains
6-29
In this demonstration, you will review the default accepted domain configuration, and then learn how to
configure accepted and remote domains.
Demonstration Steps
1.
In Exchange Management Console, expand Microsoft Exchange On-Premises, expand

2.
Click the Accepted Domains tab, double-click Contoso.com, and then click OK.
3.
Click New Accepted Domain, and then create an accepted domain for adatum.local as Internal
Relay Domain.
4.
Click the Remote Domains tab, review the default remote domain settings, and then click OK.
5.
Click New Remote Domain, and then create a remote domain for contoso.com.
What Is an SMTP Connector?
6-30
For a Hub Transport server to send or receive messages using SMTP, at least two SMTP connectors must
be available on the server. An SMTP connector is an Exchange Server component that supports one-way
SMTP connections that route mail between Hub Transport and Edge Transport servers, or between
transport servers and the Internet. You create and manage SMTP connectors from Exchange Management
Console or Exchange Management Shell. Exchange Server 2010 provides two types of SMTP connectors:
SMTP Receive connectors and SMTP Send connectors.
Note Exchange Server 2010 automatically creates the Send connectors required by intraorganization mail flow. These connectors are not visible in the Exchange management tools,
and as such, you cannot modify them.
What Are SMTP Receive Connectors?
A computer running Exchange Server 2010 requires an SMTP Receive connector to accept any SMTP
email. The SMTP Receive connector enables a Hub Transport or Edge Transport server to receive mail
from any other SMTP sources. These sources include SMTP mail programs such as Windows Mail and
SMTP servers on the Internet, Edge Transport servers, or other Exchange SMTP servers.
By default, SMTP Receive connectors are created on each server running the Hub Transport server role.
The default naming conventions used for the SMTP Receive connectors are:
Client SERVERNAME Receive connector. These connectors receive connections from SMTP clients such
as Windows Mail.
Default SERVERNAME Receive connector. These connectors receive authenticated connections from
other SMTP servers.
Note By default, only one Receive connector is created on an Edge Transport server.
6-31
The default configuration for the two connectors is almost identical, with one important difference: the
Client SERVERNAME Receive connector listens to port 587 rather than to port 25. As described in RFC
2476, port 587 was proposed for use for message submission only from email clients that require message
relay.
To configure open or anonymous relay, assign relay permission to anonymous connections on the Receive
connector. In some organizations, you may need to enable anonymous relay so that internal SMTP servers
can relay messages to internal or Internet user accounts. Remember that this might be a serious security
deficiency that could be exploited by unsolicited commercial email senders, or spammers, to hide the
sources of their messages. More information about how to configure open relay can be found in the
article, Allow Anonymous Relay on a Receive Connector available at
http://go.microsoft.com/fwlink/?LinkID=212698. You can configure multiple SMTP Receive connectors
with different parameters on a single Exchange server. Large organizations may have multiple SMTP
Receive connectors on a single server or on multiple servers. In small to medium-sized organizations, as
few as two connectors (a Send and a Receive connector) could serve the entire organization.
Note You must configure each SMTP Receive connector with a port on which the
connector will receive connections, local IP addresses that will be used for incoming
connections, and a remote IP subnet that can send mail to this SMTP Receive connector. The
combination of these three properties must be unique across every SMTP Receive connector
in the organization.
What Are SMTP Send Connectors?
An Exchange Server 2010 computer requires an SMTP Send connector to send SMTP email to any SMTP
server either on the Internet or to any SMTP servers in the same Exchange Server organization.
Note By default, SMTP Send connectors are not configured on Hub Transport servers,
except for the implicit SMTP Send connectors. SMTP Send connectors are created
dynamically to communicate with Hub Transport servers in other Active Directory sites.
How to Configure SMTP Connectors
You can use Exchange Management Console or Exchange Management Shell to create, configure, or view
SMTP connectors. In Exchange Management Console, you configure SMTP Receive connectors for each
Hub Transport server in the Server section, while you configure Send connectors in the Organization
Configuration section. To manage connectors by using Exchange Management Shell, use the SetReceiveConnector and Set-SendConnector cmdlets.
Note Incorrect configuration of SMTP Receive connectors can lead to opened relay on the
mail server. Therefore, you must carefully test the configuration.
Question: When do you require additional SMTP Send connectors?
Designing Inbound and Outbound Message Flow
6-32
To enable message flow to and from the Internet, you must configure the Exchange Server organization
with at least one SMTP Send connector and one Receive connector that has an SMTP address space that
includes Internet SMTP domains. You should carefully consider how to implement the inbound and
outbound message flow to your organization.
Considerations for Designing Inbound Message Flow

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

When designing outbound message flow, consider the following:
Do you want to use a single location for routing all messages to the Internet, or enabling message
routing through multiple locations? If your organization has more than one location with an Internet
connection, you can enable message routing through each location. To do this, you can do one of the
following:
Install an Edge Transport server in each location, and then configure Edge subscriptions between
the Edge Transport servers and the local Active Directory sites.
Manually configure Send connectors on the Hub Transport or Edge Transport servers.
Use a scoped, or a non-scoped Send connector? You can put a scope on the Send connector to
prevent other Active Directory sites from using it. However, do not forget that a connector with a
scoped address space should not be located in the same site as the alternate least-cost route
connector with a non-scoped address space. Thus, you should not configure a scoped address space
at hub sites.
How and where do you want to configure SMTP Send connectors? To enable outbound message
flow, you must configure at least one SMTP Send connector to send email to the Internet. You can
use one of the following methods to configure SMTP Send connectors:
Use Edge synchronization to configure the SMTP Send connectors. When you configure an Edge
subscription, Edge synchronization automatically configures a Send connector for the Active
Directory site to enable message delivery between the local Hub Transport servers and the Edge
Transport server. Additionally, Edge synchronization configures a Send connector to enable
message delivery from the Edge Transport server to the Internet.
Create additional SMTP Send connectors. You might have additional requirements for Send
connectors if you need to configure unique message routing or message security for a partner
organization. You can configure an additional Send connector using the organizations SMTP
domain as the address space, and then configure the other Send connectors properties.
Manually configure Send connectors for Internet email. If you do not use an Edge Transport
server, or if you do not want to use Edge synchronization, you must manually configure the Send
connectors. You can configure Send connectors in the Hub Transport servers to route email
directly to the Internet, to an SMTP gateway server, or to other smart hosts.
How to configure DNS lookups? By default, the Hub Transport server and Edge Transport server
perform DNS lookups for Internet message delivery by using the DNS server that is configured on the
network connection. Configure the settings on the Exchange Server properties to configure other
DNS servers for message delivery. Consider this option if you want to use external DNS servers to
perform name-resolution services for the Edge Transport servers, rather than using internal DNS
servers.
Question: How would you plan to implement inbound and outbound message flow in your
own organization? What SMTP Send or Receive connectors would you configure and why?
6-34
Demonstration: Configuring SMTP Send and Receive Connectors
In this demonstration, you will see how to configure SMTP Send and Receive connectors.
Demonstration Steps
6-35
1.

2.
Click the Send Connectors tab, and create a New Send Connector by using the following settings:
Name: Adatum.com
SMTP Address Space: Adatum.com
Network Settings: Use domain name system (DNS) MX records to route mail
automatically
3.
In Exchange Management Console, expand Server Configuration, and then click Hub Transport.
4.
Click New Receive Connector, and create a Receive connector that allows the anonymous group to
send messages. Configure it to allow connections only on Port 2525.
What Is Back Pressure?
6-36
Back pressure is a system-resource monitoring feature of the Microsoft Exchange Transport service that
exists on computers with a Hub Transport server role or Edge Transport server role.
Back pressure monitors important system resources, such as available hard-disk drive space, and the
memory used by the EdgeTransport.exe process and memory used by all other processes. If utilization of a
system resource exceeds the specified limit, the Exchange server stops accepting new connections and
messages. This prevents the system resources from being overwhelmed, and enables the Exchange server
to deliver the existing messages. When utilization of the system resource returns to a normal level, the
Exchange server accepts new connections and messages.
Back pressure can be used to:
Restrict new connections and messages if a system resource exceeds a specified level.
Prevent the server from being overwhelmed.
For each monitored system resource on a Hub Transport server or Edge Transport server, the following
three levels of resource utilization are applied:
Normal. The resource is not overused. The server accepts new connections and messages.
Medium. The resource is slightly overused. Back pressure is applied to the server in a limited manner.
Mail from senders in the authoritative domain flows. However, the server uses tar-pitting to delay
server response or rejects incoming MAIL FROM commands from other sources.
High. The resource is severely overused. Full back pressure is applied. All message flows stop, and the
server rejects all MAIL FROM commands from other SMTP servers.
Options for Configuring Back Pressure

All configuration options for back pressure are available in the EdgeTransport.exe.config application
configuration file that is located in the C:\Program Files\Microsoft\Exchange Server\V14\Bin directory.
6-37
The EdgeTransport.exe.config file is an XML application configuration file that is associated with the
EdgeTransport.exe file. The Microsoft Exchange Transport service uses the EdgeTransport.exe and
MSExchangeTransport.exe executable files. This service runs on every Hub Transport server and Edge
Transport server. Exchange Server applies the changes that are saved to the EdgeTransport.exe.config file
after the Microsoft Exchange Transport service is restarted.
Back pressure is configured automatically with the predefined default settings. There are various options
you can configure in back pressure. However, you should carefully read and understand each option you
configure before you implement it in your Exchange server, because it might affect your server
performance.
Lab Setup
6-38
following steps:
1.
2.
Ensure that the following virtual machines are running: 10165A-NYC-DC1-B, 10165A-NYC-EX03-B,
10165A-NYC-EX10-B, 10165A-NYC-EX11-B, and 10165A-NYC-SVR1-B.
10165A-NYC-EX03-B: Exchange 2003 SP2 server in the contoso.com domain
10165A-NYC-EX10-B: Exchange 2010 server in the contoso.com domain
10165A-NYC-SVR1-B: Stand-alone SMTP server
3.
If required, connect to the virtual machines. Log on to NYC-DC1, NYC-EX03, NYC-EX10, and NYCEX11 as Contoso\Administrator, with the password, Pa$$w0rd.
4.
On NYC-EX11, click Start, right-click Network, and then click Properties.
5.
Click Change adapter settings.
6.
Right-click Local Area Connection 2, and then click Properties.
7.
Click Internet Protocol Version 4 (TCP/IPv4), and then click Properties.
8.
Change the IP address to 10.10.11.21, click OK, and then click Close.
9.
Open a command prompt, type Ipconfig /registerdns, and then press Enter.
10. Open the Services management console.
11. Right-click Microsoft Exchange Active Directory Topology, click Restart, and then click Yes.
Ensure that all Microsoft Exchange services that are configured for Automatic are started.
12. Close all open Windows.
Lab Scenario
6-39
You are a messaging administrator in Contoso, Ltd. As part of your job responsibilities, you need to set up
the message transport to and from the Internet, and ensure that the message flow is operational within
and between the various sites.
Your organization has deployed Exchange Server 2010 in two of its sites. By default, all messages to and
from the Internet are still flowing through the Exchange Server 2003 SMTP connector. You need to modify
the configuration so that messages sent from Exchange Server 2010 mailboxes are delivered to the
Internet without passing through the Exchange 2003 server. You also need to ensure that all Internet
messages will flow through the main site in New York, and that the mail flow is working correctly.
Exercise 1: Configuring Internet Message Transport

Scenario
First, you need to install Exchange Server 2010 in two sites.
1.
Test Internet mail delivery by using the Exchange Server 2003 connector.
2.
Configure a Send connector to the Internet.
3.
Configure a Receive connector to accept Internet messages.
4.
Modify the Routing Group connector.
5.
Configure message size restrictions and priority queuing.
6.
Verify Internet message delivery from Exchange Server 2010.
Task 1: Test Internet mail delivery by using the Exchange Server 2003 connector
6-40
1.
On NYC-EX11, open Internet Explorer and browse to https://NYC-EX11.contoso.com/owa. Log on

to Microsoft Outlook Web App as Contoso\Alan, with the password, Pa$$w0rd, and then send a
new email message to Info@Internet.com with the subject, Test Mail to Internet.
2.
On NYC-EX03, use Exchange System Manager to check that the queues are empty. If the Internet Mail
connector queue is not empty, verify that the Simple Mail Transfer Protocol (SMTP) service is running
on NYC-SVR1.
3.
In Exchange System Manager, use Message Tracking Center to verify that the message was
delivered successfully to the smart host.
4.
On NYC-SVR1, use Telnet to send a message to Alan.
5.
Open Alans mailbox to verify that the mail arrived.
Task 2: Configure a Send connector to the Internet

1.
2.
Create a new Send Connector with the following configuration:
Name: Internet Send Connector
Use: Internet
Address space: *
Route all messages through 10.10.0.201
Task 3: Configure a Receive connector to accept Internet messages

1.
2.
On NYC-EX10, create a new Receive Connector with the following configuration:
Name: Internet Receive Connector
Use: Custom
Remote Network Settings: 10.10.0.201
Change the configuration on the Internet Receive connector to enable anonymous users and enable
verbose logging.
Task 4: Modify the Routing Group connector
6-41
1.
On NYC-EX10, open Exchange Management Shell.
2.
At the PS prompt, type Get-RoutingGroupConnector |fl, and then press Enter.
3.
At the PS prompt, type Get-RoutingGroupConnector Identity First Routing

Group\Ex2003toEx2010 | Set-RoutingGroupConnector TargetTransportServers NYC-EX11
Cost 100, and then press Enter.
4.
At the PS prompt, type Get-RoutingGroupConnector Identity Exchange Routing Group

(DWBGZMFD01QNBJR)\Ex2003toEx2010 | Set-RoutingGroupConnector
SourceTransportServers NYC-EX11 Cost 100, and then press Enter.
Task 5: Configure message size restrictions and priority queuing

1.
2.
Type Set-SendConnector Internet Send Connector MaxMessageSize 15MB, and then press
Enter.
3.
Open EdgeTransport.exe.config by using Notepad.
4.
Search for PriorityQueuingEnabled and replace value=false with value=true, and then save
the file again. Configuring this setting means that the Hub Transport server will send messages
marked with a high priority before sending messages with a normal priority.
5.
Switch to Exchange Management Shell, type Restart-Service MSExchangeTransport, and then press
Enter.
Task 6: Verify Internet message delivery from Exchange Server 2010

1.
On NYC-EX11, open Internet Explorer and browse to https://NYC-EX11.contoso.com/owa. Log on

to Outlook Web App as Contoso\Alan, with the password, Pa$$w0rd, and send a message to
Info@Internet.com with the subject, Test Mail #2 to Internet.
2.
Open Exchange Management Console, and then, from the Toolbox node, open the Queue Viewer.
Check the queues on NYC-EX10 to verify that the message was delivered.
3.
Close all open windows on NYC-EX11.
Results: After this exercise, you should have moved the Internet Mail connector from Exchange Server
2003 to Exchange Server 2010, configured Send and Receive connectors, modified the Routing Group
connector, implemented message size restrictions and priority queuing, and verified that message delivery
works correctly.
Exercise 2: Troubleshooting Message Transport

Scenario
6-42
You have successfully installed Exchange Server 2010 in two sites. You now need to ensure that the mail
flow is working correctly.
1.
Verify that the mail delivery functions as expected.
2.
Troubleshoot message transport.
Task 1: Verify that the mail delivery functions as expected

1.
On NYC-EX10, open Internet Explorer and browse to https://NYC-EX10.contoso.com/OWA. Log on

to Outlook Web App as Christine, with the password, Pa$$w0rd. Then, send an email message with
the subject, Test Mail to NYC-EX11 to Alan, whose mailbox is on NYC-EX11.
2.
Switch to NYC-EX11 and verify that Alan received the mail, and can reply to it.
Task 2: Troubleshoot message transport

1.
On NYC-EX10, in Exchange Management Shell, run the

d:\labfiles\Lab06Prep.ps1 script.
2.
Send another email message from Christine to Alan, verifying that the message does not deliver.
3.
On NYC-EX10, use Queue Viewer to investigate mail flow problems.
4.
Use Telnet to check connectivity from NYC-EX10 to NYC-EX11.
5.
On NYC-EX11, re-create the Receive connector to enable the mail flow to function correctly. Name
the connector, Internal NYC-EX11, and configure the intended use to be Internal.
6.
On NYC-EX10, use Queue Viewer to force an immediate retry of message delivery.
7.
Verify that Alan received the message.
Results: After this exercise, you should have used the Routing Log Viewer to view your routing topology.
For troubleshooting, you will have used the Queue Viewer and Telnet to investigate the mail-flow
problem.

When you complete the lab, revert the virtual machines to their initial state. To do this, complete the
following steps:
1.
On the host computer, start Microsoft Hyper-V Manager.
2.
3.
4.
machine.
6-43
5.
machine.
6.
Wait for 10165A-NYC-EX10-B to start, and then start 10165A-NYC-SVR1-B. Connect to the virtual
machine.
7.
Wait for 10165A-NYC-SVR1-B to start. Connect to the virtual machine.
Review Questions
1.
In what four ways can a message enter the Hub Transport server submission queue?
2.
When would you consider implementing Exchange Server-specific routing costs?
3.
What Exchange Server version would you implement if you need to consider Routing Group
connectors with Exchange Server 2010?
Common Issues Related to Managing Message Transport
6-44
Identify the causes for the following common issues related to managing message transport, and fill in the
Issue
You configure a Send Connector
to the Internet, but messages
cannot be transferred over it.
You want to understand over what
hops the message has been
transferred.
Your Exchange Server does not
accept messages for the domain
adatum-info.com.
Troubleshooting tip
7-1
Module 7
Implementing Messaging Security
Contents:
Lesson 1: Deploying Edge Transport Servers
Lesson 2: Deploying an Antivirus Solution
7-3
7-18
Lab A: Configuring Edge Transport Servers and Forefront Protection 2010

for Exchange Server
7-26
Lesson 3: Configuring an Anti-Spam Solution
7-33
Lesson 4: Configuring Secure SMTP Messaging
7-45
7-51
Module Overview
7-2
In any Microsoft Exchange Server organizationwhether coexistent or notyou should be aware of the
security ramifications of Internet usage in your messaging organization. As you upgrade from Exchange
Server 2003 or Exchange Server 2007, you should consider replacing your smart host server with an
Exchange server in your perimeter network. The Edge Transport server role was designed to be placed
directly in a perimeter network, therefore directly in the Internet. Servers that are directly accessible from
the Internet can increase your security concerns; however, the Edge Transport server role provides
functionalities that secure data from unauthorized Internet access.
This module describes how to plan for and deploy an Exchange 2010 Edge Transport server role, and the
security issues related to the deployment.
This module describes how to configure secure Simple Mail Transfer Protocol (SMTP) messaging and
Domain Security, which is a feature available in Exchange Server 2007 and newer versions. The Edge
Transport server role provides powerful anti-spam functionalities, and some antivirus features. Because the
Edge Transport server role does not include a virus scanner, you can integrate additional antivirus
products such as Forefront Protection 2010 for Exchange Server.
Deploy Edge Transport servers.
Deploy an antivirus solution.
Configure an anti-spam solution.
Configure secure SMTP messaging.
Lesson 1
Deploying Edge Transport Servers
7-3
In any Exchange Server deployment, you must ensure critical data (such as email messages) is protected
from unauthorized access from the Internet. If you are planning to place a server in your perimeter
network, you should plan to use an Edge Transport server.
This lesson describes features and functionalities of the Edge Transport server role, and explains how you
can configure data synchronization between Active Directory Domain Services (AD DS) and the Edge
Transport server.
Describe the Edge Transport server role.
Identify the infrastructure requirements for the Edge Transport server role.
Describe the functionality of Active Directory Lightweight Directory Services (AD LDS).
Configure Edge Transport servers.
Describe the purpose and functionality of Edge Synchronization.
Explain how Internet message flow works in Exchange Server 2010.
Configure Edge synchronization.
Describe the concept of cloned configuration.
What Is the Edge Transport Server Role?
7-4
The Edge Transport server role in Exchange Server 2010 provides a secure SMTP gateway for all incoming
and outgoing Internet email in an organization. As an SMTP gateway, the primary role of the Edge
Transport server is to maintain message hygiene, which includes anti-spam and antivirus filtering. You also
can use the Edge Transport server to apply messaging policies to messages that are sent to the Internet.
The Edge Transport server role was developed primarily for the small-to-medium business market, and for
organizations that have never hosted their own messaging systems on-premise, or to replace an existing
SMTP gateway. You should evaluate the Edge Transport features against your existing solution, and then
decide if your organization would benefit from using Edge Transport servers. Using Edge Transport
servers is not a mandatory requirement for Exchange Server organizations.
Edge Transport Server Role Functionality

The Edge Transport server role provides the functionalities listed in the following table.
Feature
Description
Internet
message
delivery
The Edge Transport server role accepts all email coming into the Exchange Server
2010 organization from the Internet, and from servers in external organizations. The
Edge Transport server role routes all accepted inbound messages to a Hub Transport
server inside the organization. It also routes all outbound messages to the Internet.
Antivirus and
anti-spam
protection
The Exchange 2010 Edge Transport server role helps prevent spam messages and
viruses from reaching your organizations users by using a collection of agents that
provide different layers of spam filtering and virus protection. It uses these agents to
filter email messages based on the source or destination recipients, source SMTP
server, attachments, and message contents.
Exchange Server 2010 does not include antivirus software. You must use Microsoft
products such as Forefront Protection 2010 for Exchange Server or third-party
software that integrates with Exchange Server 2010 to provide antivirus protection.
The perimeter network is the ideal location for antivirus protection, because it is the
entry point from the Internet to the company network.
7-5
Feature
Description
Edge
transport
rules
Edge Transport rules control the flow of messages that are sent to, or received from,
the Internet. These rules function much like the Hub Transport rules. Edge transport
rules apply actions to messages that meet specified conditions. The Edge transport
rule conditions are based on data such as specific words or text patterns in the
message subject, body, header or From address, the spam confidence level (SCL), or
attachment type. Actions determine how the message is processed when a specified
condition is true. Possible actions include quarantining a message, dropping or
rejecting a message, appending additional recipients, or logging an event.
Address
rewriting
Address rewriting enables SMTP address modification for any of your organizations
message senders or recipients. Address rewriting can be useful in scenarios where an
organization wants to hide internal domains, to enable multiple organizations to
appear as a single organization, or to integrate services that a third-party provides to
an organization.
Question: Would you install an Edge Transport server role as a member of your
organizations Active Directory domain?
Edge Transport Server Role Infrastructure Requirements
7-6
The Edge Transport server role differs from any other Exchange 2010 server role, because you can install it
on servers that are running the Windows Server 2008 operating system, and that are not members of the
internal AD DS. This configuration makes it easier and more secure to deploy Edge Transport servers in a
perimeter network.
Edge Transport Server Deployment Considerations

When planning to deploy Edge Transport servers, consider the following factors:
You cannot combine the Edge Transport server role with any other Exchange 2010 server role. To
provide increased security, you must install the Edge Transport server role on a separate computer,
which can be virtual or physical.
You should not install the Edge Transport server role on a computer that is a member of the internal
Active Directory domain, but you can install it in a perimeter network forest.
The computer running the Edge Transport server role must have a fully qualified domain name
(FQDN).
You should not allow Active Directory communications through the firewall that protects the internal
network from the perimeter network. Otherwise, this can cause security issues such as allowing an
unauthorized user to retrieve your email addresses directly from AD DS and use them for spam.
Instead, the Edge Transport server role uses AD LDS to store configuration and recipient information.
AD LDS does not contain all the information from AD DS, but synchronizes only the required
information such as email addresses.
You should deploy the Edge Transport server role in a perimeter network to ensure network isolation
from both the internal network and the internal Exchange servers. This configuration provides a
higher level of security for the rest of the Exchange Server organization, which should be located
behind a firewall on a separate internal network.
7-7
You must configure the external firewall on the perimeter network to allow inbound and outbound
SMTP traffic to and from the Edge Transport server role. The internal firewall must allow SMTP traffic
between the Edge Transport server role and one or more internal Hub Transport servers. The firewall
must also allow outbound traffic towards the perimeter network for AD DS to AD LDS
synchronization.
The firewall configuration required for Edge Transport servers is greatly simplified, because the server
does not need to be an internal domain member. The following table describes the firewall
configuration requirements.
Firewall
Firewall rule
Explanation
External
Allow port 25 from all

external IP addresses to the
Edge Transport server.
This rule allows the Edge Transport server to receive

email from any host on the Internet.
External
Allow port 25 to all external IP This rule enables the Edge Transport server to send
addresses from the Edge
email to SMTP hosts on the Internet.
Transport server.
External
Allow port 53 to all external IP This rule enables the Edge Transport server to
addresses from the Edge
resolve Domain Name System (DNS) names on the
Transport server.
Internet.
Internal
Allow port 25 from the Edge

Transport server to specified
Hub Transport servers.
This rule enables the Edge Transport server to send

inbound SMTP email to Hub Transport servers.
Internal
Allow port 25 from specified

Hub Transport servers to the
This rule enables the Hub Transport servers to send

email to the Edge Transport server.
Internal
Allow port 50636 for secure

Lightweight Directory Access
Protocol (LDAP) from
specified Hub Transport
servers to the Edge Transport
server.
This rule enables the Hub Transport server to

replicate information to the Edge Transport servers
by using Edge Synchronization. This port is not the
default Secure LDAP port, but it is used specifically
for the Edge Synchronization process.
Internal
Allow port 3389 for Remote

Desktop Protocol (RDP) from
the internal network to the
This rule is used for optional remote desktop

administration of the Edge Transport server.
If the Edge Transport server directly routes email to the Internet, you must configure the server with the IP
addresses for DNS servers that can resolve DNS names on the Internet.
What Is AD LDS?
The Edge Transport server does not use AD DS to store its configuration information; instead, Edge
Transport servers use AD LDS to store this data.
7-8
AD LDS is a special mode of AD DS that stores information for directory-enabled applications. AD LDS is
an LDAP-compatible directory service that runs on servers running the Windows Server 2008 operating
system. AD LDS is designed to be a stand-alone directory service. It does not require the deployment of
DNS, domains, or domain controllers; instead, it stores and replicates only application-related information.
How AD LDS Works with Exchange Server 2010 Edge Transport Servers
AD LDS stores configuration and recipient data for the Exchange 2010 Edge Transport server role. Before
you can install the Edge Transport server role, you must install the AD LDS server role on a Windows
Server 2008 computer. AD LDS configures automatically when you install the Edge Transport server role.
The following types of information are stored in AD LDS:
Schema. AD LDS requires schema information that defines the types of objects and attributes that can
be created. The AD LDS version that is installed on an Edge Transport server contains a schema that
defines the Exchange Server-related information.
Configuration. The Configuration partition is similar to the Configuration partition in AD DS, and
provides a container to hold the Microsoft Exchange Hosted Services configuration information.
Recipient information. You can synchronize recipient information from AD DS to AD LDS. Recipient
data that is synchronized from the Exchange Server organization is stored in the MSExchangeGateway
organizational unit (OU). Edge Transport servers use the recipient information when processing rules
such as recipient-filtering and transport rules.
Managing AD LDS
The AD LDS database is stored in the %programfiles%\Microsoft\Exchange

Server\V14\TransportRoles\data\Adam directory. The primary database is adamntds.dit, which is similar to
the databases that Exchange Server uses for mailbox stores and mail queue databases.
7-9
In general, minimal administration is required for the AD LDS instance running on an Edge Transport
server. You can make most changes to the AD LDS directory information by using Exchange Server 2010
management tools.
Note Before installing the Edge Transport server role, you must install AD LDS on the
computer. However, you do not need to perform any configuration steps in AD LDS before
installing the Edge Transport server role.
Question: Do you need to configure AD LDS on your Edge Transport server manually?
Demonstration: How to Configure Edge Transport Servers
In this demonstration, you will review the Edge Transport server role default configuration before
implementing Edge synchronization.
Demonstration Steps
7-10
1.
2.
Review the default configuration settings of the Edge Transport server role, including the default antispam settings, Send and Receive connectors, and accepted domains.
What Is Edge Synchronization?
7-11
Edge synchronization is a process that replicates information from AD DS to AD LDS on Edge Transport
servers. Because Edge Transport servers are not joined to the internal Active Directory domain, they
cannot directly access the Exchange Server organization configuration or recipient information that is
stored in AD DS. The EdgeSync feature enables the shared information to be replicated from AD DS to
AD LDS.
You can deploy Edge Transport servers without using Edge Synchronization, but using EdgeSync can
decrease the effort needed to administer the Edge Transport servers. AD DS contains much of the
configuration information required by the Edge Transport server. For example, if you configure accepted
domains on the Hub Transport servers, these accepted domains can replicate automatically to the Edge
Transport servers.
To enable any filtering or transport rules that are based on recipients, you must implement EdgeSync to
replicate the recipient information to AD LDS.
Best Practice When you deploy Edge Transport servers, we recommend that you also
deploy Edge synchronization.
How to Configure Edge Synchronization
You need to configure Edge synchronization between Edge Transport and Hub Transport servers
manually. Additionally, you can only deploy Edge Transport servers to one Active Directory site at a time.
Configure Edge synchronization on each Edge Transport server as follows:
1.
Create an Edge subscription file on an Edge Transport server.
2.
Import an Edge subscription file on a Hub Transport server.
3.
Start and verify the EdgeSync process.
Note To verify that EdgeSync configured correctly, use the Test-EdgeSynchronization

-FullCompareMode command.
Information Replicated by Edge Synchronization

After you enable Edge synchronization, the Edge synchronization process establishes connections
between a Hub Transport server and the Edge Transport server, and synchronizes configuration and
recipient information between AD DS and AD LDS.
7-12
In Exchange Server 2007, EdgeSync replicates all of the configuration and recipient information in its
entirety. This takes a long time, particularly in organizations with a large number of recipients. Exchange
Server 2010 introduces incremental updates for EdgeSync. After the initial synchronization, only the
changes are synchronized to the Edge Transport server.
Important The internal Hub Transport serversand not the Edge Transport servers
always initiate EdgeSync replication. EdgeSync replication traffic always encrypts using secure
LDAP.
During synchronization, EdgeSync replicates the following data from AD DS to AD LDS:
Accepted domains
Recipients (hashed)
Safe senders (hashed)
Send connectors
Hub Transport server list (for dynamic connector generation)
Note The recipient and the safe senders are hashed by using a one-way hash, which
prevents an attacker from retrieving recipient information from the Edge Transport server.
Question: Can you deploy Edge Transport servers without using EdgeSync?
7-13
How Internet Message Flow Works
The primary function of the Edge Transport server is to secure both inbound and outbound Internet
email. After you configure an Edge subscription between your organizations Hub Transport servers and
the Edge Transport servers in the perimeter network, both inbound and outbound Internet email is
enabled.
Default SMTP Connectors
When you install the first Hub Transport server in an Exchange Server 2010 organization, two SMTP
Receive connectors are created. When you install an Edge Transport server, just an SMTP Receive
connector is created. When you enable Edge subscription, two additional SMTP Send connectors are
created as listed in the following table.
Connector name
Connector type
EdgeSync Inbound to
<sitename>
SMTP Send
connector
Description
EdgeSync
<sitename> to
Internet
SMTP Send
connector
Created on the Edge Transport server by Edge

subscription.
Created in AD DS, and then replicated to the Edge
Transport server by Edge synchronization.
Settings such as smart hosts and address space are
defined by the Edge subscription. The connector is
configured to use an address space that includes all
internal domains.
Created on the site that is defined by Edge subscription.

Created in AD DS and then replicated to the Edge
Transport server by Edge synchronization.
Source server is the Edge Transport server on which the
Edge subscription is enabled.
Address space of SMTP:*
Uses DNS to locate SMTP servers on the Internet.
Default Message Transfer
7-14
After you enable EdgeSync, email flows through the Exchange Server organization in the following order:
1.
A user submits a message through a Client Access server to the Mailbox server. The Hub Transport
server retrieves the message from the Mailbox server, and then categorizes it for delivery. In this
scenario, the message recipient is outside the organization.
2.
The Hub Transport server determines that it must use the EdgeSync <sitename> to Internet Send
connector to send email to the Internet. It locates the Edge Transport server that is configured as the
bridgehead server for the connector.
Note If the Hub Transport server that retrieves the message from the Mailbox server is not
in the Active Directory site that is included in the Edge subscription, or has not been added
to the subscription, the Hub Transport server forwards the message to a Hub Transport
server that is in the subscribed site.
3.
The Hub Transport server forwards the message to the Edge Transport server, which sends the email
message to the Internet by using the EdgeSync <sitename> to Internet Send connector.
4.
For inbound messages, the sending SMTP connector connects to the Edge Transport server. The Edge
Transport server accepts this connection by using the Default internal Receive connector
SERVERNAME, which is configured to accept anonymous connections on port 25 from all IP
addresses. The Edge Transport server applies all antivirus and spam-filtering rules.
5.
If the message is accepted, the Edge Transport server uses the EdgeSync Inbound to <sitename>
connector to forward the message to a Hub Transport server configured to accept Internet messages.
6.
The Hub Transport server uses the Default SERVERNAME connector to receive the message, and then
forwards the message to the appropriate Mailbox server.
Note You can modify the default message flow by creating additional SMTP connectors.
For example, you may need to create a new SMTP send connector to send email to a specific
destination domain. You can do this by creating a new Send connector, and then configuring
the destination domain name as the address space for the connector. Finally, configure the
connector to support the unique message-routing requirements for messages sent to the
domain.
Question: When using Edge synchronization, do you need to create additional Send or
Receive connectors?
7-15
Demonstration: How to Configure Edge Synchronization
In this demonstration, you will see how to enable Edge synchronization, and verify that it is working. You
also will see how to configure address rewriting.
Demonstration Steps
1.
On the Edge Transport server, in Exchange Management Shell, run the New-EdgeSubscription FileName c:\NYC-SVR1.xml command on the Edge Transport server.
2.
Import the Edge subscription file on the Hub Transport server by using Exchange Management
Console.
3.
Use Start-EdgeSynchronization and Test-EdgeSynchronization to test Edge synchronization.
4.
Review the changes made to the Edge Transport server after Edge synchronization.
5.
Configure address rewriting by using the New-AddressRewriteEntry cmdlet.
What Is Cloned Configuration?
7-16
Cloned configuration is the process of configuring multiple Edge Transport servers with identical
configurations. To achieve high availability for messaging transport, you should ensure that multiple Edge
Transport servers are available at all times.
You can use cloned configuration to ensure that all the Edge Transport servers have the same
configuration. You only configure one server, and export the configuration to an XML file that is then
imported to the target servers. Additionally, you can use the cloned configuration to restore the Edge
Transport server configuration quickly during a disaster recovery scenario.
The XML file includes the following configuration information:
Transport server file paths and all log files paths (such as the message tracking log path)
Transport agents, including status and priority
All Send and Receive connectorrelated settings (including Send connector passwords encrypted with
a default encryption key)
Accepted Domain information
Anti-spam features and configuration settings
Note Although AD LDS supports directory replication, Exchange Server 2010 does not
provide an option to use directory replication for configuring multiple Edge Transport
servers. You must use cloned configuration if you want to automate this process, and you
must repeat the edge-cloning steps each time you make a configuration change on one of
the servers.
7-17
Configuring Cloned Configuration
To configure cloned configuration, use the ExportEdgeConfig.ps1 and ImportEdgeConfig.ps1 scripts to

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

interface scripts, and not individual cmdlets. The scripts are located in the
%programfiles%\Microsoft\Exchange\v14\Scripts folder on all servers running Exchange Server 2010.
Cloning Transport Rules
Cloned configuration does not clone any transport rule from an Edge Transport server. To ensure that all
transport rules are also cloned, use the following cmdlet to export all transport rules.
$file = Export-TransportRuleCollection
Set-Content Path c:\tmp\EdgeRuleCollection.xml Value $file.FileData Encoding Byte
On the target Edge Transport server, you then need to use the following command to import the
transport rules.
[Byte[]]$Data = Get-Content -Path "C:\tmp\EdgeRuleCollection.xml"
-Encoding Byte -ReadCount 0
Import-TransportRuleCollection -FileData $Data
Question: When using cloned configuration with your Edge Transport servers, what extra
fact should you consider?
Lesson 2
Deploying an Antivirus Solution
To protect your Exchange Server 2010 organization, it is important to implement a separate antivirus
product such as Forefront Protection 2010 for Exchange Server. This lesson describes the Forefront
security features that can improve your organizations security.
Describe the antivirus solution features in Exchange Server 2010.
Describe the Forefront Protection 2010 for Exchange Server features.
Describe the Forefront Protection 2010 deployment options.
Describe the best practices for deploying an antivirus solution.
Explain how to install and configure Forefront Protection 2010 for Exchange Server.
7-18
Antivirus Solution Features in Exchange Server 2010
7-19
One of the primary tasks in protecting your Exchange Server organization is to ensure that all messages
containing viruses are stopped at the perimeter of the messaging environment. Exchange Server 2010
includes the following virus protection features:
Continuing support of the Virus Scanning application programming interface (VSAPI). In Exchange
Server 2010, Microsoft supports a VSAPI that you can use to scan messages in the Mailbox database.
Antivirus stamping. Antivirus stamping reduces how often a message is scanned as it proceeds
through an organization. It does this by stamping scanned messages with the version of the antivirus
software that performed the scan, including the antivirus engine and pattern files, and the scan
results. This antivirus stamp travels with the message as it is routed through the organization, and
determines whether additional virus scanning must be performed on a message.
Integration with Forefront Protection 2010 for Exchange Server. Forefront Protection 2010 for
Exchange Server is an antivirus solution from Microsoft that integrates with Exchange Server 2010 to
provide advanced protection, optimized performance, and centralized management. This helps
customers deploy and maintain a secure messaging environment. Forefront Protection 2010 for
Exchange Server provides:
Advanced protection against viruses, worms, phishing, and other threats, by using up to five
antivirus engines simultaneously at each layer of the messaging infrastructure.
Optimized performance through coordinated scanning across Edge Transport servers, Hub
Transport servers, Mailbox servers, and features such as in-memory scanning, multithreaded
scanning processes, and performance bias settings.
Centralized management of remote installation, engine and signature updating, and reporting
and alerts through the Forefront Online Server Security Management Console.
Question: Does Exchange Server provide a built-in antivirus solution?
What Is Forefront Protection 2010 for Exchange Server?
Forefront Protection 2010 for Exchange Server is a separate antivirus software package that you can
integrate with Exchange Server 2010 to provide antivirus protection for the Exchange Server 2010
environment.
The following table lists the benefits of implementing Forefront Protection 2010 for Exchange Server.
7-20
Service
Description
Antivirus scan with multiple

engines
You can automatically scan messages by using multiple virus pattern

engines, not just a single engine.
Full support for VSAPI
Forefront Protection 2010 for Exchange Server fully supports the

Exchange VSAPI.
Full support for antivirus

timestamping
Forefront Protection 2010 for Exchange Server fully supports antivirus

timestamping.
Microsoft IP Reputation
Service
This service provides sender reputation information about IP addresses

that are known to send spam. This is an IP-block list offered exclusively
to Exchange Server organizations.
Spam Signature updates
This service identifies the most recent spam campaigns. The signature
updates are available on an as-needed basis, up to several times a day.
Premium spam protection
This service includes automated updates for this filter. Updates are
available on an as-needed basis, up to several times a day.
Automated content filtering

updates
Automated content filtering updates for Microsoft SmartScreen spam

heuristics, phishing websites, and other Intelligent Message Filter (IMF)
updates.
Question: What services does Forefront Protection 2010 for Exchange Server provide?

7-21
Forefront Protection 2010 Deployment Options
When you implement Forefront Protection 2010 for Exchange Server, you must consider the various
deployment options.
Installing Forefront Protection 2010
7-22
First, you need to determine the servers on which you plan to install Forefront Protection 2010 for
Exchange Server. The number of servers on which you install Forefront Protection 2010 will also depend
on financial considerations, because you will need to buy the equivalent number of server licenses.
As a baseline, you should deploy Forefront Protection 2010 for Exchange Server on all Edge and Hub
Transport servers. These servers route messages, and therefore, are the servers that will first identify
messages infected by viruses.
For full protection, you should deploy Forefront Protection 2010 for Exchange Server on all Edge
Transport, Hub Transport, and Mailbox servers.
You do not need to install Forefront Protection 2010 on the Client Access server role, because Forefront is
only needed on the Mailbox, Edge Transport, or Hub Transport server roles.
As already mentioned, Forefront Protection 2010 for Exchange Server scans each email only once, and
then stamps it with a special antivirus stamp so that other servers do not scan that message again. This
also means that you do not need to scan the Mailbox servers, because any message that comes in or
leaves the system is scanned eventually by Forefront Protection 2010 after you install it on the Edge and
Hub Transport servers. However, it is up to your security team to decide on this matter.
Forefront Protection 2010 Scanning Considerations
After you decide the servers on which you want to deploy Forefront Protection 2010, you must consider
how many scan engines you should use to scan a message, and the types of scan engines that you should
use.
7-23
As a best practice, you should use dynamic configuration of virus scanners, because this provides an
optimum combination with third-party virus scanners. You can also change the selection of the virus
scanners later.
Question: What is an antivirus stamp?
Best Practices for Deploying an Antivirus Solution
7-24
Although implementing an antivirus solution in Exchange Server is straightforward, there are some factors
that you should keep in mind when choosing and configuring an antivirus solution.
Implementing Multiple Antivirus Layers
To provide enhanced security against viruses, you should implement multiple layers of antivirus
protection. A virus can enter your organization from the Internet, through an email, or from an
unprotected client within your company. Thus, it is a best practice to implement several layers of antivirus
protection such as a firewall and an Edge Transport server, and at the client-computer level.
Maintaining Regular Antivirus Updates

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

for Exchange Server
In this demonstration, you will see how to install and configure Forefront Protection 2010 for Exchange
Server, and how to manage Forefront Protection 2010.
Demonstration Steps
1.
Install Forefront Protection 2010 for Exchange Server.
2.
Open the Forefront Protection 2010 Administration Console.
3.
Configure the Antimalware - Edge Transport settings.
4.
Configure the Antispam - Content Filter settings.
5.
Configure global settings.
6.
Review the monitoring options available in Forefront.
7-26
Lab A: Configuring Edge Transport Servers and Forefront

Protection 2010 for Exchange Server
Lab Setup
following steps:
1.
2.
Ensure that the 10165A-NYC-DC1-B, 10165A-NYC-EX10-B, and the 10165A-NYC-SVR1-B virtual

machines are running.
10165A-NYC-SVR1-B: Stand-alone server
3.
If required, connect to the virtual machines. Log on to NYC-DC1 and NYC-EX10 as

4.
If required, log on to NYC-SVR1 as Administrator, with the password, Pa$$w0rd.
5.
On the host computer, in Hyper-V Manager, click 10165A-NYCSVR1-B, and in the Actions pane,
click Settings.
6.
Click DVD Drive, click Image file, and then click Browse.
7.
Browse to C:\Program Files\Microsoft Learning\10165\Drives, click Exchange2010SP1.iso, click

Open, and then click OK. On NYC-SVR1, close the AutoPlay dialog box.
Lab Scenario
7-27
You are a messaging administrator in Contoso, Ltd. Your organization has deployed Exchange Server 2010
internally, and now must extend it so that everyone within the corporation can send and receive Internet
email.
To implement this, you need to set up an Edge Transport server to replace an existing smart host. You
need to deploy the Edge Transport server role, and verify that the Internet message flow is working.
Exercise 1: Installing an Edge Transport Server

Scenario
First, you must install the Edge Transport server, ensuring that you meet the installation prerequisites.
1.
Verify and prepare the prerequisites for installing an Edge Transport server.
2.
Install an Edge Transport server.
3.
Configure DNS records for the Edge Transport server.
7-28
Task 1: Verify and prepare the prerequisites for installing an Edge Transport server
1.
On NYC-SVR1, open Server Manager and ensure that .NET Framework 3.5.1 Features is listed in the
Features Summary pane.
2.
From Server Manager, remove the SMTP Server feature. Do not restart when prompted. This feature
was pre-installed for the classroom lab setup and cannot be installed on an Edge Transport server.
3.
Configure the Primary DNS suffix on this computer to contoso.com.
4.
Restart NYC-SVR1, and then, after the server reboots, log on locally as Administrator, with the
password, Pa$$w0rd. At the Removal Results page, click Close, and then close Server Manager.
Task 2: Install an Edge Transport server

1.
Run d:\Setup /mode:install /role:EdgeTransport /InstallWindowsComponents

/AdamLdapPort:50389 / AdamSslPort:50636. Wait for the installation to finish. The installation will
take about 8-10 minutes.
2.
Restart NYC-SVR1, and then, after the server reboots, log on as Administrator, with the password,
Pa$$w0rd.
Task 3: Configure DNS records for the Edge Transport server

1.
On NYC-DC1, in DNS Manager, add the following A-Record:
Name: NYC-SVR1
IP address: 10.10.0.201
2.
Right-click contoso.com, and then click New Mail Exchanger (MX).
3.
In the New Resource Record dialog box, in the Fully qualified domain name (FQDN) of mail
server box, type NYC-SVR1.contoso.com, and then click OK.
Results: After this exercise, you should have verified and installed the prerequisites to install an Edge
Transport server, installed the Edge Transport server role on a server, and configured the DNS records for
the Edge Transport server.
7-29
Exercise 2: Configuring Edge Transport Servers

Scenario
After installing an Edge Transport server, you want to verify that you can manage it from your Exchange
Server organization by using Edge synchronization. You also need to verify that Internet messaging is
working correctly.
1.
Configure an Edge subscription.
2.
Verify that Edge synchronization is working, and that AD LDS contains data.
3.
Configure and verify Internet message delivery.
Task 1: Configure an Edge subscription

1.
On NYC-SVR1, open the Exchange Management Shell and then run New-EdgeSubscription FileName c:\nyc-svr1.xml. The file name must end in .xml. Otherwise, the subscription will be
refused later when you try to import it into the Hub Transport server.
2.
Copy c:\nyc-svr1.xml to \\nyc-ex10\c$.
3.
On NYC-EX10, in the Exchange Management Console, click New Edge Subscription, and then create
an Edge subscription by using the following settings:
Active Directory Site: Default-First-Site-Name
Subscription file: C:\NYC-SVR1.XML
Task 2: Verify that Edge synchronization is working, and that AD LDS contains data
1.
On NYC-EX10, open Exchange Management Shell and type Start-EdgeSynchronization.
2.
At the PS prompt, type Test-EdgeSynchronization -FullCompareMode. Ensure that the displayed

results include RecipientStatus: Synchronized. If not, you need to wait for another minute and then
run Test-EdgeSynchronization -FullCompareMode again.
3.
Run Get-User -Identity Christine | ft Name, GUID, and then write down the first eight characters of
the globally unique identifier (GUID) in your notes.
4.
On NYC-SVR1, from the command prompt, run LDP.exe, click Connection on the menu bar, and
then click Connect.
5.
In the Connect window, in the Server text box type NYC-SVR1, and then in the Port text box, type
50389, and then click OK.
6.
On the menu bar, click Connection, and then click Bind.
7.
In the Bind type pane, click Bind as currently logged on user, and then click OK.
8.
On the menu bar, click View, and then click Tree.
9.
In the Tree View dialog box, clear any entry in the BaseDN field, and then click OK.
10. In the LDP window, in the left pane, double-click OU=MSExchangeGateway to expand it.
11. Double-click CN=Recipients,OU=MSExchangeGateway.
7-30
12. Using the GUID that you recorded in step 3, locate the recipient that starts with CN=<GUID>. After
you find the recipient, double-click the recipient GUID, and then review the data that is available for
this recipient.
Task 3: Configure and verify Internet message delivery

1.
On NYC-EX10, in the Exchange Management Console, configure the EdgeSync - Default-First-SiteName to Internet Send connector with the following settings:
Enable Route mail through the following smart hosts
IP address: 10.10.0.10
Cost: 1
By default, this Send connector uses DNS to resolve the mails target SMTP address. For this exercise,
you must change it to point to the IP address of NYC-DC1. This server has the SMTP service installed
so that it can verify that messages are accepted.
2.
In Exchange Management Shell, type Start-EdgeSynchronization.
3.
Start Internet Explorer and then browse to https://NYC-EX10.Contoso.com/owa, and log on as

Contoso\Christine, with the password, Pa$$w0rd.
4.
Create and send a new email message to Info@Internet.com, with the subject, Test Mail to
Internet.
5.
Switch to NYC-SVR1, and use Exchange Management Console to open Queue Viewer, and then verify
that all queues are empty.
Results: After this exercise, you should have configured Edge subscription between an Exchange Server
organization and an Edge Transport server. You will also have verified that the synchronization works
correctly, and verified the data in the AD LDS database of the Edge Transport server. Finally, you will have
configured and verified Internet message delivery.
7-31
Exercise 3: Configuring Forefront Protection 2010 for Exchange Server

Exercise Setup
Before you begin the exercise, you must perform the following steps:
1.
2.
In Hyper-V Manager, click 10165A-NYCSVR1-B, and then, in the Actions pane, click Settings.
3.
4.
Browse to C:\Program Files\Microsoft Learning\10165\Drives, click ForeFrontInstall.iso, click

Scenario
Virus prevention is critical to your organizations security. As the messaging administrator, you are
required to install virus scanning software to scan every message and automatically remove viruses. To
implement this functionality, you must install antivirus software and configure it accordingly.
You decided to use Forefront Protection 2010 for Exchange Server, and you want to install it on the Edge
Transport server, because this is the server through which messages from the Internet enter your
organization.
1.
Install Forefront Protection 2010 for Exchange Server.
2.
Configure Forefront Protection 2010 for Exchange Server.
Task 1: Install Forefront Protection 2010 for Exchange Server

1.
On NYC-SVR1, run D:\ForefrontExchangeSetup.exe.
2.
On the Antispam Configuration page, click Enable antispam later.
3.
On the Microsoft Update page, click I don't want to use Microsoft Update.
4.
Install Forefront Protection 2010 for Exchange Server with the default settings. Wait for the
installation to finish, which will take about 5 minutes.
Task 2: Configure Forefront Protection 2010 for Exchange Server

1.
On NYC-SVR1, click Start, point to All Programs, point to Microsoft Forefront Server Protection,
and then click Forefront Protection for Exchange Server Console.
2.
From the Policy Management section, on the Antimalware - Edge Transport page, in the Engines
and Performance pane, select the Scan with all engines check box.
3.
In the Scan Actions pane, in the Action list in the Virus row, select Delete, and then save the
changes.
4.
On the Global Settings - Advanced Options page, in the Threshold Levels pane, increase the value
of Maximum nested attachments to 50, and Maximum nested depth compressed files to 10.
5.
Under Intelligent Engine Management, in the Engine management list, select Manual.
6.
In the Update scheduling table, click Normal Virus Control, and then click the Edit Selected
Engines button.
7-32
7.
In the Edit Selected Engine dialog box, in the Update frequency pane, verify that the Check for
updates every check box is selected, type 00:30, click Apply and Close, and then save the changes.
8.
On the Global Settings - Scan Options page, in the Scan Targets Transport pane, under Target
types, clear the Internal check box, and then click Save.
Results: After this exercise, you should have installed and configured Forefront Protection 2010 for
Exchange Server on the Edge Transport server.
Lesson 3
Configuring an Anti-Spam Solution
7-33
Spam messages can adversely impact the messaging environment of an organization. Therefore,
implementing an anti-spam solution on your Edge Transport server is a critical component of maintaining
your organizations messaging environment after your upgrade from Exchange Server 2003 or Exchanger
Server 2007. Exchange Server 2010 includes several features that you can use to implement anti-spam
protection in your organization.
This lesson provides an overview of the options available for anti-spam filtering, and describes how you
can configure your Edge Transport servers to reduce spam in your organization.
Describe the spam-filtering features available in Exchange Server 2010.
Explain how Exchange Server 2010 applies spam filters.
Describe the concept of Sender ID filtering.
Explain sender reputation filtering.
Describe content filtering.
Explain how to configure anti-spam options.
Overview of Spam-Filtering Features
7-34
One of the main advantages of installing the Edge Transport server to route email to and from the
Internet is the available spam-filtering functionality. You can implement anti-spam functionality by using a
series of Edge Transport server transport agents.
Note Forefront Protection 2010 for Exchange Server provides more frequent updates for
the anti-spam patterns than the Exchange Server 2010 built-in anti-spam features. Typically,
the built-in anti-spam pattern is updated daily, whereas in Forefront Protection 2010, you
can configure the updates to update multiple times a day.
Edge Transport Server Anti-Spam Agents
The following table lists the anti-spam agents that are implemented during the default installation of an
Agent
Description
Connection
Filtering
Filters messages based on the IP address of the remote server that is trying to send the
message. Connection filtering uses IP Block lists and IP Allow lists.
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 ID
Filters messages by verifying the IP address of the sending SMTP server against the
purported owner of the sending domain.
Content
Filtering
Filters messages based on the message contents. This agent uses SmartScreen
technology to assess the message contents. It also supports safelist aggregation.
7-35
Agent
Description
Sender
Reputation
Filters messages based on many characteristics of the sender accumulated over a specific
period.
Attachment
Filter
Filters messages based on attachment file name, file name extension, or file
Multipurpose Internet Mail Extensions (MIME) content type.
Antivirus
Scanning
Scans messages and attachments for viruses.
Outlook
Junk E-mail
Filtering
Sends messages to the Junk E-mail folder, as applicable.
Note You can view all the agents installed on an Edge Transport server by using the GetTransportAgent cmdlet on the Edge Transport server. The default Edge Transport server
installation also includes other transport agents, such as the Address Rewriting Inbound
Agent, the Address Rewriting Outbound Agent, and the Edge Rule Agent. You cannot use
these agents for spam filtering.
Safelist Aggregation
In Exchange Server 2010, the Content Filtering agent on the Edge Transport server uses the Microsoft
Office Outlook Safe Senders Lists and trusted contacts to optimize spam filtering. Safelist aggregation is a
set of anti-spam functionality that Outlook 2010 and Exchange Server 2010 share. This anti-spam
functionality collects data from the anti-spam safe lists that Outlook users configure, and makes this data
available to the anti-spam agents on the Edge Transport server. In Exchange Server 2007, you needed to
use the Update-Safelist cmdlet to configure safelist aggregation. In Exchange Server 2010, this
functionality is enabled by default.
Question: Which anti-spam agents are available in Exchange Server 2010?
How Exchange Server 2010 Applies Spam Filters
7-36
The Edge Transport server role in Exchange Server 2010 uses spam-filtering agents to examine each SMTP
connection and the messages sent through it. When an SMTP server on the Internet connects to the Edge
Transport server and initiates an SMTP session, the Edge Transport server examines each message, using
the following sequence:
1.
2.
When the SMTP session is initiated, the Edge Transport server applies connection filtering by using
the following criteria:
Connection filtering examines the administrator-defined IP Allow list. Administrators might

include the IP addresses for SMTP servers at partner organizations in the IP Allow list. If an IP
address is on the administrator-defined IP Allow list, the server does not apply any other
connection filtering, and sends the message to Sender Filtering.
Connection filtering examines the local IP Block list. Administrators might include the IP
addresses for the SMTP servers of known spam writers, or other servers from which the
organization does not want to receive email, in the IP Block list. If the connection filtering agent
finds the IP address of the sending server on the local IP Block list, the server rejects the message
automatically, and other filters are not applied.
Connection filtering examines the safe lists provided by IP Allow list providers. If an IP address is
on the safe list, the server does not apply any other connection filtering, and sends the message
to Sender Filtering.
Connection filtering examines the real-time block list (RBL) of any IP Block List Providers that you
have configured. If the agent finds the sending servers IP address on an RBL, the server rejects
the message, and other filters are not applied.
The Edge Transport server compares the senders email address with the list of senders configured in
sender filtering. If the SMTP address is a blocked recipient or domain, the server rejects the
connection, and no other filters are applied. Additionally, you can configure the server to accept the
message from the blocked sender, but stamp the message with the blocked sender information and
7-37
continue processing. The blocked sender information is included as one of the criteria when content
filtering processes the message.
3.
The Edge Transport server examines the recipient against the Recipient Block list configured in
recipient filtering. If Edge synchronization is enabled, the Edge Transport server can use the
information about recipient filtering from AD DS. If the intended recipient matches a filtered email
address, the Edge Transport server rejects the message for that particular recipient. If multiple
recipients are listed on the message, and some are not on the Recipient Block list, further processing
is done on the message for those recipients.
4.
Exchange Server 2010 applies Sender ID filtering. Depending on how the Sender ID is configured, the
server might delete, reject, or accept the message. If the message is rejected, the server adds the
Sender ID validation failure to the message properties. The failed Sender ID status is included as one
of the criteria when content filtering processes the message.
5.
The Edge Transport server applies content filtering and performs one of the following actions:
Content filtering compares the sender to the senders in the safelist aggregation data from
Outlook users. If the sender is on the recipients Safe Senders List, the message is sent to the
users mailbox store.
If the SCL rating is higher than one of the configured Edge Transport server thresholds, content
filtering takes the appropriate action of deleting, rejecting, or quarantining the message.
If the SCL rating is lower than one of the Edge Transport server thresholds, the message passes to
a Hub Transport server for distribution to the Exchange Mailbox server containing the users
mailbox.
What Is Sender ID Filtering?
7-38
Sender ID filteringor the Microsoft implementation of the sender policy framework (SPF)is an industry
standard that verifies the Internet domain from which each email message originates, based on the
senders server IP address. SPF provides protection against email domain spoofing and phishing schemes.
Using SPF, email senders can register all email servers that send email from their SMTP domain, and then
the email recipients can filter email from that domain that does not come from the specified servers.
SPF Records
To enable Sender ID filtering, each email sender must create an 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:
Contoso.com. IN TXT v=spf1 mx -all. This record specifies that any server that has a mail exchanger
(MX) record for the contoso.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.
Contoso.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 contoso.com domain.
For More Information 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.
Sender ID Configuration
After you configure the SPF records, any destination messaging servers that use the Sender ID features
can identify your server by using Sender ID.
7-39
After you enable Sender ID filtering, the following process describes how all email messages are filtered:
1.
The sender transmits an email message to the recipient organization. The destination mail server
receives the email.
2.
The destination server checks the domain that claims to have sent the message, and checks DNS for
that domains SPF record. The destination server determines if the IP address of the sending email
server matches any of the IP addresses that are in the SPF record. The IP address of the server
authorized to send email for that domain is called the purported responsible address (PRA).
3.
If the IP addresses match, the destination server authenticates the mail and delivers it to the
destination recipient. However, other anti-spam scannerssuch as content filteringare still applied.
4.
If the addresses do not match, the email 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.
Question: Where do you configure Sender ID for your domain?
What Is Sender Reputation Filtering?
7-40
The Exchange Server 2010 Sender Reputation feature makes message filtering decisions based on
information about recent email messages received from specific senders. The Sender Reputation agent
analyzes various statistics about the sender and the email message to create a sender reputation level
(SRL). This SRL is a number between 0 and 9, where a value of 0 indicates that there is less than a 1
percent chance that the sender is a spammer, and a value of 9 indicates that there is more than a 99
percent chance that the sender is a spammer. If a sender appears to be the spam source, then the Sender
Reputation agent automatically adds the IP address for the SMTP server that is sending the message to
the list of blocked IP addresses.
How Sender Reputation Filtering Works

When the Edge Transport server receives the first message from a specific sender, the SMTP sender is
assigned an SRL of 0. As more messages arrive from the same source, the Sender Reputation agent
evaluates the messages and begins to adjust the senders rating.
The Sender Reputation agent uses the following criteria to evaluate each sender:
Sender open proxy test. An open proxy is a proxy server that accepts connection requests from any
SMTP server, and then forwards messages as if they originated from the local host. This is known as
an open relay server. When the Sender Reputation agent calculates an SRL, it does so by formatting
an SMTP request in an attempt to connect back to the Edge Transport server from the open proxy. If
the 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 provide the receiving server with the
domain name, such as contoso.com, or the IP address of the sending SMTP server. However,
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.
7-41
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 Filtering agent processes a
message, it assigns an SCL rating to the message. This rating is attached to the message as an SCL,
which is a numerical value between 0 and 9. The Sender Reputation agent analyzes data about each
senders SCL ratings, and uses it to calculate SRL ratings. More information on SCL ratings can be
found in the next topic, What Is Content Filtering?
The Sender Reputation agent calculates the SRL for each unique sender over a specific time. When the SRL
rating exceeds the configured limit, the IP address for the sending SMTP server is added to the IP Block
list for a specific time.
Sender Reputation Configuration
You can configure the Sender Reputation settings on the Edge Transport server. Use Exchange
Management Console to configure the Sender Reputation block threshold, and configure the timeout
period for how long a sender will remain on the IP Block list. By default, the IP addresses are blocked for
24 hours.
Question: When a sender sends the first message to your Exchange Server organization,
what SRL rating will be assigned to the SMTP sender?
What Is Content Filtering?
7-42
The Content Filter agent uses SmartScreen technology to analyze the content of every email message to
evaluate whether it is spam. The Content Filter agent is similar to the Exchange Server 2003 Intelligent
Message Filter feature.
When the Edge Transport server receives a message, the Content Filtering agent evaluates the message
content for recognizable patterns, and then it assigns a rating based on the probability that the message
is spam. This rating is attached to the message as an SCL, which is a numerical value between 0 and 9 (-1
for internal messages). A rating of 0 indicates that the message is highly unlikely to be spam, whereas a
rating of 9 indicates that the message is very likely to be spam. This rating persists with the message when
it is sent to other servers running Exchange Server.
Depending on how you configure the content filter, if a message SCL score is greater than or equal to the
threshold you configure, the Content Filtering agent rejects, silently deletes, or quarantines the message.
Content Filtering Configuration

Content filtering is enabled by default on Exchange 2010 Edge Transport servers, and is configured to
reject all messages with an SCL higher than 7. You can modify the default content filtering settings by
using Exchange Management Console or Exchange Management Shell. You can modify the following
settings in Exchange Management Console:
Configure custom words. You can specify a list of key words or phrases to prevent blocking any
message containing those words. This feature is useful if your organization must receive email that
contains words that the Content Filtering agent normally would block. You can also specify key words
or phrases that will cause the Content Filtering agent to block a message containing those words.
Specify exceptions. You can configure content filtering exceptions to exclude any messages to
recipients on the exceptions list.
7-43
Specify actions. You can configure the SCL thresholds and threshold actions. You can configure the
Content Filtering agent to delete, reject, or quarantine messages with an SCL higher than the value
you specify.
Note When the Content Filtering 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 Exchange Management Shell.
Configuring the Quarantine Mailbox
When the SCL value for a specific message exceeds the SCL quarantine threshold, the Content Filtering
agent sends the message to a quarantine mailbox. Before you can configure this option on the Edge
Transport server, you must configure a mailbox as the quarantine mailbox by configuring the
quarantinemailbox parameter of the set-contentfilterconfig cmdlet. As a messaging administrator, you
should regularly check the quarantine mailbox to ensure that the content filter is not filtering legitimate
emails.
Note Messages are sent to the quarantine mailbox only when the SCL threshold exceeds
the value that you configure on the content filter. To see details on all actions that transport
agents perform on an Edge Transport server, use the scripts located in the
%programfiles%\Microsoft\Exchange Server\Scripts folder. The Get-AgentLog.ps1 script
produces a raw listing of all actions that transport agents perform. The folder contains
several other scripts that produce formatted reports listing information such as the top
blocked sender domains, the top blocked senders, and the top blocked recipients. By default,
the transport agent logs are located at
%programfiles%\Microsoft\ExchangeServer\TransportRoles\Logs\AgentLog.
The SCL Junk 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
delivers the message to the users Inbox.
Anti-Spam Updates for Content Filtering
Spam is changing continuously, so Exchange Server 2010 also includes an automatic anti-spam update
service that handles content filter updates. This service requires your transport server to have either direct
Internet access, web access using a proxy, or a Windows Update Service. Anti-spam updates can be
configured as either manual updates or automatic updates.
Manual updates only include Content Filter updates, but do not require additional licenses. Automatic
updates also include Content Filter, Spam Signature, and IPReputation updates. However, automatic
updates require an Enterprise Client Access License that needs to be purchased for every mailbox in your
organization.
Manual Content Filter updates download and install when the update is made available by Microsoft; this
normally occurs on a biweekly basis. Thus, this anti-spam protection should only be considered as basic
more suitable for small organizations.
Question: What does the Content Filtering agent do?
Demonstration: How to Configure Anti-Spam Options
7-44
In this demonstration, you will see how to configure the various anti-spam options available in Exchange
Server 2010, such as Connection filters, Sender filters, and Recipient filters. You will also see how to
configure the Sender ID, Sender Reputation, and content filtering features.
Demonstration Steps
1.
Open Exchange Management Console, and on the Edge Transport server, click the Anti-spam tab.
2.
Configure the following Connection filters:
3.
4.
IP Allow List
IP Block List
IP Block List Providers
Configure the following filtering features:
Sender filtering
Recipient filtering
Sender ID
Sender Reputation
Content filtering
Configure the Edge Transport server to quarantine messages with an SCL rating greater than 7.
Lesson 4
Configuring Secure SMTP Messaging
7-45
To configure secure SMTP messaging, you can use Transport Layer Security (TLS) in Exchange Server, or
Domain Security, which is available with Exchange Server 2007 and Exchange Server 2010. This lesson
describes how to secure SMTP messaging by using the available options.
Describe the common SMTP security issues.
Explain the concept of Domain Security.
Describe the Domain Security configuration process.
Discussion: SMTP Security Issues
7-46
Although SMTP messaging is common in many organizations, you must consider a few security issues.
Question: What are the security issues with SMTP?
Question: How do you currently secure SMTP?
What Is Domain Security?
7-47
Exchange Server 2010 can use TLS to provide security for SMTP email. In most cases, you cannot use TLS
when sending or receiving email because SMTP servers are not configured to use TLS. However, by
requiring TLS for all SMTP email sent between your organization and other specified organizations, you
can enable a high security level for SMTP email.
What Is Domain Security?
The Domain Security feature in Exchange Server 2010 and Exchange Server 2007 provides a relatively lowcost alternative to S/MIME or other message-encryption solutions. It uses mutual TLS, where each server
verifies the identity of the other server by validating the certificate that is provided by the other server. It
is an easy way for administrators to manage secured message paths between domains over the Internet.
This means that all connections between the partner organizations are authenticated, and all messages
are encrypted while in transit on the Internet.
TLS with mutual authentication differs from TLS in its usual implementation. Typically, when you
implement TLS, the client verifies a secure connection to the intended server by validating the servers
certificate, which it receives during TLS negotiation. With mutual TLS, each server verifies the connection
with the other server by validating a certificate that the other server provides.
How Domain Security Works
Domain Security works in a manner similar to establishing a TLS connection to an SMTP Receive
connector. However, as mutual TLS is used, both the sender and the receiver authenticate one another
before they send data. When using Domain Security, the message takes the following route from one
organization to the other:
1.
The Edge Transport server in the source organization receives the email message from a source Hub
Transport server.
2.
The Edge Transport server initiates a mutual TLS session to the target Edge Transport server by
exchanging and verifying certificates. The target Edge Transport server is in a different organization.
7-48
The mutual TLS session is only established when both the sending and receiving SMTP connectors can
identify the sending domain and when both certificates installed on the Edge Transport servers are
trusted.
3.
The message is encrypted and transferred to the target Edge Transport server.
4.
The target Edge Transport server delivers the email to the target Hub Transport server for local
delivery. The message is marked as Domain Secure, which is displayed in Office Outlook 2007 or
newer, and in Outlook Web App.
Question: Can you configure your Exchange Server to use Domain Security as the default for
all domains to which you want to send messages?
Process for Configuring Domain Security
To configure Domain Security, perform the following steps:
7-49
1.
On the Edge Transport server, generate a certificate request for TLS certificates. You can request the
certificate from an internal, private certification authority (CA) or from a commercial CA. The SMTP
server in the partner organization must trust the certificate. When you request the certificate, ensure
that the certificate request includes the domain name for all SMTP domains used by your
organization on the Internet, and the FQDN of the Edge Transport server name as the subject
alternative name.
2.
Import and enable the certificate on the Edge Transport server. After you request the certificate, you
must import the certificate on the Edge Transport server, and then enable the certificate for use by
the SMTP connectors that are used to send and receive domain-secured email.
3.
Configure outbound Domain Security. To configure outbound Domain Security, use Exchange
Management Shell cmdlets to specify the domains to which you will send domain-secured email, and
then configure the SMTP Send connector to use domain-secured email. You must run the following
cmdlets:
a.
b.
4.
Set-TransportConfig -TLSSendDomainSecureList <domain name>. This cmdlet specifies the

domain to which you want to send domain-secured e-mail.
Set-SendConnector <send connector name>
-domainSecureEnabled:$true. This cmdlet enables domain security for the send connector. You
can use the send connector that you use for other Internet e-mail, or you can configure a
dedicated send connector with the address space of the target domain.
Configure inbound Domain Security. To configure inbound Domain Security, use Exchange
Management Shell cmdlets to specify the domains to which you will receive domain-secured email,
and then configure the SMTP Receive connector to use domain-secured email. You must run these
cmdlets:
a.
b.
7-50
Set-TransportConfig -TLSReceiveDomainSecureList <domain name>. This cmdlet specifies

the domain from which you want to receive domain secured e-mail.
Set-ReceiveConnector <send connector name> -DomainSecureEnabled $true AuthMechanism TLS. This cmdlet enables domain security for the receive connector and
configures it to use TLS.
5.
Notify the partner organization to configure Domain Security. Domain Security must be configured
on both the sending and receiving sides. Thus, you also need to contact your partners administrator
to configure the domain for Domain Security.
6.
Test message flow. Finally, send a message to the partner and vice-versa to verify that domain
security is working correctly. You can see an extra icon in Outlook and Outlook Web App.
Note When you install the Edge Transport server role, a self-signed certificate is issued to
the server. No other computers trust this certificate. When you require that the partner
organization trust 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 import a CAs
certificate in the Trusted Root CA store on both sides.
Question: When creating a digital certificate for your Edge Transport server so that you can
use it for Domain Security, what do you need to consider?
Lab Setup
7-51
following steps:
1.
On the host computer, click Start, point to Administrative Tools, and click Hyper-V Manager.
2.
Ensure that the 10165A-NYC-DC1-B, 10165A-NYC-EX10-B, and the 10165A-NYC-SVR1-B virtual

3.
10165A-NYC-SVR1-B: Stand-alone server
Lab Scenario
You are a messaging administrator at Contoso, Ltd. Your organization has deployed Exchange Server 2010
internally. In your organization, users complain that they receive too many spam messages in their
inboxes, and they want these spam messages automatically moved to their Junk email folder. This means
that after configuring the Edge Transport server and installing an antivirus solution, you must also
implement an anti-spam solution.
Exercise 1: Configuring Anti-Spam Filtering

Scenario
7-52
To limit the number of spam messages received by your organization, you need to increase the SCL junk
threshold value for the organization, and ensure that junk email above a certain rating is rejected. You
also want to configure a block list provider.
1.
Configure DNS for Sender ID filtering.
2.
Configure and verify global SCL for junk mail delivery.
3.
Configure and verify content filtering to reject junk messages.
4.
Configure and verify an IP Allow list.
5.
Configure a block list provider.
Task 1: Configure DNS for Sender ID filtering

1.
On NYC-DC1, open DNS Manager.
2.
For contoso.com, create a Text (.txt) record with the following: v=spf1 mx -all.
Task 2: Configure and verify global SCL for junk mail delivery
1.
On NYC-SVR1, in Exchange Management Console, clear the Reject messages that have a SCL rating
greater than or equal to check box in Content Filtering.
2.
On NYC-EX10, open the Exchange Management Shell, and type Set-OrganizationConfig SCLJunkThreshold 6.
3.
In Exchange Management Shell, run D:\labfiles\Lab7ex3.ps1. This will send 11 messages with
different SCL ratings to NYC-SVR1, addressed to Christine.
4.
Open Outlook Web App, and on NYC-EX10, log on as Contoso\Christine, with the password,
Pa$$w0rd.
5.
You should see three new messages in the Inbox. If not, wait for another minute until they arrive.
Open one messages Message details window, and identify the SCL level of this message by looking
for X-MS-Exchange-Organization-SCL in the Internet Mail Headers box.
6.
Verify that the rest of the messages are in the Junk E-Mail folder. Delete all messages in the Inbox
and Junk E-Mail folders.
Task 3: Configure and verify content filtering to reject junk messages

1.
On NYC-SVR1, in Exchange Management Console, select the Reject messages that have a SCL
rating greater than or equal to check box in Content Filtering, and then configure the rating to 7.
2.
On NYC-EX10, in Exchange Management Shell, run D:\labfiles\Lab7ex3.ps1.
3.
Open Outlook Web App on NYC-EX10, and then log on as Contoso\Christine, with the password,
Pa$$w0rd. Notice that all messages with an SCL level of 7 or above are rejected as spam by the
Content Filtering agent.
4.
In Outlook Web App, log on as Christine, and delete all messages in the Inbox.
7-53
Task 4: Configure and verify an IP Allow list
1.
On NYC-SVR1, in the Exchange Management Console, configure an IP Allow List for 10.10.0.20.
2.
On NYC-EX10, in Exchange Management Shell, run D:\labfiles\Lab7ex3.ps1.
3.
Open Outlook Web App on NYC-EX10, and then log on as Contoso\Christine, with the password,
Pa$$w0rd.
4.
You should see 11 new messages in the Inbox. Double-click a message, and review the Message
Detail. The SCL rating should be -1. When the sending SMTP server is added to the IP Allow List,
content filtering is not applied to the messages. Delete all messages in the Inbox.
Task 5: Configure a block list provider
On NYC-SVR1, in Exchange Management Console, configure an IP Block List Provider with the
following settings:
Provider: Spamhaus
Lookup domain: zen.spamhaus.org
Results: After this exercise, you should have configured a Sender ID for contoso.com, and configured and
tested a global SCL junk mail delivery. You will also have configured and tested content filtering to reject
spam messages. Finally, you will have configured and tested an IP allow list, and configured a block list
provider.
Exercise 2: Configuring Secure SMTP Messaging

Scenario
7-54
Together with your partner organization, you want to configure the Domain Security feature to ensure
that all messages transferred between your organization and the partner organization are encrypted and
verified.
1.
Verify the certificate, and check the Receive connector.
2.
Configure Domain Security.
Task 1: Verify the certificate, and check the Receive connector

1.
On NYC-SVR1, add the Certificates snap-in to the MMC console and verify the computer certificate in
the certificate store. You should find a self-signed certificate from when the Edge Transport server
role was installed.
Note In a production environment, to enable Domain Security, you would need to obtain a
certificate from a public CA, or exchange root certificates with other organizations.
2.
Enable Domain Security on Default internal receive connector NYC-SVR1.
3.
On the Authentication tab, verify that both the Transport Layer Security (TLS) and Enable
Domain Security (Mutual Auth TLS) check boxes are selected.
Task 2: Configure Domain Security

Note In this lab, we only configure Domain Security so you understand the steps required.
The lab is not built to verify Domain Security, because the target messaging organization is
not configured. You would also need to perform these steps on the partners side for Domain
Security to work correctly.
1.
On NYC-EX10, in Exchange Management Console, configure the EdgeSync - Default-First-SiteName to Internet Send connector to use MX records to route mail automatically.
2.
On the Network tab, click Enable Domain Security (Mutual Auth TLS).
3.
In Exchange Management Shell, run the following cmdlets to configure the Domain Security
partnership.
Set-TransportConfig -TLSSendDomainSecureList adatum.com
Set-TransportConfig -TLSReceiveDomainSecureList adatum.com
Get-TransportConfig |FL
4.
7-55
Run Start-EdgeSynchronization to synchronize the changes immediately to the Edge Transport

server.
Results: After this exercise, you should have viewed the Exchange Servers computer certificate, checked
the Receive connector to ensure Domain Security is enabled, configured the Send Connector, and added
the domain adatum.com to the Domain Secure list.

following steps:
1.
2.
3.
4.
machine
5.
machine.
6.
machine.
7.
Wait for 10165A-NYC-EX11-B to start. Connect to the virtual machine.
Review Questions
1.
Is Edge synchronization a mandatory requirement?
2.
Which Exchange Server versions support the Domain Security feature?
3.
Does the Edge Transport server role in Exchange Server 2010 include virus-scanning capabilities?
Common Issues Related to Edge Synchronization and Domain Security
7-56
Identify the causes for the following common issues related to implementing messaging security, and fill
Issue
You configured Domain Security
with a partner domain, but
messages only use TLS for
message encryption, not mutual
TLS or Domain Security.
Edge synchronization is not
working anymore.
You are logged on to your
Windows Server 2008 computer
using your own account. When
you run TestEdgeSynchronization, it indicates
that the connection is broken.
Troubleshooting tip
Best Practices Related to Implementing Message Security

7-57
If you have a smart host available that is servicing messages to and from the Internet, you do not
need to consider Edge Transport servers for your organization.
Always implement at least one antivirus solution in your Exchange Server organization.
Domain Security can only be configured between Exchange Server 2007 or Exchange Server 2010
organizations if they do not have a smart host in between. Thus, you should talk to your partner
organization and ask if they use Edge Transport servers before you can implement Domain Security.
7-58
8-1
Module 8
Implementing High Availability
Contents:
Lesson 1: Configuring Highly Available Mailbox Databases
8-3
Lesson 2: Deploying Highly Available Non-Mailbox Servers
8-21
Lesson 3: Deploying High Availability with Site Resilience
8-29
8-40
8-2
Module Overview
Messaging systems are a critical business tool in most organizations. Outages of even a few hours reflect
poorly upon the IT departments, and can result in lost sales or loss of business reputation. High availability
ensures that messaging systems built on Microsoft Exchange Server 2010including those that are
coexisting with Exchange Server 2003 or Exchange Server 2007can survive the failure of a single server,
or even multiple servers. You can implement high availability for all the server roles in Exchange Server
2010.
Configure highly available mailbox databases.
Deploy highly available non-Mailbox servers.
Deploy high availability with site resilience.
8-3
Lesson 1
Configuring Highly Available Mailbox Databases
You can implement high availability for mailbox databases by using a database availability group (DAG).
DAG is a new feature in Exchange Server 2010, and therefore a new concept for both Exchange Server
2003 and Exchange Server 2007 administrators.
When you implement a DAG, there are unique considerations that you must take into account. Proper
design for a DAG ensures sufficient performance and redundancy. A poorly designed DAG may not
provide any redundancy for mailbox databases, or may experience performance issues when one or more
Mailbox server fails.
Describe database availability groups.
Describe quorum.
Describe Active Manager.
Describe continuous replication.
Describe how DAGs protect databases.
Identify the differences between Exchange Server 2010 and Exchange Server 2007 mailbox high
availability options.
Explain how to create a DAG and configure a highly available database.
Describe the transport dumpster.
Describe the switchover and failover process.
Design database copies and continuous replication.
Monitor and manage a DAG.
8-4
What Is a Database Availability Group?
A DAG is a collection of servers that provides the infrastructure for replicating and activating database
copies. The DAG uses continuous replication to each of the passive database copies within the DAG,
which:
Requires the Windows Server 2008 failover clustering feature, although all installation and
configuration tasks occur with the Exchange Server 2010 management tools. Although a DAG
requires the failover clustering feature, Exchange Server 2010 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 failure detection scenarios such as a server failure.
Uses an improved version of the continuous replication technology that was introduced in 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 can also use third-party replication instead of continuous replication.
Allows you to add and remove Mailbox servers at any time. You do not need to decide on the DAG
membership during installation. Because DAGs use the failover clustering feature, Exchange Server
2010 must be installed on Windows Server 2008 or Windows Server 2008 R2 Enterprise Edition or
Data Center Edition.
Allows you to move a single database between servers in the DAG without affecting other databases.
Allows up to 16 copies of a single database on separate servers. You can add up to 16 servers to a
DAG, which allows you to create up to 16 copies of a database. The database copies must be stored in
the same path on all servers. For example, if you store Mailbox Database 1 in D:\Mailbox\DB\Mailbox
Database 1\ on NYC-EX10, then you must also store it in D:\Mailbox\DB\Mailbox Database 1\ on all
other servers that host Mailbox Database 1 copies.
8-5
Defines the boundary for replication, because only servers within the DAG can host database copies.
You cannot replicate database information to Mailbox servers outside the DAG.
You cannot add an Exchange Server 2003 or Exchange Server 2007 databases to an Exchange Server
2010 DAG.
Question: During installation, do you need to decide if you want to join a server to a DAG?
8-6
What Is Quorum?
The failover cluster quorum configuration as used by the Exchange Server 2010 database availability
group determines the number of failed nodes or failed storage and network components that the cluster
can sustain while continuing to function. Quorum prevents two sets of nodes from operating
simultaneously as the failover cluster. Simultaneous operation could happen when network problems
prevent one set of nodes from communicating with another set of nodes. Without a quorum mechanism,
each set of nodes could continue to operate as a failover cluster, resulting in a partition within the cluster.
To prevent problems caused by a split in the cluster, failover clusters use a voting algorithm to determine
whether the cluster has enough votes to maintain quorum. Because a given cluster has a specific set of
nodes and a specific quorum configuration, the cluster will know how many votes are required. If the
number of votes drops below the majority, the cluster cannot start. Nodes will still listen for the presence
of other nodes, in case another node appears again on the network, but the nodes will not function as a
cluster until a consensus is reached.
For example, if there are five votes in the cluster, the cluster continues to function as long as there are at
least three available votes. The source of the votes in Exchange Server 2010 can be a node or a witness file
share. When a majority of votes is not available, including when half the votes are available, the cluster
will not start.
Windows Server 2008 Quorum Options

The following table lists the quorum options in Windows Server 2008:
Quorum Mode
Description
Node Majority
Only nodes in the

cluster have a vote
Quorum is maintained
when more than half
the nodes are online
Supported and recommended

because the node and disk
majority, and node and file
majority, provide an additional
vote to enable maintaining
quorum if half the nodes fail
Not supported
8-7
Node and File

Share Majority
The nodes in the

cluster and a witness
file share have a vote
when more than half
the votes are online

for cluster continuous
replication (CCR)
Supported
Node and Disk

Majority
The nodes in the

cluster and a witness
disk have a vote
when more than half
the votes are online

for single copy clusters (SCCs)
Not supported
No Majority:
Disk Only
Only the quorum

shared disk has a vote
when the shared disk
is online
Supported but not

Not supported
recommended for SCC because
the quorum shared disk is a
single point of failure
Question: Your DAG has two Mailbox servers (nodes) and one witness server. When will you
lose quorum and not be able to mount the databases automatically anymore?
8-8
What Is Active Manager?
To manage mailbox database replication and activation, Exchange Server 2010 includes a new component
called Active Manager, which runs as a function of the Microsoft Exchange Replication service
(MSExchangeRepl.exe). Active Manager replaces the resource model and failover management features
integrated into Windows failover clustering, and used in Exchange Server 2003 and Exchange Server 2007.
To simplify the architecture, Active Manager runs on all Mailbox servers, even if the server is not part of a
DAG.
Active Manager runs on all of the DAG members and runs as either the primary Active Manager (PAM) or
a standby Active Manager (SAM). The PAM is the Active Manager in a DAG that controls which copies will
be active and which will be passive. It is responsible for processing topology change notifications, and
reacting to server failures. The DAG member acting as the PAM is always the member that currently owns
the default cluster group. To identify the PAM, we recommend using the GetDatabaseAvailabilityGroup <DAG Name> -Status | Format-List Name, PrimaryActiveManager
cmdlet, rather than using the Windows Failover Clustering tools. If the server that owns the default cluster
group fails, the PAM function automatically moves to the server that takes ownership of the default
cluster group.
Far from having a passive role, the SAM function provides information about which server hosts the active
copy of a mailbox database. The SAM detects local database and Microsoft Exchange Information Store
failures, and reacts to them by requesting that the PAM initiate a failover when a copy is available. A SAM
does not determine a failover target, nor does it update a databases location state for the PAM. Each
SAM accesses the state of the active database copy so that it can redirect Hub Transport and Client Access
server requests. The PAM also performs the functions of the SAM role on the local system.
Question: On what Exchange servers does Active Manager run?
What Is Continuous Replication?
8-9
Continuous replication was introduced for Mailbox servers in Exchange Server 2007. Exchange Server 2010
continued to use continuous replication. Exchange Server 2010 Service Pack 1 (SP1) provides two options
for continuous replication continuous replication, file mode and continuous replication block mode.
Continuous ReplicationFile Mode
Continuous replication creates a passive database copy on another Exchange Server computer in the DAG,
and then uses asynchronous log shipping to maintain the copies.
The continuous replicationfile mode, or log shipping process, is as follows:
1.
The Mailbox server role with the active database writes the active log, and then closes it.
2.
The Replication Service replicates the closed log to servers hosting the passive databases.
3.
Since 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 2007, the replay functionality was performed by the Microsoft Exchange Replication
service. This functionality is now performed by the Microsoft Exchange Information Store service.
Replaying the log files to the passive database takes place continuously, which results in a database cache
called a warm state. In Exchange Server 2007, when the passive copy is activated, the database cache that
was built by the Microsoft Exchange Replication service as a result of replay activity is lost when the
Microsoft Exchange Information Store service mounts the database. This behavior places the database
cache in a cold state. The improvement in Exchange Server 2010 continuous replication means that read
input/output (I/O) operations during database activation are significantly reduced.
Additionally, seeding no longer requires you to use the active copy as the source for the seed. In
Exchange Server 2010, you also can perform seeding from passive databases. If a healthy copy of the
database is available on any server, the Exchange Server can replay the transaction logs against a
common, valid data set.
8-10
You can seed the data:
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, as opposed to using the Exchange Server 2007 file-share
method. Continuous replication occurs as follows:
1.
The targetor passive nodetells the active instance which transaction logs it expects.
2.
The source responds with the required transaction log files.
3.
After Exchange Server 2010 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 2010 places it in the target log directory. If the log does not pass
inspection, Exchange Server 2010 requests it from the source up to three times before failing.
5.
Once Exchange Server 2010 saves the transaction log to the target log directory, the information
store validates the logs to ensure that they are valid, that none are missing, and that the database
requires them.
Continuous ReplicationBlock Mode
Continuous replicationblock mode reduces the exposure of data loss on failover by replicating Extensible
Storage Engine (ESE) log buffer writes to the passive database copies in parallel to writing them locally.
Block mode automatically becomes active when continuous replication file mode is up to date with the
database copies. The continuous replication block mode process is as follows:
1.
Once in block mode, any block of data written to the ESE log buffer on the Exchange server that hosts
the active database is automatically copied to the replication log buffer all passive copies of the active
database s.
2.
When the ESE log buffer is full, the final block is sent to the passive databases, and a transactional log
file is written to the Exchange server that hosts the active database. Then the ESE log buffer is
emptied.
3.
When the Exchange servers hosting the passive databases receive the final block that fills up their
replication log buffer, they also save the buffer to a transaction log file with the same log generation
sequence number. After that, the buffer is emptied and the process starts again.
4.
When the Exchange server with the active database fails, but the replication log buffer is not yet full,
then the buffer on the server hosting the passive copy of the database is saved to a new transactional
log file.
Replication transport is the same when file mode is enabled or disabled. The benefit of block mode is that
it can reduce the differences between the active copy and the passive copy, while also reducing the
possibility of data loss during a failover and the time it takes to perform a switchover.
8-11
How Databases Are Protected in a DAG
The active database copy uses continuous replication to keep the passive copies synchronized based on
their replay lag-time setting. A DAG requires the Windows Server operating system failover clustering
feature to manage quorum and to manage server failover. However, it relies on the Active Manager server
to maintain the status of all of the DAGs hosted databases. Database characteristics are:
A single database can failover or switchover between DAG servers. However, it is only active on one
server at a time.
At any given time, a copy is either the replication source or the replication target, but not both.
A server may not host more than one copy of a given database.
Not all databases need to have the same number of copies. In a 16-node DAG, one database can
have 16 copies, while another database is not redundant and contains only one active copy.
Database failovers occur when failures cause the active database to go offline. Either a single server failure
or a database failure may cause the failure. A switchover occurs when an administrator intentionally
moves the active database from one server to another.
Question: Can you have one database copied three times, and another database copied only
one time?
8-12
Comparing Exchange Server 2010 to Exchange Server 2007 Mailbox High

Availability Options
Exchange Server 2010 extends and improves upon the continuous replication technology that was
introduced in Exchange Server 2007. The new high availability model that uses the DAG is a more flexible
and resilient solution than previous high availability solutions.
The Exchange Server 2010 database high availability model:
Enables deployments that have no single point of failure.
Supports backups.
Allows up to 16 copies of a database in a DAG. Individual databases can be configured with up to a

14-day log replay lag time.
Can have multiple servers roles run on the same server as the Mailbox server.
Allows you to move a single database between servers.

Question: How has mailbox high availability improved since Exchange Server 2007?
8-13
Demonstration: Creating a DAG and Configuring Highly Available

Databases
In this demonstration, you will review how to create a new DAG, add member servers to it, and create a
copy of a mailbox database.
Demonstration Steps
1.
Management Shell.
2.
Use the New-DatabaseAvailabilityGroup cmdlet to create a database availability group named

DAG1 with a WitnessServer on NYC-DC1, and a WitnessDirectory of C:\FSWDAG1. Assign the
DAG an IP Address of 10.10.0.99.
3.
Use the Add-DatabaseAvailabilityGroupServer cmdlet to add NYC-EX10 as a member.
4.
Click Start, click Programs, click Microsoft Exchange Server 2010, and then click Exchange
Management Console.
5.
Use the Manage Database Availability Group Membership Wizard to add

NYC-EX11 as a member of DAG1.
6.
Use the Add Mailbox Database Copy Wizard to add a copy of Mailbox Database 1 to NYC-EX11.
Note When you create a DAG, all available networks on the DAG member servers are
enumerated and added to the DAG as DAG networks. After you create a DAG, you then can
configure DAG networks for replication or for messaging application programming interface
(MAPI) traffic. You can add multiple replication networks for redundancy or improved
throughput, but can implement only one MAPI network.
8-14
What Is the Transport Dumpster?
When a database failover occurs and some transaction logs have not replicated to the passive copy, the
transport dumpster is used to redeliver any recently delivered email. The transport dumpster is a
temporary queue located on all Hub Transport servers, and it stores messages that have been delivered to
Mailbox servers in the Active Directory Domain Services (AD DS) site. If a database failure occurs, a
request is made to the Hub Transport servers to redeliver any lost email messages.
The transport dumpster only retains email that has already been delivered. The local submission queue
withholds any pending outgoing email. After the transaction logs containing the email message are
replicated to and inspected by each DAG member with a copy of the database, the Hub Transport server
purges the message from the dumpster.
The transport dumpster is enabled by default. You can configure the transport dumpster by using the
Get-TransportConfig cmdlet using the following two properties:
MaxDumpsterSizePerDatabase. This setting defines the maximum size of the transport dumpster
queue per database, and is set globally for the entire Exchange Server organization. The
recommended size is 1.5 times the maximum message size that can be sent. For example, if the
maximum size for messages is 20 megabytes (MB), this parameter should be set to 30 MB.
MaxDumpsterTime. This is the time for which the transport dumpster retains a message if the
message is not purged for exceeding the maximum dumpster size. The default is set to seven days.
You can also modify the transport dumpster settings by accessing the Hub Transport server settings in the
Organization Configuration node, and then modifying the Transport Settings located on the Global
Settings tab.
If you implement a multisite DAG, the mailbox database can be mounted in more than one Active
Directory site. If a database fails over to a second Active Directory site, Mailbox servers request re-delivery
of messages from Hub Transport servers in both the databases original and new Active Directory sites.
Understanding the Switchover and Failover Process
8-15
A failover occurs when service to the existing active database copy is compromised in some way. This can
occur when the server hosting the active database goes offline, when something causes the active
database to dismount, or when the server loses network connectivity. A switchover occurs when an
administrator manually moves the active database from one server to another. The main difference
between the failover process and the switchover process is that the failover process occurs automatically
when the service fails, while the switchover is a manual process. During a switchover, you can choose
which database will be mounted, or let Active Manager choose the best copy to mount. During a failover,
the Active Manager makes this decision.
When a failure affecting the active database occurs, Active Manager uses several sets of selection criteria
to determine which database copy to activate. In the process for selecting the best copy to activate, Active
Manager:
1.
Creates a list of database copies that are potential candidates for activation.
2.
Ignores and removes from the list any database copies that are unreachable or are administratively
blocked from activation.
3.
Sorts the resulting list by using the copy queue length as the primary key. In Exchange Server
2010 SP1, if the servers are configured with an automatic database mount dial value of Lossless,
Active Manager sorts the resulting list in ascending order by using the value for ActivationPreference
as the primary key.
4.
Attempts to locate a mailbox database copy on the list that has a status of Healthy,
DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource, and then evaluates
the activation potential of each of the copies on the list by using an order set of ten criteria. These
criteria include various combinations of settings such as content indexing status, copy queue length,
and replay queue length.
8-16
Database Failovers
When a highly available mailbox database failure occurs, the PAM attempts to perform a failover of the
database. Before attempting to select a suitable copy to activate, the attempt copy last logs (ACLLs)
process occurs. ACLL makes remote procedure calls (RPCs) to the server that hosted the active copy of the
mailbox database that is being activated. The RPCs request confirmation that the servers are available and
healthy, and they determine the LogInspectorGeneration value for the database copy. The last active
mailbox database copy is used to copy any missing log files to the copy selected by Active Manager for
activation.
After the ACLL process completes, the configured AutoDatabaseMountDial value is consulted. The
AutoDatabaseMountDial value has the following three potential settings:
BestAvailability. This value allows the database to be automatically mounted if the copy queue length
is less than or equal to 12. The copy queue length is the number of logs that have not been replicated
to the target Mailbox server. When Active Manager identifies the target server, Exchange Server 2010
attempts to replicate the remaining logs to the passive copies and mount the database. This is the
default value.
GoodAvailability. This value allows the database to be automatically mounted immediately after a
failover if the copy queue length is less than or equal to six. When Active Manager identifies the
target server, Exchange Server 2010 attempts to replicate the remaining logs to the passive copy and
mount the database.
Lossless. This value does not allow a database to mount automatically until all logs generated on the
active copy have been copied to the passive copy.
If the number of lost logs is within the configured AutoDatabaseMountDial value, Active Manager issues a
mount request to the store. If the number of lost logs falls outside the configured
AutoDatabaseMountDial value, Exchange Server 2010 evaluates the next mailbox database copy in the
sorted list and repeats the evaluation. If no databases meet the configured AutoDatabaseMountDial
setting, an administrator must manually mount the database and accept that the loss of data is larger
than the AutoDatabaseMountDial setting. You use the Set-MailboxServer cmdlet to configure the
AutoDatabaseMountDial setting for each DAG node.
It may seem counterintuitive to list the Best Availability as allowing for 12 missing transaction logs, and
Good Availability as only allowing 6. In this case, availability refers to the database being mounted and
available, not to the possibility of lost data. In most cases, data loss is less acceptable than the loss of
service. You must decide whether to keep the database available by allowing it to mount despite potential
data loss, or to leave it unavailable and wait for manual recovery of missing log files.
In Exchange Server 2010 SP1, 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, which is the default behavior in Exchange Server 2010.
Question: Suppose you want to ensure that databases are not mounted if any transaction
logs have not been replicated. What AutoDatabaseMountDial setting do you need to
configure?
Designing Database Copies and Continuous Replication
8-17
When planning for database copies and continuous replication, you need to consider several areas to
ensure a design that works for your organization.
Database Copies
First, you need to consider how many database copies are required. You need to evaluate factors such as
storage requirements, potential failure scenarios, and availability requirements when planning the
database copies. More databases increase redundancy, but it also increases the processing and storage
load on the DAG members.
As a best practice rule, if you decide that you need at least three copies of a database, then you can
consider deploying the databases on just a bunch of disks (JBOD) hard disks. In this configuration, the
number of database copies provides redundancy so that it is not required at the storage level. If you are
deploying only two database copies, you should configure your hard disk subsystem to use a redundant
array of independent disks (RAID) system to provide a higher level of storage level redundancy.
Replay Lag
You can configure a replay lag for passive copies of a database. This prevents shipped transaction logs
from being replayed on passive database copies for a specific timeframe.
The main purpose of configuring a replay lag is to provide a good copy of a database if there is logical
corruption of the active database. You need to consider how long this replay lag should be. It needs to be
long enough for you to identify the error and prevent the bad data from being replayed on the passive
copy. The replay lag is set for each database copy.
Using three database copies provides fast recovery from database failure. One copy is active, and a second
copy is passive with no replay lag. In case of a disk failure or server failure, you can configure the second
copy to activate automatically. The third copy is passive with a replay lag, and is used to recover from
logical corruption of the active database. If a logical corruption occurs, the first two copies are corrupted,
but the third copy is not corrupted due to the replay lag.
8-18
Log Truncation
Typically, database logs are truncated when you perform a backup. However, with multiple database
copies, only one database is backed up. Therefore, you must determine how long other database copies
should retain logs before they are truncated. In general, you should retain transaction logs until you are
sure they have been backed up. You can configure one database copy to retain transaction logs for a
longer period of time than the other so that you can recover from log loss on the active copy of the
database.
If your organization uses Native Data Protection and is not backing up the Exchange servers, you need to
configure circular logging for the databases on the server.
Site Resilience
A DAG can include members on multiple AD DS subnets, and in multiple physical locations. This makes it
possible to provide site resilience by placing DAG members in two separate data centers in two separate
locations.
Note Site resilience is discussed in Lesson 3: Deploying High Availability with Site
Resilience.
Question: How long should the transaction logs for a database copy remain on a server?
Designing Monitoring and Management for a DAG
8-19
In larger organizations, DAG management is likely to be restricted to a relatively small group of

administrators. This group understands all of the design parameters that need to be considered when
creating and managing DAGs and database copies. You can delegate these permissions using role based
access control (RBAC).
To create and manage DAGs, you must be part of either the Organization Management role group, or the
Database Availability Groups management role. To create and manage database copies, you must be part
of either the Organization Management role group, or the Database Copies management role.
Monitoring
One of the unique challenges when managing DAGs is that in a well-designed system, you may not notice
the failover of a database from one DAG member to another. One way you can monitor DAG members is
by using Microsoft System Center Operations Manager 2007. System Center Operations Manager 2007
proactively monitors servers, and can notify administrators when errors and events occur.
Exchange Server 2010 SP1 provides the following options for monitoring DAG status:
CheckDatabaseRedundancy.ps1. This script checks the redundancy of replicated databases, and it

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

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

server. This script moves all active databases including the PAM role to a different server and blocks
the server from receive any database activations requests.
StopDagServerMaintenance.ps1. Use this script if you want take the DAG member server out of
maintenance mode. This script removes all blocks from a server and enables databases to be activated
on the server.
Note For examples on how to use the monitoring tools included in Exchange Server 2010,
see Monitoring High Availability and Site Resilience at
Question: Which users in your organization will have permission to manage DAGs?
Lesson 2
Deploying Highly Available Non-Mailbox Servers
8-21
High availability for non-Mailbox servers varies depending on the server role. As with Exchange 2007,
each server role has a unique method for providing high availability. To enable redundant message
routing between Exchange servers, Hub Transport servers require no configuration other than the
addition of a second Hub Transport server. Client Access servers require you to create a client access array
and to configure some type of load balancing. Edge Transport servers require the proper configuration of
mail exchanger (MX) records in Domain Name System (DNS).
Describe how high availability works for Client Access servers.
Describe how shadow redundancy provides high availability for Hub Transport servers.
Describe how high availability works for Edge Transport servers.
Explain how to design high availability for servers with multiple roles.
8-22
How High Availability Works for Client Access Servers
A client access array is a load-balanced collection of Client Access servers that is in a single site. Because
all MAPI clients now rely on connections to Client Access servers, it is important to provide a redundant
server array to improve availability.
To enable high availability for Client Access servers, you first must deploy multiple Client Access servers.
Next, you need to configure either hardware-based network load balancing (NLB) or software-based NLB
(such as the Windows Server 2008 network load balancing feature). You can also create multiple A records
in DNS for your Client Access servers and configure round-robin DNS. Round-robin DNS enables you to
distribute network connections across the different Client Access servers, but it does not provide load
balancing or automatic failover.
Then, add the name for the load-balanced array to the DNS. For example, you could add an A record for
casarray.contoso.com that points to 10.10.10.25. After adding the DNS record, you can create the client
access array, and then assign it to an Active Directory site using the New-ClientAccessArray cmdlet.
Additionally, you must do the following:
Use the Set-MailboxDatabase cmdlet to assign the name of the client access array name to the
RpcClientAccess parameter for each mailbox database.
Use the Set-ClientAccessServer cmdlet to assign the name of the client access array name to the
AutoDiscoverServiceInternalUri parameter on each Client Access server that is part of the client
access array.
Use the Set-WebServicesVirtualDirectory -Identity EWS* cmdlet with the InternalUrl parameter
on each Client Access server that is part of the client access array.
Change the InternalURI in the Exchange Control Panel, offline address book, and Microsoft Exchange
ActiveSync. Do this in the Exchange Management Console, under Server Management, for each
Client Access server that is part of the client access array.
8-23
If Macintosh computer clients exist, configure Kerberos authentication for Client Access server NLBs.
A client access array can exist only in one Active Directory site. Therefore, you need to create a client
access array in each Active Directory site that needs to load-balance Client Access servers.
8-24
How Shadow Redundancy Provides High Availability for Hub Transport

Servers
Exchange Server 2010 includes the new shadow redundancy feature, which provides redundancy for
messages during the entire time they are in transit. This message redundancy is in addition to the
transport dumpster. With shadow redundancy, message deletion from the transport queue is delayed
until the transport server verifies that all of the next hops for that message have completed delivery. If any
of the next hops fail before reporting successful delivery, the transport server resubmits the message for
delivery to that next hop. If the next-hop server does not support shadow redundancywhich is the case
for Exchange 2003 servers and Exchange 2007 serversthe message is sent to the next hop and a shadow
copy of the message is not retained.
Shadow redundancy provides the following benefits:
It reduces the reliance on the state of the transport server queues. If redundant message paths exist
and a transport server fails, you can simply remove it from production without worrying about
emptying its queues or losing messages currently in transit.
It allows the transport server to be taken offline for maintenance tasks, without the risk of losing
messages in transit.
It reduces the need for hardware redundancy for transport servers for messages in transit.
It consumes less bandwidth than other forms of redundancy that create duplicate copies of messages
on multiple servers. With shadow redundancy, the only added network traffic is the discard status
being communicated between transport servers.
It provides resilience and simplifies recovery from a transport server failure because messages still in
transit within the Exchange Server 2010 organization are protected by the previous Exchange 2010
transport server.
8-25
Note The messages in the transport dumpster are also stored in the transport server queue.
In the event of a Hub Transport server failure, these messages are not protected by the
shadow redundancy feature.
Exchange Server 2010 implements shadow redundancy by extending the Siimple Mail Transfer Protocol
(SMTP). These service extensions allow SMTP hosts to negotiate shadow redundancy support, and
communicate the discard status for shadowed messages.
Shadow redundancy message flow follows these stages, where Hub is a Hub Transport server and Edge
is an Edge Transport server.
1.
Hub delivers message to Edge.

a.
b.
c.
d.
e.
f.
2.
Edge delivers message to the next hop:

a.
b.
c.
3.
Edge submits message to third-party mail server.

Third-party mail server acknowledges the messages receipt.
Edge updates the discard status for the message as delivery complete.
Hub queries Edge for discard status (success case):

a.
b.
c.
4.
Hub opens SMTP session with Edge.

Edge advertises shadow redundancy support.
Hub notifies Edge to track discard status.
Hub submits message to Edge.
Edge acknowledges the receipt of message, and records the Hubs name for sending discard
information for the message.
Hub moves the message to the shadow queue for Edge, and marks Edge as the primary server.
Hub becomes the shadow server.
At end of each SMTP session with Edge, Hub queries Edge for discard status on messages
previously submitted. If Hub has not opened any SMTP sessions with Edge after the initial
message submission, it will open an SMTP session with Edge to query for discard status after a
specific time.
Edge checks local discard status and sends back the list of messages that have been delivered,
and removes the discard information.
Hub server deletes the list of messages from its shadow queue.
Hub queries Edge for discard status and resubmits the message (failure case):
a.
b.
If Hub cannot contact Edge, Hub resumes the primary server role and resubmits the messages in
the shadow queue.
Resubmitted messages are delivered to another Edge server, and the workflow starts from step 1.
Within Exchange Server 2010, the Shadow Redundancy Manager is the core component of a transport
server that is responsible for managing shadow redundancy. The Shadow Redundancy Manager is
responsible for maintaining the following information for all the primary messages that a server is
currently processing:
The shadow server for each primary message being processed.
The discard status to be sent to shadow servers.
For all the shadow messages that a server has in its shadow queues, the Shadow Redundancy Manager is
responsible for the following:
8-26
Maintaining the queue, and checking primary server availability for each shadow message.
Processing discard notifications from primary servers.
Removing the shadow messages from the database once it receives all expected discard notifications.
Deciding when the shadow server should take ownership of shadow messages, thus making it the
primary server.
In addition to the shadow redundancy implemented at the SMTP protocol level, shadow redundancy also
enables the following features:
Delayed acknowledgement. Exchange 2010 transport servers use delay acknowledgement when
receiving messages from SMTP servers other than Exchange 2010 servers. In this case, the transport
server delays acknowledging a received message until it verifies that the message was successfully
delivered to the next hop. This way, if the Exchange 2010 server fails, the sending mail server will
assume that the message was never delivered and will attempt delivery again.
Shadow redundancy promotion. With Exchange Server 2010 SP1, shadow redundancy promotion
provides an additional level of protection when receiving messages from a non-Exchange 2010 SMTP
server. Rather than just sending a delayed acknowledgement when the next hop cannot be verified,
the transport servers now forward the message to another Hub Transport server so that the message
is protected by shadow redundancy.
How High Availability Works for Edge Transport Servers
8-27
Failure of an Edge Transport server can prevent an organization from receiving new Internet messages. It
can also prevent Exchange Server 2010 users from sending messages to Internet recipients. In many cases,
an interruption in Internet mail is considered a critical business event.
To make the Edge Transport server role highly available, you can install a second Edge Transport server.
For message delivery to the Internet, no additional configuration is required if you configured Edge
Synchronization. For message reception, you must configure an additional MX record for the second Edge
Transport server. If both MX records have the same priority, then incoming messages are distributed
between the two Edge Transport servers.
To provide network redundancy for message delivery to the Internet, you can use two Internet service
providers (ISPs). To receive messages on the second Internet connection, you must create additional MX
records.
If your Exchange Server organization has multiple points of contact with the Internet, and multiple
locations with Edge Transport servers, this does not provide redundancy for outgoing messages. Messages
are delivered only on the lowest-cost path. If the Edge Transport servers on the lowest-cost path are
unavailable, the messages are queued on a Hub Transport server for delivery to the Edge Transport server.
Routing paths are not recalculated based on availability.
Question: Is high availability for Edge Transport servers important for your organization?
8-28
Designing High Availability for Servers with Multiple Roles
Exchange Server 2010 allows you to combine multiple server roles on a single Exchange server. For
example, a small company or a branch office may have only a single Exchange server that performs the
Mailbox, Client Access, and Hub Transport server roles. Even in larger organizations, it is common to
combine the Client Access and Hub Transport server roles on a single Exchange server.
When combined on a single server, you can enable the high availability methods used for the different
server roles. An Exchange server with multiple server roles can be a member of a DAG, or a client access
array.
However, if you are using a DAG, the Mailbox server that is a DAG member cannot also be a member of a
Windows network load balancing cluster. If you want to combine Mailbox and Client Access server roles
on the same server, you need to use hardware-based load balancing or a software-based network load
balancing solution other than Windows network load balancing to make the Client Access server highly
available.
You need to consider the design details for each server role as already described in this module.
Additionally, when combining roles on a single server, you must consider server capacity.
Capacity Planning
When planning capacity and optimizing performance, you need to consider not only the roles that are
running on the server now, but the additional load that will be placed on the server when another server
fails. For example, a single server that is a member of a DAG and in a client access array will experience a
load increase if another server in the DAG or another server in the client access array fails. This makes
performance planning more complex.
Question: Do you expect to have servers with multiple roles?
Lesson 3:
Deploying High Availability with Site Resilience
8-29
Site resilience allows you to extend high availability for your Exchange servers beyond a single data
center. Exchange Server 2010 supports site resilience for mailbox databases that are protected in a DAG.
In Exchange Server 2003, the only option for implementing site resilience was to implement storage
replication. In Exchange Server 2007, you could use continuous cluster continuous replication or standby
continuous replication to provide site resilience. With the implementation of DAGs, configuring site
resilience in Exchange Server 2010 is significantly easier.
Describe high availability for multiple sites.
Describe the requirements for creating a multiple site DAG.
Describe Datacenter Activation Coordination mode.
Describe how to design other roles for site resilience.
Describe the switchover and switchback process with site resilience.
Describe best practices for multiple site high availability solutions.
8-30
Discussion: High Availability for Multiple Sites
Deploying Exchange Server 2010 in multiple locations allows you to host your companys Exchange Server
2010 environment in many different scenarios. You can use a secondary site for maintenance events, or
when the primary site experiences a level of failure that requires a complete switchover to the secondary
site.
Although Exchange Server 2010 simplifies multisite configuration, it still requires ample planning and
configuration to implement and maintain a multisite configuration successfully.
Question: What are some common multisite high availability scenarios?
Question: Does your company have a warm disaster-recovery site, or is it planning to have
one?
Question: After mail services have been successfully switched over to the second site, what
other issues might you still need to address?
8-31
Requirements for Creating a Multiple Site DAG
You can extend a DAG to one or more data centers in a configuration that provides site resilience for one
or multiple data centers. Such a configuration produces several design challenges that you must take into
account before implementing a multiple site DAG.
One Mailbox Server at Each Site

To configure a DAG for site resilience, the DAG must have at least one member in an alternate data
center. Then databases can then be replicated to the member in the alternate data center. No other
specific configuration is required for the Mailbox servers, or for the databases.
When implementing a DAG across multiple sites, you do need to configure the DAG networks. A DAG
supports having multiple subnets on the MAPI network, and multiple subnets on a replication network.
Therefore, subnets do not need to span a wide area network (WAN) link. When configuring the multisite
DAG, you need to collapse the networks that are automatically enumerated when you add servers to the
DAG into one MAPI network and one or more replication networks. However, there can be no routing
between the MAPI network and the replication network or between replication networks if you configure
multiple networks. The WAN link must support separate routes for all networks.
Round-Trip Network Latency Time
Regardless of their geographic location to other DAG members, each member of the DAG must have
round-trip network latency no greater than 500 milliseconds between each other member.
Other Server Roles Must Be Available in Each Site
In addition to the Mailbox server in the alternate data center and the basic Active Directory servers such
as domain controllers and DNS servers, you also need to install a Client Access server and a Hub Transport
server. To reduce hardware requirements in the alternate data center, you can place the Client Access
server and Hub Transport server roles on the same computer as the Mailbox server role. However, you
should do so only if the computer has sufficient capacity.
8-32
Datacenter Activation Coordination Mode
Use the Datacenter Activation Coordination mode for DAGs that span multiple locations. This mode
prevents database copies from experiencing split-brain syndrome. Split-brain syndrome occurs when
more than one DAG member mounts the same database. This is a problem because there is no way to
reconcile the different content in the two mounted databases. More about the Datacenter Activation
Coordination mode is described in the next topic.
What Is Datacenter Activation Coordination Mode?
8-33
Datacenter Activation Coordination mode is a DAG property that prevents mounting of the same
database at two different Active Directory sites that cannot communicate to each other. This is called
split-brain syndrome. Datacenter Activation Coordination (DAC) mode prevents split-brain syndrome in a
multi-Active Directory site DAG implementation.
Suppose you have two data centers, each with two DAG members. The witness server for the DAG is in the
first data center. A power outage occurs, and as the administrator, you activate the DAG at the second
data center. Because you do not have majority quorum in the second data center, you can do this by
configuring an alternative witness server or by configuring the DAG to use a different quorum mode. As
long as the first data center stays offline, no problem occurs. Split-brain syndrome occurs when the first
data center is powered back up, but WAN connectivity between the two data centers is not immediately
restored. If DAC mode is not enabled, the first data center could achieve majority quorum because it still
does not know that the second data center already has the databases mounted, and mounts the
databases. The same database is active at two different sites, which causes split-brain problems when
WAN connectivity is restored.
To prevent split-brain syndrome, Datacenter Activation Coordination mode uses a protocol called
Datacenter Activation Coordination Protocol (DACP). This protocol configures a bit in memory for each
Active Manager hosted on every Exchange server that is a DAG member, and has the following options:
Local database is not allowed to be mounted
Local database is allowed to be mounted
The DACP protocol is:
During Active Manager start up, DACP is set at 0.
In Datacenter Activation Coordination mode, the server tries to communicate with all other Exchange
servers that are members of the DAG to find a member that has its DACP bit set at 1.
8-34
If it finds a DAG member with a DACP of 1, the server sets its DACP bit to 1 and mounts its active
databases. Alternatively, if the server contacted all DAG members successfully, it also sets its DACP to
1 and mounts the database.
If the server cannot reach a server that has a DACP of 1, it cannot automatically mount its active
database.
DAC mode differs in the Exchange Server 2010 versions in the following way:
In Exchange Server 2010, DAC mode is limited to DAGs with at least three members that have at least
two or more members in the primary data center. When you enable DAC mode , you can use
Exchange Server cmdlets rather than the failover cluster tools to perform a data center switchover.
Exchange Server 2010 SP1 supports two-member DAGs that have each member in a separate data
center. Two-member DAGs in DAC mode use the witness server boot time to provide a weighted vote
for mounting. DAC mode in Exchange Server 2010 SP1 supports DAGs that have all members
deployed in a single Active Directory site, including single Active Directory sites that have been
extended to multiple locations.
Two-Member DAGs in DAC Mode
A two-member DAG in DAC mode may have difficulty achieving majority quorum when it relies on the
DACP setting alone. For this reason, the Datacenter Activation Coordination uses the DAGs witness server
boot time to help determine whether a database should be mounted. The Active Manager compares the
boot time of the witness server to the time when the DACP was set to 1. This provides the following
scenarios:
If the DACP setting was set earlier than the witness boot time, the DAG member is not allowed to
mount databases.
If the DACP setting was set later than the witness boot time, the DAG member is permitted to mount
databases.
You can enable DAC mode with the following cmdlet:

Set-DatabaseAvailabilityGroup -Identity <DAG Name>
-DatacenterActivationMode DagOnly
Question: When should you consider configuring the Datacenter Activation Coordination
mode?
Designing Other Roles for Site Resilience
8-35
For Mailbox servers, you can use a DAG across multiple physical locations to provide site resilience. For
other server roles, there is no special configuration to provide site resilience; those server roles must
already exist in the alternate data center.
Hub Transport Server
Message transport is performed based on Active Directory sites. Each Active Directory site with a Mailbox
server must have a Hub Transport server as well. When a database is activated in the alternate data center,
it uses the Hub Transport server in the alternate data center. No specific configuration is required to
enable message routing between Exchange servers.
If you have applications or non-MAPI clients that are configured to use a specific Hub Transport server for
relaying messages, you need to direct those applications to a new Hub Transport server. If the application
is configured to use the IP address of the Hub Transport server, you must reconfigure the application to
use the IP address of a Hub Transport server in the alternate data center. If the application is configured
to use the hostname of the Hub Transport server, you can modify the host record for the Hub Transport
server to use the IP address of the Hub Transport server in the alternate data center.
You should ensure that the Hub Transport servers in the alternate data center have sufficient capacity to
handle the volume of message processing that is expected when the alternate data center is used.
Client Access Server
You cannot span a client access array over multiple Active Directory sites. Therefore, similar to a Hub
Transport server, you need to include a Client Access server in the Active Directory site in the alternate
data center.
If the client access array in the original site is still available, it can continue to both provide services for
clients, and access the active database in the alternate data center. This is a good solution if the alternate
data center will be used for a short time.
8-36
If the alternate data center will be used for a long time you should consider modifying the DNS record for
the Client Access servers or the client access array to reference the Client Access server in the alternate
data center.
Outlook Anywhere and Exchange ActiveSync clients locate a Client Access server accessible on the
Internet by using DNS records. If the original client access array is unavailable, you need to change the
host record for the external client access to point to the Client Access server in the alternate data center.
A potential concern is caching DNS records. If the client computer caches the hostname of the Client
Access server, you can clear the cache on the client computer by specifying ipconfig /flushdns, or by
restarting the client. However, many Internet DNS servers cache resolved hostnames for 24 hours. To
ensure that clients can access the Client Access servers in the alternate data center quickly, you must
provide clients with an alternate hostname to access services or configure a short time to live (TTL) on the
DNS records.
Edge Transport Server
To provide site resilience for Edge Transport servers, you must have a Internet connection at the alternate
data center. The simplest way to configure site resiliency is by having the Edge Transport servers already
active and able to receive messages.
Incoming messages are directed to an Edge Transport server based on MX records in DNS. The MX
records are a pointer to the hostname of the Edge Transport server. To have messages automatically
redirected to the alternate data center when the primary location is unavailable, you can configure
multiple MX records.
The priority number for MX records determines the order in which they are used. An MX record with a
lower priority number is contacted first. The MX record for the alternate data center has a higher priority
number than the MX record for the primary data center. With this configuration, Simple Mail Transfer
Protocol (SMTP) mail servers attempt delivery to the primary data center first, and if the primary data
center is unavailable, the messages are delivered to the alternate data center.
Messages transported through the alternate data center automatically use the Edge Transport server in
the alternate data center for message delivery, because it is the closest Edge Transport server.
8-37
Switchover and Switchback Process with Site Resilience
Failover for databases within an Active Directory site is always automatic, and may not be noticed by
clients. You can also failback mailbox databases in the same site with no disruption in services. However,
switchover and switchback between sites is a manual process that will result in a short service outage. .
The Switchover Process with Site Resilience
To access the site resilience cmdlets, you must enable DAC mode on the DAG before the failure occurs.
When the primary data center fails, the switchover process includes the following steps:
1.
Reconfigure the DAG to remove the primary sites servers from the Windows Failover Cluster, but
retain them in the DAG. There are two options for configuring the DAG. If some Mailbox servers in
the primary site are still running but with not enough servers to maintain quorum, you need to stop
the DAG on the running servers. You can accomplish this by running the following cmdlet in the
Exchange Management Shell on a server in the primary data center:
Stop-DatabaseAvailabilityGroup <DAG Name> ActiveDirectorySite <Primary Site Name>
If all of the Mailbox servers in the primary site are unavailable, or if Active Directory replication with
the secondary data center has failed, you need to stop the DAG in the primary data center from an
Exchange server in the secondary data center. You can accomplish this by running the following
cmdlet in the Exchange Management Shell on a server in the secondary data center:
Stop-DatabaseAvailabilityGroup <DAG Name> ActiveDirectorySite <Primary Site Name>
-ConfigurationOnly
2.
Reconfigure the DAG to use an alternative file-share witness, and restore the functionality in the
secondary site. To do this, first stop the cluster service on each of the secondary sites DAGs servers,
and then run the following cmdlet:
8-38
Restore-DatabaseAvailabilityGroup <DAG Name> -ActiveDirectorySite <Secondary Site Name>

-AlternateWitnessServer <Secondary Site Witness Server>
3.
Start the cluster service on each of the servers in the DAG in the secondary site.
4.
If you have blocked activation on any Mailbox servers in the secondary data center, you need to
remove the activation block. Available Active Managers will then mount the mailbox databases in the
secondary site.
5.
Adjust DNS records, if necessary, for SMTP, Outlook Web App, Autodiscover, Outlook Anywhere, and
any legacy protocols. You can make adjustments manually, or use a third-party global-server DNS
server to make changes automatically.
The Switchback Process with Site Resilience
In most instances, after you recover the primary site, you need to perform a switchback to the primary
site. The switchback process includes the following steps:
1.
Verify that the primary data center is capable of hosting Exchange services.
2.
Reconfigure the DAG to add primary data center servers back into the switchover cluster. To do this,
run the following cmdlet:
Start-DatabaseAvailabilityGroup <DAG Name> ActiveDirectorySite <Primary Site Name>
3.
If required, reconfigure the DAG to use the primary sites witness server. To do this, run the following
cmdlet:
Set-DatabaseAvailabilityGroup <DAG Name> WitnessServer <Primary Site Witness Server>
4.
Manually reseed or allow replication to update the primary data centers database copies.
5.
Schedule downtime for the mailbox databases, and then dismount them.
6.
Adjust DNS records for SMTP, Outlook Web App, Autodiscover, Outlook Anywhere, and any legacy
protocols. You can accomplish this manually, or you can take advantage of third-party global-server
DNS server that performs the change automatically, and points it back to the primary data center.
7.
Move the active databases back to primary data center by running the following cmdlet, and then
mount the databases in primary data center.
Move-ActiveMailboxDatabase <Database> ActivateOnServer <Server in Primary Site>
Best Practices for Multiple Site High Availability Solutions
8-39
By implementing certain best practices, you can ensure a successful, highly available, multiple-site
configuration. To begin, reduce failover time by using a TTL of 5 minutes or less on DNS records for all
relevant namespaces. Using a low TTL enables the DNS clients to more quickly discover DNS entries that
point to the secondary site.
If a failure occurs, it is important to ensure that the system works as designed. Therefore, you should
continually monitor and verify that all messaging-system components are functioning properly. To do
this, monitor all aspects of the Exchange Server 2010 environment to ensure that it is functioning
normally, and that mailbox data is successfully replicating to the secondary site in a timely manner. Next,
you can schedule periodic failover tests to provide an additional level of preparation, and to validate the
configuration and operation of the cross-site failover process.
You also should follow a change management process to ensure that each Mailbox server in the DAG,
each Client Access server, and each Hub Transport server are configured correctly and have the same
updates applied. Doing this reduces the possibility of incompatibilities and unexpected behavior if a
failover occurs.
Finally, we recommend that you follow the Windows Server Failover Clustering best practice of having
each node connected to multiple networks. Separating the MAPI and replication networks provides
enhanced performance. In some cases, you might also create multiple replication networks to provide
redundancy. However, to avoid network crosstalk, the MAPI and replication networks must not be able to
route to each other.
8-40
Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, do the
following:
1.
2.
Ensure that the 10165A-NYC-DC1-B, 10165A-NYC-EX10-B, and the 10165A-NYC-EX11-B virtual

3.
10165A-NYC-EX11-B: Exchange 2010 server in the contoso.com domain.
Lab Scenario
You are the messaging administrator for Contoso, Ltd. You have completed the basic installation for the
Exchange 2010 servers. One of the critical business requirements for the Exchange Server 2010
deployment at Contoso is to enable high availability for the messaging system. You need to ensure that
the failure of any individual server will not result in the loss of any messaging services. This means that
you must complete the configuration of the Exchange 2010 servers so that they are highly available.
8-41
Exercise 1: Deploying a Database Availability Group

Scenario
You must complete the Mailbox server high availability configuration by creating a DAG and making the
Accounting database highly available.
1.
Create and configure a DAG.
2.
Add Mailbox servers to the DAG, and configure the replication network.
3.
Create and verify a mailbox database copy.
4.
Suspend the Accounting database copy on NYC-EX11.
Task 1: Create and configure a DAG

1.
2.
On NYC-EX10, use the Exchange Management Console to create a DAG by using the following
settings:
DAG Name: DAG1
Witness Server: NYC-DC1
Witness Directory: C:\FSWDAG1
In the properties dialog box for DAG1, add the following IP Address on the IP Addresses tab:
10.10.0.99
Task 2: Add Mailbox servers to the DAG, and configure the replication network
1.
2.
On the Database Availability Group tab, right-click DAG1, click Manage Database Availability
Group Membership, and then add the following servers to DAG1:
NYC-EX10
NYC-EX11
In the DAG1 pane, change the following settings for DAGNetwork01:
3.
Description: Replication network
In the DAG1 pane, change the following settings for DAGNetwork02:
Description: MAPI Communication Networkl
Enable Replication: Un-checked
Task 3: Create and verify a mailbox database copy

1.
On the Database Management tab, click Accounting, in the Actions pane, click Add Mailbox
Database Copy, and then add a database copy for server NYC-EX11.
2.
Right-click the Accounting entry that has a Healthy copy status, and then click Properties. Review all
properties.
Task 4: Suspend the Accounting database copy on NYC-EX11

1.
In the Exchange Management Shell, on the Database Management tab, click Accounting.
8-42
2.
Right-click the Accounting entry that has a Healthy copy status, and then click Suspend Database
Copy.
3.
View the Copy Status column for each database copy. The copy status will change to Suspended.
Results: After this exercise, you should have created and configured a DAG and a mailbox database copy
of the Accounting database. You also verified the Accounting database copy, and suspended it on NYCEX11.
Exercise 2: Deploying Client Access Servers

Scenario
The network team used a hardware load balancer to load balance NYC-EX10 and NYC-EX11 for Client
Access server connections. They have assigned a load-balanced IP address on the load balancer for the
name CASArray.adatum.com. Now you must add the host name to DNS and complete the Client Access
server configuration.
1.
Add a host record for CASArray.adatum.com to the Contoso.com zone in DNS.
2.
Create a client access array for CASArray.contoso.com.
3.
Configure the mailbox databases to use the client access array.
Task 1: Add a host record for CASArray.adatum.com to the Contoso.com zone in

DNS
1.
On NYC-DC1, open the DNS management console.
2.
Create a host record in the contoso.com domain for CASArray.adatum.com using the IP address
10.10.0.20.
Task 2: Create a client access array for CASArray.contoso.com

1.
2.
Run the following cmdlet:
New-ClientAccessArray
Fqdn casarray.contoso.com Name CASArray.contoso.com
Site Default-First-Site-Name
Task 3: Configure the mailbox databases to use the client access array
1.
In the Exchange Management Shell, run the following cmdlet:
Get-MailboxDatabase |ft Name,RPCClientAccessServer
2.
Get-MailboxDatabase |Set-MailboxDatabase RpcClientAccessServer casarray.contoso.com
Note This command configures the RpcClientAccessServer setting for all mailbox databases
in the organization. You should run this command only if all Mailbox servers are in a single
Active Directory site, and you want all mailbox databases to use the same value for this
setting.
3.
To verify that everything was configured correctly, run the following cmdlet:
Get-MailboxDatabase |ft Name,RPCClientAccessServer
8-43
Results: After this exercise, you should have created a client access array, and then assigned it to the
databases.
8-44
Exercise 3: Testing the High Availability Configuration

Scenario
Finally, you need to test the high availability deployment to ensure that your organizations requirements
are met. You should verify Hub Transport redundancy, and manual and automatic failover of mailbox
databases when a server outage occurs.
1.
Create an SMTP connector associated with NYC-EX11.
2.
Stop the SMTP server on NYC-DC1, and then send an email message.
3.
Use Queue Viewer to locate the message in the queue.
4.
Start the SMTP service on NYC-DC1 to allow queued message delivery.
5.
Verify that the messages are removed from the shadow redundancy queue.
6.
Verify the copy status of the Accounting database, and resume the database copy.
7.
Perform a switchover on the Accounting database to make the NYC-EX11 copy active.
8.
Simulate a server failure.
Task 1: Create a SMTP connector associated with NYC-EX11

1.
On NYC-EX11, in the Exchange Management Console, expand Organization Configuration, and

then click Hub Transport.
2.
Create a Send connector with the following settings:
Name: Internet Mail
Select the intended use for this Send connector: Internet
Address space: * with cost 1
Network Settings: Route mail through the following smart hosts: nyc-dc1.contoso.com
Source server: NYC-EX11
Task 2: Stop the SMTP server on NYC-DC1, and then send an email message
1.
On NYC-DC1, on the quick launch bar, click Server Manager.
2.
Stop the service Simple Mail Transport Protocol (SMTP).
3.
On NYC-EX10, open Windows Internet Explorer, and connect to https://NYCEX10.contoso.com/owa.
4.
Log on as Contoso\Alan by using the password Pa$$w0rd.
5.
Create a new message to George Schaller; jane@adatum.com, with the subject Shadow
Redundancy, the text in the body Test email, and then send it.
Task 3: Use Queue Viewer to locate the message in the queue

1.
On NYC-EX11, in the Exchange Management Console, under Toolbox, open Queue Viewer.
2.
On the Queues tab, locate the entry with nyc-dc1.contoso.com as the next hop domain. If the
message is not visible, connect to server NYC-EX10.
3.
Create a filter by using Delivery Type, Equals, and Shadow Redundancy as settings.
4.
Examine the shadow redundancy queue contents.
8-45
Task 4: Start the SMTP service on NYC-DC1 to allow queued message delivery
1.
On NYC-DC1, from the quick launch bar, click Server Manager.
2.
Start the service Simple Mail Transport Protocol (SMTP).
Task 5: Verify that the messages are removed from the shadow redundancy queue
1.
On NYC-EX11, in the Queue Viewer, click the Queues tab.
2.
Task 6: Verify the copy status of the Accounting database, and resume the database
copy
1.
On NYC-EX10, in the Exchange Management Console, under Organization Configuration, click

Mailbox.
2.
Click the Database Management tab, and then select Accounting.
3.
View the Copy Status column for each database copy, click the Accounting entry that has a
Suspended copy status, and then review the properties.
4.
Right-click the Accounting entry that has a Suspended copy status, and then click Resume Database
Copy. Wait until the copy status of the Accounting database copy on NYC-EX11 is Healthy.
Task 7: Perform a switchover on the Accounting database to make the NYC-EX11

copy active
1.
In the Exchange Management Console, right-click the Accounting entry that has a Healthy copy
status, and then click Activate Database Copy.
2.
Wait until the copy status of the Accounting database copy on NYC-EX11 displays as Mounted.
Task 8: Simulate a server failure

1.
On NYC-EX10, in the results pane, click the Database Management tab. Wait until the Accounting
database copy status for NYC-EX10 is healthy.
2.
On the host machine, turn off 10165A-NYC-EX11-B.
3.
On NYC-EX10, in the Accounting pane, on the Database Copies tab, right-click on the empty space,
and then click Refresh.
4.
View the status of the Accounting database in the results pane. The database copy on NYC-EX10 will
change to a status of Mounted, and the database copy on NYC-EX11 will have a status of
ServiceDown.
Results: After this exercise, you should have verified that the mailbox databases can be failed over and
switched between DAG servers, and that Hub Transport shadow redundancy is working properly.
8-46

following steps:
1.
2.
3.
4.
Repeat the steps for 10165A-NYC-EX10-B, and 10165A-NYC-EX11-B.
5.
machine.
6.
machine.
7.
machine.
8-47
Review Questions
1.
To make a highly available Exchange Server 2010 organization, which components must be highly
available?
2.
Besides planning for Exchanger Server 2010 failures, what other failures should you consider?
3.
In which scenarios might you use hardware load balancing with Edge Transport servers?
4.
Which Exchange Server 2010 feature provides fault tolerance for message delivery?
5.
How many networks should you use for a DAG?
6.
What are the requirements for using the Datacenter Activation Coordination mode?

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

Identify all possible failure points before designing a solution. Even the most elaborate and expensive
designs can have a simple and crippling failure point.
Document all of the components to the solution so that everyone involved in the deployment
understands how the solution is configured.
8-48
Follow change-management procedures. In some environments, it may be tempting to skip these

steps. However, not following proper change-management procedures often leads to extended,
unplanned downtime.
Use a client access array and load-balancing to make client access highly available.
If a Client Access server is also a member of a DAG, then use hardware-based load-balancing.
Ensure that Internet-accessible sites that proxy Client Access for multiple sites are highly available,
because their outage will affect many users.
When a mailbox database fails over to an alternate site for a short period of time, allow the clients to
continue using the client access array in the original site.
Implementing Backup and Recovery
9-1
Module 9
Contents:
Lesson 1: Planning Backup and Recovery
9-3
Lesson 2: Backing Up Exchange Server 2010
9-9
Lesson 3: Recovering from Disasters
9-21
9-34
Module Overview
Your Microsoft Exchange Server 2010 databases contain the messages for all of your users. As an
administrator, one of your key concerns should be ensuring that the mailbox contents are protected
against accidental deletion or the failure of Exchange 2010 servers.
9-2
Exchange Server 2010 provides features that you can use to protect and recover mailbox contents. These
features differ from Exchange Server 2003 and Exchange Server 2007 backup and restore features. You
should understand these differences so you can consider using the new features instead of the traditional
backup-to-tape approach that most organizations use. This module describes features available in
Exchange Server 2010 for protecting mailbox data, and what to consider when creating a disaster
recovery plan.
1.
Plan backup and recovery.
2.
Back up Exchange Server 2010.
3.
Recover from disasters.
Lesson 1
Planning Backup and Recovery
9-3
Before deciding which backup type you want to use and which software to buy, you need to consider
your available options first. Exchange Server 2010 provides many options beyond traditional backup and
restore. These options include restoring single items that were deleted and purged by users. Some of
these options are familiar to Exchange Server 2003 and Exchange Server 2007 administrators, but many
are new. In this lesson, you will learn the important considerations for backing up and restoring Exchange
Server 2010, so that you can create a good plan for your organization.
1.
Identify and mitigate potential Exchange Server 2010 disasters.
2.
Explain Exchange Native Data Protection.
3.
Explain how to create a point-in-time database recovery.
4.
Describe backup and restore scenarios.
Disaster Mitigation Options in Exchange Server 2010
9-4
As you prepare to implement disaster recovery solutions in Exchange Server 2010, you must first identify
the potential risks to the Exchange Server 2010 environment, and then identify the options for mitigating
those risks. The following table lists potential risks and the Exchange Server 2010 options for mitigating
the risks.
Risks
Risk mitigation strategies
Loss of a single
message
Configure single item recovery by using the Recoverable Items folder. This
option is described in the topic Options for Recovering Mailbox Data and
Databases later in this module.
Recover messages from backup by using the recovery database.
Loss of a single mailbox
Configure mailbox-retention settings to ensure that you can recover most

deleted mailboxes before they are deleted permanently.
Recover mailbox using the recovery database.
Loss of a database or
server
Create a database availability group (DAG) on another server.

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

Back up the Exchange Server 2010 data, and recover lost mailbox databases
from backup.
Loss of a public folder

database
Implement public folder replicas on other computers running Exchange

Server 2010.
Question: What mitigation strategy can you follow to be able to recover single messages for
a mailbox?
What Is Exchange Native Data Protection?
9-5
In Exchange Server 2003 and Exchange Server 2007 deployments, the primary means for providing
disaster recovery is through a backup and restore solution. Exchange Server 2010 enables a much tighter
integration of high availability with disaster recovery, especially if the new Exchange Server 2010 high
availability features are sufficient to satisfy your backup requirements.
Exchange Server 2010 SP1 includes a new feature called Exchange Native Data Protection that allows you
to reduce or completely remove your traditional backup solutions for mailboxes and Exchange servers.
You should carefully consider whether this feature meets your disaster recovery requirements. Exchange
Native Data Protection includes the following features:
1.
DAGs as the primary means of disaster recovery. The high availability features built into Exchange
Server 2010 DAGs allow you to minimize downtime and data loss in the event of a mailbox database
or Mailbox server failure. With DAGS, you can spread database copies across multiple data centers or
Active Directory Domain Services (AD DS) sites, which allows you to address data center failures, and
maintain offsite copies of a database. In some cases, it can be less expensive to provide multiple
copies of databases than it is to backup up very large databases.
2.
Single item recovery and litigation hold policies for recovering deleted messages. In Exchange Server
2010 SP1, single item recovery ensures that all deleted and modified items are preserved so that you
can recover them. Users can no longer completely purge items from their mailboxes. Legal (or
litigation) hold preserves electronically stored information such as email messages so that users
cannot delete them. This feature replaces the necessity of performing a restore when a user deletes
messages from a mailbox and then wants to restore them. Single item recovery and litigation hold are
discussed in Module 10.
3.
Point-in-time database recovery with lagged copies of mailbox databases. When you configure a
mailbox database copy, you can configure the database copy to delay replaying the log files for up to
14 days. Thus, you continuously maintain a database in the state it was in during the previous days or
weeks. This means that if you have an issue with your current database, such as a script changing
9-6
many items at once, you can revert to a lagged database copy and commit the transaction logs to a
specific time.
4.
Archive mailboxes, retention and archive policies, and Multi-Mailbox Search for managing large
mailboxes. By configuring archive mailboxes, you can provide users with a storage location for old
messages. You can also automate the process of managing messages in user mailboxes, including
moving messages into the archive mailbox, by configuring retention and archive policies. All of the
messages are available to the user, and can also be accessed through Multi-Mailbox Search.
As you consider implementing these features, you should evaluate the cost of your current backup
infrastructure, including hardware, installation, and license costs, and the management cost associated
with recovering data and maintaining the backups. Additionally, you should determine the service level
agreements (SLAs) for protecting against and recovering from data lose or service failures. Depending on
your organizations backup requirements and SLAs, Exchange Server 2010 SP1 Native Data Protection
may provide lower total cost of ownership (TCO) than a traditional backup environment while at the same
time ensuring that you comply with the SLAs.
Even though it may appear that highly available deployments no longer require traditional backups, you
may still require them in your environment. Integrating high availability features as an alternative to
backups only works for the mailbox database, not for other Exchange Server resources, such as the Hub
Transport configuration. You still may need to consider using traditional backup for your other Exchange
2010 server roles.
Question: Why should you back up Exchange Server databases?
9-7
Demonstration: Creating a Point-in-Time Database Recovery
In this demonstration, you will review how to configure a database copy on a remote server, and how to
configure a database copy to be a lagged database copy. Additionally, you will also see how to disable an
active server to prevent automatic activation.
Demonstration Steps
1.
At the Exchange Management Shell prompt, type the following command, and then press Enter:
New-DatabaseAvailabilityGroup Name DAG1 WitnessServer NYC-DC1 -WitnessDirectory

C:\FSWDAG1 DatabaseAvailabilityGroupIPaddresses 10.10.0.99
This command creates a DAG with the name DAG1, uses the witness server NYC-DC1, creates the
C:\FSWDAG1 folder on the witness server, and uses the DAG group IP address of 10.10.0.99.
Note As a best practice, place the witness directory on a Hub Transport server, because this
server is normally managed by Exchange Server administrators. However, you can place the
witness directory on any Windows 2003 or later server that is a member of the same Active
Directory forest as the Exchange 2010 servers, including a server that is not running any
Exchange server roles. The file share witness cannot be placed on a DAG member server.
2.
In the Exchange Management Console, add NYC-EX10 and NYC-EX11 to DAG1, and then add a
copy of the Accounting database to NYC-EX11 with a replay lag time of 7 days.
3.
At the Exchange Management Shell prompt, type Set-MailboxServer NYC-EX11

DatabaseCopyAutoActivationPolicy Blocked, and then press Enter. This command prevents
databases from being activated on NYC-EX11.
Backup and Restore Scenarios
Even though Exchange Server 2010 supports backup-less scenarios, there are cases in which your
organization may need to maintain its traditional backup methods.
No Available DAGs
Organizations that do not use DAGs need to consider traditional methods to back up their databases.
Single Exchange Server Implementation

Single Exchange 2010 server implementations are not conducive to DAG usage, because it requires
adding more server hardware. Traditional backups to disks or tapes are the option to follow in this
scenario.
Existing Backup Environment Requires Backup Copies
9-8
Some organizations have a policy that requires all application data to be backed up to an existing backup
environment. Thus, even when you maintain multiple copies of your mailbox databases, you may be
required to back up the database in your backup environment.
Backups Governed by Compliance Requirements
You typically use tape backups if there is an archival reason to preserve data for an extended time, as
governed by compliance requirements. If the storage is long-term (sometimes up to 10 years), you also
need to ensure that you can access the data in the future.
Question: Are you considering deploying Exchange Server 2010 without traditional backups,
and why might you choose this option?
Lesson 2
Backing Up Exchange Server 2010
9-9
Backing up your companys data is the most important task in your Exchange Server 2010 installation,
especially as you upgrade your existing Exchange Server 2003 or Exchange Server 2007 data to Exchange
Server 2010. You cannot recover necessary data if you have not backed it up correctly. In this lesson, you
will learn the different ways that you can back up data with Exchange Server 2010.
1.
Describe the backup changes in Exchange Server 2010.
2.
Describe the backup requirements for Exchange Server 2010.
3.
Describe how a volume shadow copy service (VSS) backup works.
4.
Select an Exchange Server 2010 backup solution.
5.
Back up Exchange Server 2010.
6.
Explain the benefits of using Microsoft System Center Data Protection Manager.
9-10
Changes to Backup in Exchange Server 2010
Exchange Server 2010 changes to the backup application programming interface (API) and the underlying
database structure affects how you back up the Exchange Server 2010 database.
Removal of ESE Streaming APIs for Backup and Restore
In Exchange Server 2003 and Exchange Server 2007, you use Extensible Storage Engine (ESE) streaming
APIs for backup and restore. Now, Exchange Server 2010 supports only VSS-based backups. To back up
and restore Exchange Server 2010, you must use an Exchange Server-aware application that supports the
VSS writer, such as Windows Server Backup included in Windows Server 2008, System Center Data
Protection Manager, or a third-party Exchange Serveraware, VSS-based application.
Storage Group Removal
One significant change from Exchange Server 2007 to Exchange Server 2010 is the removal of storage
groups. In Exchange Server 2010, each database is associated with a single log stream as represented by a
series of 1 megabyte (MB) log files.
Database Not Closely Linked to a Specific Mailbox Server
Another significant change in Exchange Server 2010 is that databases no longer link closely to a specific
Mailbox server. Database mobility expands the systems use of continuous replication by replicating a
database to multiple servers. This provides better database protection and increases availability. If failures
occur, the other servers with database copies can mount the database.
Use DAGs for Backup-Less Exchange Server

Because you can have multiple database copies hosted on multiple servers, you can also consider
maintaining a backup-less Exchange Server organization in which you enable circular logging on your
databases. This removes the transaction log files so they do not pile up.
9-11
Backup Requirements for Exchange Server 2010
The backup requirements for Exchange Server 2010 computers differ depending on the Exchange 2010
server roles that you install on the computers. The following table lists the information that you should
consider backing up for each Exchange server role.
Exchange server
role
Backed-up data
Purpose
All roles
System state of server

and AD DS database
on domain
controllers
System state includes the local configuration data of the

machine.
AD DS stores most Exchange Server 2010 configuration
information, which is required to rebuild the server by
using Recover Server mode.
A system state backup is required only if you want to
restore a particular Exchange server. It is not required for
recovering an Exchange server, or if you are going to
replace a failed server with a new server.
Mailbox server
Databases,
transaction logs and
content indexes
Restore data if a database or storage group is lost.
Server certificates
used for Secure
Sockets Layer (SSL)
Specific Internet
Information Server
configuration
Restore the server certificate on a new Client Access

server.
Restore IIS configuration.
Hub Transport
server, Edge
Transport server
Message-tracking
logs
Restore tracking information for analysis.
9-12
Edge Transport
server
Content-filtering
database
Restore the content-filtering configuration.

Restore the Edge Transport server configuration by
enabling Edge synchronization.
Unified Messaging
server
Custom audio
prompts
Restore audio prompts.
The Exchange Server 2010 environment includes additional information, such as the offline address book,
availability data that a local folder stores, and other configuration data. This information is rebuilt
automatically when you rebuild the Exchange Server 2010 environment. AD DS stores much of the
configuration information, which you can restore only if an Active Directory domain controller is available.
You must ensure that your disaster recovery planning includes backing up and restoring AD DS.
9-13
How Does a VSS Backup Work?
Exchange Server 2007 and Exchange Server 2003 include two different options for data backup and
recovery: ESE streaming backup APIs, and support for the VSS backup APIs. ESE streaming APIs are not
available for public use in Exchange Server 2010, thus you can back up Exchange Server 2010 with VSS
backup APIs only.
What Is VSS?
VSS provides the backup infrastructure for the Windows Server 2008 operating system, as well as a
mechanism for creating consistent point-in-time data copies, which are known as shadow copies.
VSS produces consistent shadow copies by coordinating with business applications, file-system services,
backup applications, fast-recovery solutions, and storage hardware. It includes the following components:
1.
Writer. The VSS writer that is included with Exchange Server 2010 and that coordinates Exchange
Server 2010s input/output (I/O) with VSS.
2.
Requestor. Backup or restore application, such as Windows Server Backup.
3.
Provider. Low-level system or hardware interfaces, such as storage area networks (SANs). These
interfaces control both the storage where the data currently resides, and the storage where the
shadow copy will reside once it is created.
For example, the requestor could be Windows Server Backup running on the Windows Server 2008
computer where Exchange Server 2010 is installed; the writer could be Exchange Server 2010; and the
provider could be the Windows Server volume manager that controls the volumes where Exchange Server
currently resides, and the volume where the shadow copy data will be stored.
How VSS Backup Works
Backup solutions that use VSS create a shadow copy of the disk as the backup process begins. Then,
Exchange Server 2010 creates the backup with the shadow copy rather than the working disk, so that
backup does not interrupt normal operations.
9-14
This method offers the following advantages:

1.
It produces a backup of a volume that reflects that volumes state when the backup begins, even if
the data changes while the backup is in progress. All the data in the backup is internally consistent,
and it reflects the volumes state at a single point in time.
2.
It notifies applications and services that a backup is about to occur. The services and applications
such as Exchange Server 2010can then prepare for the backup by cleaning up on-disk structures
and flushing caches.
Exchange Server Support for VSS Backup
To perform a VSS backup, you must enable the VSS on the Exchange server, and the third-party backup
solution must support the VSS backup and restore APIs.
Exchange Server 2010 support for VSS has the following limitations:
1.
VSS support is at the database level.
2.
VSS support is for normal backups and copy backups, but not for incremental or differential backups.
9-15
Considerations for Selecting an Exchange Server Backup Solution
When selecting a backup solution for your upgraded Exchange Server 2010 organization, you must
consider your systems characteristics and those of the software and hardware.
System characteristics to consider include:
1.
The amount of data you are backing up.
2.
The time frame in which the backup can occur.
3.
The type of backup you are performing.
4.
Recovery time requirements.
5.
Archiving requirements.
Backup Software Selection Criteria
The following table provides some basic criteria for selecting backup software. Select the software that
best meets the needs of your Exchange Server 2010 upgrade and disaster recovery requirements.
Selection criteria
Explanation
Backup architecture
Your backup software should provide support for any operating

systems that you have. Additionally, the backup software should be
able to back up Exchange Server 2010 to your desired media, either on
the local computer or over the network. Windows Server Backup is not
capable of backing up to a tape drive.
Scheduling
Your backup software should support the ability to schedule backups

that you require for your organization. Most backup software allows
you to schedule jobs at any time you require. However, it is easier to
configure in some software packages.
Brick-level backup support
One option that is available with some backup solutions is brick-level

backups. Brick level refers to backing up individual mailboxes as
9-16
opposed to backing up entire databases. Brick-level backups can

require a significant amount of extra time. Because Exchange Server
2010 provides other options for recovering mailbox level data, we do
not recommend using brick-level backups.
Exchange Server VSS API
support
Your backup software must support the Exchange Server VSS API to
perform online backups successfully.
Tape management
Different backup software has varying degrees of flexibility for tape

management. This includes automated naming of blank tapes, and
preventing existing tapes from being overwritten accidentally.
Vendor support
Vendor support is essential if you experience any problems during

disaster recovery. Ensure that vendor support is available for your
backup software.
Disaster-recovery support
Some backup software has a disaster recovery option that provides

complete disaster recovery for a failed server, including Exchange
Server 2010.
Hardware support
Your backup software must support the technologies that your

company uses.
Windows Server Backup
When you install the Exchange Management Console on a server running Windows Server 2008, it
updates Windows Server Backup to support Exchange Server 2010. Windows Server 2008 enables you to
perform VSS-based backups of Exchange Server data.
For many smaller organizations, Windows Server Backup provides a sufficient solution. However, larger
organizations may require a more robust backup strategy. Windows Server Backup limitations include the
following:
1.
Backups are only performed at volume level; you cannot back up only a single database.
2.
There is no Exchange Serveronly backup feature. You need to back up at least a complete volume to
create an Exchange Serveraware backup.
3.
You cannot restore a single database, but need to recover all databases to a different folder, and then
move it manually.
4.
You can only perform full or copy backup, not incremental or differential backups.
5.
Backup support exists for active databases, but not for passive databases.
6.
Windows Server Backup has no remote server backup functionality. It must run on the Exchange 2010
server that you want to back up.
7.
The Windows PowerShell cmdlets in Windows Server Backup are not compatible with the Exchange
Server 2010 VSS plug-in.
Backup Hardware Selection Criteria

The two most common types of backup hardware are tape and disk. Which you use depends on your
requirements. The following table lists the characteristics of using either a tape or disk for backup.
Characteristic
Tape
Disk server
Portable disk
Speed
Slower
Faster
Faster
9-17
Characteristic
Tape
Disk server
Portable disk
Capacity
Up to 400 GB per tape

(Tape libraries allow the
use of multiple tapes.)
Large
1+ terabyte (typical) per disk
Off-site storage
Yes
Typically no
Yes
Media durability
Excellent
Excellent
Acceptable in most cases
Many organizations use disk-based backup as the first tier, and then utilize tape as a second tier. This
allows you to perform primary backups to disk quickly. Typically, any data that you need to archive offsite is backed up to tape from the disk backup.
DAG Awareness
If you use DAGs in your Exchange environment, verify that the backup solution you are considering is
DAG-aware and supports backing up active and passive databases. Microsoft System Center Data
Protection Manager is an example of a DAG-aware backup solution.
Question: Are you planning to use Windows Server Backup as your backup solution? If yes,
what do you need to consider?
9-18
Demonstration: Backing Up Exchange Server 2010
In this demonstration, you will review how to install the Windows Server Backup program, and how to use
Windows Server Backup to back up Exchange Server 2010. You will also use the Event Viewer to verify that
the Exchange Server databases were backed up correctly.
Demonstration Steps
1.
On NYCEX10, in Server Manager, click Features to add the Windows Server Backup feature.
2.
In Windows Server Backup, use the Backup Once Wizard to create a backup set to back up drive C
and run the backup.
3.
In Event Viewer, verify that the Exchange Server databases are part of the backup, and that they have
backed up successfully.
What Is System Center Data Protection Manager?
9-19
System Center Data Protection Manager is a backup solution for Windows servers. It can back up basic file
and print servers, and application servers. Each file server that you back up requires a Standard license.
Additionally, you need an Enterprise license to properly back up applications such as Exchange Server,
Microsoft SQL Server, Windows SharePoint Services, and Microsoft Virtual Server.
Note You must use System Center Data Protection Manager 2010 to back up Exchange
Server 2010. Previous versions of System Center Data Protection Manager cannot back up
DAGs.
The Backup Process

System Center Data Protection Manager backs up Exchange servers as follows:
1.
System Center Data Protection Manager triggers a snapshot. It performs disk-based backups first, and
then allows you to archive to tape. The first backup to disk is a complete copy of the Exchange 2010
server.
2.
VSS writer communicates with Exchange Server 2010.
3.
Exchange Server 2010 creates consistent databases.
4.
VSS snapshot is taken. The second snapshot captures only changes, and writes them to disk. Multiple
backup versions exist on the disk, but the tool only uses up disk space equivalent to the first backup
plus changes. This is similar to VSS in that it allows you to restore multiple versions of shared files on a
file server.
VSS backups snapshot the entire logical disk, not individual files. However, you can restore specific
informationsuch as files, an Exchange Server 2010 database, or even a mailboxrather than an entire
logical disk.
5.
Truncate (or remove) transaction logs.
9-20
6.
Snapshots are copied to disk.

Question: When should you consider using System Center Data Protection Manager 2010?
Lesson 3
Recovering from Disasters
9-21
Another important component in ensuring availability of email services in your upgraded Exchange Server
2010 organization is planning for recovery.
Organizations that implement high availability solutions still need to plan for scenarios in which the high
availability solutions are not enough. These scenarios might include something as minor as needing to
recover a single mailbox or message, to something as catastrophic as losing an entire data center. This
lesson discusses how to restore Exchange Server 2010.
1.
Explain how to repair an Exchange Server 2010 database.
2.
Use Exchange Database repair cmdlets.
3.
Describe options to recover mailbox data and databases.
4.
Explain how to recover data using the recovery database.
5.
Explain how to restore data from a lagged database copy.
6.
Explain how to restore a computer running Exchange Server 2010.
9-22
Repairing Exchange Database Corruption
In Exchange Server 2003 and Exchange Server 2007, you can repair a mailbox or a public folder with the
Information Store Integrity Checker (Isinteg.exe) tool. To repair mailboxes, you need to dismount the
mailbox database on which that mailbox resides, and run the fixes while the database is offline.
Exchange Server 2010 does not use Isinteg.exe. Instead, with Exchange Server 2010 SP1, you use the NewMailboxRepairRequest cmdlet to detect and repair a corrupted mailbox while leaving the mailbox
database online. For public folders, you need to use the New-PublicFolderDatabaseRepairRequest
cmdlet to detect and correct replication issues in the public folder database.
Note After you begin the repair process with these cmdlets, you can only stop the process
by dismounting the database.
The New-MailboxRepairRequest Cmdlet
Use the New-MailboxRepairRequest cmdlet to detect and fix mailbox corruptions. You can run this cmdlet
against a mailbox or against a database. During the repair process, only the current mailbox being
repaired is inaccessible; all other mailboxes in the database remain operational.
The New-MailboxRepairRequest cmdlet detects and fixes the following types of mailbox corruptions.
CorruptionType
Description
SearchFolder
Detects and fixes Search folder corruptions.
AggregateCounts
Detects and fixes aggregate counts on folders that are not reflecting the
correct values.
FolderView
Detects and fixes views on folders that are not returning the correct contents.
ProvisionedFolder
Detects and fixes provisioned folders that are pointing incorrectly into parent
folders that are not provisioned.
9-23
For example, the following cmdlet detects and repairs all corrupt items for user Christines mailbox:
New-MailboxRepairRequest -Mailbox Christine -CorruptionType
ProvisionedFolder,SearchFolder,AggregateCounts,Folderview
The New-PublicFolderDatabaseRepairRequest Cmdlet
The New-PublicFolderDatabaseRepairRequest cmdlet detects and fixes replication issues in public

folder databases. This cmdlet always runs against a public folder database. During the repair process, only
the public folder currently being repaired is inaccessible. The public folder database itself is available.
The New-PublicFolderDatabaseRepairRequest cmdlet detects and fixes replication state corruptions
(ReplState)..
For example, the following cmdlet detects and repairs all corrupt items for the Public Folder Database 1
public folder database:
New-PublicFolderDatabaseRepairRequest Database Public Folder Database 1
CorruptionType ReplState
Question: In your Exchange Server environment, you experience corrupt mailbox items.
What can you do to remove these corrupt items from the mailboxes?
9-24
Demonstration: Using Exchange Database Repair Cmdlets
In this demonstration, you will use Exchange Server 2010 SP1 cmdlets to repair a corrupt Exchange Server
2010 database. You will also verify the results of the repair in the Event Log.
Demonstration Steps
1.
Use the following command to repair Christines mailbox:
New-MailboxRepairRequest -Mailbox Christine CorruptionType

ProvisionedFolder,SearchFolder,AggregateCounts,Folderview
This command scans the mailbox for the provided corruption types and repairs any found errors.
2.
Use the following command to detect corruptions in the accounting database:
New-MailboxRepairRequest Database Accounting -CorruptionType

ProvisionedFolder,SearchFolder,AggregateCounts,Folderview -DetectOnly
3.
Open Event Viewer to verify the results.
4.
Use the following command to repair a public folder database for corruptions:
New-PublicFolderDatabaseRepairRequest Database Public Folder Database 1

CorruptionType ReplState
5.
Verify the results in the Event Log.
9-25
Options for Recovering Mailbox Data and Databases
You can use several strategies to restore Exchange Server 2010 data. The strategy that you select depends
upon the data that you need to recover.
Hold Policy and Single Item Recovery
Exchange Server 2003 and Exchange Server 2007 provide the dumpster to recover deleted items, but
there is no way to recover items if they are removed from the dumpster itself. Exchange Server 2010
provides the single item recovery feature to recover items that were purged from the dumpster. This
feature also allows you to access messaging data that has been changed by the user in the mailbox.
When you enable single item recovery for a mailbox, items that were purged from the Deleted Items
folder are stored in a new dumpster folder called the Recoverable Items folder. The items are stored for
the time dictated by your organizations hold policy, which is specified by the deleted item retention
settings for the mailbox database. You can also configure a deleted item retention setting directly on the
mailbox to overwrite the default policy.
The Recoverable Items folder is not accessible to the end user, but it is accessible to administrators
assigned to the Discovery Management role. Essentially, you can ensure that items are not deleted for the
duration that you typically keep backups.
Deleted Mailbox Retention
By default, the mailbox database stores deleted mailboxes for 30 days. Within those 30 days, you can
reconnect the mailbox to another account and access its messages. After you connect the mailbox to an
account, the deleted mailbox retention period restarts if the mailbox is deleted again.
You can extend the deleted mailbox retention period on mailbox databases. However, extending the
deleted mailbox retention period causes the mailbox database to grow to hold the additional deleted
mailboxes.
You can permanently delete mailboxes with the Remove-Mailbox Permanent $True command.
9-26
Database Restores
You can restore a database to its original server and location, or to a different server. In Exchange Server
2003 and Exchange Server 2007, the database was a server-specific object, so recovering it to a different
server was extremely difficult. In Exchange Server 2010, moving database copies to different servers is
easier because the databases are completely portable.
You can restore and mount databases on any Exchange 2010 Mailbox server that is at the same service
pack level 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 that is
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.
Restoring a database to the original location overwrites the existing database with a restored copy of the
database. After you restore the database, you can replay the uncommitted transaction logs to bring the
database to its current state.
Note When you restore a database in Exchange Server 2003 and Exchange Server 2007, in
the Properties dialog box for the database, you have to select the This database can be
overwritten by a restore option. Otherwise, the restore can fail. In Exchange Server 2010,
using VSS-based restore, this option does not prevent you from overwriting the database, so
you should be careful before starting a restore.
Recovery Database
The recovery database restores databases without affecting current mailboxes. After you restore a
database to the recovery database, you can either copy messages to a folder, or merge them into user
mailboxes.
This type of restore recovers mailbox content for a single mailbox, without affecting other users. However,
the recovery database has the following requirements and characteristics:
1.
The server must have enough free disk space to restore the database. There must be enough total
storage space on the server to store two database copies simultaneouslythe live version, and the
restored version if you restore the database to the same server as the recovery database.
2.
You cannot use the recovery database to restore public folders.
Note You can only create and manage the recovery database from the Exchange
Management Shell. You can no longer use the Exchange Management Console for this task
as you could with Exchange Server 2003 and Exchange Server 2007.
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 new, empty dial-tone 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 the old data by merging the dial-tone database with the recovered database.
Dial-tone recovery allows you to recover from a serious system failure more quickly than recovering the
database from backup.
Note When a user with a cached mailbox connects to a dial-tone recovery database for the
first time, Exchange Server 2010 deletes the contents of the cache. Outlook gives you a
choice about whether it will connect to the online copy of the mailbox or the cached copy.
Using DAGs
9-27
By implementing multiple copies of mailbox databases in a DAG, you are much less likely to need to
perform a database restore. When one database copy in a DAG fails, Exchange Server 2010 automatically
mounts and redirects users to another database copy.
Question: You want to restore mailbox data because it was deleted by the user. How can
you do this, assuming you have a DAG with a lagged database, and single item recovery is
enabled?
9-28
Process for Recovering Data Using the Recovery Database
The recovery database is a restored database that can coexist on the same server that hosts the original
database. The recovery database replaces the Recovery Storage group that was available in Exchange
Server 2003 and Exchange Server 2007. As with the Recovery Storage group, only authorized
administrators can access the recovery database to recover single items, folders, mailboxes, or complete
databases from the recovery database.
Recovering Data Using the Recovery Database

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

You can use the recovery database in the following scenarios:
1.
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 production database from backup. You can then swap the
temporary and restored database, and then merge the messages sent to the temporary database into
the restored database.
2.
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.
3.
9-29
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 using single item recovery for this situation, as recovering the database might be
time consuming.
Question: On which Exchange 2010 server do you need to create the recovery database?
9-30
Process for Restoring Data from a Lagged Database Copy
A lagged database copy is a mailbox database copy that is configured with its replay log time property set
to greater than 0. The replay lag time allows you to return a database back to a specific point in time. You
replay the log files from a lagged database copy so that you can recover older mailbox content or a
database that was corrupted, for example, by a virus outbreak. For example, assume the lagged database
is five days old. This means that you can recover the database to any point within the last five days.
Replaying log files can be a time-intensive task; on average, you can play back about 7 GB of log files per
hour into a database.
Consider using this recovery method only when a user has deleted folder information, and recovering the
items using single item recovery is not sufficient.
Recovery Process
To recover messages from a lagged database, perform the following steps:
1.
Suspend the lagged database. Use the Exchange Management Shell or the Exchange Management
Console to suspend the lagged database on the Exchange 2010 server where the lagged database is
located.
2.
Copy the database and all transactional log files to another directory. This means that you can
activate an offline copy of the lagged database and not modify the lagged status of the original
database. Once you have copied the files, you can resume the lag database copy that you suspended
previously.
3.
Delete newer transactional log files and the checkpoint (.chk) file. Use Windows Explorer to delete
or move all log files from the log files time stamp that are newer than the time to which you are
returning. For example, if you have 14 days worth of log files available, and you want to replay the
log files to return to 10 days previously, you only need the log files that are 10 days and older.
Therefore, you need to delete or move all log files that have a time stamp newer than 10 days.
Delete the .chk file, but remember the log prefix for the file, because you need it in the next step.
4.
9-31
Replay log files, and then verify the clean database status. Run the Eseutil.exe /r E00 /a command,
but replace E00 with the log prefix of the .chk file. Depending on the number of log files that need to
replayed, this might take several hours. A rule of thumb is that on 7.2K just a bunch of disks (JBOD)
3.5-inch disks, you can assume that you will replay approximately 7.2 GB of transactional log files per
hour. The exact value, of course, depends on your local factors, such as storage performance or CPU.
Verify the state of the database by using the ESEUTIL /MH <database.edb> command. If the
database is still in Dirty Shutdown state, use ESEUTIL /P <database.edb> to clean the state.
5.
Create a recovery database from the lagged database copy, and then mount it. Run the following
command to create a new recovery database:
New-MailboxDatabase -Recovery -Name <recovery database name> -Server <server name>

-EDBFilePath "<path>\<database name>.edb" -LogFolderPath "<path>"
Next, run the following command to mount the recovery database:

Mount-Database <database name>
6.
Identify the mailbox to be recovered. Run the following command to view all mailboxes that are
available in the recovery database so that you can identify the one that you want to restore:
Get-MailboxStatistics Database <database name>
7.
Recover the mailbox content to a different mailbox. As you cannot directly recover the data to the
same mailbox, you should create another mailbox recovery mailbox into which you move the mailbox
items. Use the following command to recover data from the mounted recovery database:
New-MailboxRestoreRequest SourceStoreMailbox <Name or MailboxGuid>

-SourceDatabase <recovery database> -AllowLegacyDNMismatch
-TargetMailbox <Recovery Mailbox> -TargetRootFolder <DestinationFolder>
8.
Use Microsoft Office Outlook to recover items to the original mailbox. A best practice is to use Office
Outlook to open your original mailbox and your recovery mailbox, and then copy the items to their
target folders. This provides an easy process for the administrator to recover the desired items and
folders.
9.
Remove the recovery database. After recovering data from the recovery database, do not forget to
remove the recovery database. This will preserve processing power as well as disk space. To remove
the recovery database, use the following command:
Remove-MailboxDatabase <database name>
10. Finally, you need to delete the folder where you stored the database files, because Exchange Server
2010 does not do this automatically.
Question: In what situations should you consider recovering data from a lagged database
copy?
9-32
Process for Recovering Computers That Run Exchange Server 2010
When recovering a failed Exchange 2010 server, you have several options. The option you choose
determines the process that you use to restore the server.
Exchange Server Recovery Options

You can choose from among the following options when you need to replace a failed server:
1.
Restore the server. You can restore the server from a full computer backup set, and then restore your
Exchange Server 2010 information. When you restore a server, you are reproducing the server
configuration, including the server security identifier (SID). This option is feasible only if you have a
full server backupincluding the System State backupand you have replacement hardware that is
very similar to the failed server.
2.
Recover the server. This option involves performing a new installation of Windows Server and an
Exchange Server 2010 installation in Recover Server mode, which gathers the previous settings from
AD DS, and then restores your Exchange Server 2010 databases.
3.
Use a standby server. You can use a standby recovery server as part of the Mailbox server recovery
strategy. This option involves keeping recovery servers available with the operating system and other
software installed. Having available standby recovery servers reduces the time you need to rebuild a
damaged server.
Note Exchange Server 2010 does not have any direct dependency on an Exchange Servers
SID. We recommend that you do not use the restore server option for recovering Exchange
2010 servers. Instead, you should recover the server using the Recover Server installation
mode.
9-33
What Is Recover Server Mode?
If an Exchange 2010 server fails and is unrecoverable and needs replacement, you can perform a server
recovery operation. Exchange Server 2010 Setup includes a switch called /m:RecoverServer that you can
use to perform the server recovery operation.
Running Exchange Server Setup with the /m:RecoverServer switch causes Setup to read configuration
information from AD DS for the server with the same name as that from which you are running Setup.
After you gather the servers configuration information from AD DS, the original Exchange Server 2010
files and services are installed on the server, and the Exchange server roles and settings that AD DS stored
are applied to the server.
Important When you run Exchange Server Setup in Recover Server mode, it must be able
to connect to AD DS and to read the Exchange Server 2010 configuration information that
links to the name of the computer that is running Exchange Server 2010 setup. This means
that the computer account must still exist in AD DS. If you delete the computer account, you
will not be able to restore the Exchange 2010 server unless if you can restore the Active
Directory account.
Restoring a Server Using Recover Server Mode

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

3.
4.
5.
6.
If required, connect to the virtual machines. Log on to NYC-DC1 and NYC-EX10 as

Contoso\Administrator using the password Pa$$w0rd.
Lab Scenario
You are a messaging administrator for Contoso, Ltd. Your organization has deployed Exchange Server
2010. You need to ensure that the Exchange servers in your organization are protected in the event of a
server or data center failure. You need to implement disaster recovery using lagged copies, ensure that all
Exchange Server-related data is backed up, and ensure that you can restore the full server or database,
and mailboxes and mailbox contents. As you are an experienced administrator, you create the DAG using
the Exchange Management Shell.
9-35
Exercise 1: Implementing Disaster Recovery with DAGs

Scenario
Your organization is concerned about the loss of a database in the event of logical database corruption.
The organization also wants to be able to use a lagged copy as an alternative for recovering mailbox data
that users accidently delete. Your new DAG will include two Mailbox servers, and you have decided to use
a 5-day replay lag time for one of the database copies.
Create and configure a DAG using the Exchange Management Shell.
Configure a lagged copy of a mailbox database.
Delete the lagged database copy, and reseed the database copy.
Task 1: Create and configure a DAG using the Exchange Management Shell
1.
On NYC-EX10, in the Exchange Management Shell, run the following command:

C:\FSWDAG1 DatabaseAvailabilityGroupIPaddresses 10.10.0.99.
2.
Run Add-DatabaseAvailabilityGroupServer DAG1 MailboxServer NYC-EX10.
3.
Run Add-DatabaseAvailabilityGroupServer DAG1 MailboxServer NYC-EX11.
4.
Run Add-MailboxDatabaseCopy Mailbox Database 1 MailboxServer NYC-EX11.
Task 2: Configure a lagged copy of a mailbox database

1.
In the Exchange Management Shell, run Set-MailboxDatabaseCopy Mailbox Database 1\NYCEX11 ReplayLagTime 5.0:0:0. This command delays committing transaction logs to the
Accounting database on NYC-EX11 for five days.
2.
Run Suspend-MailboxDatabaseCopy Mailbox Database 1\NYC-EX11 ActivationOnly

Confirm:$false.
Task 3: Delete the lagged database copy, and reseed the database copy
1.
In a Windows Explorer window, browse to C:\Program Files\Microsoft\Exchange

Server\V14\Mailbox\Mailbox Database 1, and then delete the file Mailbox Database 1.edb.
2.
In the Exchange Management Shell, expand Microsoft Exchange On-Premises, expand

Organization Configuration, click Mailbox, and then click Mailbox Database 1.
3.
In the Mailbox Database 1 pane, right-click Mailbox Database 1 on Mailbox Server NYC-EX11, and
then click Suspend Database Copy.
4.
Right-click Mailbox Database 1 on Mailbox Server NYC-EX11, and then click Resume Database
Copy.
5.
In the Mailbox Database 1 pane, on the Database Copies tab, right-click the empty space, and then
click Refresh. Now the Copy Status of Mailbox Database 1 on Mailbox Server NYC-EX11 should
display Failed and Suspended.
6.
Right-click Mailbox Database 1 on Mailbox Server NYC-EX11, and then click Update Database
Copy.
7.
Run the Update Database Copy Wizard with the following settings:
9-36
Select a source server for seeding: NYC-EX10
Delete them and continue the update process: selected
Results: After this exercise, you should have created and configured a DAG, added a lagged database
copy to the DAG, and reseeded the database copy.
9-37
Exercise 2: Backing Up Exchange Server 2010

Scenario
You need to back up the Exchange Server 2010 database correctly so that you restore data as needed. As
Contoso, Ltd is a small company, you decide to use Windows Server Backup to back up your Exchange
Server 2010 data to another disk.
1.
Populate a mailbox.
2.
Perform a backup of the active mailbox database using Windows Server Backup.
Task 1: Populate a mailbox

1.
On NYC-EX10, in Outlook Web App, log on as Contoso\Christine using the password Pa$$w0rd.
2.
Create a new message to Kern with the subject Message before Backup, and then send it.
Task 2: Perform a backup of the active mailbox database using Windows Server
Backup
1.
In Server Manager, add the Windows Server Backup feature.
2.
Use Windows Server Backup to create a local backup using the following settings:
3.
Backup: Backup once
4.
Select Backup Configuration: Custom
5.
Select Items for Backup: Local disk (C:)
6.
Advanced Settings: VSS full Backup
7.
Specify Destination Type: Local drives
8.
Select Backup Destination: Allfiles (D:)
Results: After this exercise, you should have added the Windows Server Backup feature, and created a
backup of all active databases.
9-38
Exercise 3: Restoring a Database in a DAG

Scenario
The mailbox databases on one of your Exchange 2010 servers are damaged. You decide to restore to the
most recent backup, but do not consider any transactional log files on the server.
1.
Delete messages in a mailbox.
2.
Restore the databases using Windows Server Backup.
3.
Verify the recovery.
Task 1: Delete messages in a mailbox

1.
On NYC-EX11, connect to https://nyc-ex11.contoso.com/owa, and then log on to Contoso\Kern

using the password Pa$$w0rd.
2.
Delete the message with the subject Message before Backup.
3.
Right-click Deleted Items, and then click Empty Deleted Items.
Task 2: Restore the databases using Windows Server Backup

1.
On NYC-EX10, use Windows Server Backup to recover the Exchange Server 2010 databases using the
following settings:
a.
b.
c.
d.
e.
Restore to: This Server (NYC-EX10)

Recovery Type: Applications
Applications: Exchange
Click Do not perform a roll-forward recovery of the application database
Recovery Options: Recover to original location
Task 3: Verify the recovery

1.
In Outlook Web App, log on as Contoso\Kern using the password Pa$$w0rd.
2.
Ensure the message with the subject Message before Backup displays in the Inbox.
Results: After this exercise, you should have deleted a message from a mailbox, recovered all Exchange
Server 2010 databases using Windows Server Backup, and verified that the recovery was successful.
9-39
Exercise 4: Recover a Lagged Database Copy to a Point in Time

Scenario
One of your users deleted a subfolder in his Inbox, which contained an important folder structure. As the
Exchange Server 2010 administrator, you understand that you can recover the items by using single item
recovery, but you cannot recover the folder structure. You decided to use the lagged database copy to
recover the mailbox.
1.
Delete messages and folders from the mailbox.
2.
Suspend the lagged database, and copy it to the target folder.
3.
Configure the database recover time by deleting log files before merging them into the database.
4.
Create and mount a recovery database for the lag database.
5.
Restore the mailbox from the recovery database, and verify successful recovery.
Task 1: Delete the messages and folders from the mailbox

1.
On NYC-EX11, log on to Contoso\Spencer using the password Pa$$w0rd,
2.
Expand Inbox, and then delete the OldEmail folder.
3.
Right-click Deleted Items, and then click Empty Deleted Items.
Task 2: Suspend the lagged database, and copy it to the target folder
1.
In the Exchange Management Console, in Organizational Configuration, in Database Management,

suspend Mailbox Database 1 on Mailbox Server NYC-EX11.
2.
Use a Windows Explorer window to copy all files from C:\Program Files\Microsoft\Exchange
Server\V14\Mailbox\Mailbox Database 1 to C:\Lag.
Task 3: Configure the database recover time by deleting log files before merging
them into the database
1.
In a Windows Explorer window, in folder C:\Lag, delete the most recent transactional log files.
2.
If a .chk file exists in the folder, delete it.
3.
At the command prompt, run Eseutil.exe /r E00 /a /in. This process will replay the old transactional
log files and make the database as current as your provided log files.
4.
Run Eseutil.exe /P Mailbox Database 1.edb.
5.
Run Eseutil.exe /mh Mailbox Database 1.edb, and then verify a Clean Shutdown state.
Task 4: Create and mount a recovery database for the lag database
1.
In the Exchange Management Shell, run the following command:
New-MailboxDatabase -Recovery -Name LagRecovery -Server NYC-EX11 -EDBFilePath

"C:\Lag\Mailbox Database 1.edb" -LogFolderPath "C:\Lag".
2.
Run Mount-Database LagRecovery.
3.
Run Get-MailboxStatistics Database LagRecovery to view a list of all mailboxes that are part of
the recovery database.
9-40
Task 5: Restore the mailbox from the recovery database, and verify successful
recovery
1.
In the Exchange Management Shell, run the following command:
New-MailboxRestoreRequest SourceStoreMailbox Spencer Low SourceDatabase LagRecovery

AllowLegacyDNMismatch TargetMailbox Lag TargetRootFolder Restore Spencer.
2.
Run Get-MailboxRestoreRequest, and ensure the status is Completed.
3.
Log on to Outlook Web App as Contoso\Lag using the password Pa$$w0rd, and verify that the
OldEmail folder, subfolders, and messages have been restored.
Results: After this exercise, you should have deleted messages and folder from a mailbox, suspended the
lagged database copy, and copied the lagged database to a different location. Then, you will have deleted
the transactional log files that included the changes you wanted to revert, the .chk file, and used ESEUTIL
to get the database to a clean shutdown state. Finally, you will have created a recovery database using the
database file from the lag database, and recovered a mailbox from the recovery database.

following steps:
1.
2.
3.
4.
Repeat steps 1-3 for 10165A-NYC-EX10-B, and 10165A-NYC-EX11-B.
5.
machine.
6.
machine.
7.
machine.
8.
machine.
9-41
Review Questions
1.
What kind of backup options for Exchange Server 2010 do you find suitable for your organization?
2.
What options does Exchange Server 2010 include for restoring a single item from a mailbox?
Common Issues Related to Recovering Messages

Identify the causes for the following common issues related to recovering messages and fill in the
Issue
Troubleshooting tips
Recover deleted mailbox items quickly.

Restore fails during an emergency situation.
Best Practices Related to Implementing Backup and Recovery

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

10-44
Lesson 4: Configuring Archive Mailboxes
10-51
Lesson 5: Configuring Retention and Archive Policies
10-59
Lab B: Configuring Archive Mailboxes and Retention Policies
10-73
10-2
Module Overview
Organizations today are required quite often to produce evidence for litigation, or provide
documentation, to prove that they are in compliance with regulations. Organizations that consider
compliance when they plan their information technology infrastructuresincluding their email
infrastructurescan supply the required documentation on demand with less effort. They can also comply
with other regulatory requirements more easily.
Organizations that do not consider compliance up-front may find themselves wasting both time and
money attempting to track down the required information. Organizations can also be held legally
responsible for not complying with laws or regulatory requirements.
Microsoft Exchange Server 2010 provides new tools for complying with a growing number of legal,
regulatory, and internal policy and compliance requirements in relation to email. Most organizations must
be able to filter email delivery based on several criteria, and to manage email retention and deletion. In
addition, it is very important for organizations to manage mail archiving according to regulatory and legal
policy. This module describes how to configure the Exchange Server 2010 messaging policy and
compliance features.
Objectives
Describe messaging policy and compliance.
Configure transport rules.
Configure journaling and Multi-Mailbox Search.
Configure archive mailboxes.
Configure Retention and Archive Policies.
10-3
Lesson 1
Introducing Messaging Policy and Compliance
Governments in most countries have implemented legislation regarding the archiving of certain
information. Depending on the location, corporations may also have their information regulated by local,
regional, or state laws or regulations. In addition, many organizations have implemented their own
corporate security policies that limit how to share and track information within the organization.
Because email is recognized as a critical business tool, you must configure your organizations messaging
system so that it is compliant with government legislation and corporate policies. By understanding the
laws and regulations that apply to your organization, you can use the tools in Exchange Server 2010 to
take proactive steps and ensure your corporations compliance.
Messaging policies in Exchange Server 2010 enable messaging administrators to manage email messages
that are in transit and at rest, and ensure that your organization complies with policy requirements. This
lesson provides an overview of messaging policies and their use.
Objectives
Describe messaging policy and compliance requirements.
Identify compliance requirements in your organization.
Describe the options for enforcing messaging policy and meeting compliance requirements.
10-4
Messaging Policy and Compliance Requirements
Organizations are faced with a wide variety of compliance requirements for how they manage data.
Because messaging plays a central role in many organizations, these requirements extend to the Exchange
Server environment.
The Messaging compliance features in Exchange Server 2010 consist of a set of rules and settings that
control message flow and storage. The following list provides several examples of times when your
organization may need to utilize Exchange Server 2010 features:
Restricting message flow. In certain scenarios, you may need to block messages that potentially
contain sensitive data.
Data retention policies. Many organizations are required to keep data for a specific time, and then
remove that data to protect privacy.
Privacy and confidentiality requirements. Organizations transmit sensitive and confidential

information through email on a daily basis. These emails must be protected to maintain the privacy of
individuals and the confidentiality of communications.
Ethical walls. Organizations within the securities and financial fields are frequently required to
prohibit communication between specific groups in their own organization.
Discovery requests. Organizations that are subject to litigation can request or be requested for
information. Because most business communication occurs over email, information request
compliance requires the ability to search mailbox content, including email messages and attachments.
You use these features to apply rules to messages as your organizations users send and receive them, to
regulate how users store messages, and to search all user mailboxes for messages based on a variety of
criteria.
10-5
Discussion: Compliance Requirements
Users typically send a large amount of business information by email. This information may include
confidential information, such as customer data or business intelligence. Exchange Server 2010 messaging
policies provide features that help you comply with both legal requirements and corporate messaging
policies.
Question: What type of business does your organization conduct? What are some legislated
compliance requirements for your organization?
Question: What additional compliance requirements does your organization have?
Question: How are you currently meeting your organizations compliance requirements?
10-6
Options for Enforcing Messaging Policy and Compliance
Exchange Server 2010 provides many new options for implementing messaging policies, while other
Exchange Server 2010 options were present in somewhat different forms in Exchange Server 2003 and
Exchange Server 2007. Some of the most important technologies for messaging compliance in Exchange
Server 2010 are:
Transport rules. You can define transport rules on both the Edge Transport and Hub Transport
servers. On Edge Transport servers, you can restrict message flow based on: message data, such as
specific words or text patterns in the message subject, body, header, or From address; the spam
confidence level (SCL); and attachment type. You can configure the transport rules to quarantine
messages, drop or reject a message, append additional recipients to a message, and log an event.
While transport rules were present in Exchange Server 2007, Exchange Server 2010 provides
additional features to this functionality.
Rights management integration. Exchange Server 2010 enables integration with Active Directory
Rights Management Service (AD RMS) to apply policies that restrict what recipients can do with their
received messages. For example, you can restrict users from printing or forwarding messages. You can
also use Microsoft Office Outlook or transport rules to enforce AD RMS templates, so that the Office
Outlook client or the Hub Transport server will apply the template based on specified message
criteria.
Message journaling. Exchange Server 2010 provides several options for message journaling (saving
copies of messages). You can journal messages according to the messages distribution scope, and
you can define the conditions that trigger the journaling action by specifying criteria such as an
individual user, sender, or the recipients distribution-list membership. You can also configure
message journaling for specific mailbox databases, or implement message journaling as part of a
messaging records management (MRM) deployment. Message journaling exists on all Exchange
Server versions. However, on Exchange Server 2007 and 2010, it is implemented on transport level.
10-7
Mailbox searching. Multi-Mailbox Search is a new Exchange Server 2010 feature that enables users
with the appropriate permissions to search all mailboxes for specific content. The Multi-Mailbox
Search functionality is available through the Exchange Control Panel. The Multi-Mailbox Search
interface allows you to conduct searches across multiple mailboxes for items, including email,
attachments, calendar items, tasks, and contacts.
Message retention and deletion. Administrators can use the messaging records management features
to retain messages as required by organizations for business or legal reasons, and to delete
unnecessary messages. You can apply retention policies to folders that the administrator creates, and
to default mailbox folders such as the Inbox or Sent Items folders. When a message reaches a
specified retention limit, administrators can configure the messaging records management features to
archive, delete, or log the message, or flag it for user attention. While Exchange Server 2007 managed
messaging records management by using managed folders, in Exchange Server 2010, this concept
was enhanced with Retention Policy Tags and retention policies that will be discussed later.
Personal archives. Exchange Server 2010 allows you to create archive mailboxes for users to store
contents of .pst folders and old messages that they want to retain. A key new feature for Exchange
Server 2010 is that you can now search and manage archive mailboxes just like other mailboxes on
the Exchange servers. This technology was not available in previous versions of Exchange Server.
10-8
Lesson 2
Configuring Transport Rules
Transport rules let you apply messaging policies to email messages that flow through the transport
pipeline on Hub Transport and Edge Transport servers. These rules allow IT administrators to comply with
messaging policies by securing messages, protecting messaging systems, and preventing information
leakage.
You also can use transport rules to apply rights management policies to messages, so you can control the
level of access for specific data that is being sent within the message. This lesson describes how to
implement transport rules in Exchange Server 2010.
Objectives
Describe transport rules.
Describe transport rule components.
Explain how to configure transport rules.
Describe message classifications.
Describe AD RMS, and how it works.
Describe AD RMS integration with Exchange Server 2010.
Explain how to configure AD RMS integration.
Describe options for configuring moderated transport.
Explain how to configure moderated transport.
10-9
What Are Transport Rules?
Transport rules are rules that you create in Exchange Server 2010 and apply to email messages during
transport. Implementing transport rules ensures that all email messages sent within the organization or to
external recipients meet your organizations compliance requirements. Transport rules were also present
in Exchange Server 2007, but they are improved in Exchange Server 2010.
Exchange Server 2010 applies transport rules to messages as they pass through Edge Transport or Hub
Transport servers. The Transport Rule agent applies transport rules on Hub Transport servers, and the
Edge Rule agent applies them on Edge Transport servers. Transport rules restrict message flow or content
modification while messages are in transit.
With transport rules, you can:
Prevent specified users from sending or receiving email messages from other specified users.
Prevent inappropriate content from entering or leaving the organization.
Apply restrictions based on message classifications to restrict the flow of confidential organization
information.
Track or journal messages that specific individuals send or receive.
Redirect incoming and outgoing messages for inspection before delivery.
Apply disclaimers to messages as they pass through the organization.
Apply AD RMS templates to the messages, based on message criteria.
Transport Rules on Hub Transport Servers
Transport rules configured on one Hub Transport server automatically apply to all other Hub Transport
servers in the Exchange Server 2010 organization. Exchange Server 2010 stores the transport rules in the
Configuration container in Active Directory Domain Services (AD DS), and replicates them throughout the
Active Directory forest so that they are accessible to all other Hub Transport servers. This means that
10-10
Exchange Server 2010 applies the same transport rules to all email messages that users send or receive in
the organization.
You can use Hub Transport rules to manage email messages sent inside in the organization. For example,
to prevent certain users from sending email messages to other users, to assign message classifications to
messages sent within the organization, you configure a Hub Transport rule. You can also use Hub
Transport rules to manage messages that the organization sends and receives. To attach a disclaimer to all
messages sent to internal or external recipients, use a Hub Transport rule.
Transport Rules on Edge Transport Servers
Exchange Server 2010 applies transport rules that you configure on an Edge Transport server only to
email messages that pass through that specific Edge Transport server. The transport rules are stored in
Active Directory Lightweight Directory Services (AD LDS), and Exchange Server 2010 does not replicate
them to other Edge Transport servers. Therefore, you can configure Edge Transport servers to apply
distinct transport rules, depending on the email messaging traffic that they manage.
If you have more than one Edge Transport server and you want to apply a consistent set of rules across all
Edge Transport servers, you must configure each server manually, or export the transport rules from one
server and import them into all other Edge Transport servers.
Only use Edge Transport rules to manage messages that users send to, or receive from, the Internet. For
example, if you need to attach a disclaimer only to messages sent to the Internet, you use an Edge
Transport rule. If you need to filter or modify message flow based on key words, use an Edge Transport
server rule to apply the restrictions before messages enter the organization.
Note Although the process for creating transport rules on Hub Transport servers and Edge
Transport servers is similar, the options available when creating the rules are not identical.
For example, when configuring the recipients to whom a rule will apply on a Hub Transport
server, you can configure specific recipients based on the global address list (GAL). On the
Edge Transport server, you can configure recipients based on text patterns in the Simple Mail
Transfer Protocol (SMTP) addresses, rather than on specific GAL recipients.
10-11
Transport Rule Components
All transport ruleswhether they apply to Hub Transport or Edge Transport serversare configured in
the same way. For creating a transport rule, you can use a wizard in the Exchange Management Console,
or you can use the New-TransportRule cmdlet in the Exchange Management Shell. Either way, you must
configure several components for the transport rule to become active.
Transport Rule Components

When configuring transport rules, consider the following components:
Conditions. Transport rule conditions indicate which email message attributesheaders, recipients,
senders, or other parts of the messageExchange Server uses to identify the email messages to which
it applies a transport rule action. If the email message data matches a transport rule conditions value,
Exchange Server 2010 applies the rule, provided that the condition does not match an exception.
You can configure multiple transport rule conditions to narrow the rules scope to very specific
criteria. Conversely, you can decide not to apply any conditions, which means that the transport rule
then applies to all messages. There is no limit to how many conditions you can apply to a single
transport rule.
Note If you configure multiple conditions on the same transport rule, all the conditions
must be met for the transport rule to apply to a particular email message. When you specify
multiple values on a single condition, the condition is satisfied if at least one of the values is
met.
Actions. Exchange Server applies actions to email messages that match the conditions 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.
10-12
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 2010 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 2010 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.
Regular Expressions in Transport Rules
Before defining regular expressions, you must first understand the simple expressions that can be used in
transport rules. A simple expression is a specific value that must be matched exactly in a message.
Predicates using simple expressions match specific words or strings. For example, a simple expression
could be the title of a document that your organization does not want to be distributed outside the
organization, such as Yearly Sales Forecast.doc. A piece of data in an email message must match a simple
expression exactly to satisfy a condition or exception in transport rules. If the previous title is changed to
YearlySalesForecast.doc (spaces removed), it will no longer match the transport rule. This is why using
simple expressions is inefficient.
Instead of specifying all possible variations for simple expressions, you can configure the transport rule
predicate to search for a text pattern using regular expressions. Unlike simple expressions, a regular
expression is a concise and flexible notation for finding patterns of text in a message. The notation consists
of two basic character types:
Literal characters. Text that must exist in the target string. These are normal characters, as typed.
Metacharacters. One or more special characters that are not interpreted literally. These indicate how
the text can vary in the target string.
You can use regular expressions to quickly parse email messages to find specific text patterns in different
parts of a messagesuch as message headers, sender, recipients, message subject, and body. This enables
you to detect messages with specific types of content, such as social security numbers (SSNs), patent
numbers, and phone numbers. You cannot reasonably match this type of data with a simple expression,
because a simple expression requires that you enter every possible variation of the value that you want to
detect. In many cases, using simple expressions for such applications becomes a logistical challenge, and
matching a large number of simple expressions in message content can be resource-intensive.
10-13
The following code sample demonstrates how to create a transport rule that uses a regular expression to
prevent sending messages that contain social security numbers. The regular expression used here is
\d\d\d-\d\d-\d\d\d\d. The portion \d\d\d requires that exactly three numeric digits appear in the first
segment, then two digits in the second, and four in the third segment.
New-TransportRule -Name "Social Security Number Block Rule" SubjectOrBodyMatchesPatterns '\d\d\d-\d\d-\d\d\d\d' -RejectMessageEnhancedStatusCode
"5.7.1" -RejectMessageReasonText "This message has been rejected because of content
restrictions"
In the following topic, you will see a demonstration of how to configure transport rules by using the
Exchange Management Shell to run cmdlets.
10-14
Demonstration: How to Configure Transport Rules
In this demonstration, you will review how to configure transport rules. You can configure transport rules
by using either the Exchange Management Console or the Exchange Management Shell. If you are using
the Exchange Management Console on a Hub Transport server, access the Hub Transport container in the
Organization Configuration work area.
The following table describes the cmdlets you run to configure transport rules by using the Exchange
Management Shell.
Cmdlet
Description
Get-TransportRule
New-TransportRule
Remove-TransportRule
Set-TransportRule
Enable-TransportRule
Disable-TransportRule
These cmdlets create, remove, and configure transport rules.
Get-TransportRuleAction
This cmdlet retrieves a list of all available transport rule actions.
Get-TransportRulePredicate
This cmdlet retrieves a list of all available rule predicates.
Import-TransportRuleCollection
Export-TransportRuleCollection
These cmdlets import and export a set of transport rules configured

on a Hub Transport server or Edge Transport server.
10-15
Note Implementing transport rules with security features such as digital signatures or
encryption can result in potential issues. For example, if you add a disclaimer to digitally
signed messages, the signature becomes invalid. When users open the message, the original
message displays as an attachment, and only the signature that the transport rule adds is
visible in plain text. If users encrypt messages by using Secure Multipurpose Internet Mail
Extensions (S/MIME) or another encryption tool, the transport rules can access the message
envelope headers and process messages based on unencrypted information. Transport rules
that require inspection of message content, or actions that may modify content, cannot
process with encrypted messages.
Demonstration Steps
Configure transport rules to apply a disclaimer and a restriction
1.
2.
Under Organization Configuration, in the Hub Transport node, create a new transport rule with
the following configuration:
Name: Company Disclaimer HTML.
Condition: sent to users that are inside the organization.
Action: append disclaimer text and fallback to action if unable to apply.
Disclaimer text: Type the following.
<html>
<body>
 &nbsp
 &nbsp
This e-mail and attachments are intended for the individual or group
addressed.
</body>
</html>
3.
Open the Exchange Management Shell.
4.
Type the following cmdlet.
New-TransportRule -Name Social Insurance Number Block Rule SubjectOrBodyMatchesPatterns \d\d\d-\d\d\d-\d\d\d -RejectMessageEnhancedStatusCode
5.7.1 -RejectMessageReasonText This message has been rejected because of content
restrictions
5.
Test the transport rules:
Send a message from one internal user to another. Verify that the HTML disclaimer is attached.
Send a message from one internal user to another with the string 111-111-111 in the message
body. Verify that the sender receives a non-delivery report (NDR).
10-16
Note In a regular expression, the \d pattern string matches any single numeric digit. You
can use a variety of pattern strings to search the message contents for a consistent pattern.
For example, you can use \s to represent a space, or \w to represent any letter or decimal
digit. For detailed information about configuring regular expressions in a transport rule, see
the topic Regular Expressions in Transport Rules in Exchange Online Help.
Question: What transport policies will you need to implement in your organization?
What Are Message Classifications?
10-17
Message classifications enable users or transport rules to mark a message with a label. Message
classifications are available in Exchange Server 2010 and Exchange Server 2007, in Office Outlook 2010,
Office Outlook 2007, and Outlook Web App.
When a message is classified by a transport rule or a user, the message receives extra metadata. This
metadata contains additional information about the recipient or sender of the message, or some other
information about the message that can be used as a parameter for classification. Office Outlook 2007,
Office Outlook 2010, or Outlook Web App then act on this metadata and display the classifications
description to the message senders and receivers. In Exchange Server 2010, you can also configure a
transport rule that acts on the metadata by applying an action based on the classification. For example,
you can block messages with a specific classification from being sent outside the organization.
The following list provides a brief description of some of the message classification fields that you can set:
Display name. This property specifies the display name for the message classification instance. The
display name appears in the Permission menu in Office Outlook 2007, Outlook 2010, and Outlook
Web App, and is used by Office Outlook and Outlook Web App users to select the appropriate
message classification before a message is sent. The display name is also displayed in the recipient
description that appears in the InfoBar in an Office Outlook message. The parameter name for this
property is DisplayName.
Sender description. This property explains to the sender what the message classification is intended
to achieve. The text that you enter for this field is used by Office Outlook and Outlook Web App users
to select the appropriate message classification before a message is sent. The parameter name for this
property is SenderDescription.
Recipient description. This property explains to the recipient what the message classification was
intended to achieve. The text that you enter for this field is viewed by Office Outlook and Outlook
Web App users when they receive a message that has this message classification. The parameter
name for this property is RecipientDescription.
10-18
Locale. This field specifies a culture code to create a locale-specific version of the message
classification. The parameter name for this property is Locale.
Managing Message Classifications

Exchange Server 2010 enables the following message classification fields by default:
Attachment Removed. This classification notifies recipients when attachments have been removed
from the message.
Originator Requested Alternate Recipient Mail. This classification notifies recipients that the message
has been redirected from delivery to the original addressed recipient.
Partner Mail. This classification notifies recipients that the message was encrypted and delivered
through a secure connector.
As an Exchange Server administrator, you can manage message classifications in the following ways:
Review the message classifications configured on the server. Use the Get-MessageClassification
cmdlet to view the message classifications.
Modify the default message classifications. Exchange Server administrators can customize the sender
description for each message classification and locale. Use the Set-MessageClassification cmdlet to
configure the message classification on the Exchange server.
Create new message classifications. Use the New-MessageClassification cmdlet to create new
message classifications.
Enable message classifications for Office Outlook 2007 or Office Outlook 2010 clients. By default,
Office Outlook clients do not support message classifications. To enable message classifications, you
must:
1.
2.
3.
Export the message classifications to an .xml file. To do this, run the ExportOutlookClassification.ps1 script in the Scripts folder on an Exchange Server 2010 server. The
output of this script is an .xml file describing all of the classifications available on the server.
Deploy the .xml file that contains definitions of the message classifications to each client
computer that uses these classifications. You must re-create and re-deploy this file whenever you
update the message classification list on an Exchange server.
Create a new registry key that enables message classification and references the
Classifications.xml file on the client computer.
Note For detailed information about deploying message classifications for Outlook
2007/2010, see the topic, Deploy Message Classification for Outlook 2007 in the Exchange
Server Help file.
Using Message Classifications

There are two options for using message classifications:
Users can add a message classification to an email when they create it. When using Outlook Web
App, Office Outlook 2007, or Office Outlook 2010 with the appropriate configuration, users can
classify any message.
10-19
Administrators can add a message classification as the result of a transport rule. For example, when
the Attachment Filter agent removes an attachment from a message, the Attachment Removed
message classification attaches to the message. You can also create a transport rule that adds a
message classification to a message based on any conditions in the email message.
What Is Active Directory Rights Management Service?
AD RMS is an information-protection technology that works with AD RMS-enabled applications to help

safeguard digital information from unauthorized use. The primary intention of using AD RMS is to protect
an organizations intellectual property, meet new governmental regulations, or better track and control
access to company data. Using an AD RMS server and the AD RMS client, you can augment an
organization's security strategy by protecting information through persistent usage policies, which remain
with the information no matter where it is moved. You can use AD RMS to help prevent sensitive
informationsuch as financial reports, product specifications, customer data, and confidential email
messagesfrom intentionally or accidentally getting into the wrong hands.
Restrict Access to an Organizations Intellectual Property

Use AD RMS to restrict access to digital information so that users can view, change, or print
documentation only. This protects data by preventing users from forwarding, copying, or otherwise
transporting sensitive data outside the company network.
Limit the Actions Users Can Perform on Content
Enforce restrictions that limit the specific actions that a user can perform on a document or email
message. You can use Microsoft Office Word, Office Excel, and Office PowerPoint as AD RMS-enabled
applications. These applications allow you to set rights for viewing, changing, saving, and printing
documents, and to set the length of time a particular right is active. Depending on the application you are
using, you can limit the action on content to the following restrictions:
View-only
Prevent change
10-20
Prevent print
Set expiration times on the content
AD RMS used with Office Outlook helps you protect email content. You can prevent users from
forwarding sensitive email messages to other email users, printing email messages, using messages offsite,
or copying the messages to unauthorized users.
AD RMS Components
Several components interact with AD RMS. Each of these components must be configured when
deploying an AD RMS solution:
Author. The user or service that generates the rights-protected document.
AD RMS-enabled applications. Specific applications are enabled for, and can interact with, AD RMS.
Authors can use these applications to create and protect content, and recipients can use them to read
protected content and apply the appropriate rights to them.
Recipient. The user or service that accesses the rights-protected document.
AD RMS server. The server with an installed AD RMS server role. This server is responsible for
providing the licenses that control access to content. When you install the first AD RMS server,
Exchange Server creates an AD RMS root cluster. You can add other AD RMS servers to the cluster.
Database server. AD RMS requires a database service. The Windows Internal Database feature
deployed on the same server as the AD RMS server provides this service, as does the Microsoft SQL
Server installed on another computer. The database stores configuration and other AD RMS-related
information.
AD DS and Active Directory. These services authenticate authors and recipients so that Exchange
Server applies the appropriate rights to the content.
How AD RMS Works
10-21
The AD RMS components work together to enable secure creation, distribution, and consumption of
protected data.
The following steps describe how AD RMS components interact to generate and protect rights-protected
content:
1.
The first time a user tries to rights-protect content by using AD RMS, the client application requests a
rights account certificate and client licensor certificate from the AD RMS server. This request only
occurs once for each user. It enables the user to publish online or offline, and to consume rightsprotected content.
2.
The author then creates content by using an AD RMS-enabled application. The author can create the
file, and then specify user rights. Additionally, the AD RMS server generates the policy license
containing the user policies.
The application then generates the content key and encrypts the content with it. This process differs
slightly depending on whether you publish the content online, with access to the AD RMS server, or
whether you publish offline. The differences are:
3.
Online publishing encrypts the content key with the AD RMS server public key and sends it to the
AD RMS server. The AD RMS server creates and signs the publishing license.
Offline publishing encrypts the content key with the client licensor certificate public key and
encrypts a copy of the key with the AD RMS server public key. The client then creates the
publishing license and signs it with the client licensor certificate private key. Afterwards, it
appends the publishing license to the encrypted content.
The author sends the rights-protected content to the recipient.
10-22
4.
The recipient receives the file and opens it by using an AD RMS-enabled application or browser. If the
recipients computer does not contain an account certificate, the client application requests a
certificate, and the AD RMS cluster issues one. If this is the first time the recipient has tried to access
rights-protected content on the computer, the AD RMS server also issues a rights account certificate.
The application sends a request for a use license to the AD RMS cluster that issued the publishing
license. However, if the file was published offline, the application also sends a request to the server
that issued the client licensor certificate. The request includes both the rights account certificate and
the publishing license for the file.
The AD RMS cluster confirms or denies the recipients authorization. If the AD RMS cluster denies the
users authorization, the cluster checks for a named user and then creates a use license for the user.
The cluster decrypts the content key by using the clusters private key and re-encrypts the content
key with the recipients public key. It then adds the encrypted session key to the use license. This
ensures that only the intended recipient can access the file.
5.
The AD RMS cluster sends the generated use license to the recipients computer. The application
examines both the license and the recipients account certificate. Exchange Server then grants the
user access as per the content authors specifications.
How AD RMS Integrates with Exchange Server 2010
10-23
Exchange Server 2010 and AD RMS integrate to provide several options for ensuring content protection
when users send messages through email. To use any of these AD RMS features, you must have both
Exchange Server 2010 and Windows Server 2008 installed.
Enable Users to Protect Content
After deploying AD RMS in an organization, Office Outlook users can control who reads, copies, or
forwards messages regardless of where the messages are stored. When users create email messages, they
can set limits on what the message recipients can do with the messages. This functionality does not
require any Exchange Server 2010 components other than those used for message delivery.
Implement AD RMS Prelicensing
One of the issues with using RMS to protect email is that the recipient must be able to connect to the AD
RMS server to read the protected email. This is an issue when users access their email while using Outlook
Anywhere, using a Microsoft Exchange ActiveSync device, accessing email through Outlook Web App, or
while offline. However, AD RMS prelicensing enables offline access to protected mail, and makes it faster
to open protected mail from Office Outlook and other mobile clients. In this scenario, protected messages
already contain the recipients end-user license, which Exchange Server requires to decrypt and view the
message upon delivery.
In Exchange Server 2010, the RMS Prelicensing built-in agent is on all Hub Transport servers, and is
enabled by default for the Exchange Server 2010 organization. You can disable the Prelicensing agent
with the Set-IRMConfiguration -PrelicensingEnabled $false cmdlet.
Implement Outlook Protection Rules
Outlook Protection Rules allow you to rights-protect messages by applying an RMS template before the
message is sent. Outlook Protection Rules automatically trigger the client to apply an RMS template
(based on sender/receiver) to mail prior to it sending. This feature also enables administrators to allow
users to manually add or remove protection policies from a message.
10-24
Note
Outlook Protection Rules are only available for Office Outlook 2010 or newer clients.
Implement Transport Protection Rules
Transport Protection rules allow you to use transport rules to apply rights protection to messages.
Transport Protection rules help organizations implement messaging policies by encrypting sensitive email
content and using rights-management to control access to the content.
AD RMS uses XML-based policy templates to allow compatible Information Rights Management (IRM)enabled applications to apply consistent protection policies. In Windows Server 2008, the AD RMS server
is accessible through a web service that you can use to enumerate and acquire templates.
Exchange Server 2010 users can use the Do Not Forward template. When you apply the Do Not Forward
template to a message, only the specified recipients can decrypt the message. The recipients cannot
forward the message to anyone else, copy content from the message, or print the message.
You can create additional RMS templates in the on-premise AD RMS deployment to meet rightsprotection requirements in your organization.
Enable Journal Report Decryption
When you enable Journal Report Decryption, you grant permission for the Journaling agent to attach a
decrypted copy of a rights-protected message to the journal report. If the rights-protected message
contains supported attachments that have been protected by the AD RMS cluster in your organization,
the attachments are also decrypted. The Journal Report Decryption agent performs decryption.
Enable Transport Decryption
When you enable Transport Decryption, Hub Transport servers can decrypt rights-protected messages
and enforce messaging policies. The first Hub Transport server to process a message in an Active Directory
forest utilizes the Decryption agent to perform transport decryption. After decryption, unencrypted
content becomes available to other transport agents on that server. For example, the Transport Rule agent
on a Hub Transport server can inspect message content and apply transport rules. Any actions specified in
the rulesuch as applying a disclaimer or modifying the messagecan be applied to the unencrypted
message. After other transport agents have inspected the message, the message is encrypted again with
the same user rights that it had before being decrypted by the Decryption agent. The message is not
decrypted again by other Hub Transport servers in the organization.
Enable IRM in Outlook Web App

After you enable IRM in Outlook Web App, users can use Outlook Web App to:
Send IRM-protected messages. Outlook Web App users can use the permissions feature when
composing a new message, and select an applicable policy template to apply to the message. This
allows users to send IRM-protected messages from within Outlook Web App. The Client Access server
applies IRM protection to messages and message attachments.
Read IRM-protected messages. Messages that are protected by using your organizations AD RMS
cluster will display in the Outlook Web App preview pane without requiring additional add-ons, or
that the users computer be enrolled in the AD RMS deployment. When you open or view a message
in the preview pane, the message is decrypted by using the use license added to message by the prelicensing agent. Once decrypted, the message displays in the preview pane. If a pre-license is not
available, Outlook Web App requests one from the AD RMS server before displaying the message.
10-25
Important Before configuring Journal Report Decryption, Transport Decryption, or IRM for
Outlook Web App, you must provide Exchange servers with the right to decrypt IRMprotected content. Do this by adding the Federated Delivery Mailbox to the super users
group configured on the AD RMS cluster. You must also use the Set-IRMConfiguration
cmdlet to enable the required features.
You can disable or enable IRM in Outlook Web App for an Outlook Web App virtual directory. You can
also control IRM in Outlook Web App at the following levels of granularity:
Per-Outlook Web App virtual directory. To enable or disable IRM in Outlook Web App for an Outlook
Web App virtual directory, use the Set-OWAVirtualDirectory cmdlet with the IRMEnabled
parameter set to $false or $true (the default). This allows you to disable IRM in Outlook Web App for
one virtual directory on a Client Access server, while keeping it enabled on another virtual directory
on a different Client Access server.
Per-Outlook Web App mailbox policy. To enable or disable IRM in Outlook Web App for an Outlook
Web App mailbox policy, use the Set-OWAMailboxPolicy cmdlet with the IRMEnabled parameter
set to $false or $true (the default). This allows you to enable IRM in Outlook Web App for one set of
users, and disable it for another set of users by assigning them a different Outlook Web App mailbox
policy.
IRM Enhancements in Exchange Server 2010 SP1

IRM functionality in Exchange Server 2010 SP1 includes the following features:
WebReady Document Viewing of IRM-protected attachments. In Exchange Server 2010 SP1, IRM in
Microsoft Office Outlook Web App supports WebReady Document Viewing of supported IRMprotected attachments. This allows users to view IRM-protected attachments without having to
download them. Users can preview IRM-protected documents on computers that do not have
Microsoft Office installed. Along with the cross-browser and cross-platform support in Outlook Web
App, this functionality extends the reach of IRM to various browsers and operating systems.
IRM in Exchange ActiveSync. IRM in Exchange ActiveSync allows users with supported devices to
access IRM-protected messages without first having to activate the device for IRM, or by tethering the
device to a computer.
Cross-organization support. Exchange Server 2010 SP1 IRM features are supported in crossorganization topologies, which provides for easier collaboration between two organizations via
Outlook Web App.
IRM logging. In Exchange Server 2010 SP1, you can enable logging of IRM features on the Mailbox,
Hub Transport, Client Access, and Unified Messaging server roles. IRM logs contain detailed
transaction and error information, allowing administrators to easily monitor and troubleshoot IRM
features.
10-26
Demonstration: How to Configure AD RMS Integration
In this demonstration, you will review how to configure and test AD RMS and Exchange Server 2010
integration. The first part of the demonstration will show you how to protect email messages by using AD
RMS. This feature does not require any special Exchange Server functionality. The second part of the
demonstration will show you how to configure a transport rule that applies AD RMS protection to a
message based on message properties.
Demonstration Steps
Protect email messages by using AD RMS

1.
On NYC-CL1, open Outlook 2010 and create a new message for an internal recipient.
2.
In the Message ribbon, click the Permission icon.
3.
In the Windows Security dialog box, log on as the mailbox user.
4.
In the Permission dialog box, select the Restrict permission to this document check box.
5.
When the message appears, verify that the message now contains the Do Not Forward header, and
then send the message.
6.
Log on as the message recipient, open Outlook 2010, open the restricted message, and then log on
by using the user credentials. Verify that you do not have permission to forward the message.
Configure a transport rule to apply AD RMS protection

1.
On NYC-DC1-B, modify the permissions on the C:\inetpub\wwwroot

\_wmcs\certification\servercertification.asmx file to grant Read and Execute access to the
Exchange Servers group and the anonymous Internet Information Services (IIS) user account.
2.
Restart the IIS.
3.
10-27
On an Exchange server, at the PS prompt, type the following cmdlet, and then press Enter. This
cmdlet enables AD RMS encryption on the Hub Transport server.
set-irmconfiguration InternalLicensingEnabled:$true.
4.
Use the following cmdlet to test the IRM configuration.
test-irmconfiguration
5.
In the Exchange Management console, create a new transport rule named

AD RMS Test Rule that applies the Do Not Forward AD RMS template for all messages sent between
two specified users.
6.
Send a message from one of the specified users to the other. Verify that the Do Not Forward
template is applied to the message.
Question: Does your organization have AD RMS deployed? Are you planning to deploy AD
RMS?
Question: How will Exchange Server 2010 make it easier to deploy AD RMS?
10-28
Options for Configuring Moderated Transport
In any type of organization, you may need to restrict access to specific recipients. The most common
scenario is controlling messages sent to large distribution groups. Depending on your organizations
requirements, you may also need to control messages sent to executive mailboxes or partner contacts.
You use Exchange Server 2010 moderated recipients to accomplish these tasks.
The Exchange Server 2010 moderated transport feature enables you to require moderator approval for all
email messages sent to specific recipients, and you can specify any type of recipient as a moderator. The
Hub Transport servers ensure that all messages sent to those recipients go through an approval process.
This is a new feature in Exchange Server 2010.
You can also use transport rules to enforce moderation. For example, you could configure a transport rule
that sends a message for moderation based on any of the available criteria.
How Moderated Transport Works
When you configure a recipient as a moderated recipient, all messages sent to the recipient go through
the following process:
1.
The sender creates a new message and sends it to the moderated recipient.
2.
The categorizer intercepts the message, marks it for moderation, and then reroutes it to the
arbitration mailbox.
3.
The store driver stores the message in the arbitration mailbox and sends an approval request to the
moderator.
4.
The moderator uses the buttons in the approval request to either accept or reject the message.
5.
The store driver marks the moderators decision on the original message stored in the arbitration
mailbox.
6.
10-29
The Information Assistant reads the approval status on the message stored in the arbitration mailbox,
and then processes the message based upon the moderators decision:
If the moderator approves the message, the Information Assistant resubmits the message to the
submission queue, and the message is delivered to the recipient.
If the moderator rejects the message, the Information Assistant deletes the message from the
arbitration mailbox, and then notifies the sender that the moderator rejected the message.
Note Previous Exchange Server versions do not support moderated recipients. If a message
sent to a moderated distribution group is expanded on a Hub Transport server that is
running Exchange Server 2007, the message will be delivered to all members of that
distribution group, and will bypass the moderation process. If you have Exchange
Server 2007 Hub Transport servers in your Exchange Server 2010 organization, and you want
to use moderated distribution groups, you must designate an Exchange Server 2010 Hub
Transport server as the expansion server for the moderated distribution groups. Doing this
ensures that all messages sent to the distribution group are moderated.
Bypassing Moderation
For certain senders, Exchange Server 2010 bypasses the approval process and delivers messages
immediately to the moderated recipient. Exchange Server 2010 considers the following senders as trusted
senders, and because of that status, messages from them do not go through the approval process:
Moderators. By definition, a moderator has the authority to determine what messages are
appropriate for a moderated recipient.
Senders that Exchange Server 2010 specifically allows to send messages. For each moderated
recipient, you can specify a list of senders for whom Exchange Server bypasses the approval workflow.
Exchange Server explicitly allows these senders to send to this recipient, and therefore trusts them.
Administrators group. The Administrators group is automatically excluded from moderation.
Exchange Server 2010 does not treat owners of distribution groups and dynamic distribution groups
automatically as trusted senders, and messages from these senders are subject to the approval process.
Additionally, the owner of a distribution group can be responsible for managing the distribution group
membership, but may not be able to moderate messages sent to it. To bypass moderation for owners, you
must either designate the owners as moderators, or add them to the list of senders that are explicitly
allowed to send messages to the moderated recipient.
You can also configure a single user to be moderated, although this option is rarely used. Options for
configuring a single mailbox for moderation are not available in the Exchange Management Console.
Instead, you must use the Exchange Management Shell, and the Set-Mailbox cmdlet with the
ModerationEnabled switch set to true.
10-30
Demonstration: How to Configure Moderated Transport
In this demonstration, you will review how to configure a distribution group for moderation, and how to
configure a transport rule that enforces moderation for all messages sent to a distribution list.
Note In this demonstration, you will configure a distribution group by using the Exchange
Management Console. If you need to enable a mailbox or contact for moderation, you would
use the set-mailbox cmdlet with the parameters
moderationenabled:$true and moderationedby.
Demonstration Steps
Configure a distribution group for moderation

1.
On NYC-Ex10, in the Exchange Management Console, under Recipient Configuration, click

Distribution Group.
2.
In the middle pane, right-click the distribution group, Projects, and then click Properties.
3.
On the Mail Flow Settings tab, double-click Message Moderation.
4.
In the Message Moderation dialog box, select the Messages sent to this group have to be
approved by a moderator check box. Add the group moderators, and add any users who do not
require moderation to send to the group.
Configure a transport rule that enables moderation

1.
Create a new transport rule that forwards any message sent to a distribution list for moderation.
Select a moderator for the rule, and then configure any exceptions that are required.
2.
Send a message to the distribution group that is configured for moderation.
3.
Send a message to the distribution group that is configured for moderation in the transport rule.
4.
10-31
Open the mailbox of a moderator configured for both the distribution group and transport rule.
Approve both messages.
Question: Will you deploy moderated transport in your organization? If so, where would you
use it?
10-32
Lesson 3
Configuring Journaling and Multi-Mailbox Search
Two important Exchange Server 2010 components for enforcing message compliance are message
journaling and Multi-Mailbox Search. Message journaling allows you to archive all messages automatically
that meet the criteria that you specify. You can archive journaled messages to any SMTP address,
including an Exchange Server mailbox, a Microsoft SharePoint Server document library, or a third-party
archiving solution. Multi-Mailbox Search enables an authorized user to search all of the organizations
mailboxes based on specific criteria.
This lesson describes how to configure and utilize message journaling and Multi-Mailbox Search in
Objectives
Describe message journaling options.
Explain how to configure message journaling.
Describe considerations for managing the Message Journal Mailbox.
Describe Multi-Mailbox Search.
Explain how to configure Multi-Mailbox Search.
Describe legal hold.
Message Journaling Options
10-33
Message journaling enables you to save copies of all email messages in a collection mailbox as they are
sent to, or from, specified mailboxes, contacts, or distribution-group members. You also can configure
journal rules based on parameters such as messages sent to, or received from, mailboxes in a mailbox
database, or configure journaling as part of a messaging-records management rule.
Messages that meet the message journaling criteria are sent to the collection mailbox as a journal report.
This report includes detailed informationsuch as the recipients address, the senders address, and the
message subject.
Message journaling technology is also present in Exchange Server 2003 and Exchange Server 2007. In
Exchange Server 2003, journaling was configured on database level only.
How Journal Rules Work
When you create a journal rule, the Journaling agentwhich runs only on Hub Transport servers
monitors all messages sent through the server. When a message matches the journal rule criteria, the
server forwards a copy of the message to a journal mailbox. You can configure the journal mailbox by
using any Exchange Server recipient. The recipient address can refer to another mailbox in the Exchange
Server organization, a document library on a Windows SharePoint Services site, or an address used by
other third-party message-archival solutions.
Journal rules are based on message recipients and message senders. When you configure a journal rule,
you can designate any Exchange Server recipient including mailbox users, contacts, or distribution groups.
The Journaling agent sends to the journal mailbox a copy of all messages that the recipient sends or
receives.
10-34
You can also configure the following three journal rule scopes to limit which messages the Journaling
agent sends to the journal mailbox.
Scope
Description
Internal
Rules with this scope process messages sent and received by recipients inside the
organization.
External
Rules with this scope process messages sent to recipients from senders outside the
organization.
Global
Rules with this scope process all messages that pass through a computer that has a Hub
Transport serverthese include messages that journal rules processed previously in the
Internal and External scopes.
Journal rules configured on a Hub Transport server apply to the entire Exchange Server organization.
When you create a journal rule on a Hub Transport server, the Active Directory Configuration stores it.
Any changes replicate to all Active Directory servers in the organization. All the Hub Transport servers in
the organization then read the new configuration from the Active Directory servers, and apply the new or
modified journal rules to messages that pass through the Hub Transport server.
How Mailbox Database Journaling Works
You can also configure a journal mailbox for a mailbox database. When you assign a journal recipient for
a mailbox database, all messages sent to or received from recipients with mailboxes in the database are
also sent to the journal recipient.
How Messaging Records Management Journaling Works
When you configure messaging records management, you can configure managed content settings that
apply policies that are located in user mailboxes. These managed content settings can specify retention or
deletion time limits, and specify actions to take when you reach the time limit. When you configure
managed content settings, you can also configure a journal recipient so that all messages that match the
criteria specified in the managed content settings are sent to the journal mailbox.
Note Mailbox database journaling is a standard journaling option, and is the only option
available for organizations with Exchange Server Standard client access licenses (CALs).
Journaling rules and messaging records management journaling are premium journaling
options. To use premium journaling, you must have the Exchange Server Enterprise CALs.
Journal Reports
When journal criteria is applied to a message, a journal report is sent to the SMTP address that the rule
lists. The journal report is a new email message that includes the original message, unaltered, as an
attachment.
The information that the journal report contains is organized so that every value in each header field has
its own line. The Journaling agent captures as much detail as possible about the original message. This
information is important in determining the messages intent, its recipients, and its senders. For example,
how the message identifies recipients (directly addressed in the To field, the Cc field, or included in a
distribution list) may determine how the recipient is involved in the message discussion.
10-35
Demonstration: How to Configure Message Journaling
You can configure journaling rules by using either the Exchange Management Console or the Exchange
Management Shell. In this demonstration, you will see how to configure a message journaling rule by
using the Exchange Management Console.
To configure transport rules with the Exchange Management Shell, use the following commands:
Enable-JournalRule
Disable-JournalRule
Get-JournalRule
Set-JournalRule
New-JournalRule
Remove-JournalRule
Demonstration Steps
Configure a message journaling rule by using the Exchange Management Console

1.
On NYC-EX10, in Exchange Management Console, under Organization Configuration, click Hub

Transport.
2.
Create a new journal rule. Specify a name for the rule, and specify a journal mailbox. A copy of all
messages that the rule affects will be sent to the journal mailbox.
3.
Specify the journal rule scope and recipients. The scope defines whether only internal or only external
messagesor bothwill be journaled. All messages that the recipient sends or receives are journaled.
4.
Send a test message to a journal recipient. Log on to the journal recipient mailbox, and then reply to
the message.
10-36
5.
Log on to the journal mailbox, and confirm that the journal mailbox contains a journal report for both
the sent message and the reply message.
Question: What are the advantages and disadvantages of using the Exchange Server 2010
message journaling feature?
Considerations for Managing the Message Journal Mailbox
10-37
In a large organization, or if you configure journaling for a large number of users, the journal mailbox can
grow very rapidly. Additionally, the journal mailbox may contain highly confidential information that
should not be accessible to most users. This means that you will need to develop policies for managing
the journal mailbox.
Using a SharePoint Document Library for Journaling
You can configure SharePoint document libraries with SMTP addresses that will accept email messages. In
Exchange Server, you can configure a custom recipient by using the SharePoint document library email
address, and then configure journaling to use the custom recipient as the journal recipient.
Using a SharePoint document library as the journal recipient has several advantages:
You configure a location outside of Exchange Server in which to store your messages, which reduces
the size of the Exchange Server databases.
You can index the SharePoint document libraries to enhance the search experience.
You can specify security on SharePoint document lists to ensure that only authorized users can view
the journaled messages.
Considerations for Managing the Journal Mailbox Size
When configuring a journaling mailbox to accept journal reports, you must determine the maximum size
of the journaling mailbox. As with any other mailbox, the maximum size depends on the data that the
mailbox will store, the hardware resources that are available, and the disaster-recovery capabilities for the
server that contains the journaling mailbox. Additionally, you also must consider what will occur if a
journaling mailbox exceeds the configured mailbox quota.
Avoid using the Prohibit send and receive at (KB) option to set the journaling mailboxs storage limit.
When the mailbox exceeds the specified quota, it stops accepting journaling reports. When this happens,
NDRs are not sent to users or administrators, but rather are queued on Hub Transport servers. To reduce
10-38
the possibility that your journaling mailbox will reject journal reports because it has reached the
configured storage quota, either avoid configuring this option, or configure your journaling mailboxs
storage quota to the maximum size allowable for your hardware resources and disaster-recovery
capabilities. If you are backing up the mailbox on a daily basis, consider specifying a messaging records
management rule to remove backed-up messages regularly.
Considerations for Managing Journal Mailbox Security
Security is an important consideration when managing the journal mailbox. Journaling mailboxes may
contain sensitive information. You must secure journaling mailboxes because they collect messages that
your organizations recipients send and receive, and those messages may be part of legal proceedings or
subject to regulatory requirements. Create policies that govern who can access your organizations
journaling mailboxes, and limit access to only those individuals who have a direct need for access. Ensure
that legal representatives approve your plan to ensure that your journaling solution complies with all the
laws and regulations that apply to your organization.
10-39
What Is Multi-Mailbox Search?
Searching the content of user mailboxes has always been challenging for Microsoft Exchange Server
administrators. Naturally, companies are always cautious when accessing data in users' mailboxes because
of potential legal problems that can arisesuch as privacy issues. Furthermore, until the release of
Microsoft Exchange Server 2010, previous Exchange Server versions did not have a friendly tool to
perform a search across multiple mailboxes. Multi-Mailbox Search (also known as discovery search) is a
new Exchange Server 2010 tool that lets administrators and other authorized personnel use a new
graphical console to perform keyword-based searches on one or more mailboxes in an Exchange
organization.
Important You must have valid approval to perform a search on users mailboxes. If you
do not, serious legal issues can ensue.
How Multi-Mailbox Search Works
In Exchange Server 2010, the mailbox search functionality is available through the Multi-Mailbox Search
feature in the Exchange Control Panel. The Multi-Mailbox Search feature allows you to search multiple
mailboxes for mailbox items (including email, attachments, calendar items, tasks, and contacts) across
both primary and archive mailboxes. Advanced filtering capabilities include: sender, receiver, expiry policy,
message size, sent/receive date, cc/bcc, and regular expressions.
Multi-Mailbox Search uses the content indexes that Exchange Search creates. Having a single contentindexing engine ensures no additional resources are utilized for crawling and indexing mailbox databases.
Discovery Management Role
A user who is a member of the Discovery Management role group can perform a Multi-Mailbox Search.
The Discovery Management role group is a universal security group that you configure in AD DS or during
10-40
the Exchange Server 2010 installation. The Discovery Management role group is assigned to the Mailbox
Search management role, which has permission to search all mailboxes in the organization.
Note Exchange Server 2010 uses Role Based Access Control (RBAC) to define what actions
users can perform in the Exchange Server organization. RBAC uses management roles and
management role groups to manage these permissions. Management roles and
management role groups will be discussed further in Module 11.
Viewing Search Results in Discovery Search Mailbox
All search results are stored in a special mailbox called Discovery Search Mailbox. It is not possible to store
results in any other mailbox. The Discovery Search Mailbox is always created during Exchange Server 2010
installation, and cannot be used for standard purposes such as sending and receiving email, because
delivery restrictions are applied to it. The user account associated with the Discovery Search Mailbox is
disabled, so no one can log on to this mailbox without being explicitly granted rights to do so. The
Discovery Management group has full access rights to the Discovery Search Mailbox. You can control and
audit membership in the Discovery Management role group by using Group Policy's restricted group
policy setting.
Because the Discovery Search Mailbox should be able to store a large amount of data, it is assigned a 50gigabyte (GB) storage quota on creation. If you have multiple teams or individuals that perform discovery
searches and you do not want them to see results from other searches, you will need to create additional
Discovery Search Mailboxes. This can be done by using the Exchange Management Shell.
After you perform a search, a new folder is created in the Discovery Search Mailbox that bears the same
name as the search. Within that folder, a subfolder is created for each source mailbox that was searched.
Additionally, messages that the search returns are copied to the corresponding folder in the target
mailbox.
Multi-Mailbox Search Enhancements in Exchange Server 2010 SP1
The Multi-Mailbox Search functionality in Exchange Server 2010 SP1 includes the following new features:
Multi-Mailbox Search preview. In Exchange Server 2010 SP1, discovery managers can determine the
number of items that will be returned by a discovery search, before the items are copied to the
selected discovery mailbox. (Discovery managers are users who are members of the Discovery
Management role group.) This functionality allows discovery managers to view the number of hits the
specified keywords return, and then modify the search queryif requiredbefore messages returned
by the search are copied to the discovery mailbox.
Annotations. Discovery managers can also add annotations to messages returned by the discovery
search.
Data de-duplication. Multi-Mailbox Search includes the optional data de-duplication feature. When
selected, Multi-Mailbox Search copies only a single instance of a message returned across multiple
folders within the same mailbox, or across different mailboxes. However, you should not select deduplication if you want to see each instance of a message and its location.
10-41
Demonstration: How to Configure Multi-Mailbox Search
In this demonstration, you will see how to configure Multi-Mailbox Search. To use the Multi-Mailbox
Search feature, you must add the users who will perform the search to the Mailbox Search management
role. The easiest way to do this is to add the user to the Discovery Management universal security group
in AD DS. The user can then use the Exchange Control Panel to search for messages based on multiple
criteria.
Demonstration Steps
Configure Multi-Mailbox Search

1.
On NYC-DC1, in Active Directory Users and Computers, add the user or group that will perform
Discovery searches to the Discovery Management group. Also provide Full Access on Discovery
Search Mailbox to the user who will perform Discovery Search.
2.
Send a message with a key word or phrase in it. You will be searching on this key word or phrase.
3.
Connect to the Exchange Control Panel on a Client Access server by using the account that will
perform the search.
4.
On the Reporting tab, under Multi-Mailbox Search, configure the search parameters.
5.
Select the Send me an e-mail when the search is done check box, and then start the search.
6.
Open the email indicating that the search concluded, and then click the Discovery Search Mailbox
link.
7.
Review the messages located by the search.
10-42
What Is Legal Hold?
Besides searching the contents of users mailboxes, you can also perform Multi-Mailbox Searches on items
that users have deleted. Under some circumstancessuch as a court order or lawsuitit may be
necessary to retrieve items that users intentionally delete.
Legal hold (also known as litigation hold) is an option in Exchange Server 2010 that can be applied to user
mailboxes to achieve this result. However, the ability to do this is directly related to Dumpster 2.0, which is
new technology in Exchange Server 2010.
Dumpster 2.0
In previous versions of Exchange Server, the dumpster was a view that was stored per folder. Using this
approach, items in the dumpster remained in the folder from where they were soft-deleted (either by
pressing the SHIFT+DELETE keys in any folder, or by clicking Delete from within the Deleted Items folder),
but they were marked with the ptagDeletedOnFlag flag. These marked items were excluded from normal
Outlook views and quotas. In addition, data with this flag could not be searched or indexed. These items
were recoverable by end-users by using the Recover Deleted Items tool accessible through Outlook Web
Access (OWA); however, the user was also able to delete these items permanently.
In Exchange Server 2010, Dumpster 2.0 functions differently. Dumpster 2.0 has now become a base
structure to the legal hold feature. Unlike version 1.0, Dumpster 2.0 is now a folder called Recoverable
Items. This folder is located inside the user's mailbox in the Non-IPM subtree, and it is not viewable
through the user interface. The Recoverable Items folder is indexed, can be searched, and you can prevent
deletions from this folder by implementing legal hold. It is also possible to apply a quota to this folder.
Using Legal Hold
Legal hold is enabled on a per-mailbox basis, and it is virtually transparent to the end user, because
retention policies continue to operate. By enabling legal hold, you preserve almost all mailbox items from
both the primary mailbox and Personal Archive, even if the user deletes something, and you can perform
discovery searches on these items too.
10-43
In Exchange Server 2010, when a user deletes an item, the item is no longer marked with a
ptagDeletedOnFlag flag; instead, it goes to the Deletions subfolder within the Recoverable Items folder.
From this folder, a user can retrieve items that were deleted. However, the user is no longer able to delete
items from this folder permanently. If a user deletes an item from Recoverable Items, it goes to the Purges
subfolder. The user can no longer access this item, but an administrator can, which prevents users from
intentionally hiding or destroying items.
You can use the legal hold feature to:
Place a hold on users' mailboxes and keep mailbox items in an unaltered state.
Preserve mailbox items that users attempt to delete or modify after the hold is placed.
Preserve mailbox items that are automatically deleted based on messaging records management
retention policies.
Keep the legal hold transparent from user by not having to suspend messaging records management.
Enable discovery searches of items placed on hold.
Items in the Recoverable Items folder are not calculated toward the user's mailbox quota. The Recoverable
Items folder has its own quota, and two parameters apply to this quota:
RecoverableItemsWarningQuota, and RecoverableItemsQuota. The default
RecoverableItemsWarningQuota and RecoverableItemsQuota values are 20 GB and 30 GB
respectively. If these quotas are reached, an event is logged in the application log of the Mailbox server,
so it is important to monitor this event log. If you want to modify quota values for a mailbox database,
you use the Set-MailboxDatabase cmdlet. If you want to modify quota values for an individual mailbox,
you use the Set-Mailbox cmdlet.
To enable legal hold on a user mailbox, use following command in Exchange Management Shell:
Set-Mailbox user@contoso.com -LitigationHoldEnabled $true
In Exchange Server 2010 SP1, it is also possible to use Exchange Management Console and Exchange
Control Panel to enable legal hold by modifying the properties of a users mailbox.
Authorized users that have been added to the Discovery Management RBAC role group or assigned the
legal hold management role can place mailbox users on legal hold. You can delegate the task to records
managers, compliance officers, or attorneys in your organization's legal department, while assigning the
least privileges.
Question: In which scenarios is it appropriate to use legal hold?
10-44

Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, you must
perform the following steps:
1.
2.
Ensure that the 10165A-NYC-DC1-B, 10165A-NYC-EX10-B, 10165A-NYC-EX11-B and the 10165ANYC-CL1 virtual machines are running:
10165A-NYC-DC1-B: Domain controller in the Contoso.com domain
10165A-NYC-EX10-B: Exchange Server 2010 server in the Contoso.com domain
10165A-NYC-CL1-B: Client computer in the Contoso.com domain
3.
If required, connect to the virtual machines. Log on to NYC-DC1, NYC-EX10, and NYC-EX11 as
4.
Log on to NYC-CL1 as Contoso\Terri, with the password, Pa$$w0rd.
Lab Scenario
You are a messaging administrator at Contoso, Ltd. The legal and audit departments at Contoso provided
you with several requirements for implementing messaging policy and compliance. These requirements
include applying rights protection to some messages sent inside and outside the organization, restricting
message flow based on message classifications, and restricting which messages are sent to critical
distribution lists.
10-45
You must also ensure that you establish a separate and secure mailbox in which to retain all messages that
the legal department sends and receives. Specifically, your deployment needs to meet the following
requirements:
All messages sent to users on the Internet must have a disclaimer that the legal department approves.
Messages with an Internet Confidential classification must not be sent to the Internet.
The transport rule should apply the Do Not Forward AD RMS template to all messages with the words
confidential or private in the subject.
A member of the Marketing group must approve all messages sent to the Projects distribution list
before the message is delivered.
A copy of all messages sent to and from the Executives group will be saved. The journal mailbox
should be accessible only with a special auditor account.
Implement an auditor account that has permission to search all user mailboxes, and access to the
journaled Executives messages must be implemented.
10-46
Exercise 1: Configuring Transport Rules

Scenario
In this exercise, you will implement various technologies to fulfill requirements from the Lab Scenario.
1.
Create a transport rule that adds a disclaimer to all messages sent to the Internet.
2.
Enable message classifications for Outlook 2010 clients.
3.
Create a transport rule that blocks all messages with a Company Confidential classification from being
sent to the Internet.
4.
Enable AD RMS integration for the organization.
5.
Configure a transport rule that applies the Do Not Forward AD RMS template to all messages with the
words confidential or private in the subject.
6.
Configure a moderated group.
7.
Test the transport rule configuration.
To prepare for this lab

1.
On NYC-EX10, click Start, point to All Programs, point to Microsoft Exchange Server 2010, and
then click Exchange Management Console.
2.
Expand Microsoft Exchange On-Premises, expand Organization Configuration, and then click
Hub Transport.
3.
In the Actions pane, click New Send Connector.
4.
On the Introduction page, type Internet Connector as the connector name. In the Select the
intended use for this Send connector drop-down list, click Internet, and then click Next.
5.
On the Address space page, click Add.
6.
In the Address space field, type *, click OK, and then click Next.
7.
On the Network settings page, click Route mail through the following smart hosts, and then
click Add.
8.
In the IP address field, type 10.10.0.10, click OK, and then click Next.
9.
On the Configure smart host authentication settings page, click Next.
10. On the Source Server page, click Next, click New, and then click Finish.
Task 1: Create a transport rule that adds a disclaimer to all messages sent to the
Internet
On NYC-EX10, create a new transport rule with the following settings:
Name: Internet Email Disclaimer
Conditions: Sent to users outside the corporation
Actions: Add a disclaimer
Disclaimer text: This email is intended solely for the use of the individual to whom it is
addressed.
10-47
Task 2: Enable message classifications for Outlook 2010 clients
1.
On NYC-EX10, use the new-messageclassification -Name CompanyConfidential displayname

Company Confidential -senderdescription Do not forward to the Internet cmdlet to
configure a new message classification.
2.
Use the Export-OutlookClassification.ps1 script in the c:\Program Files

\Microsoft\Exchange Server\v14\scripts folder to export the message classifications to the
C:\Classifications.xml file.
3.
Copy the Classifications.xml file to drive C on NYC-CL1. In the User Account Control dialog box,
type Administrator in the User name box, and Pa$$w0rd in the Password box, and then click Yes.
4.
On NYC-CL1, import the EnableClassifications.reg file from

\\nyc-ex10\d$\Labfiles.
Task 3: Create a transport rule that blocks all messages with a Company Confidential
classification from being sent to the Internet
Create a new transport rule with the following settings:
Name: Company Confidential Rule
Condition: Marked with classification Company Confidential
Actions: Send rejection message to sender with enhanced status code
Rejection message text: Company confidential email messages cannot be sent to the
Internet
Enhanced status code: 5.7.1
Task 4: Enable AD RMS integration for the organization

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

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

1.
On NYC-EX10, configure the Projects distribution group to require moderation.
2.
Configure Andrea Dunker as the groups moderator.
10-48
Task 7: Test the transport rule configuration

1.
On NYC-CL1, verify that you are logged on as Contoso\Terri, and then open Microsoft Outlook
2010.
2.
Send two messages to Carol@adatum.com. The first message should contain no settings, and the
second message should have the Company Confidential message classification assigned.
3.
On NYC-DC1, open a Windows Explorer window. Browse to the C:\inetpub\mailroot\queue folder,

and then open the .eml file with Notepad. Scroll to the middle of the message and verify that the
disclaimer has been added to the message.
4.
On NYC-CL1, confirm that Terri received a message from the postmaster account stating that the
second message could not be delivered.
5.
In Outlook, create a new message, and send it to the Projects distribution group.
6.
Open Windows Internet Explorer, and connect to https://nyc-ex10.contoso.com/owa. Log on as

Contoso\Andrea, with the password, Pa$$w0rd. If prompted for mailbox language settings, click
OK.
7.
In Outlook, verify that the message to the Projects distribution list has arrived. Open the message and
click Approve.
8.
In Outlook Web App, logged on as Andrea, create a new message with a subject of Private, and then
send the message to Terri.
9.
In Outlook, verify that Terri received the message and that it has the Do Not Forward template
applied. Verify that the Forward option is not available on the message.
Results: After this exercise, you should have configured a transport rule that ensures that all messages
sent to users on the Internet include a disclaimer of which the legal department approves. Additionally,
you should have configured a transport rule that ensures that messages with a Company Confidential
classification are not sent to the Internet. You should also have configured a transport rule that applies the
Do Not Forward AD RMS template to all messages with the words confidential or private in the
subject. Finally, you should have configured a moderated group by using the All Company distribution
group.
10-49
Exercise 2: Configuring Journal Rules

Scenario
In addition to the requirements restricting message flow, the project sponsors at Contoso, Ltd also have
the following requirements for saving messages and enabling auditors to search all mailboxes:
A copy of all messages sent to and from the IT group will be saved. The journal mailbox should be
accessible only with a special auditor account.
Implement an auditor account that has permission to search all user mailboxes and access the
journaled IT group messages.

1.
Create a mailbox for the IT department journaling messages.
2.
Create a journal rule that saves a copy of all messages sent to and from IT department members.
3.
Test the journal rule.
Task 1: Create a mailbox for the IT department journaling messages
Create a new recipient on NYC-EX10 with the following attributes:
First name: Executives Journal Mailbox
User Logon name (User Principal Name): ITJournal
Password: Pa$$w0rd
Create the mailbox in Mailbox Database 1
Task 2: Create a journal rule that saves a copy of all messages sent to and from IT
department members
Create a new journal rule with the following attributes:
Rule name: IT Department Message Journaling
Journal mailbox: IT Journal Mailbox
Scope: Global
Recipient: IT distribution group
Task 3: Test the journal rule

1.
On NYC-CL1, if required, open Outlook 2010.
2.
Create a new message, and then send it to Andrea Dunker. Andrea is a member of the IT group.
3.
Connect to Outlook Web App as Andrea, and confirm that the message was delivered. Reply to the
message.
4.
Connect to Outlook Web App as Contoso\ITJournal and verify that the journaled message is in the
Inbox.
Results: After this exercise, you should have created a mailbox for the IT department journaling messages,
and then created a journal rule that saves a copy of all messages sent to and from IT department
members.
10-50
Exercise 3: Configuring Multi-Mailbox Search

Scenario
In addition to the requirements restricting message flow, the project sponsors at Contoso, Ltd also have
the following requirement for enabling auditors to search all mailboxes:
Implement an auditor account that has permission to search all user mailboxes and access the
journaled IT messages.

1.
Create and configure the MailboxAuditor account.
2.
Test the Multi-Mailbox Search configuration.
Task 1: Create and configure the MailboxAuditor account

1.
Create a new recipient with the following attributes:
First name: Mailbox Auditor
User Logon name (User Principal Name): MailboxAuditor
Password: Pa$$w0rd
Create the mailbox in Mailbox Database 1
2.
Grant the Mailbox Auditor account full access to the IT Journal mailbox.
3.
Add the Mailbox Auditor account to the Discovery Management Active Directory group.
4.
Grant Mailbox Auditor account full access to the Discovery Management mailbox.
Task 2: Test Multi-Mailbox Search configuration

1.
On NYC-CL1, if required, open Outlook.
2.
In Outlook, send a message with the following properties:
To: Sten; Carol@adatum.com
Subject: Customer Order
Message body: Here is the order for Carol at Contoso. Her customer number is 1111-1111.
3.
Connect to the Exchange Control Panel as the Contoso\MailboxAuditor.
4.
Create a new search named Customer Number Discovery. Configure the search to look for the
phrase customer number in Terri and Stens mailboxes.
5.
Wait until the search finishes, and then, in the lower-right pane, click the Open link.
6.
In Outlook Web App, verify that the discovery folder named Customer Number Discovery contains
the search result.
Results: After this exercise, you should have configured and tested the Mailbox Auditor account, and
tested Multi-Mailbox Search.
Lesson 4
Configuring Archive Mailboxes
10-51
A compliance issue that is difficult to solve for many organizations is that much of the information users
receive by email is not stored within the email system. Because of mailbox size limits, many users are
encouraged to move messages from their mailboxes to personal storage table (PST) files, where the
messages are not backed up regularly, and where the messages are not available for either discovery or
indexing.
Exchange Server 2010 introduces Personal Archives as an option for ensuring that all messages are stored
in a mailbox on an Exchange server. This lesson describes how to configure and manage Personal Archives
in Exchange Server 2010.
Objectives
Describe the options for implementing mailbox archiving.
Describe how Personal Archives work in Exchange Server 2010.
Explain how to configure Personal Archives.
Describe the considerations for implementing Personal Archives.
10-52
Discussion: Options for Implementing Mailbox Archiving
Some organizations have implemented mailbox archiving by using third-party products. These products
provide different types of functionality, and implement the functionality in different ways. In this
discussion, you will review the mailbox archiving solutions that various organizations have implemented.
Question: Do you have any archiving or journaling requirements in your organization?
Question: How are you currently meeting these requirements?
How Personal Archives Work in Exchange Server 2010
10-53
In previous Exchange Server versions, messages that were not kept in a users mailbox were mostly stored
in local .pst files. These files were not centrally stored, and as such, it was very difficult to back them up or
manage them. Exchange Server 2010 provides the Personal Archives feature, which enables users to move
their .pst files back into the Exchange Server database. To implement a Personal Archive, a second
mailbox is created that the user can use to store messages that are no longer current, but which they may
need to retain. The user can access this archive mailbox in Outlook 2007, Outlook 2010, or Outlook Web
App, just like any other folder in the user mailbox.
How Personal Archives Work
To implement Personal Archives, the Exchange Server administrator creates a new archive mailbox for the
users. This mailbox can be on the same database as the primary mailbox, or on another database (if
Exchange Server 2010 SP1 is installed). You can create the archive mailbox when you create the primary
mailbox, or you can add the archive mailbox later.
When a user accesses his or her mailbox by using Outlook 2010 or Outlook Web App, the archive mailbox
appears as a folder in the users regular mailbox. The user can then move the PST foldersor any other
messagesinto the archive mailbox simply by dragging the email message into the archive folder.
Users can access and search their archived email directly through their primary mailbox without the need
for plug-ins or special configurations that third-party archiving tools often require.
One difference between the primary mailbox and the archive mailbox is that the archive mailbox is not
cached on the client computer when you configure Outlook in cached mode. This decreases the mailbox
cache size on the client, but also means that the user can access the mail in the mailbox only when
connected to the Exchange Server 2010 server.
You manage the archive mailbox through messaging records management policies. For example, you can
configure retention policies that will move messages from the primary mailbox to the secondary mailbox
10-54
based on the Retention Policy Tags assigned to the primary mailbox folders. You can also configure
retention policies for folders located in the archive mailbox.
Archive Quotas
Archive mailboxes are designed so that users can store historical messaging data outside their primary
mailbox. Historically, users often used .pst files because of low mailbox storage quotas and the restrictions
imposed when these quotas are exceeded. For example, users can be prevented from sending messages
when their mailbox size exceeds the Prohibit send quota. Similarly, users can be prevented from sending
and receiving messages when their mailbox size exceeds the Prohibit send and receive quota.
To eliminate the need for .pst files, you can provide an archive mailbox with storage limits that meet the
user's requirements. However, you may still want to retain some control of the storage quotas and growth
of archive mailboxes to help monitor costs and expansion.
To help with this control, you can configure archive mailboxes with an archive warning quota and an
archive quota. When an archive mailbox exceeds the specified archive warning quota, a warning event is
logged in the Application event log. When an archive mailbox exceeds the specified archive quota,
messages are no longer moved to the archive, a warning event is logged in the Application event log, and
a quota message is sent to the mailbox user. By default, in Exchange Server 2010 SP1, the archive warning
quota is set to 45 GB, and the archive quota is set to 50 GB. In Exchange Server 2010, both quotas are set
to Unlimited.
Personal archive functionality in Exchange Server 2010 SP1 includes the following:
Provision personal archive on a different mailbox database. You can provision a user's personal
archive on a mailbox database different from the one where the user's primary mailbox resides. This
capability allows you to implement a tiered storage topology. You can also store personal archive
mailbox on Exchange Online services.
Import historical mailbox data to archive. You can import historical mailbox data from .pst files
directly to the user's personal archive by using the New-MailboxImportRequest cmdlet in the
Exchange Management Shell. You can also import data from .pst files to the user's primary mailbox,
and both the personal archive and the primary mailbox can be exported to .pst files by using the
New-MailboxExportRequest cmdlet in the Exchange Management Shell.
Delegate access to archive. Delegates can access the delegating user's archive mailbox by using
Outlook 2010.
10-55
Demonstration: How to Configure Personal Archives
In this demonstration, you will see how to configure a Personal Archives mailbox for a user account. You
will also see how to access the mailbox by using Outlook Web App.
Demonstration Steps
Configure and access a Personal Archives mailbox

1.
On NYC-EX10, in the Exchange Management Console, click Recipient Management, and then click
Mailbox.
2.
Right-click a mailbox, and then click Enable Archive.
3.
On the mailbox properties, review the archive quota settings.
4.
Use the get-mailbox cmdlet to view the mailbox settings. Review the ArchiveName and
ArchiveQuota settings.
5.
Verify that you can view the archive mailbox in Outlook 2010, and through Outlook Web App.
Question: Will you implement Personal Archives in Exchange Server 2010?
Question: What are the benefits and challenges of the Personal Archives feature?
10-56
Considerations for Implementing Personal Archives
Personal Archives provides an excellent opportunity for organizations to ensure that all messages in the
email system are stored in a location where the messages can be managed and accessed. However,
deploying Personal Archives will also require careful planning to ensure that the implementation is
successful.
In many organizations, some users may have several gigabytes of data stored in .pst files. If all of these
messages are moved into archive mailboxes, the amount of storage required for the mailbox databases
will increase dramatically. Exchange Server 2010 enables you to manage very large mailboxes, but
organizations may not have sufficient storage or other infrastructure componentssuch as backup
capacityto increase greatly the size of the Exchange Server data store.
Some considerations for managing Personal Archives implementation can be as follows:
Consider an incremental implementation for Personal Archives. If your storage infrastructure cannot
handle implementing Personal Archives for all users, start by identifying the users who will benefit
most from Personal Archives. This may include users with the most critical information currently
stored in .pst files, or it may include all executives in the organization.
Because of the decrease in disk IO, it is now feasible to store mailbox databases on lower performance
and less expensive disk arrays using Serial ATA (SATA) drives. Additionally, rather than depending on
redundant disk arrays and backup to provide high availability, you can use database availability
groups (DAGs) to provide the required level of availability.
You can also use messaging records management policies to manage the archive mailboxes. By
configuring retention tags for the primary mailbox, you can ensure that messages are moved into the
archive mailbox on a regular basis. You can also use retention tags to manage the messages in the
archive mailbox.
10-57
Limiting Access to .PST Files
You can start moving users away from using .pst files by creating a Group Policy Object (GPO) that
prevents new items from being added to existing .pst files. Making .pst files read-only gives users access
to the .pst files they may already have while encouraging them to keep the messages that they want to
keep in their Exchange Server mailboxes. If you plan to deploy archive mailboxes, data from .pst files can
be moved to the user's archive mailbox. Eventually, you may want to create a GPO to remove access to
.pst files altogether.
Limiting access to .pst files can disrupt the work habits of some users, but it also has a number of
advantages. Keeping user messages on the server and limiting access to .pst files can:
Significantly increase the effectiveness of messaging records management by keeping messages

where they can be managed and monitored.
Reduce the risk of losing important data that is stored on individual hard disks rather than on servers
that are backed up regularly.
Help reduce the loss of the organization's intellectual property when vendors, interns, and employees
leave the organization.
Improve users' access to their data by keeping all mailbox items in their mailboxes.
Make Outlook Web App more effective by making all user messages available anywhere with only a
web connection.
Reduce the cost of legal discovery during a lawsuit. The process of capturing and discovering
information that is stored in .pst files is labor-intensive and expensive, because .pst files must first be
located on user computers, and then the contents must be processed by legal personnel.
Outlook 2010 allows you to control your organization's mailbox data effectively, so it cannot be moved or
copied to a .pst file. This allows users to open .pst files and copy the data into an Exchange Server
mailbox, but not copy or move messages from the Exchange Server mailbox to .pst files. Using Outlook
2010, you can provide your users with a migration path to move messaging data from .pst files to their
primary Exchange mailbox or their archive mailbox (if it is provisioned).
To disable the copying of Exchange mailbox data to a .pst file, set the following registry value for your
Outlook 2010 users.
Registry path: HKEY_CURRENT_USER/Software/Microsoft/Office/14/Outlook

Registry value: DisableCrossAccountCopy
Value type: REG_MULTI_SZ
Value data: Domain names used for user's primary SMTP e-mail addresses. For example, use
contoso.com to prevent copying or moving data from any mailbox that uses a contoso.com
e-mail address as the primary SMTP e-mail address. Use * (asterisk) to prevent moving or
copying data from any mailbox.
If you want to disable copying or moving messages to .pst files, configure the following registry setting.
Registry path: HKEY_CURRENT_USER/Software/Microsoft/Office/14/Outlook/PST
Registry value: PstDisableGrow
Value type: DWORD
Value data: 1
10-58
If you want to disable users from creating new .pst files, configure the following registry setting.
Registry path:
HKEY_CURRENT_USER/Software/Policies/Microsoft/Office/14/Outlook/DisableCmdBarItemsList
Registry value: TCID1
Value type: DWORD
Value data: 5575
You can also configure these options by using Group Policy, after importing Outlook Administrative
Templates into GPO.
Question: How can you easily implement these registry values on a large number of clients?
Lesson 5
Configuring Retention and Archive Policies
10-59
An important requirement for many organizations is retaining certain email messages while deleting
others after a specified time. Exchange Server 2010 uses messaging records management to implement
this functionality through retention policies and managed folders. This lesson describes how to implement
messaging records management in Exchange Server 2010.
Objectives
Describe the messaging records management options.
Describe Managed Folders.
Describe Retention Policy Tags and Retention Policies.
Explain how to configure Retention Policy Tags and Retention Policies
Describe the differences between Retention Tags and managed folders.
Explain how to migrate from managed folders to Retention Policies.
Apply best practices for implementing messaging records management.
10-60
Messaging Records Management Options
Organizations and users utilize an increasing volume of email every day. These messages may contain
information that is important to the organization from a business, legal, or regulatory perspective, and
may need to be retained for a certain period, depending on the organization's messaging policies.
However, many email messages may not have any retention value beyond a certain period, if at all. For
example, a user's mailbox may contain critical messages that need to be retainedsuch as messages
related to business strategy, transactions, product development, or customer interactions. However,
messages such as newsletter subscriptions or personal email may not have any retention value, and
therefore do not need to be retained beyond a certain period. Retaining messages with little retention
value results in mailbox growth that requires more resources on mailbox servers.
Messaging records management is the records management technology in Microsoft Exchange Server
2010 that helps organizations reduce the legal risks associated with email, and to better handle mailbox
growth. Messaging records management makes it easier to keep the messages necessary to comply with
company policy, government regulations, or legal needs, and to remove content that has no legal or
business value. This is accomplished through the use of retention policies or managed folders:
Retention policies. Retention policies are the new messaging records management technology in
Exchange Server 2010 that uses retention tags to apply retention settings. You create retention tags,
and then link them to a retention policy, which is then applied to a users mailbox. Mailboxes that
have a retention policy applied to them are processed by the Managed Folder Assistant, a mailbox
assistant process that provisions retention tags in mailboxes.
Managed folders. Managed folders, the messaging records management technology introduced in
Exchange Server 2007, have managed content settings applied to them. You create managed folders,
and then link them to a managed folder mailbox policy. Mailboxes that have managed folder mailbox
policies applied are processed by the Managed Folder Assistant, which provisions managed folders in
mailboxes.
When a message reaches its retention age, the retention action specified in the Retention Policy Tag (or
the managed content settings for a managed folder) is taken. Messages can be either moved to the
10-61
Deleted Items folder, deleted with the ability to recover them from the Recoverable Items folder, or
permanently deleted. Retention tags also provide an additional action of moving a message to the user's
archive mailbox, if an archive mailbox has been provisioned for the user. Managed content settings for
managed folders also provide an additional action of moving a message to a managed custom folder.
Question: How do you handle messaging records management right now?
10-62
What Are Managed Folders?
Managed folders are a messaging records management feature that was introduced in Microsoft
Exchange Server 2007 and is available in Exchange Server 2010. Using managed folders, you can specify
retention settings for default folders such as Inbox, Deleted Items, and Sent Items, and create custom
managed folders with their own retention settings. Managed folders rely on users to classify messages for
retention, and to move the messages to the appropriate managed folders based on retention
requirements.
Note Managed Folders in Exchange Server 2010 SP1 can only be managed by using
Managed folders are an Active Directory representation of folders in a mailbox. You can define two types
of managed folders:
Managed default folders. Managed default folders are managed folder objects created for default
folders such as Inbox, Deleted Items, and Sent Items. Exchange Server 2010 Setup creates a set of
managed default folders that are visible on the Managed Default Folders tab in the Exchange
Management Console. You can use these folders or create additional folders for different sets of
users.
Managed custom folders. Managed custom folders are managed folder objects that you can use to
create custom folders in a user's mailbox. The folders are created under a top-level folder called
Managed Folders.
Managed content settings specify the retention and journaling settings for a managed folder. The settings
can be for a specific message class (such as email messages, calendar items, and tasks), or they can be for
all message classes. You can specify multiple managed content settings for different message classes,
which allows you to specify different retention settings for different types of items in the same folder.
10-63
These retention settings include a message class (whether retention is enabled for the specified message
class), the retention age, and a retention action. The retention age specifies the period for which a
message is retained in the mailbox. The retention action specifies the action to take after the item is past
its retention age. For example, you can create a managed content setting for a managed default folder
that moves all items to the Deleted Items folder after 120 days.
You can select from one of the following retention actions:
Move to the Deleted Items Folder. Use this action to move items to the Deleted Items folder upon
expiration.
Move to a Managed Custom Folder. Use this action to move items to a managed custom folder. To
use this action, you must first create the managed custom folder.
Delete and Allow Recovery. Use this action to move items to the Recoverable Items folder. Deleted
items are available for recovery from the Recoverable Items folder until the deleted item retention
time specified for the mailbox database or the user mailbox elapses.
Permanently Delete. Use this action to delete items permanently. Users cannot recover items that
have been permanently deleted.
Mark as Past Retention Limit. Use this action to mark items as expired, after they reach their
retention age. Items marked as expired are displayed by using strikethrough text in Outlook 2010 and
Office Outlook 2007.
You can also specify whether the retention age is calculated from when a message is delivered to a
mailbox, or when it is moved to the folder it currently resides in. For calendar items and recurring tasks,
the retention age is calculated from the end date of the item.
Managed Folder Assistant
The Managed Folder Assistant is a process that runs on Mailbox servers, and applies managed folder
mailbox policies to mailboxes located on that server. The assistant retrieves the list of managed folders
associated with a policy, provisions managed folders in mailboxes, and processes items in those folders.
Items for which retention is enabled are stamped with the retention age. The retention action specified in
applicable managed content settings is applied to items that have reached their retention age. In
Exchange Server 2007, the Managed Folder Assistant was handling managed folders in users mailboxes,
and was applying policies for these folders.
In Exchange Server 2010, the Managed Folder Assistant also applies retention policies for messaging
records management. You can apply either a retention policy or a managed folder mailbox policy to a
mailbox. If you modify the Managed Folder Assistant schedule, it affects both messaging records
management features. In Exchange Server 2010, the Managed Folder Assistant is a schedule-based
assistant that is scheduled to run from 01:00 through 09:00 (1:00 A.M. through 9:00 A.M.) every day. You
can modify the Managed Folder Assistant schedule to make sure there is minimal user impact. You can
also start and stop the assistant manually by using the Exchange Management Shell.
In Exchange Server 2010 SP1, the Managed Folder Assistant is a throttle-based assistant. Throttle-based
assistants do not run on a schedule; instead, they are configured to process all mailboxes on a Mailbox
server within a certain period of time (known as a work cycle). Additionally, at a specified interval known
as the work cycle checkpoint, the Managed Folder Assistant refreshes the list of mailboxes to be
processed. During the refresh, the assistant adds newly created or moved mailboxes to the queue. It also
re-prioritizes existing mailboxes that have not been processed successfully for a while because of failures,
and moves them higher in the queue so they can be processed during the same work cycle.
10-64
To start the Managed Folder Assistant on Exchange Server 2010 SP1, you use the Exchange Management
Shell. If you want to run the Managed Folder Assistant for one specific mailbox, run the following cmdlet.
Start-ManagedFolderAssistant -Identity Sten@contoso.com
This will apply all retention policies or managed folders to specific mailbox.
Question: Why would you want to run Managed Folder Assistant manually by using
Exchange Management Shell?
What Are Retention Tags and Retention Policies?
10-65
Organizations formulate messaging records management policies that specify the retention period for
different classes of email messages. However, in the past, enforcing those policies has often been
challenging. Attempts to automate the messaging records management process have met with limited
success. To manage these challenges, Exchange Server 2010 provides new messaging records
management functionality.
In Exchange Server 2010, you use Retention Tags to tag messages or folders for retention or deletion.
Each Retention Tag is associated with one or more managed content settings that define the time for
which items are retained, and determine what will happen when the retention period expires. You can
associate multiple Retention Tags with a retention policy, which you then assign to a user mailbox.
Messages are processed based on the Retention Tags and their associated content settings. When a
message reaches a retention limit, Exchange Server archives it, deletes it, or flags it for user attention.
Retention Tags
Use Retention Tags to apply retention settings to mailbox folders and individual items. The following
types of Retention Tags are available:
Retention Policy Tags: Retention Policy Tags are applied to default mailbox folders such as Inbox,
Deleted Items, and Junk Mail. A Retention Policy Tag has one or more Managed Content Settings
associated with it for retaining messages of different types. It may have additional Managed Content
Settings associated with journaling settings.
Default Policy Tag: A Default Policy Tag can be associated with a retention policy, and applies to all
items in the mailbox that do not have a Retention Tag explicitly applied to them, or that do not
inherit a tag from the folder in which they reside. A Default Policy Tag can have more than one
Managed Content Setting associated with it for different item types, such as email, voice mail, and
Contacts. Additionally, it can also have Content Settings with journaling settings. You cannot have
more than one Default Policy Tag associated with a retention policy.
10-66
Personal Tags: Personal Tags are Retention Tags that are available to users as part of their retention
policy. A user can opt-in to use additional Personal Tags on folders or mailbox items by using the
Exchange Control Panel. Personal Tags can have only one managed content setting for expiry of all
message types.
Managed Content Settings
Managed content settings define the settings for message retention and journaling. They are associated
with Retention Tags. The content settings specify how long a message remains in a mailbox folder, and
the action that Exchange Server should take when the message reaches the specified retention age.
You can also configure journal settings to ensure that all message copies with the associated Retention
Tag are sent to another recipient.
Retention Policies
Retention policies are a group of one or more Retention Tags, and they apply the tags to mailboxes. A
retention policy consists of one or more Retention Policy Tags, a maximum of one Default Policy Tag, and
any number of Personal Tags. You can link or unlink tags from a retention policy at any time.
You can apply retention policies to mailboxes by using the Exchange Management Shell or the Exchange
Control Panel. A mailbox cannot have more than one retention policy.
Retention Policy Tags and Mailbox Folders
Retention Policy Tags apply to default folders as specified in the retention policy. Users cannot change the
Retention Policy Tags associated with default folders. However, users can apply a different Retention
Policy Tag to an item in a default folder, thereby causing the item to have a different retention setting
than the folder in which it resides. Similarly, an item in a user-created folder can also have a different
Retention Policy Tag than the folder within which it resides.
A mailbox item moved from one folder to another inherits any Retention Policy Tags applied to the folder
to which it moves. If an item moves to a folder that does not have a Retention Policy Tag assigned to it,
the Default Policy Tag applies to it. If the item has a Retention Policy Tag explicitly assigned to it, the tag
moves with the item and always takes precedence over any folder-level Retention Policy Tags or the
Default Policy Tag.
AutoTagging
AutoTagging is an Exchange Server 2010 feature that optimizes the use of Retention Policy Tags by
automatically applying Retention Policy Tags to items based on past user behavior.
AutoTagging uses a machine-learning algorithm that tracks users tagging behavior. Given a sampling
that is large enough for it to learn, AutoTagging can predict the users tagging behavior from the
sampling. The user must have manually tagged a minimum of 500 email messages for AutoTagging to
start learning. The AutoTagging algorithm inspects message characteristics, content, and the userassigned Retention Policy Tags, and creates a model to predict the users tagging behavior. After the
learning is complete, AutoTagging automatically assigns the appropriate Retention Policy Tags to new
items as they arrive.
Users can enable AutoTagging from the Exchange Control Panel. The mailbox should have at least 500
messages tagged before AutoTagging is enabled. You can also use cmdlets to enable or disable
AutoTagging for one or more mailboxes, and to determine the AutoTagging status of users.
Users can disable AutoTagging at any time. They can also override the Retention Policy Tag automatically
applied to a message by applying a different tag that may be more appropriate, or they can move a
10-67
message to a folder to which a tag is applied. User-applied tags always take precedence, and
AutoTagging never alters them.
Whenever a user overrides the tag applied by AutoTagging, the message metadata is updated with that
information. AutoTagging notices changes that the user makes, and the learning algorithm continues to
fine-tune its predictions based on such changes.
Regardless of whether a user or administrator enables AutoTagging on a mailbox, Exchange Server 2010
lets the administrator control the AutoTagging functionality as necessary. Administrators can enable or
disable AutoTagging for a mailbox. To do this, use the Set-MailboxComplianceConfiguration -Identity
user-RetentionAutoTaggingEnabled cmdlet to assign a value of $true or $false.
10-68
Demonstration: Configuring Retention Tags and Retention Policies
In this demonstration, you will see how to configure Retention Policy Tags and retention policies.
Demonstration Steps
Configure Retention Policy Tags and retention policies

1.
On NYC-EX10, in the Exchange Management Console, click Organization Management, and then
click Mailbox.
2.
Create new Retention Policy Tag that removes deleted items from mailboxes after 30 days.
3.
Create new retention policy, and link a new Retention Policy Tag to it.
4.
Apply the retention policy to users in the IT OU.
Managed Folders vs. Retention Policies
10-69
Retention policies and managed folders provide two different approaches to messaging records
management. You can use either of the messaging records management technologies to enforce basic
messaging records management policies on default folders and on the entire mailbox. For messaging
records management to be effective, users must participate in the process of classifying messages based
on their nature and retention value.
With Retention Policy Tags, you can apply default retention settings to default folderssuch as the Inbox
folderand apply a Default Policy Tag to the entire mailbox. The Default Policy Tag retention settings are
applied to untagged items that may reside in folders without a retention tag, such as custom folders
created by the user. Retention Policy Tags help both users who file email into folders and keep few
messages in the Inbox, and users who leave most of their email in the Inbox. Retention Policy Tags have a
lesser impact on the user's workflow, because users are not required to file messages in folders based on
the folder's retention settings. Instead, users can apply any personal tag to custom folders, and explicitly
apply a different tag to individual messages.
With managed folders, users participate in the messaging records management process by classifying
their own messages and sorting them into managed folders. This sorting process ensures that messages
are classified according to the users' preferences and the organization's needs. It also helps eliminate the
mishandling of messages that can occur with an automated messaging management solution.
Unlike managed folderswhich require users to move items to a managed folder based on retention
settingsRetention Policy Tags can be applied to a folder or an individual item in the mailbox. This
process has minimal impact on the user's workflow and email organization methods. When a folder has
Retention Policy Tags applied, all items in that folder inherit the retention settings. Users can further
specify retention settings by applying different Retention Policy Tags to individual items in that folder.
Managed folders support different managed content settings for a folder, each with a different message
class (such as email items or calendar items). Retention Policy Tags do not require a separate managed
content settings object, because the retention settings are specified in the tag's properties. Creating
10-70
Retention Policy Tags for particular message classes is not supported. Retention Policy Tags also do not
allow you to use journaling (which is performed by the Managed Folder Assistant).
Upgrading from Managed Folders to Retention Policies
In Microsoft Exchange Server 2010, retention policies replace managed folders, the messaging records
management feature introduced in Exchange Server 2007. Using the Port Managed Folder wizard, you
can port managed folders to retention tags, thereby maintaining the same retention settings as the
managed folder.
Retention tags created by porting managed folders contain the managed folder name in the
LegacyManagedFolder property. After you port or create retention tags, you must link the tags to a
retention policy and apply the policy to a mailbox. When the Managed Folder Assistant processes the
mailbox and finds a managed folder that matches a ported retention tag, the assistant applies the
retention tag to the managed folder. The ported retention tag must be linked to the user's retention
policy for this to occur.
If you want to port a managed folder to a retention policy, you should perform the following procedure in
the Exchange Management Console:
1.
Navigate to Organization Configuration > Mailbox.
2.
In the Action pane, click Port from Managed Folder to Tag.
3.
On the Introduction page, complete the following fields:
4.
Tag Name. Use this box to type a name for the new retention tag. This name can be up to 64
characters in length.
Select managed folder to upgrade. Click Browse to select a managed folder to port.
Comments. Use this box to type a comment that will display in Outlook. For example, to alert
users that messaging records management is enabled on the folder, you could type the following
message: "Messages are removed from this folder after 120 days." The maximum length of this
comment is 255 characters. To configure localized comments, use the Set-RetentionPolicyTag
cmdlet.
On the Completion page, review the following, and then click Finish to close the wizard:
A status of Completed indicates that the wizard completed the task successfully.
A status of Failed indicates that the task did not complete. If the task fails, review the summary
for an explanation, and then click Back to make any required configuration changes.
10-71
Best Practices for Implementing Messaging Records Management
Messaging records management policies deal primarily with message retention issues. By implementing
messaging records management policies, you can ensure that certain messages are deleted in user
mailboxes, and that certain messages are retained for an extended period.
Note Remember that messaging records management requires an Exchange Enterprise

CAL for each mailbox on which it is enabled.
When planning and deploying messaging records management policies, you should implement the
following recommendations:
Ensure that you have business and legal approval before configuring messaging records management
policies. This is particularly important if you are configuring policies that will delete messages from
user mailboxes.
Use retention policies and managed folder mailbox polices to group a collection of folders with
associated Retention Tags or content settings. If different user groups in your organization have
different requirements for messaging records management, you can create a unique policy for each
user group that includes just the folders that should apply to those users.
If your organization requires messages to be retained or managed based on projects, consider using
managed custom folders to apply messaging records management policies. With managed custom
folders, you can create the required folders in the mailboxes for all users associated with the projects,
and then ensure appropriate management of the folders messages.
If you want to automate the messaging records management process for all users, consider using
retention policies and AutoTagging. With retention policies, you can set default tags that will be
assigned to all folders, while providing users with the option of overriding the tags. With
AutoTagging, you can further automate the process for managing Retention Tags to the extent that
users no longer have to manage the tags.
10-72
If you need to ensure that copies of some messages are retained for extended periods, consider using
journaling as part of a content setting to ensure message retention. When you configure a content
setting, you can add a journal location so that all messages that the content setting covers, are also
moved automatically to the journal location. With this as an option, you can consider deleting
messages from user mailboxes.
Use messaging records management policies to limit mailbox sizes. You can use messaging records
management policies to remove old messages from folders such as the Deleted Items folder, or the
Sent Items folder.
Prevent users from using .pst files after you implement archive mailboxes, to ensure that all messages
are kept in the Exchange Server 2010 server database.
Note When you implement managed custom folders, users must move messages into the
managed email folders for the content settings to apply. This means that you must provide
user training to educate users about why they need to move messages into these folders.
You may also need to teach users how to configure Outlook rules to move messages
automatically into the correct folders.
10-73
Lab B: Configuring Archive Mailboxes and Retention

Policies
Lab Setup
1.
2.
Ensure that the 10165A-NYC-DC1-B, 10165A-NYC-EX10-B, 10165A-NYC-EX11-B, and the 10165ANYC-CL1-B virtual machines are running.
3.
10165A-NYC-DC1-B: Domain controller in the Contoso.com domain
10165A-NYC-CL1-B: Client computer in the Contoso.com domain
Lab Scenario
To decrease the cost of storage for the mailbox databases, Contoso, Ltd has decided to configure archive
mailboxes for some users who are using a separate mailbox database. This database will have fewer copies
in the DAG. You need to configure the archive mailbox database, and create archive mailboxes on the
database for all members of the Executives group.
Additionally, the legal and audit departments at Contoso provided you with several requirements for
implementing messaging policy and compliance. These requirements include configuring rules that will
ensure that some messages are retained for an extended period of time, while other messages are deleted
when they expire.
10-74
Exercise 1: Configuring Archive Mailboxes

Scenario
Contoso, Ltd is concerned about the number of email messages that some users are storing in .pst files. In
particular, some members of the IT group have several GB of data stored in .pst files. To provide these
users with larger mailboxes, the project team has agreed to provide the members of the IT group with
archive mailboxes. You need to implement archive mailboxes for these users.
1.
Create a mailbox database that will be used to store archive mailboxes.
2.
Create an archive mailbox for all members of the IT group, and verify its functionality.
3.
Create an archive policy that moves all messages from the primary mailbox to the archive mailbox
after 36 months.
Task 1: Create a mailbox database that will be used to store archive mailboxes
1.
On NYC-EX10, in the Exchange Management Console, under Organization Configuration

Management, click Mailbox.
2.
Using the New Mailbox Database wizard, create a new mailbox database, name it Archive
Database, and place it on the NYC-EX11 server.
Task 2: Create an archive mailbox for all members of the IT group, and verify its
functionality
1.
On NYC-EX10, in the Exchange Management Console, under Recipient Management, click Mailbox.
2.
Sort the mailbox list by organizational unit, select all of the users in the contoso.com/IT OU, and
then create an archive mailbox for them. Place archive mailboxes on Archive Database that you
created in Task 1.
3.
Log on as Terri on NYC-CL1, start Outlook 2010, and verify that Archive Mailbox appears in the
navigation pane.
Task 3: Create an archive policy that moves all messages from the primary mailbox to
the archive mailbox after 36 months
1.
Create a Retention Policy Tag that moves all messages older than 36 months from the default
mailbox to the archive mailbox, and name the tag, Move to archive after 36 months.
2.
Create a retention policy with this Retention Policy Tag.
3.
Apply the retention policy to members of IT OU.
Results: After this exercise, you should have configured archive mailboxes for all members of the IT
group.
10-75
Exercise 2: Configuring Retention Policies

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

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

following steps:
1.
2.
3.
4.
machine.
5.
machine.
6.
machine.
10-77
Review Questions
1.
You need to ensure that a copy is saved of all messages sent to a particular distribution group. You
only want to save one copy of the message sent to the distribution group, and not copies of all the
messages sent to individual members of the group. What should you configure?
2.
You need to ensure that a user can search all Exchange Server 2010 organization mailboxes for
specific content. What should you do? What user training will you need to provide?
3.
You need to ensure that all messages related to a particular project are retained for three years. Users
in your organization use both Office Outlook 2007 and Outlook 2010. What should you do?
Common Issues Related to Implementing Messaging Policies
Identify the causes for the following common issues related to implementing messaging policies, and fill
Issue
Transport rules that use regular expressions
are not applied consistently.
Message recipients report that they are
receiving error messages when they receive
digitally signed messages from other users in
the organization.
After you implement a transport rule, users
report that some of the messages that they
send to Internet recipients are not being
delivered, and they are not receiving
notification of why the messages were not
delivered.
Troubleshooting tip
10-78

1.
The Exchange Server administrators at Contoso, Ltd have implemented a custom message
classification on the Exchange Server 2010 servers, but they notice that the custom classification is not
available on the Office Outlook 2007 clients in the organization. What do they need to do?
2.
A. Datum Corporation has deployed an AD RMS server, and users are using it to protect email.
However, users report that when they protect email messages, users outside the organization cannot
read the messages. What should A. Datum messaging administrators do?
3.
Woodgrove Bank has implemented message journaling for all messages sent to and from the legal
and compliance teams. These messages need to be available to auditors for seven years. The
mailboxes used for journaling are growing rapidly. What should the messaging administrators at
Woodgrove Bank do?
Best Practices Related to Configuring Message Policy and Compliance

Implementing messaging policies in Exchange Server 2010 can be complicated, and the optimal
configuration will vary in every organization. However, it is critical that you start thinking about this
issue now, to implement the policies and configurations that will meet your organizations legal
requirements.
Implement messaging policies only after extensive testing in a lab environment. If you configure
messaging policies incorrectly, you could potentially delete messages that should be retained, or
disrupt message delivery. Additionally, some messaging policies may have unintended consequences.
Because of this, be sure to test all messaging policies thoroughly, and implement the policies in the
production environment incrementally.
Planning messaging policies always involves discussions with legal and compliance personnel who
may not understand how you can use Exchange Server 2010 to enforce messaging policies. Be
prepared to explain what Exchange Server 2010 can and cannot do in terms that people who are not
messaging experts can understand.
Tools
Tool
Use for
Where to find it
Exchange
Administration and management of
Management Console
Exchange Server 2010 objects
Start menu
Exchange
Management Shell
Administration and management of

Exchange Server 2010 objects
Start menu
Exchange Control
Panel
Performing Multi-mailbox search
/ecp virtual folder
11-1
Module 11
Securing Microsoft Exchange Server 2010
Contents:
Lesson 1: Configuring Role Based Access Control
11-3
Lesson 2: Configuring Audit Logging
11-29
Lesson 3: Configuring Secure Internet Access
11-35
11-46
Module Overview
11-2
In many organizations, Microsoft Exchange Server 2010 provides a critical business function for both
internal and external users. Additionally, many organizations expose at least a few of their Exchange
servers to the Internet. For these reasons, it is important that you secure your upgraded Exchange Server
2010 deployment. It is important to configure administrative permissions properly, so that every person
that manages Exchange servers and objects has the correct permissions. For Exchange Server 2003 and
Exchange Server 2007 administrators, this means learning how to configure role base access control
(RBAC), a new feature for Exchange Server 2010.
Additionally, because mailboxes can contain sensitive, high-business impact information and personally
identifiable information, it is important for you to track who logs on to the mailboxes in your
organization, and what actions these users are performing.
Exchange Server 2010 provides a new set of functionalities for administrative roles, auditing, and securing
Internet access. This module describes how to configure administrative permissions and auditing, and how
to secure Internet access for Exchange Server 2010.
Objectives
Configure RBAC permissions.
Configure audit logging.
Configure secure Internet access.
Lesson 1
Configuring Role Based Access Control
11-3
Exchange Server 2010 uses the RBAC permissions model to restrict which administrative tasks users can
perform on the Mailbox, Client Access, Hub Transport, and Unified Messaging server roles. With RBAC,
you can control the resources that administrators can configure, and the features that users can access.
Additionally, Exchange Server 2010 Service Pack 1 (SP1) provides you with a way to split permissions
between administrators that manage Active Directory Domain Services (AD DS) objects and
administrators that manage Exchange Server objects. This lesson describes how to implement RBAC
permissions and split permissions in Exchange Server 2010, and how to configure permissions on Edge
Transport servers.
Objectives
Describe RBAC.
Describe management role groups.
Describe built-in management role groups.
Describe the process for configuring custom role groups.
Configure custom role groups.
Describe management role assignment policies.
Describe Exchange Server split permissions.
Configure RBAC split permissions.
Configure AD DS split permissions.
Manage permissions on Edge Transport servers.
Describe permission coexistence with previous Exchange Server versions.
11-4
What Is Role Based Access Control?
11-5
Exchange Server 2003 and Exchange Server 2007 control administrative permissions by using groups with
a predefined set of permissions. For example, in Exchange Server 2003, only three administrative roles
exist: Exchange View Only, Exchange Administrator, and Exchange Full Administrator. In Exchange Server
2007, you can choose between five administrative role groups: Exchange Organization Administrator,
Exchange Recipient Administrator, Exchange Server Administrator, and Exchange Public Folder
Administrator.
These administrative groups control permissions at a very high level. You cannot easily control
permissions on a granular level unless you want to edit the access control lists (ACLs) for each Active
Directory and Exchange Server object. Because of this, it is not uncommon to provide users with more
permissions than they actually need to perform their jobs.
With RBAC, you do not have to modify and manage ACLs to achieve granular control over permissions.
RBAC controls the administrative tasks that users can perform, and the extent to which they can
administer their own mailbox and distribution groups. Therefore, instead of placing users in groups with
predefined sets of administrative rights, RBAC allows you to control permissions down to the command
level.
You can define precisely which Exchange Management Shell cmdlets each user can run, and which objects
and attributes each user can modify. You also can assign permissions that range from enabling users to
run all cmdlets and modify all objects in the Exchange Server 2010 organization, to enabling users to run
only a limited set of cmdlets and modify only a few attributes on certain objects.
All Exchange Server administration toolsincluding the Exchange Management Console, Exchange
Management Shell, and Exchange Control Paneluse RBAC to determine user permissions. This means
that permissions are consistent regardless of which tool you use.
How Does RBAC Work?
11-6
You can use RBAC on every server running Exchange Server 2010, with the exception of the Edge
Transport servers. RBAC verifies whether each user performing an action has authorization to perform that
action. If a user is not authorized to perform an action, RBAC does not allow the action to proceed.
If a user has authorization to perform an action, RBAC verifies whether the user has authorization to
perform the action against the specific object being requested, as follows:
If the user is authorized, RBAC allows the action to proceed.
If the user is not authorized, RBAC does not allow the action to proceed.
If RBAC allows an action to proceed, the action is performed in the context of the Exchange Trusted
Subsystem and not the user's context. The Exchange Trusted Subsystem is a highly privileged universal
security group that has read/write access to every Exchange Serverrelated object in the Exchange
organization. It is also a member of the Administrators local security group and the Exchange Windows
Permissions universal security group, which enables Exchange Server 2010 to create and manage Active
Directory objects.
Note It is important to understand that it does not matter which Active Directory
permissions a user has when using the Exchange Server management tools. If the user is
authorized to perform an action through RBAC, the user can perform the action regardless of
his or her Active Directory permissions. Conversely, if a user is an Enterprise Admin in AD DS
but is not authorized to perform an actionsuch as creating a mailboxin the Exchange
Server management tools, the action will not succeed because the user does not have the
required permissions according to RBAC.
RBAC Options
RBAC assigns permissions to users in two primary ways, depending on whether the user is an
administrator or end user:
Management role groups. RBAC uses management role groups to assign permissions to
administrators. These administrators may require permissions to manage the Exchange Server
organization or some part of it. Some administrators may require limited permissions to manage
specific Exchange Server features, such as compliance or specific recipients.
Management role assignment policies. RBAC uses management role assignment policies to assign
end-user management roles. Role assignment policies consist of roles that control what users can do
with their mailboxes or distribution groups. These roles do not allow management of features with
which users are not associated directly.
Note You also can use direct role assignment to assign permissions. Direct role assignment
is an advanced method for assigning management roles directly to a user or universal
security group without the need to use a role group or role assignment policy. Direct role
assignments are useful when you need to provide a granular set of permissions to a specific
user only. However, we recommend that you avoid using direct role assignment, as it is
significantly more complicated to configure and manage.
Question: What requirements does your organization have for assigning Exchange Server
permissions? Does your organization use a centralized or decentralized administration
model? What special permissions will you need to configure for Exchange Server 2010?
What Are Management Role Groups?
11-7
A management role group is a universal security group that simplifies the process for assigning
management roles to a group of users. All members of a role group are assigned the same set of roles.
Role groups are assigned administrator and specialist roles that define major administrative tasks in
Exchange Server 2010, such as organization management, and recipient management. Role groups enable
you to more easily assign a broader set of permissions to a group of administrators or specialist users.
To use management role groups, add users to the appropriate built-in management role group, or to a
custom management role group. This is described in later topics.
Use management role groups to assign administrator permissions to groups of users. To understand how
management role groups work, you must understand their components.
Management Role Group Components
Management role groups use several underlying components to define how RBAC assigns permissions:
Role holder. A role holder is a user or security group that you can add to a management role group.
When a user becomes a management role group member, RBAC grants it all of the permissions that
the management roles provide. You can either add user accounts to the group in AD DS, or use the
Add-RoleGroupMember cmdlet.
Management role group. The management role group is a universal security group that contains users
or groups that are role group members. Management role groups are assigned to management roles.
The combination of all the roles assigned to a role group defines everything that users who are added
to a role group can manage in the Exchange Server organization.
Management role. A management role is a container for a group of management role entries. These
entries define the tasks that users can perform if RBAC assigns them the role using management role
assignments.
11-8
Management role entries. A management role entry is a cmdlet, including its parameters, which you
add to a management role. By adding cmdlets to a role as management role entries, you are granting
rights to manage or view the objects associated to that cmdlet.
Management role assignment. A management role assignment assigns a management role to a role
group. After you create a management role, you must assign it to a role group so that the role
holders use it. Assigning a management role to a role group grants the role holders the ability to use
the cmdlets that the management role defines.
Management role scope. A management role scope is the scope of influence or impact that the role
holder has once RBAC assigns a management role. When assigning a management role, use
management scopes to target which objects that role controls. Scopes can include servers,
organizational units, recipient objects, and more.
To understand how these components work together, think of it this way:
A management role group collects users or groupsthe role holdersto whom you want to assign rights.
Additionally, you group the cmdlets that you will allow the role holders to run into a management role.
Then, by using management role assignment, you connect the management role to the management role
group. Finally, the management role scope defines the target object scope where these commands and
rights can be used.
Management Role Group Examples
Management role groups define who can perform specific tasks and the scope within which
administrators can perform those tasks. For example, you could use RBAC to assign permissions as listed
in the following table.
Role
holder
Management
role group
Management
role
Management role
entries
Gregory
Organization
Management
Organization
Management
All Exchange Server

cmdlets
Organization
Alice
Help Desk
HelpDesk
Cmdlets related to
mailbox and user account
management
Organization
Jason
Sales Admins
SalesAdminRole
Cmdlets related to
Recipient management
only
Sales department
organizational unit (OU) in
AD DS
Management role scope
11-9
Built-In Management Role Groups
Exchange Server 2010 includes several built-in management 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.
The only exceptions are the following:
You cannot remove any delegating role assignments from the Organization Management role group.
You cannot remove the Role Management role from the Organization Management role group.
The following table lists the built-in role groups included with Exchange Server 2010.
Role group
Description
Organization
Management
Role holders have access to the entire Exchange Server 2010 organization, and
can perform almost any task against any Exchange Server 2010 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 2010 recipients
within the Exchange Server organization.
UM Management
Role holders can manage the Unified Messaging features within the
organization, such as Unified Messaging server configuration, properties on
mailboxes, prompts, and auto-attendant configuration.
Discovery Management
Role holders can perform searches of mailboxes in the Exchange organization

for data that meets specific criteria.
Records Management
Role holders can configure compliance features, such as retention policy tags,
message classifications, transport rules, and more.
11-10
Role group
Description
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.
Note All of these role groups are located in the Microsoft Exchange Security Groups OU in
AD DS. This OU contains several other universal security groups that grant permissions to
the Exchange Server computer accounts.
Process for Configuring Custom Role Groups
In addition to the built-in role groups, you also can create custom role groups to delegate specific
permissions within the Exchange Server organization. Use this option when your ability to limit
permissions is beyond the scope of the built-in role groups.
Configuring a Custom Management Role Group
11-11
RBAC enables complete flexibility in how you assign permissions in an Exchange Server 2010 environment.
For example, RBAC enables you to assign permissions to a group of administrators in a branch office who
only need to manage recipient tasks for branch-office users and mailboxes on branch office Mailbox
servers. To implement this scenario, you would:
1.
Create a new role group, and then add the branch office administrators to the role group. You can
use the New-RoleGroup cmdlet to create the group. When you create the group, you must specify
the management roles. Additionally, you also can specify the management scope for the role.
2.
Assign management roles to the branch office administrators. To delegate permissions to a custom
role group, you can use one or more of the default built-in management roles, or you can create a
custom management role that is based on one of the built-in management roles. Exchange Server
2010 includes approximately 70 built-in management roles that provide granular levels of
permissions. To view a complete list of all the management roles, use the get-managementrole
cmdlet. To view detailed information about a management role, type get-managementrole
<rolename> | FL, and then press Enter.
Note Example of note reader aid. 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
11-12
cmdlet. However, it can be complicated to create a new management role and remove
unnecessary management role entries, so we recommend that you use one of the existing
roles whenever possible.
3.
Identify the management scope for the management role. For example, in the branch office scenario,
you could create a role assignment with an OU scope that is specific to the branch office OU.
4.
Create the management role group using the information that you collect. Use the New-RoleGroup
cmdlet to create the link between the role group, the management roles, and the management
scope.For example, consider the following command:
New-RoleGroup Name BranchOfficeAdmins roles Mail Recipients, Distribution Groups,

Move Mailboxes, Mail Recipient Creation
User BranchOfficeAdmins RecipientOrganizationUnitScope Contoso.com/BranchOffice
This command does the following:
Creates a new role group named BranchOfficeAdmins.
Assigns the Mail Recipients, Distribution Groups, Move Mailboxes, and Mail Recipient Creation
management roles to the BranchOfficeAdmins role group.
Configures a management role scope limited to the BranchOffice OU in the Contoso.com

domain.
Note With Exchange Server 2010 SP1, administrators with the proper permissions can also
create custom management role groups by using the Exchange Control Panel. After logging
into Exchange Control Panel, navigate to the Roles&Auditing window.
Demonstration: Configuring Custom Role Groups
11-13
In this demonstration, you will review how to create a custom role group, and how to assign management
roles to the group. You also will verify that the correct permissions are assigned to the user accounts.
Demonstration Steps
1.
Log on to NYC-EX10 as Administrator with password Pa$$w0rd.
2.
On NYC-EX10, open Exchange Control Panel and log on as Contoso\Administrator.
3.
Navigate to Roles&Auditing.
4.
Create a new role group named Marketing Admins.
5.
Set the write scope to contoso.com/Marketing.
6.
Add the Mail Recipient and Mail Recipient Creation roles.
7.
Add Adam Carter to the new role group.
8.
In Active Directory Users and Computers, verify that the group has been created in the Microsoft
Exchange Security Groups OU, and that the user has been added to the group.
9.
Open the Exchange Management Console as the delegated user account. Verify that the user can
modify mailboxes and create new mailboxes only in the Marketing OU.
Question: Will you implement custom management roles in your organization? If so, how
will you configure the management roles?
11-14
What Are Management Role Assignment Policies?
A management role assignment policy is a collection of one or more end-user management roles that
enables end users to manage their own mailbox and distribution group configuration. These policies allow
you to define everything users can do with their mailboxes. For example, a role assignment policy may
allow users to set display names, set up voice mail, and configure Inbox rules. Another role assignment
policy might allow users to change their company information, such as addresses or phone numbers, use
text messaging, and set up distribution groups.
Every user with an Exchange Server 2010 mailbox 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.
Choose not to assign role assignment policies by default.
Role Assignment Components

Role assignment policies consist of the following components that define what users can do with their
mailboxes:
Mailbox. Mailboxes are assigned a single role assignment policy. When a mailbox is assigned a role
assignment policy, the policy is applied to the mailbox. This grants the mailbox all of the permissions
that the management roles provide.
Management role assignment policy. The management role assignment policy is an object in
Exchange Server 2010. Users are associated with a role assignment policy when you create their
mailboxes, or when you change the role assignment policy on their mailboxes. The combination of all
roles included in a role assignment policy defines everything that associated users can manage on
their mailboxes or distribution groups.
11-15
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.
A default role assignment policy is a policy that is assigned to a mailbox when the mailbox is created or
moved to a server running Exchange Server 2010, and when a role assignment policy was not provided
using the RoleAssignmentPolicy parameter on the New-Mailbox or Enable-Mailbox cmdlets. You can
change the default permissions on the default role assignment policy by adding or removing
management roles to or from it.
When you change the default role assignment policy, mailboxes assigned the default role assignment
policy are not automatically assigned the new default role assignment policy. If you want to update
previously created mailboxes to use the role assignment policy that you have set as default, you must use
the Set-Mailbox cmdlet to do so.
You can also manage management role assignments policies through the Exchange Control Panel.
11-16
What Are Exchange Server Split Permissions?
Although AD DS and Exchange Server 2010 are highly integrated, in some larger organizations, managing
the AD DS and Exchange Server infrastructures is separated. Many organizations have two IT groups:
administrators that manage the organizations Exchange Server infrastructure (including servers and
recipients), and administrators that manage the AD DS infrastructure. Normally, this means that Exchange
Server administrators cannot manage AD DS objects, and vice versa.
Organizations that separate the management of Exchange Server 2010 objects and Active Directory
objects use a split permissions model. Split permissions enable organizations to assign specific permissions
and related tasks to specific groups within the organization.
The highest level of split permissions is the separation of Exchange Server management and Active
Directory management. This is an important separation for many organizations, because the Active
Directory infrastructure often spans many locations, domains, services, applications, and even Active
Directory forests. Active Directory administrators must ensure that changes made to AD DS do not
negatively impact any other services. As a result, typically only a small group of administrators is allowed
to manage that infrastructure.
At the same time, the infrastructure for Exchange Serverincluding servers and recipientscan also be
complex and require specialized knowledge. Additionally, Exchange Server stores extremely confidential
information. Exchange Server administrators can potentially access this information. By limiting the
number of Exchange Server administrators, the organization limits who can make changes to Exchange
Server configuration, and who can access sensitive information.
Split permissions typically make a distinction between the creation of security principals in AD DS (such as
users and security groups), and the subsequent configuration of those objects. This helps reduce the
chance of unauthorized access to the network by controlling who can create objects that grant access to
it. Most often only Active Directory administrators can create security principals while other
administratorssuch as Exchange Server administratorscan manage specific attributes on existing
Active Directory objects.
11-17
To support the varying needs for separating Exchange Server and Active Directory management,
Exchange Server 2010 lets you choose whether you want a shared permissions model or a split
permissions model.
Split Permissions Models in Exchange Server 2010 SP1

Exchange Server 2010 SP1 offers two types of split permissions models:
RBAC split permissions. Permissions to create security principals in the Active Directory domain
partition are controlled by RBAC. Only those who are members of the appropriate role groups can
create security principals.
RBAC split permissions is a good choice for an organization if the following are true:
The organization does not require security principal creation to be performed using only Active
Directory management tools, and only by users who are assigned to specific Active Directory
permissions.
The organization allows services such as Exchange servers to create security principals.
You want to simplify the process required to create mailboxes, mail-enabled users, distribution
groups, and role groups by allowing their creation from within the Exchange Server management
tools.
You want to manage the membership of distribution groups and role groups within the
Exchange Server management tools.
You have third-party programs that require that Exchange servers be able to create security
principals on their behalf.
Active Directory split permissions. Permissions to create security principals in the Active Directory
domain partition are completely removed from any Exchange Server user, service, or server. No
option is provided in RBAC to create security principals. Creation of security principals in AD DS must
be performed using Active Directory management tools.
Active Directory split permissions is a good choice for an organization if the following are true:
The organization requires security principals to be created using only the Active Directory
management tools, or only by users who are granted specific permissions in AD DS.
You want to completely separate the ability to create security principals from those who manage
the Exchange Server organization.
You want to perform all distribution group managementincluding creating and modifying
distribution groupsusing Active Directory management tools.
You do not want Exchange servers, or third-party programs that use Exchange Server on their
behalf to create security principals.
Exchange Server 2010 SP1 defaults to the shared permissions model, which is the same behavior as
Exchange Server 2003 and Exchange Server 2007. 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.
Configuring Split Permissions
If your organization separates Exchange Server management and Active Directory management, you need
to configure Exchange Server 2010 to support the split permissions model. When configured correctly,
11-18
only the administrators who you want to create security principals (such as Active Directory
administrators), will be able to do so, while only Exchange Server administrators will be able to modify the
Exchange Server attributes on existing security principals.
This permissions splitting can also apply to permissions on the domain and configuration partitions in AD
DS. Exchange Server uses both partitions: the domain partition stores users, groups, and other objects
from a specific domain, and the configuration partition contains Exchange Server service information. In
the split permissions model, an administrator with permission for the domain partition might not have
permission to administer data in the configuration partition, and vice versa.
You can only enable and disable split permissions by running Setup on a computer running Exchange
Server 2010 SP1. However, Active Directory split permissions configuration applies to both Exchange
Server 2010 and Exchange 2010 SP1 servers. It does not, however, have an impact on Exchange 2003 and
Exchange 2007 servers.
You can configure split permissions during Setup, or you can postpone the task until after Exchange
Server installation. If you configure split permissions during Exchange Server Setup, you can activate
Active Directory split permissions mode. You can switch back to the shared permissions model any time
after Exchange Server installation.
Note If your organization chooses to use the split permissions model instead of the shared
permissions model, use the RBAC split permissions model. The RBAC split permissions model
provides significantly more flexibility while providing nearly the same administration
separation as Active Directory split permissions, with the exception that Exchange servers and
services can create security principals in the RBAC split permissions model.
Configuring RBAC Split Permissions
11-19
The RBAC security model modifies the default management role assignments to separate those who can
create security principals in the Active Directory domain partition from those who administer the
Exchange Server organization data in the Active Directory configuration partition. In this model, you are
actually removing rights that Exchange Server administrators have in the shared permissions model to
focus them only toward Exchange Server administration.
Administrators who are members of the Mail Recipient Creation and the Security Group Creation and
Membership roles can create security principals, such as users with mailboxes and distribution groups.
These permissions remain separate from the permissions required to create security principals outside of
the Exchange Server management tools. Exchange Server administrators who are not assigned the Mail
Recipient Creation or Security Group Creation and Membership roles can still modify Exchange Serverrelated attributes on security principals. Active Directory administrators also have the option of using the
Exchange Server management tools to create Active Directory security principals.
Exchange servers and the Exchange Trusted Subsystem also have permissions to create security principals
in Active Directory on behalf of users and third-party programs that integrate with RBAC.
Unlike activating AD DS split permissions, switching from shared permissions to RBAC split permissions is a
manual process. If you want to use RBAC split permissions in your organization, you should remove the
permissions required to create security principals from the role groups that are granted them by default.
The following table shows the roles that enable the creation of security principals in Exchange Server and
the management role groups they are assigned to by default.
11-20
Management role
Role Group
Mail Recipient Creation Role
Organization Management
Security Group Creation and

Membership Role
By default, members of both the Organization Management and Recipient Management role groups can
create security principals. You must transfer the ability to create security principals from the built-in role
groups to a new role group that you create.
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.
3.
Create regular and delegating role assignments between the Mail Recipient Creation role and the
new role group.
4.
Create regular and delegating role assignments between the Security Group Creation and
Membership role, and the new role group.
5.
Remove the regular and delegating management role assignments between the Mail Recipient
Creation role, and both the Organization Management and Recipient Management role groups.
6.
Remove the regular and delegating role assignments between the Security Group Creation and
Membership role, and the Organization Management role group.
After configuring RBAC split permissions, only members of the new role group that you create can create
security principals, such as mailboxes. The new role group will only be able to create the objects; it will not
be able to configure the Exchange Server attributes on the new object. An Active Directory
administratorwho is a member of the new groupwill need to create the object, and then an Exchange
Server administrator will need to configure the Exchange Server attributes on the object. 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
11-21
Exchange Server administrators will, however, be able to create and manage Exchange Serverspecific
objects (such as transport rules and distribution groups) and manage Exchange Serverrelated attributes
on any object.
Additionally, the associated features in the Exchange Management Console and Exchange Control Panel
(such as the New Mailbox Wizard) will also no longer be available or will generate an error if you try to
use them.
If you want the new role group to also be able to manage the Exchange Server attributes on the new
object, you need to assign the Mail Recipients role to the new role group.
11-22
Configuring Active Directory Split Permissions
With Active Directory split permissions, you must create security principals in the Active Directory domain
partitionsuch as mailboxes and distribution groupsusing Active Directory management tools. Several
changes are made to the permissions granted to the Exchange Trusted Subsystem and to the Exchange
servers to limit what Exchange Server administrators and servers can do. The following changes in
functionality occur when you enable Active Directory split permissions:
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.
Switching to Active Directory split permissions is a choice that you can make when you install Exchange
Server 2010 SP1 either by using the Setup wizard or by using the /ActiveDirectorySplitPermissions
parameter while running setup.com from the command line. You can also enable or disable Active
Directory split permissions after you have installed Exchange Server 2010 by rerunning setup.com from
the command line.
To enable Active Directory split permissions, set the /ActiveDirectorySplitPermissions parameter to true.
To disable it, set this parameter to false. You must always specify the /PrepareAD parameter along with
the /ActiveDirectorySplitPermissions parameter.
If you have multiple domains within the same forest, you must also either specify the /PrepareAllDomains
parameter when you apply Active Directory split permissions, or run Setup with the /PrepareDomain
parameter in each domain. If you choose to run Setup with the /PrepareDomain parameter in each
11-23
domain rather than use the /PrepareAllDomains parameter, you must prepare every domain that contains
Exchange servers, mail-enabled objects, or global catalog servers that could be accessed by an Exchange
server.
Note You cannot enable Active Directory split permissions if you have installed Exchange
Server 2010 on a domain controller. After you enable or disable Active Directory split
permissions, we recommend that you restart the Exchange 2010 servers in your organization
to force them to pick up the new Active Directory access token with the updated
permissions.
Exchange Server 2010 SP1 achieves Active Directory split permissions by removing permissions and
membership from the Exchange Windows Permissions security group. This security groupin shared
permissions and RBAC split permissionsis given permissions to many non-Exchange Server objects and
attributes throughout AD DS. By removing the permissions and membership to this security group,
Exchange Server administrators and services are prevented from creating or modifying the non-Exchange
Server Active Directory objects.
Exchange Server 2010 SP1 exhibits the following behaviors when you enable Active Directory split
permissions either through the Setup wizard or by running setup.com with the /PrepareAD and
/ActiveDirectorySplitPermissions:true parameters:
Creates an OU called Microsoft Exchange Protected Groups.
Creates the Exchange Windows Permissions security group in the Microsoft Exchange Protected
Groups OU.
Does not add the Exchange Trusted Subsystem security group to the Exchange Windows Permissions
security group.
Skips creating non-delegating management role assignments to management roles with the
following management role type:
MailRecipientCreation
SecurityGroupCreationandMembership
Does not add access control entries (ACEs) that would have been assigned to the Exchange Windows
Permissions security group to the Active Directory domain object.
If you run Setup with the /PrepareAllDomains or /PrepareDomain parameter, the following occurs in each
child domain Exchange Server prepares:
All ACEs assigned to the Exchange Windows Permissions security group are removed from the
domain object.
ACEs are set in each domain as defined in Exchange 2010 Deployment Permissions Reference with the
exception of any ACEs assigned to the Exchange Windows Permissions security group.
11-24
Managing Permissions on Edge Transport Servers
You deploy the Edge Transport server role in an organizations perimeter network, either as a stand-alone
server, or as a member of a perimeter Active Directory domain. Deploying an Edge Transport server does
not generate Exchange Server-specific groups; instead, the Administrators local group is granted full
control of the Edge Transport server, which includes an instance of Active Directory Lightweight Directory
Service (AD LDS).
You can administer Edge Transport servers remotely by using Remote Desktop. When you enable Remote
Desktop, RBAC grants the Administrators local group remote logon permissions automatically. Other user
accounts must have membership in the Remote Desktop Users local group to use a remote desktop
connection to log on to the server. You should create a specific user account for each user who
administers an Edge Transport server. You must add these user accounts to the Administrators local group
to ensure that RBAC grants them the correct access level.
Permissions Required to Administer the Edge Transport Server
The following table lists common administrative tasks that users perform on the Edge Transport server,
and the group memberships necessary to complete each task successfully.
Task
Required group membership
Backup and restore
Backup Operators
Enable and disable agents
Administrators
Configure connectors
Administrators
Configure anti-spam policies
Administrators
Configure IP Block and Allow lists
Administrators
View queues and messages
Users
11-25
Task
Required group membership
Manage queues and messages
Administrators
Create an Edge Subscription file
Administrators
11-26
Permissions Coexistence with Previous Exchange Server Versions
As mentioned previously, Exchange Server 2003 and Exchange Server 2007 do not control permissions
with RBAC. Therefore, during the coexistence period of your upgrade to Exchange Server 2010, you must
understand how to integrate RBAC with the older permissions models used by Exchange Server 2003 or
Permissions Coexistence with Exchange Server 2003
Permissions in Exchange Server 2010 and Exchange Server 2003 are completely separate. You must take
steps to grant existing Exchange Server 2003 administrators permissions to your Exchange 2010 servers,
and vice versa. Additionally, management of Exchange Server 2010 and Exchange Server 2003 is
performed separately using the management tools provided by each version. You can grant permissions
to your administrators so that they can manage both Exchange Server 2003 and Exchange Server 2010
during the coexistence period.
To grant existing Exchange Server 2003 administrators appropriate permissions to manage Exchange 2010
servers, you must add them as members to one or more Exchange Server 2010 role groups. You can add
either users or groups to role groups. The permissions granted to the role groups are applied to the users
or groups you add as members.
The following table provides a mapping between Exchange Server 2003 administrative roles and
Exchange Server 2010 role groups.

administrative role
11-27
Exchange Server 2010 role group
Exchange Full
Administrator
Exchange Full Administrator
Exchange Administrator
No equivalent role group. To generate the equivalent role group in

Exchange Server 2010, create a custom role group based on the
Organization Management role group, but without any delegating role
assignments.
Exchange View-Only
View Only Organization Management
If all of your Exchange Server 2003 administrators are members of one of the three Exchange Server 2003
administrative roles, you must add the members of these administrative groups to their equivalent
Note If you use domain local or global Active Directory security groups, you must change
them to universal security groups if you want to add them as members of an Exchange
Server 2010 role group. Exchange Server 2010 supports only universal security groups.
Permissions Coexistence with Exchange Server 2007
The Exchange Server 2007 administrative model leverages Active Directory forests to define security
boundaries. There is no isolation of security permissions within a particular forest. Forest owners and
enterprise administrators can always gain access to all resources in any domain. In Exchange Server 2007,
you may have to grant both enterprise administrator rights and top-level domain administrator rights on
a temporary basis only.
Exchange Server 2007 uses five groups with the following predefined administrator roles:
Exchange Organization Administrator
Exchange View-Only Administrator
Exchange Recipient Administrator
Exchange Server Administrator
Exchange Public Folder Administrator
By adding users or groups to one of these groups, you provide them with a predefined set of rights and
permissions. If you need to make more granular permission assignments, you can modify the ACLs on
individual Exchange Server 2007 objects, such as address lists or databases. You must add the user or
security group of which the user is a member, directly to the ACL. Then, the actions are performed in the
context of the particular user.
If you want Exchange Server 2007 administrators to administer Exchange 2010 servers, you must add the
Exchange Server 2007 administrators as members of one or more Exchange Server 2010 role groups. You
can add either users or universal security groups to role groups. The permissions granted to the role
groups are then applied either to the users, or to the universal security groups that you add as members.
Note When you are performing an upgrade, Exchange Server 2007 administrative groups
are automatically added to the corresponding Exchange Server 2010 groups.
11-28
The following table describes the mapping between Exchange Server 2007 administrator roles and
Exchange Server 2007 administrative role
Exchange Server 2010 role group
Exchange Organization Administrator
Exchange Recipient Administrator
Exchange Server Administrator
Server Management
Exchange View-Only Administrator
View Only Organization Management
Exchange Server
No equivalent role group in Exchange Server 2010
Exchange Public Folder Administrator
Public Folder Management
If the built-in role groups do not provide the specific set of permissions that you want to grant to some
administrators, you can create custom role groups. When you create a custom role group, you can select
which roles to add to it. You can define the specific features that you want members of the role group to
manage. For example, if you want administrators to manage only distribution groups, you can create a
custom role group, and then select only the Distribution Groups role.
Lesson 2
Configuring Audit Logging
11-29
In organizations where multiple Exchange Server administrators exist, it can sometimes be difficult to trace
changes that have been made to the Exchange configuration objects. Additionally, it can be difficult to
provide information about users accessing other mailboxes or performing other types of data access.
Exchange Server 2010 SP1 contains new logging functionality that can provide you with information
about administrative tasks performed on your Exchange servers.
Objectives
Describe administrator audit logging.
Describe mailbox audit logging.
Configure audit logging.
11-30
What Is Administrator Audit Logging?
In Exchange Server 2010, you can use administrator audit logging to capture data about changes made to
your organization by users and administrators. By maintaining a log of these changes, you can trace
changes back to the users who made the changes, augment your change logs with detailed records of
changes as they were implemented, and comply with regulatory requirements and discovery requests.
Exchange Server 2010 administrator audit logging logs cmdlets performed in the Exchange Management
Shell. However, because all tasks performed in the Exchange Management Console and Exchange Control
Panel are translated to Exchange Management Shell cmdlets, you can perform all logging of all
management tasks no matter which tool you are using to perform the task.
Cmdlets, regardless of where they are run from, are audited if a 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. Audit logging is intended to show what actions
were taken to modify objects in an Exchange Server organization, rather than what objects were viewed.
Configure administrator audit logging in the Exchange Management Shell by using the SetAdminAuditLogConfig cmdlet. This cmdlet uses several parameters that allow you to configure audit
logging. Some of the most important parameters for this cmdlet are:
AdminAuditLogEnabled. When set to False, logging is not enabled. By default, this is the case for
Exchange Server 2010, but logging is enabled by default in Exchange Server 2010 SP1.
TestCmdletLoggingEnabled. This parameter enables Test- cmdlet logging.
AdminAuditLogCmdlets. This parameter specifies which cmdlets are logged when administrator audit
logging is enabled. By default, all cmdlets are logged, as indicated by the * wildcard character.
AdminAuditLogParameters. This parameter specifies whether cmdlet parameters are logged. By

default, this parameter is set to log all cmdlet parameters, as indicated by the * wildcard character.
11-31
AdminAuditLogAgeLimit. This parameter specifies how long each log entry should be kept before it is
deleted. The default age limit is one year.
AdminAuditLogMailbox. This parameter controls which mailbox is used to store the logged results.
This applies only to Exchange Server 2010.
You can enable administrator audit logging by specifying the following cmdlet:
Set-AdminAuditLogConfig -AdminAuditLogEnabled $True
If you want to see how administrator audit logging is configured currently, specify the GetAdminAuditLogConfig cmdlet.
Each time a cmdlet is logged, Exchange Server creates an audit log entry. Exchange Server 2010 stores
audit logs in a hidden, dedicated arbitration mailbox that you can only access by using the Exchange
Control Panel Auditing Reports page, or the Search-AdminAuditLog or New-AdminAuditLogSearch
cmdlet. The logs are not accessible from Microsoft Outlook Web App or Microsoft Office Outlook.
In Exchange Server 2010, you specify the administrator audit log mailbox. Exchange Server 2010 SP1 uses
a dedicated mailbox for administrator audit logging. You cannot modify this dedicated mailbox.
The ECP Auditing Reports page, and the Search-AdminAuditLog and New-AdminAuditLogSearch
cmdlets work only with Exchange Server 2010 SP1 administrator audit logs. To view the contents of an
Exchange Server 2010 audit log mailbox, you must open that mailbox using Outlook Web App, or use an
email client such as Office Outlook.
In Exchange Control Panel, you can view only a few administrator audit logging reports. If you want to
search the logs by specifying your own search parameters, you must use the Exchange Management Shell.
For example, suppose you want to search Set-Mailbox usage between 9/1/2010 and 1/16/2011, and send
the search results to Andrea@contoso.com. Run the following cmdlet:
New-AdminAuditLogSearch -Cmdlets Set-Mailbox -StartDate 09/01/2010
-EndDate 01/16/2011 -StatusMailRecipients Andrea@contoso.com
-Name "Mailbox changes report"
After you run the New-AdminAuditLogSearch cmdlet, Exchange Server may take up to 15 minutes to
deliver the report to the specified recipient.
You can also use same parameters with the Search-AdminAuditLog cmdlet, except for the
StatusMailRecipients parameter that specifies to send a report by email. The Search-AdminAuditLog
cmdlet provides the report inside the Exchange Management Shell window.
11-32
What Is Mailbox Audit Logging?
Mailbox audit logging allows you to log mailbox access by mailbox owners, delegates (including
administrators with full mailbox access permissions), and administrators. Mailboxes are considered
accessed by an administrator only in the following scenarios:
Discovery searches.
Mailbox exports specified through the New-MailboxExportRequest cmdlet.
Microsoft Exchange Server MAPI Editor mailbox access.
When you enable audit logging for a mailbox, you can specify which user actions (accessing, moving, and
deleting) should be logged for a logon type (administrator, delegate user, and owner). Audit log entries
also include important information such as the client IP address, host name, and process or client used to
access the mailbox. For items that are moved, the entry includes the name of the destination folder.
Mailbox audit logs are generated for each mailbox that has mailbox audit logging enabled. Log entries
are stored in the Audits subfolder of the audited mailbox Recoverable Items folder. This ensures that all
audit logs are available from a single location, regardless of which client access method was used to
access the mailbox, or which server or workstation an administrator uses to access the mailbox audit log. If
you move a mailbox to another Mailbox server, the mailbox audit logs for that mailbox also move
because they are located in the mailbox.
By default, mailbox audit log entries are retained in the mailbox for 90 days.
Unlike administrator audit logging, mailbox audit logging is not enabled by default, so you have to
activate it manually. In addition, mailbox audit logging is activated on a per-mailbox basis and not as a
general option. When you enable mailbox audit logging for a mailbox, access to the mailbox and certain
administrator and delegate actions are logged by default.
To log actions taken by the mailbox owner, you must specify which owner actions should be audited. You
should be aware that auditing of mailbox owner actions can generate a large number of mailbox audit
11-33
log entries, and is therefore disabled by default. 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 Terri Chudziks mailbox:
Set-Mailbox -Identity "Terri Chudzik" -AuditEnabled $true
To disable mailbox auditing, change the $true parameter to $false.
To search the mailbox audit log, you can use both the Exchange Control Panel and the Exchange
Management Shell. The Exchange Control Panel allows you to generate reports for 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 2010, limiting results to
2000:
Search-MailboxAuditLog -Identity Terri -LogonTypes Admin,Delegate -StartDate 1/1/2010 EndDate 12/31/2010 -ResultSize 2000
The results return to the Exchange Management Shell window.
The following example searches Terris and Candys mailboxes and sends the results to a specific mailbox:
New-MailboxAuditLogSearch Name "Admin and Delegate Access" -Mailboxes "Terri
Chudzik","Candy Spoon" -LogonTypes Admin,Delegate -StartDate 1/1/2010 -EndDate
12/31/2010 -StatusMailRecipients "auditors@contoso.com"
This command locates access attempts by administrators and delegates during 2010. Results are sent to
email alias auditors@contoso.com.
11-34
Demonstration: Configuring Audit Logging
In this demonstration, you will review how to configure administrator audit logging and mailbox audit
logging, and how to search audit logs from both the Exchange Control Panel and the Exchange
Management Shell.
Demonstration Steps
1.
Log on to NYC-EX10 and NYC-EX11 as Administrator with password Pa$$w0rd.
2.
Check the administration audit logging configuration by using the Get-AdminAuditLogConfig

cmdlet.
3.
Perform a search of the administrative audit log by using the Search-AdminAuditLog cmdlet.
4.
Enable mailbox auditing for Terri@contoso.com.
5.
Access Terris mailbox as Candy Spoon and send an email message from Terris mailbox to
Administrator.
6.
Using the Exchange Control Panel, perform a search for mailboxes accessed by non-owners.
Lesson 3
Configuring Secure Internet Access
11-35
Exchange Server 2010 provides access to user mailboxes from a wide variety of clients. In many cases,
these clients may be located outside the corporate network, and may be accessing the user mailboxes
through an Internet connection. Because the Exchange 2010 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 2010 servers
from the Internet.
Objectives
Describe secure Internet access components.
Deploy Exchange Server 2010 for Internet access.
Secure Client Access traffic from the Internet.
Secure SMTP connections to the Internet.
11-36
Secure Internet Access Components
Exchange Server 2010 enables users to access their mailboxes from many different types of messaging
clients, and from almost anywhere. To provide secure access for the messaging clients, you need to
understand what types of access each client type requires.
Client Access to Exchange Servers
The following table lists the access requirement for clients when connecting to the Exchange 2010 servers
from the Internet.
Client
Access requirements
Outlook Anywhere
Access to the remote procedure call (RPC), Exchange Web Services, and online
address book virtual directories on a Client Access server.
Access to the Autodiscover virtual directory on a Client Access server if
Autodiscover is enabled.
Protocol requirements: Hypertext Transfer Protocol/Secure (HTTPS)
Outlook Web App
Access to Outlook Web App and the Exchange Control Panel virtual directories
on a Client Access server.
Protocol requirements: HTTPS
Microsoft Exchange
ActiveSync
Access to the Microsoft-Server-ActiveSync virtual directory on a Client Access

server.
Access to the Autodiscover virtual directory on a Client Access server if
Autodiscover is enabled.
Protocol requirements: HTTPS
Internet Message
Access Protocol
version 4 rev1 (IMAP4)
Access to the IMAP4 service on a Client Access server.

Access to a Simple Mail Transfer Protocol (SMTP) Receive connector on either a
Hub Transport server, Edge Transport server, or another SMTP server.
Protocol requirements: IMAP4, SMTP (Port 25 or 587)
11-37
Client
Access requirements
Post Office Protocol

version 3 (POP3)
Access to the POP3 service on a Client Access server.

Access to a SMTP Receive connector on either a Hub Transport server, an Edge
Transport server, or another SMTP server.
Protocol requirements: POP3, SMTP (Port 25 or 587)
Note In addition to the Client Access components, you also need to configure the
environment to support secure sending and receiving of SMTP email. In most cases, this
includes deploying an Edge Transport server in the perimeter network.
Options for Configuring Internet Access
There are several options available to provide the necessary access to the Client Access and transport
servers. The most common options include:
Virtual Private Network (VPNs). Some organizations require that all clients use a VPN to connect to
the internal network. The VPN gateway may be a Windows Server 2008 Routing and Remote Access
server, or a third-party solution. By enabling VPN access, users can access all resources on the internal
network, including the Exchange servers.
Using a VPN does not require modifications to the messaging clients, and users can use the same
server names both 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.
However, the VPN solution also limits the options that users have for accessing their email. Users will
be able to access their email only from clients that can establish a VPN connection to the internal
network.
Firewall configuration. Virtually all organizations have firewalls that protect their internal networks
from unwanted Internet access. You can configure these firewalls to enable users to connect to the
required virtual directories and services on the Client Access server, and to provide access to an SMTP
server for IMAP4 and POP3 clients.
Implementing a firewall solution means that messaging clients need to be configured to use a server
name that resolves to an external IP address on the firewall. If users connect to the Exchange servers
from both inside and outside the organization, this can complicate the messaging client
configuration. For example, users may connect to the Exchange servers from the internal network
using the actual server name, but may need to use a more generic name (such as mail.contoso.com),
when connecting to the server from the Internet. You may need to instruct users to use the two server
names, or you may need to configure the internal Domain Name System (DNS) zone to provide name
resolution to the more generic name.
Configuring firewalls to provide access to the Exchange servers is easy, but does raise potential
security issues. Standard firewalls can filter network traffic based on source and destination IP
addresses and ports, but cannot analyze the contents of the network packets. A standard firewall may
use reverse Network Address Translation (NAT), but still forward the packets directly to the Client
Access server. This means that the traffic that the firewall forwards to the internal Exchange servers
may contain undetected malicious code.
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.
11-38
The reverse proxy then initiates a new connection to the Client Access server, and then 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.
Question: What type of access will you enable from the Internet to your organizations
Exchange 2010 servers?
11-39
Deploying Exchange Server 2010 for Internet Access
When deploying Exchange Server 2010 so it is accessible from the Internet, you must deploy all server
roles on the internal network, except for the Edge Transport server role. You should deploy the Edge
Transport server role in the perimeter network, and it should run on a server that is not an internal
domain member.
The recommended deployment for Exchange Server 2010 Internet access includes two firewalls in a backto-back firewall scenario, which enables you to implement a perimeter network between the two. An
external firewall faces the Internet and protects the perimeter network. You then deploy an internal
firewall between the perimeter and internal networks.
Configuring External Firewalls for Internet Access
The Internet-facing or external firewall in this deployment protects the perimeter network. You configure
the firewall to accept packets based on source and destination IP addresses and ports. To support the
Exchange Server 2010 deployment, you need to configure the external firewall with the firewall rules listed
in the following table.
Destination port
Address
25
Source address: All

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

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

11-40
Destination port
Address
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 e-mail
Configuring Internal Firewalls for Internet Access
The internal firewall may be another standard firewall or reverse proxy. To support the Exchange Server
2010 deployment, configure the internal firewall with the firewall rules listed in the following table.
Destination port
Address
25
Source address: Edge Transport server

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

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

Only required for POP3 access
143, 993

Only required for IMAP4 access
587

Destination address: Hub Transport server
Only required if POP3 and IMAP4 clients are using the SMTP client submission
port to send SMTP e-mail
50636
Source address: Hub Transport servers on the internal network

Required for the Hub Transport server to replicate information to the Edge
Transport servers using EdgeSync
3389
Source address: Administrator computers on the internal network

Required if you want to use Remote Desktop to administer the Edge Transport
server remotely
Note Edge Transport servers also listen on port 50389 for unencrypted Lightweight
Directory Access Protocol (LDAP) connections. This port is used only for administering the AD
LDS instance on the Edge Transport server using standard LDAP tools. However, this port
does not have to be open on the internal firewall.
11-41
11-42
Securing Client Access Traffic from the Internet
Client Access servers are a very important component of the Exchange Server 2010 infrastructure. In
Exchange Server 2010, they accept all client connections, including messaging API (MAPI). Some of these
connectionssuch as Outlook Web App and Exchange ActiveSynccome from the Internet. To ensure that
the client connections are as secure as possible, we recommend the following implementations:
Create and configure a server certificate. By default, all Client Access servers are configured with selfsigned certificates during Exchange Server 2010 installation. Because clients do not trust this
certificate, you should replace the certificate with one from a public certification authority (CA) or
from an internal CA. If you use an internal enterprise CA, the certificates will be trusted by computers
that are the internal domains members, but not by other client computers. Thats why is
recommended to buy public certificate for this purpose.
Require Secure Sockets Layer (SSL) for all virtual directories. With Exchange Server 2010, you can
configure all of the Client Access server virtual directories to require SSL. This will encrypt all
connections to the Client Access server.
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 optionssuch as Outlook Anywhere or
Exchange ActiveSynccannot use forms-based authentication, and may need to use authentication
by the Windows NT LAN Manager (NTLM), or use basic authentication. If you configure the virtual
directories to require SSL, the network traffic that authenticates the user is encrypted.
To provide additional security, consider the following options:
11-43
Internet Security and Acceleration (ISA) server or Microsoft Forefront Threat Management Gateway
forms-based authentication. When you implement an ISA server or Forefront Threat Management
Gateway, you can publish Outlook Web App servers by using mail-server publishing rules. You also
can configure forms-based authentication and control email attachment availability to protect your
organizations resources when users access them through Outlook Web App. If you configure
authentication on the reverse proxy, you can ensure that network traffic enters your internal network
only after user authentication.
Multifactor authentication. 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
RSAs SecurID.
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 use 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 Server
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.
Require Transport Layer Security SSL (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 TLS or SSL
to encrypt all authentication and message access traffic.
Implement an application layer firewall or reverse proxy. To provide additional security, place an
application layer firewall or reverse proxy between the Internet and the Client Access server. This
firewall can decrypt all network traffic between the client and the Client Access server, and inspects
the traffic for malicious code.
Use Internet Protocol Security (IPSec) for additional Outlook Web App and Outlook Anywhere
security. You can use IPSec if you use ForeFront Threat Management Gateway or ForeFront Unified
Access Gateway. Using IPSec to secure communication between a client machine and an Exchange
server results in both computers agreeing to communicate with each other with a secure connection.
11-44
Securing SMTP Connections from the Internet
If you enable POP3 and IMAP4 connections from the Internet to your Client Access servers, you must
provide a means by which those clients can send email using SMTP. As part of ensuring security for your
client-access deployment, you also need to ensure secure SMTP connectivity.
Providing SMTP Connectivity for POP3 and IMAP4 Clients
You can use POP3 and IMAP4 only to retrievenot sendmessages from user mailboxes. To enable
clients to send email, you must configure the clients to use an SMTP server that relays the messages to
both internal and external recipients.
To enable the POP3 and IMAP4 clients to send email, you must configure a Hub Transport server SMTP
Receive connector to accept SMTP connections from the Internet. Configure the SMTP Receive connector
to require authentication, so that only users with valid accounts in the Exchange Server 2010 organization
can relay messages through the server.
Note If you accept anonymous SMTP connections from the Internet on the Hub Transport
server using the Default SMTP Receive connector, you need to create an additional SMTP
Receive connector for the POP3 and IMAP4 clients, and configure the new connector to
required authenticated connections.
Note You cannot use an Edge Transport server to accept authenticated SMTP connections,
and then use it to relay SMTP messages from POP3 and IMAP4 clients. You can configure a
SMTP Receive connector on an Edge Transport server that uses port 587, and you can
configure the Receive connector to accept authenticated connections. However, you cannot
configure the connector to authenticate the client connections using the users internal
Active Directory account.
Securing SMTP Connections

To secure the SMTP connections to the Hub Transport server, complete the following steps:
11-45
1.
Enable TLS for SMTP client connections. You can configure the SMTP Receive connector on the Hub
Transport server to require TLS security, or to enable basic authentication only after you initiate a TLS
session. If you have a trusted certificate assigned to the SMTP service, you should enable these
options, and then configure all clients to use TLS.
2.
Use the Client Receive connector (port 587), and configure the Hub Transport servers with two
Receive connectors. The Default Receive connector is configured to use port 25, while the Client
Receive connector is configured to use port 587. By default, both connectors are configured to
require TLS security and to allow users to connect to the connector. However, by using the Client
Receive connector, you can avoid using the default SMTP port for client connections. As described in
RFC 2476, port 587 was proposed only for message submission use from e-mail clients that require
message relay.
3.
Ensure that anonymous relay is disabled. Both Receive connectors block anonymous relays, and you
should not modify this option on any Receive connector that is accessible from the Internet. If you
enable anonymous relay, anyone can use your server to relay spam.
Note In some cases, you may need to enable anonymous relay to allow internal
applications to send SMTP email through the Exchange 2010 server. If you require this
functionality, then configure restrictions on the Receive connector so that only the IP
addresses that you specify can relay through the server.
4.
Enable IMAP4 and POP3 selectively. If only some users in your organization require POP3 and IMAP4
access, then disable this option on all other mailboxes.
11-46
Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, do the
following:
1.
2.

3.
10165A-NYC-EX11-B: Exchange 2010 server in the contoso.com domain.
If required, connect to the virtual machines. Log on to NYC-DC1 and NYC-EX10, as

Contoso\Administrator using the password Pa$$w0rd. Do not log on to NYC-EX11 until directed to
do so.
Lab Scenario
11-47
Contoso, Ltd has deployed Exchange Server 2010. The company security officer has provided you with a
set of requirements to ensure that the Exchange Server 2010 deployment is as secure as possible. The
security requirements state that Exchange Server 2010 administrators should have minimal permissions,
which means that whenever possible, you should delegate Exchange Server management permissions.
Specifically, you need to ensure that:
Members of the IT group can administer individual Exchange servers, but they should not be able to
modify any of the Exchange Server 2010 organization settings.
Members of the SupportDesk group should be able to manage mailboxes and distribution groups for
users in the organization.
Only members of the HRAdmins group should be able to create Active Directory users and security
groups using the Exchange Server management tools. The HRAdmins group should also be able to
manage all mailboxes and mail-enabled groups.
Any modifications to the Exchange Server 2010 deployment are audited.
Any messages sent from shared mailboxes are audited.
11-48
Exercise 1: Configuring Delegated Permissions

Scenario
Based on your organizations requirements, you need to configure permissions for the IT group and the
SupportDesk group.
1.
Configure permissions for the IT group.
2.
Configure permissions for the SupportDesk group.
3.
Verify delegated permissions.
Task 1: Configure permissions for the IT group

1.
On NYC-EX10, in Active Directory Users and Computers, add the IT group to the Server
Management group.
2.
Open the Exchange Management Shell, and then enable Remote PowerShell for the IT Group by
running Get-user OrganizationalUnit "IT" | set-user RemotePowerShellEnabled $True.
Task 2: Configure permissions for the SupportDesk group

1.
On NYC-EX10, run the following command in the Exchange Management Shell to create the
SupportDesk role group:
New-RoleGroup Name SupportDesk roles Mail Recipients, Mail Recipient Creation,

Distribution Groups.
2.
On NYC-EX10, open the Exchange Management Console. Access the Role Based Access Control
(RBAC) User Editor from the Exchange Management Console Toolbox node. Log on as
Contoso\Administrator using the password Pa$$w0rd.
3.
Add Andrea Dunker to the SupportDesk group.
Task 3: Verify delegated permissions

1.
On NYC-EX11, log on as Contoso\Terri using the password Pa$$w0rd. Terri is a member of the
IT group. Open the Exchange Management Console, and then verify that the account has the
following permissions:
Can modify the Issue warning at (KB) setting for the Accounting mailbox database.
Cannot modify Hub Transport settings at the organization level. For example, try modifying the
accepted domain settings.
Cannot modify recipient settings. For example, try modifying any properties on one of the
mailboxes.
2.
Log off NYC-EX11.
3.
On NYC-EX10, open Windows Internet Explorer, and connect to https://nycex10.contoso.com/ecp. Log on as Contoso\Andrea using the password Pa$$w0rd, and then verify
that the account has the following permissions:
Can modify mailbox settings for users by using the Exchange Control Panel. For example, try
modifying the department attribute for Alan Brewer.
11-49
Can modify distribution groups using the Exchange Control Panel. For example, add a group
description for the Marketing group.
Cannot create new mailboxes.
Results: After this exercise, you should have configured delegated permissions.
11-50
Exercise 2: Configuring Audit logging

Scenario
You now need to configure audit logging on the support@contoso.com shared mailbox.
1.
Verify permissions on the support@contoso.com account.
2.
Enable audit logging on the support@contoso.com mailbox.
3.
Perform SendAs activity on the support@contoso.com mailbox.
4.
Verify that the activity is logged.
5.
Verify the administrator audit logging configuration.
6.
Make a change to Terri Chudziks mailbox.
7.
Verify that the change was logged.
Task 1: Verify permissions on the support@contoso.com account

1.
On NYC-EX10, log on as Contoso\Administrator using the password Pa$$w0rd.
2.
In the Exchange Management Console, in Recipient Management, open the Manage Full Access
Permission dialog box for the Customer Support mailbox, and verify that Andrea and Arno have
Full Access Rights.
3.
Verify SendAs permissions on the Customer Support mailbox.
Task 2: Enable audit logging on the support@contoso.com mailbox
Open the Exchange Management Shell, and then run the following cmdlet to enable mailbox audit
logging for the support mailbox:
Set-Mailbox -Identity "Customer Support" -AuditDelegate SendAs,SendOnBehalf
-AuditEnabled $true
Task 3: Perform SendAs activity on the support@contoso.com mailbox

1.
On NYC-DC1, open Outlook Web App by typing https://nyc-ex10.contoso.com/owa in Internet

Explorer.
2.
Log on as Contoso\Andrea using the password Pa$$w0rd.
3.
Create a new message, and then send it from the support@contoso.com account to Administrator.
Task 4: Verify that the activity is logged

1.
On NYC-EX10, open Internet Explorer, type https://nyc-ex10.contoso.com/ecp, and then log on to

the Exchange Control Panel as Contoso\Administrator using the password Pa$$w0rd.
2.
Open Roles&Auditing, click Auditing, and then run a non-owner mailbox access report for the
support@contoso.com mailbox. Include a date range from 01/01/2011 to tomorrows date, and then
select the All non-owners option when running the report.
3.
Verify that the SendAs activity from Task 3 is logged.
Task 5: Verify the administrator audit logging configuration

1.
2.
Verify that administrator audit logging is enabled by typing Get- AdminAuditLogConfig.
Task 6: Make a change to Terri Chudziks mailbox
11-51
1.
On NYC-EX10, open the Exchange Management Console, expand Recipient Management, and then
click Mailbox.
2.
Open the Properties dialog box for Terri Chudzik, and change retention period for deleted items
to 20 days. Save changes.
Task 7: Verify that the change was logged

1.
On NYC-EX10, in the Exchange Management Shell, run the following cmdlet:
Search-AdminAuditLog -Cmdlets Set-Mailbox -StartDate 01/01/2011

-EndDate (Tomorrows date) ObjectID contoso.com/IT/Terri
2.
Verify that you see a result for the event logged from Task 6.
Results: After this exercise, you should have configured audit logging.
11-52
Exercise 3: Configuring RBAC Split Permissions

Scenario
Based on your organizations requirements, you must configure permissions for the HRAdmins group. This
group should be able to create Active Directory users and security groups using the Exchange Server
management tools. The HRAdmins group should also be able to manage all mailboxes and mail-enabled
groups.
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.
Verify the permissions.
Task 1: Create a new role group called HRAdmins, and assign permissions
1.
On NYC-EX10, log on as Contoso\Administrator using the password Pa$$w0rd, open the Exchange
Management Shell, and then create a new role group for HRAdmins by running the following cmdlet:
New-RoleGroup "HRAdmins" -Roles "Mail Recipient Creation", "Security Group Creation and
Membership"
2.
Create delegating role assignments between the new HRAdmins role group and the Mail Recipient
Creation role, the Security Group Creation and Membership role, and the Mail Recipients role by
running the following cmdlets:
New-ManagementRoleAssignment -Role "Mail Recipient Creation"

-SecurityGroup "HRAdmins" Delegating
New-ManagementRoleAssignment -Role "Security Group Creation and Membership" SecurityGroup "HRAdmins" Delegating
New-ManagementRoleAssignment -Role "Mail Recipients" -SecurityGroup "HRAdmins"

Delegating
3.
After role assignment completes, add Marko to the new group by running:
Add-RoleGroupMember "HRAdmins" -Member Marko
4.
Protect the membership of the new role group by replacing the delegate list on the new role group
so that only members of the role group can add or remove members. You can do it in Active
Directory Users and Computers console by setting Managed By property on HRAdmins security
group.
Task 2: Remove the permission to create AD DS objects from other Exchange Server
administrator groups
1.
On NYC-EX10, in the Exchange Management Shell, find all of the regular and delegating role
assignments to the Mail Recipient Creation role by running the following cmdlet:
11-53
Get-ManagementRoleAssignment -Role "Mail Recipient Creation" | Format-Table Name, Role,

RoleAssigneeName Auto
2.
After you see which groups have delegating role assignments for this role, remove all groups except
the HRAdmins group by running the following cmdlet:
Get-ManagementRoleAssignment -Role "Mail Recipient Creation" | Where

{ $_.RoleAssigneeName -NE "HRAdmins" } |
Remove-ManagementRoleAssignment
3.
Repeat steps 1 and 2, for both the Security Group Creation and Membership and the Mail
Recipients roles.
Task 3: Verify the permissions

1.
Open the Exchange Management Console, and try to create a new user and a new mailbox by using
the Exchange Server management tools. Verify that you cannot perform these tasks. Log off of NYCEX10.
2.
Log on to NYC-DC1 as Administrator using the password Pa$$w0rd. Open Active Directory Users
and Computers, and verify that you can create a new user object.
3.
Log on to NYC-EX11 as user Contoso\Marko using the password Pa$$w0rd. Open Exchange
Management Console, and try to create a new user and a new mailbox. Verify that you can perform
these tasks.
4.
Double-click any mailbox in a list, and verify that you can change its properties.
Results: After this exercise, you should have configured RBAC split permissions.
following steps:
1.
2.
3.
4.
machine.
5.
machine.
11-54
Review Questions
1.
You need to enable members of the Human Resources department to configure user mailboxes for
the entire organization. What should you do?
2.
In which scenario you should implement RBAC split permissions in your Exchange Server 2010
organization?
3.
How can you identify if someone was accessing another users mailbox?
4.
Users in your organization are using POP3 clients from the Internet. These users report that they can
receive, but not send, email. What should you do?
5.
Your organization has deployed Forefront Threat Management Gateway. You need to ensure that
remote users can access the Client Access server inside the organization by using cellular mobile
clients. What should you do?
Common Issues Related to Configuring Exchange Server Publishing Rules on a

Reverse Proxy
Identify the causes for the following common issues related to configuring Exchange Server publishing
rules on a reverse proxy, and fill in the troubleshooting tips. For answers, refer to relevant lessons in the
module.
Issue
Clients cannot connect to the
published sites, and they receive
internal server errors.
published sites, and they receive
certificate errors.
Troubleshooting tip
Issue
11-55
Troubleshooting tip

published sites, and they receive site
not found errors.

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

When you configure permissions in the Exchange Server 2010 organization, ensure that users have
the minimal permissions required for them to perform their tasks. Add only highly trusted users to the
Organization Management role group as it has full control of the entire organization.
Do not enable RBAC or Active Directory split permissions if you do not have a usage scenario to
support these permissions models.
Enable administrative audit logging on shared mailboxes.
Whenever possible, use the built-in role groups to assign permission in the Exchange Server 2010
organization. Creating custom role groups with customized permissions is more complicated, and
may lead to users having too manyor too fewpermissions.
Ensure that you document all permissions that you assign in the Exchange Server 2010 organization.
If users are unable to perform the required tasks, or if they are performing tasks to which they should
not have access, you should be able to identify the reason by referring to your documentation.
11-56
12-1
Module 12
Monitoring and Troubleshooting Microsoft Exchange
Server 2010
Contents:
Lesson 1: Monitoring Exchange Server 2010
12-3
Lesson 2: Troubleshooting Exchange Server 2010
12-20
12-26
Monitoring and Troubleshooting Microsoft Exchange Server 2010
Module Overview
12-2
After you deploy Microsoft Exchange Server 2010, you must ensure that it continues to run optimally by
maintaining a healthy and stable environment. As in previous versions of Exchange Server, to maintain a
healthy and stable environment, you must monitor Exchange Server 2010 performance and make
adjustments as required. This module describes how to monitor and troubleshoot your Exchange Server
2010 environment.
Objectives
Monitor Exchange Server 2010.
Troubleshoot Exchange Server 2010.
12-3
Lesson 1
Monitoring Exchange Server 2010
As in previous Exchange Server versions, having a well-tuned and consistently used monitoring solution
can greatly improve your ability to identify, troubleshoot, and repair issues before end users notice them.
Reducing end-user problems and preventing problems that are more serious are worth the additional
thought and effort that are required to design a comprehensive monitoring solution for your Exchange
Server 2010 organization.
In this lesson, you will review the basic monitoring tools, and the metrics that you should monitor.
Objectives
Describe the solutions available for monitoring Exchange Server 2010.
Identify the key performance considerations for Exchange Server 2010.
Identify the performance counters that you should monitor on the Mailbox server role.
Identify the performance counters that you should monitor on Hub Transport and Edge Transport
server roles.
Identify the performance counters that you should monitor on the Client Access server role.
Apply guidelines for developing a monitoring plan.
Solutions for Monitoring Exchange Server 2010
Enterprise Monitoring Solutions
12-4
Most enterprise environments already use monitoring and service management solutions across their IT
infrastructures. Some examples include Microsoft System Center Operations Manager 2007 R2 and System
Center Essentials 2010 (with the Exchange Server 2010 management pack), which provide a
comprehensive monitoring solution for IT infrastructures, including monitoring for Exchange Server 2010.
Microsoft System Center Operations Manager 2007 R2 or System Center Essentials 2010 perform multiple
monitoring tasks, such as:
Monitoring of Exchange Server 2010 events
Collecting Exchange component-specific performance counters in one central location
Raising alerts for operator intervention as necessary
Automatically correlating critical events
Proactively managing Exchange servers and identifying issues before they become critical.
Microsoft System Center Operations Manager 2007 R2 and System Center Essentials 2010 also allow you
to customize the data you want to collect. This can help you track down specific problems, or help when
default monitoring sets do not collect the appropriate data. Since each Exchange Server 2010 deployment
is unique, you will need to make adjustments to fit your particular usage and hardware scenarios.
After upgrading to Exchange Server 2010, organizations should import Exchange Server 2010
Management Pack for System Center Operations Manager 2007 R2 or System Center Essentials 2010, and
should uninstall the previous Exchange Server management pack.
Monitoring Solutions by Using Reliability and Performance Monitor
In situations where no enterprise monitoring solution exists, you can use the Reliability and Performance
Monitor in the Windows Server 2008 operating system to collect performance data and monitor
12-5
Exchange Server health. The Reliability and Performance Monitor analyzes how Exchange Server 2010
affects your computer's performance, both in real time and by collecting log data for future analysis.
Windows Reliability and 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.
Key Performance Considerations for Exchange Server 2010
12-6
When monitoring Exchange Server 2010 servers, you should know which performance aspects are most
important. You can use the common counters and threshold values detailed in this lesson to identify
potential issues proactively, and help identify the root cause of issues when troubleshooting.
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 creating the baseline, set thresholds
so that when performance metrics are not met, you know that the server is not operating optimally.
In addition, when running Exchange Server 2010 in a virtualized environment, you should consider adding
Virtualization counters in your monitoring strategy. Some examples of virtualization counters include:
Hyper-V Virtual Machine HealthCounters
Hyper-V Processor Counters
Hyper-V Memory Counters
Processor
The processor is a fundamental component that you need to monitor to ensure server health on all
Exchange Server 2010 roles.
The following table describes the description and expected value for the counters you can use to monitor
the server.
Counter
Description
Expected value
_Total\% Processor
Time
Displays the percentage of time that the

processor is executing application or operating
system processes.
Should be less than 75

percent on average.
_Total\% User Time
Displays the percentage of processor time that is

spent in user mode. This represents the time
Should remain below 75
Counter
_Total\% Privileged
Time
12-7
Description
Expected value
spent processing applications, environment

subsystems, and integral subsystems
percent.
Displays the percentage of processor time that is

spent in privileged mode. This represents the
time processing operating system components
and hardware-manipulating drivers.
Should remain below 75

percent.
An additional counter related to processor performance is the Processor Queue Length. 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 Processor Queue Length counter for capacity planning, you can use it
to identify 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
Counter
Description
Expected value
System
Processor
Queue Length
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.
Should not be greater than 5 per

processor core.
Memory
Another key performance indicator is the memory counter. Tracking how much memory is available, and
how much memory has to be written to the page file, can tell you 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
Expected value
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.
Should remain above 100 MB at

all times.
Pool Paged
Bytes
Displays the portion of shared system memory

that you can page to the disk paging file. Paged
pool is created during system initialization, and
is used by kernel-mode components to allocate
system memory.
No set value as value will vary by

deployment. Monitor for increases
in pool paged bytes, which may
indicate a possible memory leak.
Transition Pages
Repurposed/sec
Indicates system cache pressure.
Should be less than 100 on

average, and spikes should be less
than 1,000.
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
Should be below 100 on average.
Counter
Description
Expected value
value of more than 30 per second means the

server is no longer keeping up with the load.
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 conversion.
Pages/sec includes pages retrieved to satisfy
faults in the file system cache (usually requested
by applications) and noncached mapped
memory files.
Should be below 1,000 on

average.
Pages Input/sec
Displays the rate at which pages are read from

disk to resolve hard-page faults. Hard-page
average.
faults occur when a process refers to a page in
virtual memory that is not in its working set or
is elsewhere in physical memory, and which
must be retrieved from disk. When a page is
faulted, the system tries to read multiple
contiguous pages into memory to maximize the
benefit of the read operation. Compare the
value of Memory\Pages Input/sec 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 average
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 conversion.
MSExchange ADAccess Domain Controller
12-8
Exchange Server 2010 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
Active Directory Domain Services.
The table below displays descriptions and expected values of Lightweight Directory Access Protocol
(LDAP)-related counters.
Counter
Description
Expected value
LDAP Read
Time
Displays the time in milliseconds

(ms) that it takes to send an LDAP
Should be below 50 ms on average, and spikes

should not be higher than 100 ms.
Counter
Description
read request to the specified
domain controller and receive a
response.
12-9
Expected value
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.)
Should be less than 50 at all times. Higher

values may indicate issues with AD DS and
resources of AD LDS on Edge transport servers.
LDAP Searches
timed out per
minute
Displays the number of LDAP

searches that returned LDAP
Timeout during the last minute.
Should be below 10 at all times for all roles.

Higher values may indicate issues with the
resources of AD DS and Active Directory
Lightweight Directory Services (AD LDS) on
Edge transport servers.
Monitoring Services and Logs
It is also important to verify that each of the Exchange Server 2010 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 may also indicate
Exchange Server 2010 server problems. These events typically are classified as Errors or Warnings.
12-10
Collecting Performance Data for the Mailbox Server
When you collect performance data about Mailbox servers, you may focus on disk-response time and the
speed with which the server responds to requests. The average response time for reading data should be
less than 20 ms and the average write response time should be less than 100 ms. 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 to 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 are a good place to begin when
collecting performance data for the Mailbox server.
Logical Disk
Logical Disk counters determine whether disk performance is meeting demands. As disk latency increases,
database reads and writes take more time.
The following table displays descriptions and expected values for Logical Disk counters.
Counter
Description
Expected value
Avg. Disk sec/Read
Displays the average time for

reading data from the disk.
The average value should be below 20 ms at

all times.
Avg. Disk sec/Write
Displays the average time for

writing data to the disk.
The average value should be below 100 ms at

all times.
Avg. Disk
sec/Transfer
Displays the average number

of bytes transferred to or from
the disk during write or read
operations.

12-11
MSExchangeIS Mailbox and MSExchangeIS Public
Messages that are being queued for submission to the Hub Transport server may indicate a problem with
connectivity to the transport server.
The following table displays descriptions and expected values for the Messages Queued for Submission
counter.
Group
Counter
Description
Expected value
MSExchangeIS
Mailbox and
MSExchangeIS
Public
Messages
Queued for
Submission
Shows the current

number of submitted
messages that are
not yet processed by
transport.
Should be below 50 at all times, and not be

sustained for more than 15 minutes.
Otherwise, this counter may indicate
connectivity issues with the transport servers,
or that backpressure is occurring.
MSExchangeIS
The Client Access and transport servers use 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
Expected value
RPC Requests
Displays the overall RPC

requests that are
currently executing
within the information
store process.
Should be below 70 at all times.
RPC Averaged
Latency
Displays the RPC latency

(in ms) averaged for all
operations in the last
1,024 packets.
Should not be higher than 25 ms on average.
RPC Operations/sec
Displays the current

number of RPC
operations occurring per
second.
Should closely correspond to historical baselines.

Values much higher than expected indicate that
the workload has changed, whereas values much
lower than expected indicate a bottleneck that is
preventing client requests from reaching the server.
RPC Num Slow

Packets
Displays the number of

RPC packets in the past
1,024 packets that have
latencies longer than 2
seconds.
Should be less than 1 on average, and should be

less than 3 at all times.
MSExchangeDatabase (Information Store)
As in previous Exchange Server versions, database performance is one of the most critical parameters. The
following table displays the counters you can use to monitor database performance.
Counter
Description
Expected value
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.
Should be below 10 on
average.
12-12
Counter
Description
Expected value
Database
Displays the average length of time, in ms, per
Reads Average database read operation.
Latency
Should be 20 ms on average.
Database
Writes
Average
Latency
Shows the average length of time, in ms, per database

write operation.
Should be 50 ms on average.
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.
Should be more than 90

percent for companies with
most clients configured in
online mode. Should be more
than 99 percent for
companies with most of the
clients configured in cached
mode.
Question: If any of these performance counters is measured outside its normal range, what
will it most likely affect in the production environment?
12-13
Collecting Performance Data for the Hub Transport and Edge Transport
Servers
Transport servers use queue databases, which are temporary holding locations for messages that transport
servers process in a specific order. Therefore, a transport server 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.
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 the descriptions and expected values for performance counters that you
monitor for transport server logical disks.
Counter
Description
Expected value
Avg. Disk sec/Read
Displays the average time (in

seconds) for reading data from
the disk.
The average value should be below 20 ms

at all times.
Avg. Disk
sec/Write
Displays the average time (in

seconds) for writing data to the
disk.
The average value should be below 100 ms

at all times.
Avg. Disk Queue

Length
Displays the number of messages

in the poison message queue.
Should be 0 at all times.
MSExchange Database ==> Instances
Transport servers store message queue information in databases. Therefore, monitoring database
performance will help you identify issues with reading or storing queue information in the databases.
The table below displays descriptions and expected values of transport database counters.
12-14
Counter
Description
Expected value
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.
Should be less than 1,000 at all times.
Version buckets
allocated
Displays the total number of allocated Should be less than 200 at all times.
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.
Should be less than 10 per second on

average, and spikes should not be
greater than 100 per second.
MSExchange Transport Queues

You also should monitor the transport server queues to ensure delivery of email messages.
The following table displays the description and expected values for transport queue length-related
counters.
Counter
Description
Expected value
Aggregate Delivery
Queue Length (All
Queues)

queued for delivery in all queues.
Should be less than 3,000 and not more

than 5,000.
Active Remote
Delivery Queue
Length

in the active remote delivery
queues.
Should be less than 250 at all times.
Active Mailbox
Delivery Queue
Length

in the active mailbox queues.
Retry Mailbox
Delivery Queue
Length

in a retry state that are attempting
to deliver a message to a remote
mailbox.
Unreachable Queue
Length

in the Unreachable queue.
Should not exceed 100.
Largest Delivery
Queue Length

in the largest delivery queues.
Should be less than 200.
Poison Queue
Length

in the poison message queue. The
Counter
Description
12-15
Expected value
poison message queue contains

messages that are determined to
be harmful to the Exchange 2010
system after a server failure.
Question: If any of these performance counters is measured outside its normal range, what
will it most likely affect in the production environment?
12-16
Collecting Performance Data for the Client Access Server
Assessing the Client Access server role entails monitoring a variety of objects and counters. Users client
experience is affected by the response time of services used by Client Access servers.
Logical Disk
Logical Disk counters determine whether disk performance is meeting the demands. As disk latency
increases, database reads and writes take more time. The following table displays the description and
expected values of the performance counters that you can monitor for the Client Access server logical
disk.
Counter
Description
Expected value
Avg. Disk sec/Read
Shows the average time (in

seconds) for reading data from the
disk.
Should be below 20 ms on average.
Avg. Disk
sec/Write
Shows the average time (in

seconds) for writing data to the
disk.
Should be below 100 ms on average.
ASP.NET Services and Applications
Microsoft Outlook Web App and the Exchange Web Services rely heavily on the Microsoft .NET
Framework and Microsoft ASP.NET files, which are read, processed, and rendered for the end users.
Monitoring the response time and the number of times the application has had to restart can help you
verify the overall health of the Client Access server.
The following table displays the description and expected values of application-related counters.
Counter
Description
Expected value
Application Restarts
Displays the number of times the

application has restarted during the web
Counter
12-17
Description
Expected value
servers lifetime.
Worker Process
Restarts
Displays the number of times a worker

process has restarted on the computer.
Request Wait Time
Displays how long (in ms) the most

recent request was waiting in the queue.
Should be less than 1,000 ms at all

times.
Requests in
Application Queue
Displays 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.
Should be less than 5,000 at all times.
MSExchange Web Services
Outlook Web App, the Outlook Anywhere (RPC/HTTP) Proxy, Microsoft Exchange ActiveSync, Offline
Address Book downloads, and the Availability Service response times are valuable metrics to monitor.
The following below displays Client Access server-related counters, along with their descriptions and
expected values.
Group
Counter
Description
Expected value
MSExchange
OWA
Average
Response
Time
Average
Search Time
Displays the
average elapsed
time (in ms) for
the request. Used
to determine the
latency that a
client is
experiencing.
Displays the
average elapsed
time (in ms) while
waiting for a
search to
complete.
Should be less than 100 ms at all

times. Higher values may indicate
high user load or higher-thannormal CPU time.
Should be less than 100 ms at all
times.
RPC/HTTP Proxy
Number of failed
back-end
connection
attempts per
second
Displays the rate at

which the RPC proxy
attempts fail to
establish a connection
to a back-end server.
MSExchange
ActiveSync
Average Request
Time
Displays the average

Varies by devices, carrier, or
time that elapsed
configuration. You must use a baseline
while waiting for a
to set this threshold.
request to complete.
Determines the rate at
which the Availability
Service requests are
occurring.
12-18
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?
12-19
Applying Guidelines for Developing a Monitoring Plan
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-ofmonth accounting close process, or periods with notably high sales figures. Gathering a broad data set
will provide sufficient data to determine the appropriate operating thresholds.
To use the collected performance data:
1.
Create a monitoring baseline by averaging performance metrics from a properly operating system:
Monitor performance for a full business cycle.
Note any peaks or troughs in the data.
2.
Set warning and error level thresholds.
3.
Review growth trends regularly to:
Adjust thresholds.
Adjust server configurations.
It is important that you review your thresholds periodically, so you can adjust the serversor the
thresholds themselvesto ensure that the system is functioning properly.
Note Microsoft System Center Operations Manager 2007 R2 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 baseline learned during the previous monitoring.
12-20
Lesson 2
Troubleshooting Exchange Server 2010
Even in a well-maintained Exchange Server 2010 organization, problems can arise, and you must identify
and repair them. Although general troubleshooting guidelines exist, experience and an analytical attitude
often provide the best tools for successfully detecting the problems source, and fixing it.
Objectives
Identify troubleshooting tools that you can use to troubleshoot Exchange Server 2010 servers.
Troubleshoot Mailbox servers.
Troubleshoot Client Access servers.
Troubleshoot Message Transport servers.
12-21
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
suggest potential problem solutions.
Exchange Best Practices Analyzer (ExBPA). This tool enables you to identify potential issues based on
deviations from best practices, and to gather a great deal of information about your Exchange Server
organization. You can then use this information for reference, and for troubleshooting problems.
Performance Troubleshooter. This tool helps you locate and identify performance-related issues that
could affect Exchange servers. You diagnose problems by selecting the symptoms observed. Based on
the symptoms, the tool directs you to take the correct troubleshooting steps. Performance
Troubleshooter identifies possible bottlenecks, and suggests corrective actions.
Exchange Mail Flow Troubleshooter. This tool provides easy access to various data sources that are
required to troubleshoot problems with mail flow, such as non-delivery reports, queue backups, and
slow deliveries. The tool then automatically diagnoses the data retrieved, presents an analysis of the
possible root causes, and suggests corrective actions.
Other toolssuch as the Reliability and Performance and Monitorcheck the health of the Exchange
Server processes. You can use the Queue Viewer to view the message status in transport queues. Tools
such as Network Monitor and Telnet can help you troubleshoot network issues and message tracking, and
the Routing Log Viewer can help you troubleshoot message delivery issues.
There are many other toolsin addition to the Exchange Management Console, the Exchange
Management Shell, and Active Directory Users and Computersthat you can use to manage and
troubleshoot an Exchange Server 2010 organization.
The following table lists some of these tools.
Tool name
Description
12-22
Tool name
Description
ADSI Edit (adsiedit.msc)
Use for low-level editing of Active Directory objects and

attributes. On Windows Server 2008 or Windows Server 2008 R2,
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.
Exchange Server Database Utilities

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

defragmentation and recovery.
Exchange Store TreeView Control

(Extreeview.ocx)
Use to display a hierarchical list of node objects that correspond

to folders in the Exchange Store.
New-MailboxRepairRequest
These tools are a replacement for Information Store Integrity
Checker (isinteg.exe) in Exchange Server 2003 and Exchange
NewPublicFolderDatabaseRepairRequest Server 2007. Use to find and remove errors in the mailbox and
public folder databases. You can also run the NewMailboxRepairRequest command against mailboxes.
Use the New-PublicFolderDatabaseRepairRequest cmdlet to
detect and fix replication issues in the public folder database.
LDP (ldp.exe)
Use 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 to determine the security state of the organizations servers

in accordance with Microsoft security recommendations. Also use
to offer specific remediation guidance.
Microsoft Error Reporting
Exchange Server 2010 uses Microsoft Error Reporting 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 2010. This service gives administrators and
users the opportunity to send data about errors to Microsoft, and
to receive information about errors. Administrators can use
Microsoft Error Reporting to address customer problems in a
timely manner, and to help improve the quality of Microsoft
products.
MTA Check (Mtacheck.exe)
Use when the message transfer agent (MTA) does not start due to
corruption or suspected corruption in the MTA database. This
tool provides a soft recovery of a corrupted MTA database.
Process Monitor (procmon.exe)
Use to monitor real-time file system, registry, and process/thread

activity.
RPC Ping utility (rpings.exe and

rpingc.exe)
Use to confirm the remote procedure call (RPC) connectivity

between the computer that is running the Exchange Server, and
any of the client workstations on the network.
Telnet (telnet.exe)
Use to troubleshoot Exchange Server mail flow.
Discussion: Troubleshooting Mailbox Servers
12-23
When troubleshooting Mailbox server issues, you should check the health and availability of the databases
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?
12-24
Discussion: Troubleshooting Client Access Servers
You can apply standard troubleshooting techniques to the unique problems that can occur with Client
Access servers. Use tools such as the Exchange Best Practices Analyzer and the Event Viewer to identify the
problem and work toward a resolution.
Question: Outlook users can no longer connect to the system. What process can you use to
troubleshoot the problem?
12-25
Discussion: Troubleshooting Message Transport Servers
Transport server issues are usually due to mail queue database corruption or network connectivity
problems. Use tools such as the Queue Viewer, message tracking system, and Mail Flow Troubleshooter to
identify the problem, and then work toward a resolution.
Question: Users are reporting non-deliverable and slow-to-deliver outbound email. What
process can you use to troubleshoot the problem?
12-26
Lab: Monitoring and Troubleshooting Exchange Server

2010
Lab Setup
1.
2.
Ensure that the 10165A-NYC-DC1-B and the 10165A-NYC-EX10-B virtual machines are running:
3.
10165A-NYC-DC1-B: Domain controller in the Contoso.com domain.
10165A-NYC-EX10-B: Exchange 2010 server in the Contoso.com domain.

Lab Scenario
You are the messaging administrator at Contoso, Ltd. Now that all components of your Exchange Server
2010 environment have been deployed, you need to configure monitoring for the Exchange servers. To
do this, you need to configure basic monitoring by using the Reliability and Performance Monitor. You
also must troubleshoot issues with a mailbox database and a Client Access server.
Exercise 1: Monitoring Exchange Server 2010

Scenario
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.
12-27
2.
Create a new performance-counter data collector set to monitor basic Exchange Server performance.
3.
Create a new performance-counter data collector set to monitor 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 NYC-EX10, open the Performance Console, 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 NYC-EX10. 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 2010 performance on
NYC-EX10. Configure the sample interval to run every 1 minute.
Object
Counter
LogicalDisk
Avg.Disk sec/Read
Avg.Disk sec/Transfer
Avg.Disk sec/Write
12-28
Object
Counter
MSExchangeIS
RPC Averaged Latency

RPC Num Slow Packets
RPC Operations/sec
RPC Requests
MSExchangeIS Mailbox
Messages Queued for Submission
MSExchangeIS Public
Messages Queued for Submission
Task 4: Verify that the data collector set works properly

1.
Start the Exchange Monitoring data collector set, and let it run for five minutes.
2.
Stop the Exchange Monitoring data collector set, and then review the latest report.
Results: After this exercise, you should have created a data collector set for monitoring NYC-EX10 that
uses the recommended performance counters.
12-29
Exercise 2: Troubleshooting Database Availability

Scenario
After recovering from a hardware failure, your monitoring software reports that one of the mailbox
databases is not mounted. You must troubleshoot and repair the database problem.
1.
Identify the scope of the problem.
2.
Review the event logs.
3.
Run the Best Practices Analyzer.
4.
List the probable causes of the problem and rank the possible solutions, if multiple options exist.
5.
Review the database configuration.
6.
Reconfigure and mount the database
Preparation
Before you begin this exercise, complete the following steps:
1.
On NYC-EX10, ensure that all databases are mounted.
2.
On NYC-EX10, open an Exchange Management Shell. At the prompt, type

d:\Labfiles\Lab12Prep2.ps1, and then press Enter. This script will simulate database failure.
3.
When prompted, type N, and then press Enter.
4.
Close the Exchange Management Shell.
Task 1: Identify the scope of the problem

1.
2.
Identify whichif anymailbox databases are not mounted on NYC-EX10.
3.
List the database(s) that are not mounted.
Task 2: Review the event logs

1.
On NYC-EX10, attempt to mount MailboxDB100.
2.
When the warning message appears, click No.
3.
Open the Event Viewer. In the Application Log and System Log, review the events generated, and
note any errors.
Task 3: Run the Best Practices Analyzer

1.
On NYC-EX10, run the Exchange Best Practices Analyzer. Perform a Health Check scan of NYC-EX10
only.
2.
Review the Exchange Best Practices Analyzer report, and note issues identified by the scan that may
have an impact on the scenario.
Task 4: List the probable causes of the problem and rank the possible solutions, if
multiple options exist
List the problems and possible solutions:
12-30
Problem
Possible solution
Task 5: Review the database configuration

1.
On NYC-EX10, open the Exchange Management Console, and then review the database
configuration.
2.
Open a Windows Explorer window, and locate the database files.
Task 6: Reconfigure and mount the database

1.
On NYC-EX10, open the Exchange Management Shell, and reconfigure the database using the MoveDatabasePath cmdlet with the ConfigurationOnly parameter.
2.
Mount the database.
Results: After this exercise, you should have used a troubleshooting technique to identify and fix a
Mailbox server problem.
12-31
Exercise 3: Troubleshooting Client Access Servers

Scenario
Users report that they cannot log on to Outlook Web App. You need to determine the problem, and then
take the necessary steps to resolve it.
1.
Attempt to reproduce the problem.
2.
Review the event logs.
3.
Use the Test cmdlets to verify server health.
4.
List the probable causes of the problem, and rank possible solutionsif multiple options exist.
5.
Configure Outlook Web App settings.
6.
Verify that you have resolved the problem.
Preparation
1.

d:\Labfiles\Lab12Prep3.ps1, and then press Enter.
2.
Task 1: Attempt to reproduce the problem

1.
Attempt to log on to https://NYC-EX10.Contoso.com/owa.
2.
Make note of the error that displays.

1.
On NYC-EX10, open Event Viewer, and then review any errors listed in the Application and System
logs.
2.
Make note of any errors.
Task 3: Use the Test cmdlets to verify server health

1.
On NYC-EX10, open the Exchange Management Shell, and run the Test-ServiceHealth cmdlet.
2.
Run the Test-OwaConnectivity URL https://NYC-EX10.Contoso.com/OWA TrustAnySSLCertificate cmdlet to test Outlook Web App connectivity. Log on as
3.
Review the results of the cmdlets, and then make note of any errors.
Task 4: List the probable causes of the problem, and rank the possible solutionsif

Problem
Possible solution
12-32
Problem
Possible solution
Task 5: Configure the Outlook Web App settings

1.
Open the Exchange Management Console, and then review the Outlook Web App configuration on
NYC-EX10.
Note During this task, click OK to dismiss any messages that indicate that NYC-EX11 is not
accessible.
2.
Take the necessary actions to fix the problem, and then run IISReset.
Task 6: Verify that you have resolved the problem
Attempt to log on to https://NYC-EX10.contoso.com/owa as Contoso\Administrator, with the

password, Pa$$w0rd.
Results: After this exercise, you should have used a troubleshooting technique to identify and fix a Client
Access server problem.

following steps:
1.
2.
3.
4.
Right-click 10165A-ROM-DC1-C, and then in the Actions pane, click Start. Connect to the virtual
machine.
Important Start the 10165A-ROM-DC1-C virtual machine first, and ensure that it is fully
5.
Wait for 10165A-NYC-DC1-B to start, and then start 10165A-ROM-EX07-C. Connect to the virtual
machine.
6.
Wait for 10165A-ROM-EX07-C to start, and then start 10165A-ROM-EX10-C. Connect to the virtual
machine.
12-33
Review Questions
1.
Users are reporting issues with sending email to a remote domain. You need to determine the
problem and then resolve it. What should you do?
2.
Recent organizational growth has resulted in two issues on Mailbox server: several memory thresholds
and average read-latency threshold for the logical disk that stores the page file are exceeding their
recommended limits. What issue should you address first?
3.
After reviewing the trend information retrieved from the monitoring system, you noticed that the
processor usage for one of the four Mailbox servers is higher than average. What should you do?
Common Issues Related to Troubleshooting Exchange Server Problems
Identify the causes for the following common issues related to troubleshooting Exchange Server 2010
problems, and fill in the troubleshooting tips. For answers, refer to relevant lessons in the module, and fill
in the troubleshooting tips.
Issue
Outbound email messages are queuing on the
Hub Transport server.
Multiple sources are simultaneously reporting
different problems.
Users are reporting slowness or other
subjective problems.
Troubleshooting tip
A database has gone offline, and you need 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?
12-34
Best Practices Related to Troubleshooting Exchange Server Problems

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 facts about the issue from feelings or other subjective information. A
single persons subjective observation could cause you to troubleshoot the wrong problem and delay
resolution of the actual issue.
Ask a lot of questions about the problem before starting to troubleshoot. If you have not properly
defined the problem, you cannot properly target your troubleshooting steps.
13-1
Module 13
Upgrading from Microsoft Exchange Server 2007 to
Contents:
Lesson 1: Upgrading from Exchange Server 2007 to Exchange Server 2010
13-3
13-17
Upgrading from Microsoft Exchange Server 2007 to Exchange Server 2010
Module Overview
13-2
Many organizations are currently running Microsoft Exchange Server 2007, and are upgrading to
Exchange Server 2010 to take advantage of its new features. The process for upgrading from Exchange
Server 2007 to Exchange Server 2010 is similar to the process for upgrading from Exchange Server 2003.
However, in some ways, upgrading Exchange Server 2007 to Exchange Server 2010 is easier, because both
versions use the same server roles and message routing configuration. This module will describe how to
complete an upgrade from Exchange Server 2007 to Exchange Server 2010.
Objective
After completing this module, you will be able to complete an upgrade from Exchange Server 2007 to
Exchange Server 2010:
Lesson 1
13-3
Upgrading from Exchange Server 2007 to Exchange Server

2010
The process for upgrading Exchange Server 2007 to Exchange Server 2010 is similar to upgrading from
Exchange Server 2003, but there are some differences. This lesson describes how to complete the upgrade
from Exchange Server 2007 to Exchange Server 2010.
Objectives
Describe the process for installing Exchange Server 2010 in an Exchange Server 2007 organization.
Explain how client access works during coexistence.
Explain how to implement client access during coexistence.
Describe the considerations for message transport coexistence.
Describe the considerations for administration coexistence.
Describe the process for removing Exchange Server 2007 from an organization.
13-4
Installing Exchange Server 2010 in an Exchange Server 2007 Organization
You must complete the following steps to deploy Exchange Server 2010 servers in an Exchange Server
2007 organization:
1.
Update all of the Exchange Server 2007 servers to Service Pack 2 (SP2) or newer. Exchange Server
2010 Setup checks the server versions of all Exchange servers, and the requirement checks fail if a
server is not upgraded. Exchange Server 2007 SP2 includes several schema updates that are required
for interoperability with Exchange Server 2010.
2.
If an organization has only a single Active Directory site, use the following process for deploying
Install the Exchange Server 2010 Client Access server. After you complete this installation, you
should use this as the primary connection point for all client connections. This means that you
should modify the AutoDiscover settingsboth internally and externallyto reference the
Exchange Server 2010 Client Access server.
Note Later sections of this lesson include more information on how to configure the Client
Access server settings, including the Autodiscover settings.
3.
Install the Exchange Server 2010 Hub Transport server. Both Exchange Server 2007 and Exchange
Server 2010 Mailbox servers must use a Hub Transport server that is the same version as the Mailbox
server for routing messages in the same site.
4.
Install Exchange Server 2010 Unified Messaging servers. If you have deployed Unified Messaging in
Exchange Server 2007, add the Exchange Server 2010 Unified Messaging Server to one of your
organizations dial plans.
13-5
5.
Install the Exchange Server 2010 Mailbox servers. After the rest of the infrastructure is in place, you
can deploy the Exchange Server 2010 Mailbox servers, and begin moving mailboxes and public
folders to the new servers.
6.
Install the Exchange Server 2010 Edge Transport servers. Exchange Server 2010 Edge Transport
servers can synchronize only with Exchange Server 2010 Hub Transport servers.
For organizations with multiple sites, there are typically two types of Active Directory sites: Internetaccessible sites and non-Internet accessible sites. A single Exchange Server organization may have one or
more Internet-accessible sites. When upgrading Active Directory sites, you must begin your upgrade by
upgrading Internet-accessible sites first, followed by non-Internet accessible sites.
You should follow the same process for deploying Exchange Server 2010 servers in both Internetaccessible and non-Internet accessible sites. Before deploying any Exchange Server 2010 Mailbox server in
a site, you must deploy Exchange Server 2010 Client Access and Hub Transport servers.
Note If you are deploying multi-role servers in an Active Directory site, you can install the
Client Access, Hub Transport, and Mailbox server roles simultaneously.
How Client Access Works During Coexistence
13-6
The Client Access server role in Exchange Server 2010 has changed significantly from the Client Access
server role in Exchange Server 2007. The most important change is that all client connectionsincluding
Microsoft Office Outlook Messaging Application Programming Interface (MAPI) connectionsnow go
through the Client Access server role. The one exception to this change is that MAPI client connections to
public folders still connect directly to the Mailbox server in Exchange Server 2010.
Client Access During Coexistence
After you deploy the Exchange Server 2010 Client Access and Mailbox servers, the process for when nonMAPI clients access the user mailboxes depends on the type of client you are using, and on the location of
the user mailbox.
To implement coexistence, you must configure all clients to connect to the Exchange Server 2010
Client Access server rather than the Exchange Server 2007 client access server. Begin by changing the
Autodiscover configuration so that all clients will connect to the Exchange Server 2010 Client Access
servers when configuring the client. If you have been using an external URLsuch as
https://mail.contoso.comto connect to an Exchange Server 2007 Client Access server, you should
modify the Domain Name System (DNS) or firewall configuration to forward connections to the
Exchange Server 2010 Client Access servers URL.
When a Microsoft Outlook Web App client connects to the Exchange Server 2010 Client Access
server, and the user mailbox is located on an Exchange Server 2007 Mailbox server, the Autodiscover
service on the Exchange Server 2010 Client Access server redirects the client to the appropriate URL
configured on the Exchange Server 2007 Client Access server. For internal clients, the web browser
will be redirected to the internal URL on the Exchange Server 2007 Client Access server. If the client
connects to the Exchange Server 2010 Client Access server from the Internet, the client is redirected
to the external URL for the Exchange Server 2007 server. The client then communicates with the
Exchange Server 2007 Client Access server to access the user mailbox.
13-7
When an Outlook Web App client connects to the Exchange Server 2010 Client Access server and the
user mailbox is located on an Exchange Server 2010 Mailbox server, the Client Access server
communicates with the Mailbox server to provide access to the user mailbox.
When a Microsoft Exchange ActiveSync client connects to the Exchange Server 2010 Client Access
server, and the user mailbox is located on an Exchange Server 2007 Mailbox server, the process will
depend on whether the mobile device supports Autodiscover:
If the device does not support Autodiscover, the Exchange Server 2010 Client Access server
proxies the client request to the Exchange Server 2007 Client Access server using Hypertext
Transfer Protocol/Secure (HTTPS). The Exchange Server 2007 Client Access server then connects
to the Exchange Server 2007 Mailbox server and provides access to the user mailbox.
If the Mobile client does support Autodiscover, the Autodiscover service on the Exchange Server
2010 Client Access server redirects the client to use the external URL that is configured on the
Exchange Server 2007 Client Access server.
When an Exchange ActiveSync client connects to the Exchange Server 2010 Client Access server, and
the user mailbox is located on an Exchange Server 2010 Mailbox server, the Client Access server
connects to the Mailbox server using remote procedure call (RPC) and provides access to the user
mailbox.
When an Outlook Anywhere client connects to the Exchange Server 2010 Client Access server, and
the user mailbox is located on an Exchange Server 2007 Mailbox server, the RPC proxy service on the
Client Access server connects to the Mailbox server using RPC.
When an Outlook Anywhere client connects to the Exchange Server 2010 Client Access server, and
the user mailbox is located on an Exchange Server 2010 Mailbox server, the RPC proxy service on the
Client Access server connects to the Mailbox server using RPC.
If the user mailbox is on an Exchange Server 2007 Mailbox server in a different Active Directory site,
the Exchange Server 2010 Client Access server always proxies the client requests. For Outlook Web
App and Exchange ActiveSync clients, the Client Access server proxies the requests using HTTP to an
Exchange Server 2007 Client Access server. For Outlook Anywhere clients, the Client Access server
proxies the request using RPC to an Exchange Server 2007 Mailbox server.
When a MAPI client connects to the user mailbox, and the user mailbox is on an Exchange Server
2007 server, the MAPI client connects directly to the Mailbox server. If the user mailbox is on an
Exchange Server 2010 server, the MAPI client connects to an Exchange Server 2010 Client Access
server.
Note When you move a user mailbox from an Exchange Server 2007 Mailbox server to an
Exchange Server 2010 Mailbox server, the client profile configures automatically to use the
Exchange Server 2010 Client Access server for MAPI connectivity. You do not need to modify
the client profile manually.
Considerations for Client Access During Coexistence

When implementing client access during coexistence, consider the following:
Whether a user sees the Outlook Web App client of Exchange Server 2007 or Exchange Server 2010
depends on the location of the users mailbox. For example, if the users mailbox is located on an
Exchange Server 2007 Mailbox server and the Client Access server is running Exchange Server 2010,
the user sees the Exchange Server 2007 version of Outlook Web Access.
13-8
You cannot use an Exchange Server 2007 Client Access server to access mailboxes on Exchange Server
2010 Mailbox server.
13-9
Implementing Client Access Coexistence
During coexistence, you need to ensure that users with mailboxes on both Exchange Server 2007 Mailbox
servers and Exchange Server 2010 Mailbox servers can access their mailboxes. The following steps describe
how to enable this:
1.
Obtain the required server certificates. To support external client coexistence with the Exchange
Server 2010 Client Access server and legacy Exchange servers, you may need to acquire a new
certificate. You should request a certificate that supports at least the following subject alternative
names:
The primary URL to use to access the Exchange Server 2010 Client Access server. For example,
you might use a name such as mail.contoso.com.
The Autodiscover server name. Normally, you would us a name such as

autodiscover.contoso.com.
An alternate name for the URL to use to connect to the Exchange Server 2007 Client Access
server. For example, you might use a name such as legacy.contoso.com.
Note The Exchange Server 2010 Client Access server requires the server certificate, but you
also might install the same certificate on the Exchange Server 2007 Client Access server. The
Exchange Server 2007 Client Access server requires a certificate with subject alternative
names that include the alternate namefor example, legacy.contoso.comand the
Autodiscover server name. If you are using the actual server name rather than an alias in the
Secure Sockets Layer (SSL) certificate, you may not need to acquire additional certificates for
the Exchange Server 2007 Client Access server.
2.
Install and configure the Exchange Server 2010 Client Access server. You should configure the
external namespace during or after setup by using the Exchange Management Console or Exchange
Management Shell. By configuring the external namespace, all required external URLs will be
configured appropriately.
13-10
3.
Modify the external URLs on the Exchange Server 2007 Client Access server to use the alternate name.
If you are using legacy.contoso.com as the alternate name, configure this as the external URL for the
Outlook Web App, Offline Address Book, Unified Messaging, Web Services, and Exchange ActiveSync
virtual directories. You may also need to modify the internal URL if you are using an alias such as
mail.contoso.com for the internal URL. You do not need to modify the internal URL if you are using
the server name in the internal URL.
4.
Configure DNS. To configure DNS, you should:
Create the legacy host recordfor example, legacy.contoso.comin your external DNS
infrastructure, and configure it to reference the Exchange Server 2007 Client Access server.
Create or modify the host record for Autodiscoverfor example, Autodiscover.contoso.com

and configure it to reference the Exchange Server 2010 Client Access server.
Create or modify the host record for the primary URLfor example, mail.contoso.comand
configure it to reference the Exchange Server 2010 Client Access server.
5.
If required, enable Outlook Anywhere on the Exchange Server 2010 servers. If you use Outlook
Anywhere on the Exchange Server 2007 servers, disable Outlook Anywhere on the Exchange Server
2007 Client Access server. When you implement Outlook Anywhere on the Exchange Server 2010
Client Access server, it proxies the Outlook Anywhere client requests directly to the Exchange Server
2007 Mailbox server.
6.
Test all client scenarios, and ensure they function correctly.
Considerations for Message Transport Coexistence
13-11
A second coexistence component between Exchange Server 2007 and Exchange Server 2010 is message
transport. Message transport coexistence configures automatically, as long as the correct versions of Hub
Transport servers are available.
Message Routing During Coexistence
As you deploy Exchange Server 2010 Hub Transport and Mailbox servers in an Exchange Server 2007
organization, message transport works as follows:
Each version of Exchange Mailbox server must use an equivalent version of the Hub Transport server
when routing messages within the same site. This means that you must deploy the Exchange Server
2010 Hub Transport server before deploying the Exchange Server 2010 Mailbox servers, and that you
must not remove the last Exchange Server 2007 Hub Transport server until you have removed all of
the mailboxes from the Exchange Server 2007 Mailbox servers.
If you have both Exchange Server 2007 and Exchange Server 2010 servers deployed in a site,
messages will flow from the Exchange Server 2010 Mailbox server to the Exchange Server 2010 Hub
Transport server, to the Exchange Server 2007 Hub Transport server, and then to the Exchange Server
2007 Mailbox server. Messages sent from an Exchange Server 2007 mailbox would follow the reverse
route.
Message routing between Active Directory sites can use Hub Transport servers on either Exchange
Server version. If you installed an Exchange Server 2010 Hub Transport server in one site, it can send
messages to Exchange Server 2007 Hub Transport servers in another site.
Message routing to and from the Internet can use either Exchange Server 2007 or Exchange Server
2010 Hub Transport servers. If your current deployment uses Exchange Server 2007 Edge Transport
servers for inbound email, you can continue to have the Edge Transport servers forward all messages
to the Exchange Server 2007 Hub Transport server. As you deploy Exchange Server 2010 Hub
Transport servers, you can either add them to the Edge Subscription, or configure the Exchange
13-12
Server 2007 Edge Transport servers to forward messages to the Exchange Server 2010 Hub Transport
servers.
For outbound messages, you can add Exchange Server 2010 Hub Transport servers to the SMTP Send
connector that is responsible for sending messages to the Internet. This enables outbound messages
to be sent through either Exchange Server 2007 or Exchange Server 2010 Hub Transport servers.
Note In Exchange Server 2010, you can view message-tracking information using the
Exchange Management Console or the Exchange Control Panel. If an administrator or user
views the message-tracking information in Exchange Control Panel, the message can be
tracked only on Exchange Server 2010 Hub Transport servers. Administrators can track
messages on both Exchange Server 2010 and Exchange Server 2007 Hub Transport servers
by using the Message Tracking tool in Exchange Server 2007, and the Tracking Log Explorer
tool in Exchange Server 2010.
Edge Transport Server Coexistence
If you use the Exchange Server 2007 Edge Transport server role, you can retain or replace the server with
an Exchange Server 2010 Edge Transport server.
You can implement Edge synchronization between Exchange Server 2010 Hub Transport servers and
Exchange Server 2007 Edge Transport servers, but you cannot configure Edge synchronization between
Exchange Server 2007 Hub Transport servers and Exchange Server 2010 Edge Transport servers. This
means that if you are using Edge synchronization, you should not deploy an Exchange Server 2010 Edge
Transport server before deploying at least one Exchange Server 2010 Hub Transport server in the adjacent
Active Directory site.
Transport Rules and Journaling Coexistence
If you have deployed transport rules or journaling in Exchange Server 2007, you must plan for the
migration of these features to Exchange Server 2010. Exchange Server 2010 supports new predicates and
actions. In addition, Exchange Server 2010 uses a different format for storing transport rules in Active
Directory Domain Services (AD DS). To prevent the Exchange Server 2007 servers from using the rules
created in Exchange Server 2010, Exchange Server 2010 rules are stored in a separate Active Directory
container.
When you install an Exchange Server 2010 server in an Exchange Server 2007 organization, the transport
and journaling rules configured in Exchange Server 2007 automatically export to a temporary location,
and then import to the Exchange Server 2010 transport rule container in Active Directory. However, the
transport and journaling rules do not synchronize between the Exchange Server versions after the initial
export and import. If you make changes to the transport or journaling rules in either Exchange Server
version after installing Exchange Server 2010, the changes do not replicate in the other Exchange Server
version. This can lead to inconsistencies in how the rules are applied as messages are sent through the
Hub Transport servers. To ensure that your transport and journal rules remain consistent between the
Exchange Server versions, you must make all changes in both Exchange Server versions.
13-13
Considerations for Administration Coexistence
When implementing Exchange Server 2010 in an Exchange Server 2007 organization, you also need to
plan for administrative coexistence. In this scenario, you need to consider how you will use the Exchange
Server management tools, and how you will delegate permissions.
Management Console Coexistence
The Exchange Management Console is available in both Exchange Server 2007 and Exchange Server 2010.
You can perform the following tasks and actions using the different Exchange Management Consoles:
You can perform actions that create new objectssuch as new mailboxes or a new offline address
bookon a version of the Exchange Management Console that is the same as the target object. For
example, you must create a new mailbox on an Exchange Server 2007 Mailbox server by using the
Exchange Management Console in Exchange Server 2007.
You cannot manage Exchange Server 2007 Mailbox databases from the Exchange Server 2010
Management Console, although you can view these databases.
You cannot enable or disable Exchange Server 2007 Unified Messaging mailboxes from the Exchange
Server 2010 Management Console.
You cannot use the Exchange Server 2010 Management Console to manage mobile devices for users
that have mailboxes on an Exchange Server 2007 Mailbox server.
You can perform actions that require management on Exchange Server 2007 objects from the
Exchange Management Console in Exchange Server 2010. You cannot perform these actions from the
Management Console in Exchange Server 2007 on Exchange Server 2010 objects.
You can use any Exchange Management Console version to perform actions that require viewing of
any version of Exchange Server objects, with the following exceptions:
You can view only Exchange Server 2007 and Exchange Server 2010 transport rule objects from
the corresponding version of the Exchange Management Console.
13-14
You can view only Exchange Server 2007 and Exchange Server 2010 servers from their
corresponding version of the Exchange Management Console.
The Queue Viewer tool in Exchange Server 2010 Exchange Management Console cannot connect
to an Exchange Server 2007 server to view queues or messages.
Delegating Administration During Coexistence
The model for delegating administrative permissions has changed significantly in Exchange Server 2010.
Exchange Server 2007 Setup creates several Active Directory groups with designated permissions in both
AD DS and in the Exchange Server organization. To delegate permissions, you add users to the
appropriate Active Directory groups.
Role Based Access Control (RBAC) in Exchange Server 2010 replaces this model. Now you will use role
groups to configure permissions.
When you install Exchange Server 2010 servers in an Exchange Server 2007 organization, this adds the
Exchange Server 2010 role groups to AD DS, and the Exchange Server 2007 groups are retained. When
assigning permissions on Exchange Server 2007 servers, use the Exchange Server 2007 groups. When
assigning permissions on the Exchange Server 2010 servers, use the Exchange Server 2010 role groups.
You also can delegate permissions in an Exchange Server 2007 organization. The following table describes
some options for creating an Exchange Server 2010 administrative design that emulates an Exchange
Server 2003 design.
Exchange Server 2007 administrative
option
Exchange Server 2010 equivalent
Assign users to the Exchange Organization

Administrators group.
Add users or groups to the Organization Management

role group.
Assign users to the Exchange View-Only

Add users or groups to the View-Only Organization

Management role group.
Assign users to the Exchange Recipient

Add users or groups to the Recipient Management role

group.
Assign users to the Exchange Public Folder

Add users or groups to the Public Folder Management

role group.
Assign users as server administrators for a

specific Exchange Server 2007 server.
Create a custom role group that includes only server

management roles, and with a scope limited to a single
server.
Removing Exchange Server 2007 from the Organization
13-15
After deploying the Exchange Server 2010 servers, you can begin moving resources to the Exchange
Server 2010 servers, and then removing the Exchange Server 2007 servers.
Moving Resources to Exchange Server 2010 Servers
Before removing the Exchange Server 2007 servers, you should move all required functionality and data
to the Exchange Server 2010 servers, including the following:
Transport connectors. You can add Exchange Server 2010 Hub Transport servers as source servers on
send connectors that were created in Exchange Server 2007. To upgrade message-transport
functionality, add the Exchange Server 2010 Hub Transport servers to the send connectors, and then
remove the Exchange Server 2007 servers. If you have modified the receive connectors or created
additional receive connectors on the Exchange Server 2007 servers, you will need to create similar
connectors on the Exchange Server 2010 Hub Transport servers.
Mailboxes. You can move mailboxes from Exchange Server 2007 SP2 to Exchange Server 2010. This
move occurs online, and end users can access their mailboxes during the move. You must perform the
move from the Exchange Server 2010 server using the move request cmdlets in the Exchange
Management Shell, or by using the New Local Move Request option in the Exchange Management
Console. You cannot use the Move-Mailbox functionality on the Exchange Server 2007 server to move
mailboxes to Exchange Server 2010 servers.
Public folders. If you require system folders or other public folders after the upgrade, create replicas
of the public folders on an Exchange Server 2010 server hosting the public-folder database. Wait for
replication to complete, and then remove the replicas on the Exchange Server 2007 servers.
Offline Address Book generation. Before uninstalling the Exchange Server 2007 server that is currently
generating the Offline Address Book, move this functionality to an Exchange Server 2010 Mailbox
server.
Removing Exchange Server 2007 Servers
13-16
As you move mailboxes and message delivery to the Exchange Server 2010 servers, you can start
removing the previous Exchange Server versions. Use the following process for removing Exchange Server
2007 servers:
1.
Remove Mailbox servers first. As you move mailboxes from Exchange Server 2007 servers to Exchange
Server 2010 Mailbox servers, you can start decommissioning the Exchange Server 2007 Mailbox
servers.
2.
Remove the Exchange Server 2007 Unified Messaging server role. The Exchange Server 2010 Unified
Messaging server can coexist with Exchange Server 2007 Mailbox servers.
3.
Remove the Exchange Server 2007 Hub Transport servers. The Exchange Server 2007 Mailbox server
must be able to communicate with an Exchange Server 2007 Hub Transport server. As you remove
Exchange Server 2007 Mailbox servers, you also can begin removing the Exchange Server 2007 Hub
Transport servers. Do not remove the last Exchange Server 2007 Hub Transport server until the last
mailboxes are moved from the Exchange Server 2007 servers.
4.
Remove the Exchange Server 2007 Client Access Servers. Users who connect to their mailboxes using
Outlook Web App clients must be able to communicate with a Client Access Server that is the same
Exchange Server version as the server hosting the user mailbox.
After you remove the last mailbox and public folder from the Exchange Server 2007 Mailbox server, you
may remove all other Exchange Server 2007 servers in the Active Directory site.
13-17
Lab: Upgrading from Exchange Server 2007 to Exchange

Server 2010
Lab Setup
1.
2.
Ensure that the 10165A-ROM-DC1-C, 10165A-ROM-EX07-C, and 10165A-ROM-EX10-C virtual

3.
10165A-ROM-DC1-C: Domain controller in the Adatum.com domain.
10165A-ROM-EX10-C: Will be configured as the Exchange Server 2010 server in the Adatum.com
domain.
10165A-ROM-EX07-C: Exchange Server 2007 server in the Adatum.com domain.
If required, connect to the virtual machines. Log on to the computers as Adatum\Administrator,

using the password Pa$$w0rd.

1.
On the host machine, in Hyper-V Manager, right-click 10165A-ROM-EX10-C, and then click
Settings.
2.
Click DVD Drive, click Image file, and then, in the right pane, click Browse.
3.
Browse to C:\Program Files\Microsoft Learning\10165\Drives.
4.
Click Exchange2010SP1.iso, click Open, and then click OK.
Lab Scenario
13-18
A. Datum Corporations main office is located in Rome. A. Datum is currently using Exchange Server 2007
to provide all messaging functionality. The organization is planning to upgrade the organization to
Exchange Server 2010, and to remove all Exchange Server 2007 servers. Because the organization has a
large number of users, both Exchange Server 2007 and Exchange Server 2010 will need to be supported
during a period of coexistence.
13-19
Exercise 1: Installing Exchange Server 2010

Scenario
A. Datum is ready to deploy the first Exchange Server 2010 server in their Rome office. You need to ensure
that all prerequisites have been met for performing the installation and then you need complete the
Exchange Server 2010 server installation.
The main tasks for this exercise are as follows: Verify the organizational prerequisites for Exchange Server
2010.
Install Exchange Server 2010 server using a typical installation.
Task 1: Verify the organizational prerequisites for Exchange Server 2010

1.
Install the Microsoft Exchange Server Pre-Deployment Analyzer by using the install files located in
D:\Labfiles.
2.
Run the Pre-Deployment Analyzer, and verify that there are no critical issues that will block the
installation of Exchange Server 2010.
Task 2: Install Exchange Server 2010 using a typical installation

1.
Run the Exchange Server 2010 setup program from the attached Exchange2010SP1.iso file.
2.
Choose a typical installation, and install Windows Server roles and features as part of the installation.
3.
Configure an external domain name for the client access server of mail.adatum.com
4.
Restart the installation if prompted, and do not resume the previous setup.
Results: After this exercise, you should have verified that the Exchange Server organization is ready for
the installation of Exchange Server 2010, and you should have installed Exchange Server 2010.
Exercise 2: Configuring Exchange Server Version Coexistence

Scenario
13-20
Now that you have installed the Exchange Server 2010 server, you need to verify that the Exchange Server
versions can coexist. You need to test whether message delivery is working for internal and external
recipients. In addition, you need to configure client access coexistence before you start moving user
mailboxes to the Exchange Server 2010 server. Then, you need to start moving resources and functionality
to Exchange Server 2010, starting by moving mailboxes and public folders. Finally, you need to configure
Exchange Server 2010 route all message to and from the Internet.
Create a test mailbox in Exchange Server 2010.
Verify message delivery coexistence.
Prepare a Server Certificate request for ROM-EX10.
Request the certificate from the Certification Authority.
Import and assign the Internet Information Services Exchange services to the new certificate.
Verify Outlook Web App coexistence.
Move a test user from Exchange Server 2007 to Exchange Server 2010.
Check public folder accessibility.
Create a public folder database on ROM-EX10.
Add a replica of the CustomerService public folder and System public folders to ROM-EX10.
Verify transport and journaling rule coexistence.
Verify administrative coexistence.
Move the remaining mailboxes from Exchange Server 2007 to Exchange Server 2010.
Move the Offline Address Book server to Exchange Server 2010.
Migrate Internet message routing to Exchange Server 2010.
Verify public folder replication, and remove Exchange Server 2007 replicas.
Task 1: Create a test mailbox in Exchange Server 2010
On ROM-EX10, create a new mailbox using the following information:
First name and User logon name: EX2010User
Password: Pa$$w0rd
Mailbox database: Exchange Server 2010 mailbox database
Task 2: Verify message delivery coexistence

1.
Connect to Outlook Web App by connecting to https://ROM-EX10/owa.
2.
Log on as Adatum\EX2010User, using the password Pa$$w0rd.
3.
Send a test message to EX2010User, Administrator and test@contoso.com.
4.
In the Sent Items folder, review the delivery report to verify that the message was delivered.
13-21
5.
Connect to Exchange Server 2007 Outlook Web Access using the URL https://ROMEX07.adatum.com/owa. Log on as Administrator, using the password Pa$$w0rd. Verify that the
message from EX2010User arrived, and then reply to the message.
6.
Verify that the reply message was sent to EX2010User.
7.
Connect to ROM-DC1\C$\inetpub\mailroot\queue. Verify that a message has been delivered to

the Queue folder on ROM-DC1.
8.
On ROM-DC1, use Telnet to connect to ROM-EX07, and then send a test message from
test@contoso.com to EX2010User@adatum.com.
9.
In Outlook Web App, verify that the message from test@contoso.com arrived.
Task 3: Prepare a Server Certificate request for ROM-EX10
On ROM-EX10, use the New Exchange Certificate wizard to request a certificate with the following
parameters:
Friendly name: Adatum Mail Certificate
Outlook Web Access names: ROM-EX07.adatum.com, ROM-EX10.adatum.com,

mail.adatum.com
Exchange ActiveSync: enabled
Auto discover and Long URL: enabled
Legacy Exchange Server: ROM-EX07.adatum.com
Common name: Mail.adatum.com
Organization: A Datum
Country/region: Italy
City/locality: ROME
State/province: ROME
File name: CertRequest
Task 4: Request the certificate from the Certification Authority

1.
Copy the contents of the CertRequest.cer file into the clipboard.
2.
Connect to https://ROM-DC1.adatum.com/certsrv, and log on as Administrator using the

password Pa$$w0rd.
3.
Create an advanced certificate request for a Web Server certificate.
4.
Download the certificate, and save it to the default location.
5.
Verify that the certificate contains the required subject alternative names.
Task 5: Import and assign the Internet Information Services Exchange services to the
new certificate
1.
In the Exchange Server 2010 Exchange Management Console, complete the pending certificate
request.
2.
Assign the Internet Information Services (IIS) service to the certificate.
Task 6: Verify Outlook Web App coexistence
13-22
1.
On ROM-DC1, in DNS, create a new host record for mail.adatum.com using the IP address
10.10.10.30.
2.
Connect to https://mail.adatum.com/owa, and log on as Adatum\EX2010User using the password

Pa$$w0rd. Verify that the user can access their mailbox.
3.
Connect to https://mail.adatum.com/owa, and log on as Adatum\Anna using the password

Pa$$w0rd. Verify that the web browser is redirected back to the Exchange Server 2007 server, and
that the user can access their mailbox.
Task 7: Move a test user from Exchange Server 2007 to Exchange Server 2010
1.
On ROM-EX10, in the Exchange Management Console, add the Database attribute to the Recipient
display.
2.
Create a new local move request to move Andreas Herbingers mailbox to the mailbox database on
ROM-EX10.
3.
Verify that the move succeeds.
4.
Connect to https://mail.adatum.com/owa, and log on as Adatum\Andreas using the password

Pa$$w0rd. Verify that the user can access their mailbox.
Task 8: Check public folder accessibility

1.
Connect to https://mail.adatum.com/owa, and log on as Adatum\Andreas using the password

Pa$$w0rd.
2.
Attempt to access Public Folders. Note the error message.
Task 9: Create a public folder database on ROM-EX10
On ROM-EX10, create a new public folder database named PF-ROM-EX10. Store the database and
transaction log files in the C:\Mailbox\PF-ROM-EX10 folder.
Task 10: Add a replica of the CustomerService public folder and System public
folders to ROM-EX10
1.
On ROM-EX07, open the Public Folder Management Console.
2.
Add a replica on ROM-EX10 for the CustomerService public folder.
3.
Open the Exchange Management Shell, and switch to the cd \Program

Files\Microsoft\Exchange\v14\Scripts folder.
4.
Run the following command to add a replica of all system public folders to ROM-EX10:
.\AddReplicaToPFRecursive.ps1 TopPublicFolder \NON_IPM_Subtree ServertoAdd ROMEX10.
Task 11: Verify transport and journaling rule coexistence

1.
On ROM-EX07, in the Exchange Management Console, verify the configuration of the External
Disclaimer transport rule and the Executive Journaling journal rule.
2.
On ROM-EX10, verify that the same transport and journal rule are being applied on the Exchange
Server 2010 server.
13-23
3.
On ROM-EX10, modify the transport rule configuration by adding an exception for the ITAdmins
group.
4.
Modify the journal rule configuration to apply to only external messages.
5.
On ROM-EX07, verify that the changes to the transport and journal rule were not applied in Exchange
Server 2007.
Task 12: Verify administrative coexistence

1.
On ROM-EX10, in Active Directory Users and Computers, verify that both the Exchange Server
2007 and Exchange Server 2010 administrative groups are listed.
2.
Verify that the Exchange Server 2007 administrative groups are added to the corresponding Exchange
Server 2010 management role groups.
Task 13: Move the remaining mailboxes from Exchange Server 2007 to Exchange
Server 2010
1.
On ROM-EX10, in the Exchange Management Console, create a new local move request to move all
of the mailboxes on ROM-EX07 to ROM-EX10.
2.
Verify that the mailboxes are being moved.
Task 14: Move the Offline Address Book server to Exchange Server 2010
1.
On ROM-EX10, in the Exchange Management Console, move the Offline Address Book server to
ROM-EX10.
2.
Configure the public folder distribution to use only the Web folders on ROM-EX10, and to provide
only Version 4 versions of the offline address book.
3.
Browse to C:\Program Files\Microsoft\Exchange Server\v14\ExchangeOAB, and verify that the

offline address book has been created.
4.
Browse to C:\Program Files\Microsoft\Exchange Server\v14\ClientAccess\OAB, and verify that

the offline address book has been replicated to the Client Access Server virtual directory. If the files
do not appear in the OAB folder, restart the Microsoft Exchange File Distribution service on ROMEX10, and check again.
Task 15: Migrate Internet message routing to Exchange Server 2010

1.
On ROM-EX10, in the Exchange Management Console, modify the configuration of the Internet
Send Connector to remove ROM-EX07 as a source server and add ROM-EX10 as a source server.
2.
On ROM-EX10, modify that configuration of the Default ROM-EX10 SMTP receive connector to
accept anonymous connections.
Task 16: Verify public folder replication, and remove Exchange Server 2007 replicas
1.
On ROM-EX10, in the Exchange Management Shell, use the Get-PublicFolderStatistics command to

verify that the CustomerService public folder has replicated to the ROM-EX10 public folder database.
2.
Connect to https://mail.adatum.com/owa, log on as Adatum\Andreas using the password

Pa$$w0rd, and then verify that the user can view the public folder.
3.
Use the following command to remove ROM-EX07 from the CustomerService public folder replica list:
.\RemoveReplicaFromPFRecursive.ps1 TopPublicFolder \CustomerService ServertoRemove

ROM-EX07
4.
Use the following command to remove ROM-EX07 from the replica list for all other public folders:
.\ReplaceReplicaonPFRecursive.ps1 TopPublicFolder \ -ServertoAdd ROM-EX10

ServertoRemove ROM-EX07
5.
Use the following command to remove ROM-EX07 from the replica list for all system public folders:
.\ReplaceReplicaonPFRecursive.ps1 TopPublicFolder \non_ipm_subtree -ServertoAdd ROMEX10 ServertoRemove ROM-EX07
6.
13-24
Change the configuration of the mailbox database located on ROM-EX10 to use PF-ROM-EX10 as
the default public folder database.
Results: After this exercise, you should have verified that the Exchange Server versions are coexisting
without issues, and you should have migrated all resources and functionality from Exchange Server 2007
13-25
Exercise 3: Removing Exchange Server 2007

Scenario
Now that you have migrated all resources and functionality from Exchange Server 2007 to Exchange
Server 2010, you are ready to remove the Exchange Server 2007 server. Before removing the functionality,
you will test that Internet message delivery now works through Exchange Server 2010, and then you will
remove Exchange Server 2007 from the organization.
Verify that Exchange Server 2007 can be removed.
Remove Exchange Server 2007 from the organization.
Task 1: Verify that Exchange Server 2007 can be removed

1.
On ROM-EX10, connect to Outlook Web App by connecting to https://ROM-EX10/owa.
2.
Log on as Adatum\Anna using the password Pa$$w0rd.
3.
Send a test message to test@contoso.com.
4.
In the Sent Items folder, review the delivery report to verify that the message was delivered.
5.
Connect to ROM-DC1\C$\inetpub\mailroot\queue. Verify that a message has been delivered to

the Queue folder on ROM-DC1.
6.
On ROM-DC1, use Telnet to connect to ROM-EX10, and then send a test message from
test@contoso.com to Anna@adatum.com.
7.
In Outlook Web App, verify that the message from test@contoso.com arrived.
Task 2: Remove Exchange Server 2007 from the organization

1.
On ROM-EX07, dismount and remove the Mailbox Database.
2.
Remove the Public Folder Database.
Note If you receive a message that the object cannot be deleted because it contains messages,
wait 5 minutes and try again. If you receive the same message, complete the step shown in this note
below. In a production environment, you would ensure that all public folder contents have been
removed from the database before deleting the database. If you receive a message that the object is
read-only because it was created by a future version of Exchange, open ADSIEdit.msc and connect to
the Configuration container. Next, browse to
Configuration\CN=Configuration,DC=adatum,DC=com\CN=Services\CN=Microsoft
Exchange\CN=AdatumOrg\CN=Administrative Groups\CN=Exchange Administrative Group
(FYDIBOHF23SPDLT), CN=Servers,CN=ROM-EX07,CN=InformationStore,CN=Second Storage
Group, and delete the public folder database.
3.
In Control Panel, open Programs and uninstall Exchange Server 2007.
4.
Shut down ROM-EX07.
Results: After this exercise, you should have verified that Exchange Server 2007 can be removed safely
from the organization, and you should have uninstalled Exchange Server 2007 from ROM-EX07.
Review Questions
13-26
1.
Your organization is deploying Exchange Server 2010 in an Exchange Server 2007 organization. You
have made the changes to AD DS. What is the first Exchange Server 2010 server role that you should
deploy? How will this deployment change the user experience?
2.
Your organization includes two locations and Active Directory sites. You have deployed Exchange
Server 2007 servers in both sites. You now are deploying Exchange Server 2010 servers in one of the
sites, and removing the Exchange Server 2007 servers. When can you remove the last Exchange Server
2007 Hub Transport server in the site?
Common Issues Related to Upgrading to Exchange Server 2010
Identify the causes for the following common issues related to upgrading to Exchange Server 2010. For
answers, refer to relevant lessons in the module.
Issue
You are upgrading your Exchange
Server 2007 organization to Exchange
Server 2010, and you have configured
Client Access servers for Internet
access. Users with mailboxes on
Exchange Server 2010 Mailbox servers
can access their mailbox using
Outlook Web App from the Internet,
but users with mailboxes on the
Exchange Server 2007 Mailbox servers
cannot.
You have deployed Exchange Server
2010 servers in your Exchange Server
2007 organization. You need to
Troubleshooting tip
Issue
Troubleshooting tip
modify the settings on both Exchange

Server 2007 and Exchange Server
2010 servers, but you cannot see both
servers in the Exchange Management
Console.
13-27
1.
Your organization has deployed Microsoft Forefront Threat Management Gateway (TMG) to secure
access to the Client Access server deployment. You have completed all of the steps required to enable
access to both the Exchange Server 2010 Client Access server and the Exchange Server 2007 Client
Access server. What changes do you need to make on the Forefront TMG server?
2.
In your Exchange Server 2007 deployment, your users have been using the URL
https://mail.contoso.com/owa from the Internet to access Outlook Web Access. You want to use the
same URL during and after you upgrade to Exchange Server 2010. What do you need to do to make
sure that users can use this URL to access mailboxes on both Exchange Server 2010 and Exchange
Server 2007?
Best Practices Related to Upgrading to Exchange Server 2010

Plan to increase the number of Client Access servers as you upgrade to Exchange Server 2010. For
Exchange Server 2007 deployments, we recommended a one-to-four ratio of Client Access server
processor cores to Mailbox server processor cores. In Exchange Server 2010, we recommend a threeto-four ratio.
Use certificates with subject alternative names rather than using wildcard certificates when you obtain
certificates for the Client Access servers. Wildcard certificates are less secure, because they can be
used to secure connections to any server name. If an attacker obtains a copy of the certificate, they
can use it to secure connections to any server name while using your domain name.
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.
13-28
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.
Understanding and Planning for Microsoft Exchange Online
A-1
Appendix A

Contents:
Lesson 1: Planning for Exchange Online
A-3
Lesson 2: Migrating to and Managing Exchange Online
A-18
Lesson 3: Implementing Federated Delegation
A-25
A-2
Module Overview
Increasingly, migrating to Exchange Online as an organizations messaging host has become an attractive
option for Exchange administrators who currently run Exchange servers in their organizations data
centers. The reason for this interest is that moving Exchange administration and management to the
cloud reduces operational, licensing, and setup costs.
Exchange Online is available through Office 365, which provides cloud-based versions of Microsoft
products. This module will help you understand Office 365 and Exchange Online, and plan for Exchange
Online.
Microsoft Exchange Server 2010 Service Pack 1 (SP1) contains functionality that can help you connect
your existing Exchange organization to Exchange Online. The rich coexistence option allows collaboration
between users who use Exchange Server mailboxes and Exchange Online mailboxes. The Federated
Delegation feature also enhances collaboration by allowing you to share information between Exchange
on-premises organizations and Exchange Online organizations.
Explain how to plan for Exchange Online.
Explain how to migrate to and manage Exchange Online.
Explain how to implement Federated Delegation.
Lesson 1
Planning for Exchange Online
A-3
If you currently do not have an Exchange organization in your company, you can start with Exchange
Online as your messaging system. However, for organizations that currently maintain a messaging system,
it is important to understand Exchange Online and its coexistence options.
Describe Office 365.
Describe the Exchange Online features.
Describe Exchange Online user subscriptions.
Describe Microsoft Forefront Online Protection for Exchange (FOPE).
Describe considerations for using Exchange Online and coexistence.
Connect Exchange on-premises to Exchange Online.
Describe how mail flows during coexistence.
Describe the simple and rich coexistence scenarios.
A-4
What Is 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
with various pricing options.
Exchange Online
Exchange Online provides Exchange Server 2010 email, calendar, and contacts in addition to antivirus and
anti-spam protection. You can connect your existing Exchange Server 2010 organization to Exchange
Online to provide rich coexistence for your users. This and other features are described in the next topic.
Lync Online
Lync Online provides instant messaging (IM) and presence, video conferencing, and screen sharing to
your users. You can connect your organizations existing Microsoft Office Communications Server 2007 or
Microsoft Lync Server 2010 servers to Lync Online. By the end of 2011, Lync Voice will be available for
Lync Online users.
SharePoint Online
SharePoint Online allows you to create and manage SharePoint sites directly from the cloud. You can
share documents or keep teams updated by using a common SharePoint team site that does not require
you to set up SharePoint in your own datacenter. You can also share a SharePoint site between
organizations if you do not want to set up servers in a perimeter datacenter.
Office Professional Plus

The familiar Office desktop applications and Office Web Apps seamlessly connect to the cloud with a
flexible per-user license model. The following features are available in Office Professional Plus:
Microsoft Office Professional Plus 2010 client applications available as a monthly subscription.
Per-user license with up to five simultaneous installations.
Support for 32- and 64-bit installations.
Easy access and management through the Office 365 online portal.
Note Office Professional Plus is not a streaming client. It includes Office Web Apps in the
license. Office Professional Plus provides the full Office Professional 2010 feature set on the
local machines, but it differs in license management.
Question: What Office 365 services would you use in your company? Why?
A-5
A-6
Exchange Online Features
Exchange Online provides most of the features that are available in Exchange Server 2010 SP1 and
includes additional features such as the ability to configure your Unified Messaging IP Gateway in
Exchange Control Panel. Other key Exchange Online features include:
Note When referring to the local Exchange Server organization, we use the term onpremises to differentiate it from the online services Exchange version.
Migration and coexistence. Exchange Online provides migration tools, so you can move users to
Exchange Online over a weekend. Or, you can connect your Exchange Server 2003, Exchange Server
2007, or Exchange Server 2010 environment to the cloud and enjoy rich coexistence, which lets you
share calendar free/busy data between cloud and on-premises users and migrate at whatever pace
you want.
Compliance and archiving. Exchange Online provides the archiving and eDiscovery capabilities of
Exchange Server 2010 with built-in personal email archives, Multi Mailbox Search, retention policies,
transport rules, and optional legal hold to preserve email.
Multiple management tools such as the Exchange Management Console, Exchange Control Panel,
Microsoft Windows PowerShell, and the Exchange Online Portal. The web-based Exchange Control
Panel from Exchange Server 2010 is available in Exchange Online, so you can manage policies,
security, user accounts, and groups. You can also use PowerShell to manage all aspects of your hosted
Exchange environment remotely across the Internet or continue to use the Exchange Management
Console.
Enhanced web experience. The Microsoft Outlook Web App experience is available in Internet
Explorer, Firefox, and Safari. Instant messaging integration allows users to chat from within Outlook
Web App.
A-7
Advanced routing options. Exchange Online allows you to route outbound email through your onpremises infrastructure. This means you can perform custom post-processing of outbound email, use
third-party data loss prevention (DLP) appliances, and deliver email to business partners through
private networks.
Forefront Online Protection for Exchange. FOPE is included for automatic anti-spam and antivirus
scanning.
Hosted voicemail with Unified Messaging. You can replace your on-premises voicemail system by
integrating your on-premises private branch exchange (PBX) with hosted voicemail provided by
Exchange Online.
Exchange Online supports the following messaging clients:
Outlook Web App (Internet Explorer, Firefox, and Safari)
Outlook 2011 for Mac (without Personal Archives)
Entourage 2008 Exchange Web Services Edition
Features from Exchange Server 2010 SP1 that are currently not available in Exchange Online include:
Public folders
A catch-all messages mailbox
Custom and hierarchical address lists
Global address list (GAL) segmentation
Secure/Multipurpose Internet Mail Extensions (S/MIME) in Outlook Web App
Application connectivity for the Messaging Application Programming Interface (MAPI), Collaboration
Data Objects (CDO), and the WebDAV library
GAL synchronization with multiple on-premises Active Directory Domain Services (AD DS) forests
Note Exchange Online features are subject to change. Refer to the Office 365 website at
http://go.microsoft.com/fwlink/?LinkId=213769 for updated feature lists.
A-8
Exchange Online User Subscriptions
Office 365 is available in two service plans:
Office 365 for small business
Office 365 for enterprises
The Office 365 for small businesses service plan provides Exchange Online Kiosk subscriptions. The Office
365 for enterprises service plan includes all subscription options. This topic focuses only on the Exchange
Online subscription options.
You can subscribe to Exchange Online by choosing one of three service plans:
Exchange Online Kiosk
Exchange Online Plan 1
The following table provides details about each user subscription.
Feature
Exchange Online
Kiosk
Mailbox size
500 megabytes
(MB)
25 gigabytes (GB) shared

between the primary
mailbox and archive
mailbox
25 GB for the users mailbox

plus unlimited archive mailbox
storage
Outlook Web
App
(regular and light
versions)
Yes
Yes
Yes
POP3
Yes
Yes
Yes
A-9
Feature
Exchange Online
Kiosk
IMAP4
No
Yes
Yes
Outlook
Anywhere (MAPI)
No
Yes
Yes
Microsoft
Exchange
ActiveSync
No
Yes
Yes
Exchange Web
Services
No (no direct access

to kiosk user
mailboxes via
Exchange Web
Services)
Yes
Yes
Inbox rules
No
Yes
Yes
Delegate access
No (cannot access
other users
mailboxes, shared
mailboxes, or
resource mailboxes)
Yes
Yes
Instant
messaging
interoperability
in Outlook Web
App
No
Yes (requires Lync Online

or Microsoft Lync Server
2010)
Yes (requires Lync Online or

Microsoft Lync Server 2010)
Short Message
Service (SMS)
notifications
No
Yes
Yes
Personal Archives
No
Yes
Yes
Voicemail
(Unified
Messaging)
No
No
Yes
Legal hold
No
No
Yes
Note Exchange Online subscription options are subject to change. Refer to the Office 365
website at http://go.microsoft.com/fwlink/?LinkId=213769 for updated information.
A-10
What Is Forefront Online Protection for Exchange?
Current messaging environments require a robust antivirus and anti-spam solution to minimize the
impact of malicious messaging. FOPE is an antivirus, anti-spam service that comes with Exchange Online
or can be purchased separately for your Exchange on-premises environment. It is a hosted version of
Forefront Protection 2010 for Exchange Server that requires no hardware or software installation.
FOPE includes the following functionality:
It covers incoming, outgoing, and internal email messages. This helps protect your organization from
malicious content that originates from behind your firewall.
Multiple and complementary antivirus engines help catch email-borne viruses and other malicious
code.
The service uses proprietary anti-spam technology to achieve high accuracy rates.
All functionality is built-in to the service. No configuration is necessary to start or maintain the
filtering technology. FOPE just requires a FOPE Send connector so messages will be sent to the FOPE
domain for scanning.
A highly customizable filter helps you comply with corporate policies and government regulations.
By creating a forced Transport Layer Security (TLS) rule in the policy filter, you can help ensure that
sensitive email is encrypted during transport using TLS.
Considerations for Using Exchange Online and Coexistence
A-11
When considering Exchange Online, you need to consider your business needs so that you can decide
between:
Maintaining an Exchange on-premises organization.
Migrating Exchange on-premises to Exchange Online so that all of your users are hosted in the cloud.
Connecting Exchange on-premises to Exchange Online so that you have a coexistent organization.
Exchange On-Premises
An Exchange on-premises installation is one in which you maintain a local installation of Exchange Server
in your datacenter. This means that your company manages your companys messaging environment on
your own in your datacenters.
The on-premises scenario allows you to perform maintenance, upgrades, and customization at your
convenience. However, this model requires considerable upfront capital for such expenses as hardware,
software, licenses, IT personnel for maintenance, and physical building space.
Exchange Online
In an Exchange Online environment, all of your mailboxes are hosted from the cloud. You do not host any
Exchange servers in your datacenter. Instead, you purchase the Exchange Online service from Microsoft.
This scenario provides rapid deployment and easy scalability. You also receive automatic upgrades to the
latest technology, ensuring an easy and seamless upgrade experience.
Exchange Coexistence
A mixed Exchange on-premises and Exchange Online environment is a coexistent environment, which
means, for example, that Free/Busy and calendar sharing functions as usual between on-premises and
online mailbox users. This scenario provides the best features of both implementations such as hosting the
A-12
primary mailboxes on-premises and moving the archive mailboxes to Exchange Online. Additionally,
Exchange coexistence allows you to migrate to Exchange Online in stages.
Considerations
Consider the following questions so that you can decide on the most suitable scenario for your
organization:
Does your organization want to move all mailboxes to Exchange Online or only consider a subset of
mailboxes?
Does your organization often use mailbox delegation? If yes, you need to ensure that both the
mailboxes and the mailboxes with delegation rights to those mailboxes are either hosted online or
hosted on-premises.
Does your organization use public folders a lot? Exchange Online does not support public folders, so
you should not move users that depend on public folders to Exchange Online.
Is it important to have full control of the features and functionality of your messaging system?
Do organizational policies, governmental regulations, or compliance requirements exist with regards

to storing messaging data outside the organizations local area network (LAN)?
Does your organization satisfy the client requirements for Exchange Online?
Does your organization have a reliable connection to the Internet with sufficient bandwidth to move
all mailboxes to the cloud?
Does your organization have many mobile users or users who work outside the corporate offices that
would benefit from a connection to the cloud rather than to the corporate datacenter?
Is your organization interested in moving just some of the functionalitysuch as mailbox archivingto
the cloud?
Connecting Exchange On-Premises to Exchange Online
A-13
You can choose to run Exchange Online independently from your existing messaging infrastructure, but
the functionality that is available in a coexistence environment can help you manage your online users
and mailbox migrations more efficiently.
Configure Active Directory Federation Services
You can configure Active Directory Federation Services (ADFS) to allow single sign-on and centralized user
management. ADFS is not a requirement, but Microsoft recommends implementing this tool to improve
user satisfaction.
With ADFS, your users can access online services with their domain credentials the same way they access
their on-premises applications. There is no need for a client-side sign-in tool.
Using ADFS provides the following benefits:
Better manageability and lower total cost of ownership (TCO).
Passwords are kept within the organization. Microsoft does not see credentials and passwords
because they are not synchronized to the cloud.
Organizations retain security control over user accounts and password expiration.
Simple to configure and manage. It does not require changes to the Active Directory code or
alterations of enterprise Active Directory deployment.
With ADFS, you can deploy a multi-factor authentication system, which can include soft certificate and
smartcard authentication from out-of-the-box products such as RSA and Swivel.
You can customize the login page for Exchange Online and your other federated web applications such as
SharePoint Online.
A-14
Implement Active Directory Synchronization

After implementing ADFS, you should also implement Active Directory synchronization between your
organizations Active Directory forest and Exchange Online. You do this with the Directory
Synchronization tool.
Directory Synchronization provides simplified management through integration with your local Active
Directory forest and enables you to use the Active Directory information, so you do not have to
administer the organization from two locations.
The Directory Synchronization tool updates the Microsoft online environment whenever changes occur in
AD DS. This means that changes such as adding a new employee, deleting an employee, and changing
contact information automatically propagates to Exchange Online, so you do not have to update
Exchange Online manually. These synchronized items are read-only in the cloud, and you continue to
manage them with the AD DS tools.
The Directory Synchronization tool synchronizes changes every three hours. To protect your security, it
does not update sensitive information such as domain passwords. This tool also updates distribution
groups and the GAL and plays an important role during coexistence between your local Exchange Server
organization and Exchange Online.
Configure Exchange Federated Delegation
With Exchange Server 2010 SP1 you can provide rich coexistence. Rich coexistence allows your users to
use calendar sharing with free/busy information that includes subject and location. They can share their
contacts with each other by configuring Federated Delegation from the on-premises Exchange
Management Console. Federated Delegation is discussed in Lesson 3.
Question: Suppose you want to connect your Exchange Server organization to Exchange
Online. What options would you configure and why?
How Mail Flows During Coexistence
A-15
When managing multiple Exchange organizations, you need to consider how mail will flow to and from
the Internet, and between the organizations.
Exchange On-Premises
In your Exchange Server on-premises implementation, you generally need to configure your Domain
Name System (DNS) Mail Exchanger (MX) record to point to your companys Simple Mail Transfer
Protocol (SMTP) smart host.
Exchange Coexistence
In a coexistence environment, the following two options are available:
Shared namespace with virtual domains. The DNS MX record of your SMTP domain points to
Exchange Online and you forward all messages to Exchange on-premises using an internal, virtual
SMTP domain. FOPE scans the messages before it sends them to the on-premises mailboxes.
Shared namespace with address rewrite. The DNS MX record of your SMTP domain points to your
company. All messages are received by a SMTP smart host inside your company, and then only
messages that are targeted for online mailboxes are forwarded by using address re-write and an
internal SMTP Send connector. Additionally, messages sent to the Internet must follow this path,
which means that they flow from Exchange Online to the Exchange on-premises Send connector, and
then to external recipients. The benefit of this approach is that you can control Internet inbound and
outbound messages.
Exchange Online
When your organization runs only Exchange Online, your companys DNS MX record must point to
Exchange Online. All messages are scanned using FOPE before arriving at the online mailboxes.
A-16
Simple and Rich Coexistence Scenarios
When connecting your Exchange on-premises organization to Exchange Online, several options are
available that combine into two common scenarios: simple coexistence and rich coexistence.
Simple Coexistence
In a simple coexistence environment, you connect your existing Exchange organization using Directory
Synchronization and an SMTP connector between Exchange on-premises and Exchange Online. ADFS is
not a requirement but adds benefits by providing single sign-on to your users.
Simple coexistence provides a common GAL on the online and on-premises environments, and it allows
users to share the same domain name. Directory Synchronization ensures that the environments remain
synchronized. To move mailboxes between premises, you must use the web-based migration tool that is
available through the Microsoft Online Services portal.
You can configure simple coexistence for Exchange Server 2003 and Exchange Server 2007 organizations
when you do not want to implement an Exchange 2010 SP1 Gateway server for this task.
Rich Coexistence
The rich coexistence scenario provides the smoothest way to coexist with Exchange Online and to be
flexible about when and how to move your users between premises. We recommend this approach when
you are planning a mixed on-premises and online environment.
Rich coexistence provides the following benefits:
Exchange on-premises and Exchange Online management from a single tool by using Exchange
Management Console and Exchange Management Shell.
Mailbox moves between premises using Exchange Management Shell and Exchange Management
Console.
Calendaring, including free/busy information and full calendar sharing, between hosted and onpremises users.
Addresses for internal users resolved against GAL.
MailTips, anti-spam scanning, and Out of Office (OOF) auto-replies understand that recipients are
internal.
Delivery reports delivered across the online/on-premises boundary.
Multi-Mailbox Search performed across all mailboxes.
A-17
For this scenario, you must deploy at least one machine running Exchange Server 2010 SP1 that acts as a
gateway to Exchange Online. Also, you need to configure ADFS, Directory Synchronization, and Federated
Delegation.
For Exchange Server 2003 and Exchange Server 2007 organizations, you must deploy this additional
server. However, you do not need to upgrade mailboxes to Exchange Server 2010 prior to moving them
to Exchange Online. The Exchange 2010 SP1 server acts as a proxy between Exchange Server 2003 and
Exchange Server 2007 environments and Exchange Online.
A-18
Lesson 2
Migrating to and Managing Exchange Online
To create a coexistent Exchange environment, you must first consider how to migrate mailbox users to
Exchange Online. You use many of the same tools to manage these users as you do the on-premises
users. This lesson describes your migration options and the tools you can use to manage the mailboxes
both during and after migration.
Describe the Exchange Online migration options.
Explain how to migrate users to Exchange Online.
Describe the management tools available for Exchange Online.
Exchange Online Migration Options
A-19
Exchange Online offers various built-in tools and migration options to fit the migration needs of your
organization.
IMAP Migration
The most common way to migrate from third-party messaging systems such as Lotus Notes or GroupWise
to Exchange Online is to use the IMAP migration process. To use this process:
Ensure that your existing messaging system allows access to the mailboxes using the IMAP4 protocol.
Create a comma separated values (.csv) file to list the users you want to migrate.
Use the Exchange Control Panel to migrate mailbox contents to the respective online mailboxes.
This migration option supports the widest range of email platforms, including Exchange Server 5.5 and
Exchange 2000 Server.
Limitations include:
Only email messages migrate to the online mailbox, not calendar or contacts.
There is no coexistence. You need to migrate all mailboxes at the same to ensure that you do not lose
data.
You can only move up to1000 mailboxes at once. Currently, the Microsoft Online Portal can only read
.csv files with a maximum of 1000 rows. If you need to move more mailboxes, you must create
batches of a maximum of 1000 mailboxes and import each batch into Exchange Online.
Simple Exchange Migration
Simple Exchange migration, also called cutover migration, migrates all mailboxes from an Exchange onpremises installation to Exchange Online at the same time. This migration method does not support a
coexistence phase.
A-20
Simple Exchange migration uses Outlook Anywhere (Exchange Server 2007) or RPC-over-HTTP (Exchange
Server 2003) to connect to the source mailboxes, and it copies all contents to the online mailboxes.
You do not need additional servers on-premises to perform a migration. However, similar to IMAP
migration, you are limited to migrating up to 1000 mailboxes at one time.
Simple Coexistence with Migration
Simple coexistence with migration, or staged migration is similar to simple Exchange migration except
that it allows for simple coexistence, which means that you can choose to migrate mailboxes in stages. It
uses Outlook Anywhere or RPC-over-HTTP for the connection and accepts a .csv file.
After a mailbox has migrated, Directory Synchronization updates the information, and the user is
automatically reachable in Exchange Online at their original email address.
This migration method is available for Exchange Server 2003 and later. It requires you to configure and
install the Directory Synchronization tool before migration.
Rich Coexistence with Migration
Rich coexistence with migration is the most robust migration method. This option allows you to use the
Exchange Management Console or the Exchange Management Shell to migrate your users to or from
Exchange Online. Use the New-MoveRequest cmdlet as you would for your intra-organizational moves.
The principal benefit of this approach is that mailbox moves occur over the Internet using the Microsoft
Exchange Mailbox Replication Proxy (MRSProxy) service. The Client Access servers that are required to
communicate between Exchange on-premises and Exchange Online perform the mailbox moves. You do
not need to create .csv files. Additionally, this approach allows the mailbox to stay online while the move
completes.
To use this migration method, you must configure your Exchange Server organization for rich coexistence.
You need at least one Exchange Server 2010 SP1 machine, the Directory Synchronization tool, and
Federation Delegation configured for Exchange Online.
Question: Which Exchange Online migration option would be suitable for a larger
organization with 2000 mailboxes?
Migrating to Exchange Online
A-21
Migrating an existing messaging system to Exchange Online is a complex task that includes many
unknown variables such as the size of your system, the client protocol you use, and which messaging
system you use. However, most migrations follow a general pattern that consists of the following steps:
1.
Connect directory and message routing to Exchange Online.
As mentioned previously, establishing a connection to Exchange Online ensures that your existing
email directory is synchronized to Exchange Online. Depending on your source directory, you can use
the Directory Synchronization tool to synchronize the Exchange Online directory, or you can use
other tools such as a .csv file if you use legacy systems. Be sure that all existing SMTP addresses in
your source messaging system are also created in Exchange Online. Otherwise, you will lose messages
when you configure the DNS MX record after the migration.
You also need to verify that your existing messaging system can send messages to Exchange Online.
2.
Migrate the mailboxes.
Choose your preferred migration method, either with Microsoft tools or with third-party tools. You
can perform a staged migration or migrate everything at the same time. This depends on your
companys size, the existing messaging environment, and other factors.
3.
Switch the DNS MX record so that it points to Exchange Online.
After mailbox migration completes, you must change your companys DNS MX record so that it
points to Exchange Online. This causes all inbound message traffic to flow directly to Exchange
Online. Because of this, you should no longer see many messages in your local messaging system.
4.
Finalize the migration and remove old Mailbox servers.

Shut down everything in your on-premises messaging system. Check for the following:
Any inbound or outbound messages flowing through the system.
A-22
Any mailbox access after the time you switched over to Exchange Online.
After everything is shut down, you can remove your old mail servers from the data center and retire
them.
Exchange Online Management Tools
A-23
Exchange Online provides several tools to manage your organization. You can choose between Microsoft
Online Services Portal, the Exchange Control Panel, the Exchange Management Shell, and the Exchange
Management Console. Depending on your configuration, you can manage your Exchange Online users
using the same tools as you use to manage your Exchange on-premises users. The benefit of this type of
configuration is that you do not need to consider where your mailboxes are hosted.
If you decide to use simple coexistence, you can manage your Exchange Online users with the Microsoft
Online Services Portal or the Exchange Control Panel. In a rich coexistence environment the Exchange
Management Console and the Exchange Management Shell are also available.
Microsoft Online Services Portal
You can use the Microsoft Online Services portal to manage your Exchange Online mailboxes. You
perform tasks common across the Office 365 services within the portal, and you can follow links to the
Exchange Control Panel, where you can manage settings specific to Exchange Online.
Generally, you use the portal for the following tasks:
Provisioning new mailboxes and security groups.
Managing common user properties.
Creating and managing service requests.
Adding and managing SMTP domains.
Migrating mailboxes.
You can only perform the following tasks in the portal:
Password resets
Cross-premise permissions
Service subscriptions
A-24
License assignments

The Exchange Control Panel in Exchange Online is almost the same as the version available in your
Exchange Server 2010 SP1 on-premises installation. It includes new features such as managing Unified
Messaging dial plans.
In Exchange Online, the Exchange Control Panel is considered the central management platform for
creating and managing users, distribution groups, and contacts. You also can configure organization-wide
settings such as Unified Messaging IP gateways and Exchange ActiveSync access settings. The Exchange
Control Panel is organized into the following high-level categories:
Users and Groups. Mailboxes, distribution groups, external contacts, and email migration.
Roles. Administrator roles, user roles, and auditing.
Mail Control. Rules, journaling, e-discovery, and delivery reports.
Phone and Voice. Unified Messaging dialing plans, Unified Messaging gateways, Exchange ActiveSync
access, and Exchange ActiveSync device policy.
As with Exchange Server 2010, administrators can provide access to the Exchange Control Panel features
by using role based access control (RBAC).
Exchange Management Console
You can add your Exchange Online organization to your Exchange Management Console so that you can
view both on-premises and online configurations from one place. This feature was introduced with
Exchange Server 2010 SP1.
You can use the Exchange Management Shell with remote PowerShell to connect to Exchange Online, so
you can perform management tasks using cmdlets and scripts.
Exchange Online uses the same PowerShell cmdlets as Exchange Server 2010 SP1. However, some cmdlets
and parameters are disabled in the Exchange Management Shell because these features do not apply in
the data center environment. A list of available cmdlets can be found at
Lesson 3
Implementing Federated Delegation
A-25
Federated Delegation enables Exchange Server 2010 and Exchange Online users to share availability and
contact information with users in other Exchange organizations. Users can share information such as
free/busy data and calendar details. They can book meetings with a partner organizations users by using
exactly the same steps as booking meetings with users inside the organization.
Describe Federated Delegation.
Describe the components that are required for Federated Delegation.
Describe how Federated Delegation works for availability information access.
Explain how to configure a Federated Trust.
Explain how to configure organizational relationships and sharing policies.
A-26
What Is Federated Delegation?
Federated Delegation uses standard federation technologies to allow organizations to establish trusted
relationships with each other. To establish federation trust, organizations exchange certificates with public
keys, or with a trusted third party, and use those certificates to authenticate and secure all
communications between them. Exchange Server 2010 SP1 allows you to also use a self-signed certificate
for the federation trust.
In Exchange Server 2010, you use the Microsoft Federation Gateway to establish the federation. Microsoft
Federation Gateway is an identity service that runs over the Internet and works as a trust broker for
Federated Delegation. To enable Federated Delegation, the organization must register with the Microsoft
Federation Gateway, and then configure a federated delegation using an organizational relationship with
another organization that also registers with the Federation Gateway.
The Federation Gateway then acts as a hub for all connections that the organizations make to each other.
For example, in a Federated Delegation scenario, the Client Access servers in each organization should be
able to establish an authenticated and secure connection with each other to enable the exchange of
availability information or to enable calendar sharing. The Client Access servers use the federated trust
that you configure with the Federation Gateway to verify the other organizations Client Access servers
and to encrypt all traffic sent between the organizations.
Note The Federation Gateway only provides a broker service to establish the
communication between the organizations. The Federation Gateway does not authenticate
individual users or require any user accounts from either organization. Although the
Federation Gateway uses Windows Live as the authentication mechanism, it shares no user
accounts with Windows Live.
In a Federation Delegation scenario, each organization only needs to manage its trust relationship with
the Federation Gateway, and to manage only its user accounts. After the organization establishes the trust
A-27
relationship with the Federation Gateway, you can configure other trusted organizations with which you
want to share information, and the types of information that you want to share.
When you enable Federation Delegation, all communications between organizations are sent through the
organizations Exchange 2010 servers. This communication is transparent to the messaging clients. This
means that the feature works with any client that can connect to Exchange Server 2010, including Outlook
Web App, Microsoft Office Outlook 2007, and Outlook 2010.
Note Outlook 2007 requires GAL synchronization between Exchange organizations

because Outlook 2007 clients need to pick a recipient from the GAL. Refer to
http://go.microsoft.com/fwlink/?LinkId=213773 for more information.
A-28
Components Required for Federated Delegation
To set up federation, you must configure three major components in Exchange Server 2010.
Federation Trust
Federation trust establishes a trust with Microsoft Federation Gateway. The federation trust configures the
Microsoft Federation Gateway as a federation partner with the Exchange Server organization. This means
that Exchange Web Services on the Client Access servers can validate all Microsoft Federation Gateway
authentication requests. You establish the federation trust by submitting the organizations certificate to
Microsoft Federation Gateway and downloading the Microsoft Federation Gateway certificate.
Organization Identifier
The organization identifier defines which of the Exchange organizations authoritative accepted domains
are available for federation. If an organization supports multiple SMTP domains, you can include one or
all of the domain names in the organization identifier. Users can participate in Federated Delegation only
if they have email addresses in the domains that you configure with the organization identifier.
The first domain that you specify with the organization identifier is the Account namespace. Microsoft
Federation Gateway creates federated user identifiers within this account namespace when the Client
Access server requests a delegation token for an Exchange Server organization user. This process is
transparent to the Exchange Server organization.
Organization Relationships
An organization relationship allows you to establish a federated delegation with another federated
organization for the purpose of sharing availability (free/busy) information. Organization relationships are
one-to-one relationships established between two organizations. To configure an organization
relationship, you must establish a single federation trust with the Microsoft Federation Gateway and
configure the organization identifier.
When you create an organization relationship with an external organization, it allows users in the external
organization to access your users availability information, which allows them to schedule meetings easily
A-29
with your users. No replication of GAL information is required because Outlook 2010 and Outlook Web
App allow users to enter the SMTP address of an external recipient when scheduling meetings. For
Outlook 2007, you still need to configure GAL replication. For users in your organization to have similar
access to availability information as users in the external organization, the administrator in the external
organization must also create an organization relationship with your organization.
Sharing Relationships
You can use sharing policies to enable users to share calendar and contact information with users in
external federated organizations. After configuring the sharing relationship, a user can send a sharing
invitation to an external recipient to share his/her calendar or contact folder. Using sharing policies, you
control the domains with which your users share information, and the extent of sharing. You can also
disable a sharing policy for a user or a group of users to deny sharing for those users.
Sharing policies are assigned to mailbox users. A default sharing policy applies to all users, and it allows
you to share contacts, calendar, and availability information with all domains. After you create a
federation trust with the Microsoft Federation Gateway and configure the federated organization
identifier (OrgID), users can send sharing invitations to users in any external organization.
Note Although organization relationships and sharing policies allow sharing of availability
information with external users, they are intended for different scenarios. Organization
relationships are created to collaborate with external organizations. Sharing policies govern
what your users can share on an ad-hoc basis with users in external organizations, including
organizations with which an organization relationship does not exist.
A-30
How Federated Delegation Works for Availability Information Access
One of the options when configuring a sharing relationship is to enable users from one organization to
view availability information for another organizations users. The following steps describe the
communication flow when you configure this option, and a user in one organization invites another
organizations user to a meeting.
1.
A user in the Contoso.com organization invites a user in the Adatum.com organization to a meeting.
This meeting request is sent to the Exchange Web Service on the Client Access server at Contoso, Ltd.
2.
The Contoso Client Access server checks with a Contoso.com domain controller to verify that the user
has permission to utilize the sharing relationship to request availability information and that a sharing
relationship is configured with Adatum.com. If both verifications succeed, the Client Access server
continues with the next step.
3.
The Contoso Client Access server connects to the Microsoft Federation Gateway and requests a
security token for the Contoso, Ltd user. Because you configure Contoso.com in the organization
identifier, the Federation Gateway issues the token.
4.
The Contoso Client Access server sends a request for the availability information for the user to the
Adatum Client Access server. The Contoso Client Access server includes the security token with the
request.
5.
The Adatum Client Access server validates the security token and then checks with a domain
controller in the Adatum.com domain to verify that the organization has a sharing relationship with
Contoso.com.
6.
The Adatum Client Access server retrieves the users availability information from the users Mailbox
server.
7.
The Adatum Client Access server sends the availability information to the Contoso Client Access
server.
8.
The Contoso Client Access server provides the availability information to the Contoso, Ltd user.
Question: In your organization, what connectivity between the Microsoft Federation

Gateway and your partner organization do you need to consider?
A-31
A-32
Configuring a Federation Trust
Before you can configure a sharing relationship with another organization, both organizations must
configure a federation trust with the Microsoft Federation Gateway.
Prerequisites for Configuring a Federation Trust

Before configuring the federation trust, you must ensure that your organization meets the following
prerequisites:
Obtain a trusted certificate. Setting up a federation trust with the Microsoft Federation Gateway
requires a certificate from a public certificate authority (CA) that the Federation Gateway server trusts.
The certificate requires a private/public key pair that is both a client and server certificate, and
requires a Subject Key Identifier. This certificate must be deployed on all Exchange Server 2010 Client
Access servers. The associated name of the certificate is not relevant to federation, so you can reuse
an existing certificate on the Client Access server if the certificate is trusted.
Note Exchange Server 2010 SP1 also supports using self-signed certificates to configure a
federation trust. However, there are additional management tasks if you use self-signed
certificates because you have to renew them manually and then verify that your Exchange
server and your partners Exchange servers trust the new certificate.
Configure the authoritative domains. You must configure all SMTP domain names that you want to
use for Federated Delegation as authoritative accepted domains in Exchange Server.
Configure external DNS records. To enable Federated Delegation, you need to ensure that servers
from other organizations can resolve your servers names on the Internet. Additionally, you need to
configure DNS with a text (TXT) resource record that provides proof-of-ownership for your domain
name. The Federation Gateway uses the proof-of-ownership record to ensure that your servers are
A-33
authoritative for the domain name that you provide. To create this proof-of-ownership record, do the
following:
1.
2.
Obtain the application identifier that is created when you create a federation trust. You can
obtain this identifier by running the Get-FederationTrust Identity FederationTrustName | fl
ApplicationIdentifier cmdlet.
Create a new TXT record on the DNS server that is accessible from the Internet. The TXT record
should include the following information:
domainname IN TXT AppID=ApplicationIdentifier.
Establishing the Federation Trust with Microsoft Federation Gateway
You can set up and manage the federation trust by using the Exchange Management Console or the
Exchange Management Shell. On the machine where you run these tasks, you should deploy the
certificates that federation should use. The machine also needs to have Internet connectivity to reach
Microsoft Federation Gateway.
If you are using the Exchange Management Console, click Organization Configuration, and then click
New Federation Trust to start the New Federation Trust wizard. When you run the wizard, you must
configure a certificate that will validate the trust. When you use the Exchange Management Console to
create the federation trust, it receives the name Microsoft Federation Gateway automatically.
If you are using the Exchange Management Shell, run the New-FederationTrust Name TrustName Thumbprint <org-cert-thumbprint> cmdlet.
Note When you use the Exchange Management Console to configure the federation trust,
you can browse to locate a valid certificate. If you are using the Exchange Management Shell,
you can use the Get-ExchangeCertificate cmdlet to obtain the certificate thumbprint.
A-34
Configuring Organizational Relationships and Sharing Policies
After you create the federated trust, the next steps are to configure the organizational relationships and
sharing policies that will enable your organizations users to share information with other organizations.
Configuring Organizational Relationships
Organizational relationships define the external domains with which you want to share information, and
what types of information you will share.
To configure organizational relationships in the Exchange Management Console, click Organization
Management, and then click New Organizational Relationship. When configuring the organizational
relationship, you can configure the following:
Name. Use a descriptive name.
Enable or disable the organizational relationship.
Enable the sharing of free/busy information. If you enable this option, you can configure the
following levels of free/busy access:
No calendar sharing.
Calendar sharing with free/busy information only.
Calendar sharing with free/busy information, plus subject and location.
Specify a security distribution group. If you specify this option, the free/busy information only for
users in the group is accessible through the organizational relationship.
Configure the information for the external organization. You can configure the Exchange Server to
discover the external organizations configuration information automatically. When you do this, the
Exchange server contacts the Microsoft Federation Gateway to locate this information. Alternatively,
you can enter the external organizations information manually, including the domain names,
application Uniform Resource Identifier (URI), and Autodiscover endpoint.
Configuring Sharing Policies
A-35
Sharing policies define which users in your organization can share information with other organizations,
and what types of information those users can share.
The Default Sharing Policy is created by default when you install Exchange Server 2010. This policy
enables sharing with all domains, but enables only calendar sharing with free/busy information. The policy
is not assigned to mailboxes. You can modify all settings for the Default Sharing Policy.
If you want to enable users to participate in federated sharing, you can add the mailboxes to the Default
Sharing Policy or create a new sharing policy. When you create a new sharing policy, you can configure:
The domain name for the external domain.
The sharing actions that are permitted under the policy. Options include:
Calendar sharing with free/busy information only.
Calendar sharing with free/busy, subject and location.
Calendar sharing with free/busy, subject, location, and body.
Contacts sharing.
Calendar sharing with free/busy information only and contacts sharing.
Calendar sharing with free/busy, subject and location, and contacts sharing.
Calendar sharing with free/busy, subject, location and body, and contacts sharing.
The mailboxes to which the sharing policy will be assigned.

Question: In your organization, what factors should you consider when defining your
sharing policy?
A-36
Module 1: Introducing Microsoft Exchange Server 2010
Lab: Planning the Hardware Requirements

for Exchange Server 2010
Exercise: Identifying the Hardware Requirements
Task 1: Review the Exchange Server 2010 design and requirements
Review the information available in the student handbook, and make a note of the issues that can
affect the hardware design.
Task 2: Use the Mailbox Role Calculator to identify the hardware requirements
1.
On NYC-CL1, open the C:\Labfiles\E2010MailboxRoleCalculator1.2.xlsx spreadsheet.
2.
Enter the following data on the Input tab:
Exchange Environment Configuration
Server Multi-Role Configuration: No
High Availability Deployment: Yes
Number of Mailbox Servers hosting Active Mailboxes / DAG: 4
Number of Database Availability Groups: 1
Server Configuration
Exchange Data Configuration
Data Overhead Factor: 20%
Mailbox Moves / Week Percentage: 1%
Dedicated Maintenance / Restore LUN: Yes
LUN Free Space Percentage: 20%
Exchange I/O Configuration
I/O Overhead Factor: 20%
Additional I/O Requirement / Server: 0
Site Resilience Configuration
Site Resilient Deployment : Yes
Database Configuration
Mailbox Servers: Use the data from Task 1
Maximum Database Size Configuration: Default
Total Number of Tier-1 User Mailboxes / Environment: 1,000
Projected Mailbox Number Growth Percentage: Use the data from Task 1
L1-1
L1-2
3.
Total Number of Tier 2 User Mailboxes: Use the data from Task 1.
Primary Datacenter Server Disk Configuration
Database + Log: Use the data from Task 1
Restore LUN: Use the data from Task 1
Browse the Role Requirements, Activation Scenarios, LUN Requirements, Backup Requirements,
and other tabs to view the results, based on the data that you entered.
Results: After this exercise, you should have determined the hardware configuration for the Mailbox
servers, based on the available data.
When you complete the lab, revert the virtual machines to their initial state and start the virtual machines
required for the next module. To do this, complete the following steps:
1.
2.
Right-click 10165A-NYC-CL1-B in the Virtual Machines list, and then click Revert.
3.
4.
Right-click 10165A-NYC-DC1-A, and then in the Actions pane, click Start. Connect to the virtual
machine
Important Start the 10165A-NYC-DC1-A virtual machine first, and ensure that it is fully
L1-3
5.
Wait for 10165A-NYC-DC1-A to start, and then start 10165A-NYC-EX03-A. Connect to the virtual
machine.
6.
Wait for 10165A-NYC-EX03-A to start, and then start 10165A-NYC-EX10-A. Connect to the virtual
machine.
7.
Wait for 10165A-NYC-EX10-A to start, and then start 10165A-NYC-CL1-A. Connect to the virtual
machine.
L1-4
Module 2: Deploying Microsoft Exchange Server 2010
L2-1
Exercise 1: Evaluating the Requirements for an Exchange Server Installation

Task 1: Evaluate the Active Directory requirements
1.
On NYC-DC1-A, click Start, right-click Computer, and then click Properties.
2.
In the System window, in the Windows edition section, verify that the domain controller operating
system is compatible with the Microsoft Exchange Server 2010 requirements. Operating system
should be Windows Server 2008 R2 x64.
3.
Close the System window.
4.
Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
5.
Right-click Contoso.com, and then click Properties.
6.
In the Contoso.com Properties dialog box, verify that the domain and forest functional levels are
compatible with the Exchange Server 2010 requirements. Domain and forest functional level should
be Windows Server 2008.
7.
Click OK, and then close Active Directory Users and Computers.
8.
Click Start, in the Search box, type adsiedit.msc, and then press Enter.
9.
Right-click ADSI Edit, and then click Connect to.
10. In the Connection Settings dialog box, in the Connection Point section, in the Select a well known
Naming Context list, click Configuration, and then click OK.
11. In the left pane, expand Configuration [NYC-DC1.Contoso.com], and then click
CN=Configuration,DC=Contoso,DC=com.
12. Expand CN=Services, and verify that the CN=Microsoft Exchange is created, because an older
version of Exchange Server is already installed.
13. Close ADSI Edit.
Task 2: Evaluate the DNS requirements

1.
On NYC-EX10-A, click Start, in the Search box, type cmd, and then press Enter.
2.
At the command prompt, type IPConfig /all, and then press Enter. Verify that the DNS server IP
address for the Local Area Connection is 10.10.0.10.
3.
At the command prompt, type Ping NYC-DC1.contoso.com. Verify that you have network
connectivity with the domain controller.
4.
At the command prompt, type Nslookup, and then press Enter.
5.
At the command prompt, type set type=all, and then press Enter.
6.
At the command prompt, type _ldap._tcp.dc._msdcs.Contoso.com, and then press Enter. Verify that
a service (SRV) resource record was returned.
7.
Close the command prompt.
L2-2
Task 3: Evaluate the Exchange Server 2003 prerequisites

1.
On NYC-EX10-A, click Start, click Computer, browse to C:\Labfiles, and then double-click
ExPDA.msi.
2.
In the Security Warning window, click Run.
3.
On the Microsoft Exchange Server Pre-Deployment Analyzer Tool Installation Wizard page, click
Next.
4.
Click I agree on End User License Agreement page, and then click Next.
5.
On the Installation Directory page, click Next
6.
On the Data Directory page, click Next.
7.
Click Finish. The Microsoft Exchange Pre-deployment Analyzer Wizard opens.
8.
On the Microsoft Exchange Pre-deployment Analyzer page, click Do not check for updates on
startup, click I dont want to join the program at this time, and then click Go to the Welcome
Screen.
9.
Select the Select options for a new scan option.
10. On the Connect to Active Directory page, ensure that NYC-DC1 is listed as an Active Directory
Domain Services (AD DS) server, and then click Connect to the Active Directory server.
11. On the Start a New Scan page, in the Enter an identifying label for this scan field, type Ex10 scan,
and then click Start scanning.
12. After the scan completes, click View a report of this Best Practices scan.
13. On the View Report page, review items to ensure that nothing critical appears (no items with red
mark).
14. Click Link state suppression is not enabled, and note the explanation.
Task 4: Evaluate the server requirements

1.
On NYC-EX10-A, click Start, point to Administrative Tools, and then click Server Manager.
2.
In the left pane, click Features. Verify that no features are installed, except Microsoft .NET Framework
3.5.1.
3.
In the left pane, click Roles. Verify that the only Windows Server 2008 role installed is the Web
Services (IIS) role.
4.
Click Start, and then click Control Panel.
5.
In Control Panel, click Programs.
6.
In the Programs window, click Programs and Features. Verify that Microsoft Filter Pack 2.0 is
installed.
7.
Close the Programs and Features window.
8.
Click Start, click All Programs, click Accessories, click Windows PowerShell, and then click
Windows PowerShell.
9.
L2-3
At the PS prompt, type help about_windows_powershell, and then press Enter. Verify that
about_Windows_PowerShell_2.0 displays. It is installed with the Windows PowerShell v2 commandline interface.
10. Close Windows PowerShell.
Results: After this exercise, you should have evaluated requirements for Exchange Server 2010 installation
in the existing Active Directory environment.
L2-4
Exercise 2: Preparing for an Exchange Server 2010 SP1 Installation
Task 1: Prepare Exchange Server 2003 for the Exchange Server 2010 SP1 installation
1.
On NYC-EX03-A, open a registry editor such as Regedit.exe or Regedt32.exe.
2.
Navigate to HKLM\System\CurrentControlSet\Services\RESvc\Parameters.
3.
Right-click Parameters, select New | DWORD Value, and then name the new DWORD value,
SuppressStateChanges.
4.
Double-click SuppressStateChanges.
5.
Set Base to Decimal.
6.
In the Value data field, enter 1, and then click OK.
7.
Close the registry editor, and then restart the Simple Mail Transfer Protocol (SMTP), the Microsoft
Exchange Routing Engine, and the Microsoft Exchange MTA Stacks services for the change to
take effect.
Note If time permits, you can re-run Microsoft Exchange Pre-Deployment Analyzer at this
point to ensure that there is no warning about link state suppression.
Task 2: Prepare AD DS for the Exchange Server 2010 installation
This task requires that the Exchange Server 2010 .iso file be attached to the NYC-DC1-A virtual machine as
a DVD drive. If the .iso file is not attached, complete the following steps to attach it:
1.
In the 10165A-NYC-DC1-A on localhost Virtual Machine Connection window, on the File menu,
click Settings.
2.
Click DVD Drive, and then click Image File.
3.
Click Browse, browse to C:\Program Files\Microsoft Learning\10165\Drives, click

Exchange2010SP1.iso, click Open, and then click OK. When prompted, close the AutoPlay dialog
box.
4.
On NYC-DC1-A, open a command prompt.
5.
Type D:\setup.com /PrepareAD /OrganizationName:ContosoOrg, and then press Enter.
6.
When the task completes, close the Command Prompt window.
Exercise 3: Installing Exchange Server 2010 SP1
L2-5
Task 1: Install the Exchange Management Console on a Windows 7 client computer

1.

Learning\10165\Drives\Exchange2010SP1.iso as the DVD drive for NYC-CL1-A.
2.
On NYC-CL1-A, click Start, click Run, type D:\setup.exe, and then click OK.
Note Steps 1 and 2 are unavailable, because they are already complete. If the components
were not installed, Exchange Server provides links to download the necessary software.
3.
Click Step 3: Choose Exchange language option.
4.
Click Install only languages from the DVD.
5.
Click Step 4: Install Microsoft Exchange.
6.
Click Next to begin the Exchange Server 2010 Setup.
7.
On the License Agreement page, click I accept the terms in the license agreement, and then click
Next.
8.
On the Error Reporting page, click No to disable error reporting, and then click Next. You are
disabling error reporting, because your virtual machine does not have access to the Internet.
9.
On the Installation Type page, click Custom Exchange Server Installation, and then click Next.
10. On the Server Role Selection page, click Management Tools, and then click Next.
11. Wait until the Readiness checks are performed, and then click Install.
12. Clear the Finalize this installation using the Exchange Management Console check box, click
Finish, and then click Close.
13. At the Confirm Exit prompt, click Yes.
Task 2: Install Exchange Server 2010 SP1 with the typical configuration
1.
In the 10165A-NYC-EX10-A on localhost Virtual Machine Connection window, on the File menu,
click Settings.
2.
Click DVD Drive, and then click Image File.
3.
Click Browse, browse to C:\Program Files\Microsoft Learning\10165\Drives, click

Exchange2010SP1.iso, click Open, and then click OK. When prompted, close the AutoPlay dialog
box,.
4.
On NYC-EX10-A, click Start, click Run, type D:\setup.exe, and then click OK.
Note Steps 1 and 2 are unavailable because they are already complete. If the components
were not installed, Exchange Server 2010 provides links to download the necessary software.
5.
6.
7.
L2-6
8.
Click Next to begin Exchange Server 2010 Setup.
9.
Next.
10. On the Error Reporting page, click No to disable error reporting, and then click Next. You are
disabling error reporting because your virtual machine does not have access to the Internet.
11. On the Installation Type page, click Typical Exchange Server Installation, select the Automatically
install Windows Server roles and features required for Exchange Server check box, and then
click Next.
12. On the Configure Client Access Server external domain page, click Next.
13. On the Mail Flow Settings page, click Browse.
14. Select NYC-EX03, click OK, and then click Next.
15. On the Customer Experience Improvement Program page, click I dont want to join the program at
this time, and then click Next. A readiness check occurs to ensure that Exchange Server 2010 is ready
to install on the server. This check takes several minutes to complete.
16. Click Install. The installation takes approximately 10-15 minutes to complete.
17. On the Completion page, clear the Finalize this installation using the Exchange Management
Console check box, and then click Finish.
18. Click OK, and the click Close. Click Yes at the Confirm Exit prompt. You are not obtaining the critical
updates for Exchange Server 2010, because the virtual machine does not have Internet connectivity.
19. Restart the NYC-EX10-A server.
Results: After this exercise, you should have installed the Exchange Management Console and Exchange
Server 2010.
L2-7
Lab B: Verifying the Exchange Server 2010

SP1 Installation
Exercise 1: Verifying an Exchange Server 2010 Installation
Task 1: View the Exchange Server 2010 services
1.
On NYC-EX10-A, click Start, point to Administrative Tools, and then click Services.
2.
Scroll down the list of services, click the Microsoft Exchange Active Directory Topology service,
and then review the service description.
3.
Review the status of the remaining Exchange Server 2010 services. Ensure that all services that are set
for automatic startup are running.
4.
Close Services.
Task 2: View the Exchange Server 2010 folders

1.
On NYC-EX10-A, click Start, and then click Computer.
2.
Browse to C:\Program Files\Microsoft\Exchange Server\V14. Verify that the ClientAccess, Mailbox,

and TransportRoles folders display. These roles installed as part of the typical setup.
3.
Open TransportRoles. The Hub Transport server role uses these folders.
4.
Close the Windows Explorer window.
Task 3: View the configuration partition of AD DS for Exchange Server 2010 objects
and values
1.
On NYC-DC1-A, click Start, in the Search box, type adsiedit.msc, and then press Enter.
2.
3.
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.
4.
In the left pane, expand Configuration[NYC-DC1.Contoso.com], and then expand

CN=Configuration,DC=Contoso,DC=com.
5.
Expand CN=Services, expand CN=Microsoft Exchange, and then expand CN=ContosoOrg.
6.
Ensure that objects that belong to both Exchange Server 2003 and Exchange Server 2010 appear in
the list. For example, expand Administrative Groups to see that both Exchange Administrative
Group (FYDIBOHF23SPDLT) and First Administrative Group are displayed.
7.
Expand CN=RBAC, and then click CN=Roles to view the Exchange Server 2010 role objects.
8.
Click CN=Role Assignments to view various role assignments that you can assign through role based
access control (RBAC).
Task 4: Create a new user, send a test message, and review the delivery report
1.
On NYC-EX10-A, click Start, point to All Programs, click Microsoft Exchange Server 2010, and
2.
Click OK to acknowledge that the server is unlicensed.
L2-8
3.
In the left pane, expand Microsoft Exchange On-Premises (nyc-ex10.contoso.com). Wait for the
initialization to finish, expand Recipient Configuration, and then click Mailbox. Review the
mailboxes in the central pane to ensure that all mailboxes have Recipient Type Details with value
Legacy Mailbox.
4.
In the Actions pane, click New Mailbox.
5.
On the Introduction page, click Next.
6.
On the User Type page, click Next.
7.
On the User Information page, in the First name box, type TestUser.
8.
In the User logon name box, type TestUser.
9.
In the Password and Confirm password boxes, type Pa$$w0rd.
10. Click Next.

11. On the Mailbox Settings page, in the Alias box, type TestUser, and then click Next.
12. On the Archive Settings page, click Next.
13. Click New, and then click Finish.
14. Ensure that mailbox TestUser appears in the Mailbox list, and that it has Recipient Type Details with
value User Mailbox, because it is located on Exchange Server 2010.
15. Click Start, point to All Programs, and then click Internet Explorer.
16. In the Address bar, type https://NYC-EX10/owa, and then press Enter.
17. Click Continue to this website (not recommended).
18. Log on as Contoso\TestUser, with the password, Pa$$w0rd.
19. Click OK, and then click New.
20. Click Continue to this website (not recommended).
21. In the To box, type TestUser.
22. In the Subject box, type Test Message, and then click Send. Wait a few moments for the message to
arrive in a mailbox.
23. In the left pane, click Sent Items.
24. Expand the test message conversation node, right-click the message that you just sent, and then click
Open Delivery Report.
25. Click Continue to this website (not recommended), and then review the report that appears in the
window. It may take several minutes for the report to display.
26. Click Close.
Task 5: Run the ExBPA tool

1.
On NYC-EX10-A, in the Exchange Management Console, in the left pane, click Toolbox.
2.
In the center pane, double-click Best Practices Analyzer.
3.
Click Do not check for updates on startup, because your virtual machine does not have Internet
access.
L2-9
4.
Click I dont want to join the program at this time, because your virtual machine does not have
Internet access.
5.
Click Go to the Welcome screen.
6.
Click Select options for a new scan.
7.
Click Connect to the Active Directory server.
8.
In the Enter an identifying label from this scan box, type Post-Installation Test.
9.
Deselect the First Administrative Group and NYC-EX03 options.
10. Review the options, and then click Start scanning.

11. When the scan completes, click the View a report of this Best Practices scan link.
12. On the Critical Issues tab, click Offline address book replica not found. This presents you with
options to either get information about how to fix the problem, or hide the message.
13. Click Tell me more about his issue and how to resolve it. This opens the Microsoft Exchange
Server Best Practices Analyzer (ExBPA) Help, and gives specific information about the warning, and
how to resolve the issue.
14. Close Exchange Server Best Practices Analyzer Help.
15. Close the Exchange Server Best Practices Analyzer Tool.
Results: After this exercise, you should have verified the Exchange Server 2010 installation.
L2-10
Exercise 2: Verifying Exchange Server Version Interoperability

Task 1: Send a test message between Exchange Server versions
1.
On NYC-CL1, start Internet Explorer, type https://nyc-ex10.contoso.com/owa, and then press

Enter.
2.
Click Continue to this web site (not recommended).
3.
On the Outlook Web App page, log on as CONTOSO\TestUser, with the password, Pa$$w0rd.
4.
Click New.
5.
In the New Message window, in the To field, type Candy Spoon, in the Subject field, type Test email from E2010, type some text in the email body, and then click Send.
6.
Switch to NYC-EX03-A, start Internet Explorer, and then type http://nyc-ex03/exchange/candy.

to open Microsoft Outlook Web Access.
7.
In the Connect to nyc-ex03 window, in the User name field, type CONTOSO\Candy, in the
Password field, type Pa$$w0rd, and then click OK. Ensure that Candy received the message from
TestUser. Click the email, and then click Reply.
8.
Type any text in the message field, and then click Send.
9.
Switch to NYC-CL1 and restore the Outlook Web App window.
10. Ensure that you received an email from Candy Spoon.

11. On both computers, log off from both Outlook Web Access and Outlook Web App.
Task 2: Test a mailbox move between Exchange Server versions

1.
On NYC-EX10, click Start, and then select Exchange Management Console.
2.
Expand Microsoft Exchange On-Premises (nyc-ex10.contoso.com), expand Recipient

3.
Right-click the Candy Spoon mailbox object, and then click New Local Move Request.
4.
In the New Local Move Request window, click Browse.
5.
On NYC-EX10, click Mailbox Database, and then click OK.
6.
Click Next two times, and then click New.
7.
Ensure the mailbox move has completed successfully, and then click Finish.
8.
On NYC-CL1, start Internet Explorer, type https://nyc-ex10.contoso.com/owa, and then press

Enter.
9.
Click Continue to this web site (not recommended).
10. On the Outlook Web App page, log on as CONTOSO\Candy, with the password, Pa$$w0rd.
11. Ensure that Outlook Web App for Candy Spoon appears.
Results: After this exercise, you should have verified Exchange Server version interoperability.
Module 3: Configuring Mailbox Servers

Exercise 1: Configuring Mailbox Databases
Task 1: Create a new database for the Executives mailboxes
L3-1
1.
On NYC-EX10-B, click Start, click All Programs, click Microsoft Exchange Server 2010, and then
click Exchange Management Console.
2.
In the console tree, expand Microsoft Exchange, expand Microsoft Exchange On-Premises,
expand Organization Configuration, and then click Mailbox.
3.
In the Content pane, select the Database Management tab.
4.
In the Actions pane, click New Mailbox Database.
5.
In the New Mailbox Database Wizard, and in the Mailbox database name box, type Executives, and
then click Browse.
6.
In the Select Mailbox Server dialog box, select NYC-EX10, and then click OK.
7.
Click Next.
8.
In the Database file path box, type C:\Mailbox\Executives\Executives.edb.
9.
In the Log folder path box type C:\Mailbox\Executives.
10. Click Next, click New, and then click Finish.
Task 2: Configure the Executives mailbox database with appropriate limits

1.
In the Content pane, select the Database Management tab, right-click the Executives database,
and then click Properties.
2.
Click the Limits tab.
3.
In the Issue warning at (MB) box, type 850.
4.
Clear the Prohibit send at (MB) check box.
5.
In the Prohibit send and receive at (MB) box, type 1024, and then click OK.
Task 3: Move the existing Accounting database to a new location

1.
In the Content pane, select the Database Management tab, and then select the Accounting
database.
2.
In the Actions pane, click Move Database Path.
3.
In the Move Database Path Wizard, in the Database file path box, type
C:\Mailbox\Accounting\Accounting.edb.
4.
In the Log folder path box, type C:\Mailbox\Accounting\.
5.
Click Move, click Yes, and then click Finish.
6.
Close the Exchange Management Console.
L3-2
Results: After this exercise, you should have created and set the specified limits for a new Executives
database and moved the existing Accounting database to a new location.
Exercise 2: Configuring Public Folders

Task 1: Verify Research public folder statistics
L3-3
1.
On NYC-EX03-B, click Start, click All Programs, click Microsoft Exchange, and then click System
Manager.
2.
In System Manager, expand Administrative Groups, expand First Administrative Group, expand
Folders, expand Public Folders, and then click the Research public folder.
3.
On right pane of the console, click Status.
4.
On the Status tab, record the Items and Size of the items in the public folder.
5.
Leave the System Manager Console running.
Task 2: Create a public folder database on NYC-EX11

1.
On NYC-EX11, open the Exchange Management Console, browse to Organization Configuration,

2.
In the Content pane, select the Database Management tab.
3.
In the Actions pane, click New Public Folder Database.
4.
On the New Public Folder Database page, in the Public Folder database name box, type PF-NYCEX11, and then click Browse.
5.
In the Select Mailbox Server dialog box, select NYC-EX11, and then click OK.
6.
Click Next.
7.
In Database file path box, type C:\Mailbox\PF-NYC-EX11\PF-NYC-EX11.edb.
8.
In the Log folder path box, type C:\Mailbox\PF-NYC-EX11.
9.
Click Next, click New, and then click Finish.
Task 3: Add a replica of the Research public folder on NYC-EX11

1.
On NYC-EX03-B, right-click the Research public folder, and then click Properties.
2.
Click the Replication tab, and then click Add.
3.
In the Select a Public Store window, select the PF-NYC-EX11 database, and then click OK.
4.
In the Research Properties window, click OK.
Note It can take up to 15 minutes for replication to complete.
Task 4: Replicate system folders from NYC-EX03 to NYC-EX11

1.
On NYC-EX03-B, right-click Public Folders, and then click View System Folders.
2.
Expand Public Folders, and then expand OFFLINE ADDRESS BOOK.
3.
Right-click the /o=ContosoOrg/cn=addrlists/cn=oabs/cn=Default Offline Address List public

folder, and then click Properties.
4.
Click the Replication tab, and then click Add.
5.
In the Select a Public Store window, select the PF-NYC-EX11 database, and then click OK.
L3-4
6.
Click OK to close the /o=ContosoOrg/cn=addrlists/cn=oabs/cn=Default Offline Address List

Properties window.
7.
Perform steps 3-6 for EX:/o=ContosoOrg/ou=First Administrative Group.
8.
In Public Folders, expand SCHEDULE+ FREE BUSY.
9.
Perform steps 3-6 for EX:/o=ContosoOrg/ou=First Administrative Group.
Task 5: Verify replication between NYC-EX03 and NYC-EX11
Wait for replication to complete, and then ensure that the replica folders are synchronized with the
source folders. To do so, follow these steps:
1.
2.
On NYC-EX03, in the Exchange System Manager, right-click the public folder that you want to
verify, and then click Properties.
Click the Replication tab on each of the replicated folders, and then click Details.
Note When replication has completed, the Replication Status column indicates In Sync.
3.
Verify that the number and size of items in the Research public folder on NYC-EX11 match the
numbers you recorded from NYC-EX03-B.
Results: After this exercise, you should have created a new public folder database on NYC-EX11, and
added replicas for each public folder, including system folders.
Module 4: Managing Recipient Objects
L4-1

Exercise 1: Managing Recipients
Task 1: Move mailboxes from Exchange Server 2003 to Exchange Server 2010
1.
On NYC-EX10, click Start, click All Programs, click Microsoft Exchange Server 2010, and then click
2.
3.
In the results pane, click the Recipient Type Details column to sort the mailboxes by recipient type
criteria.
4.
Note that user mailboxes located on NYC-EX03 display as Legacy Mailbox.
5.
In the results pane, click Bobby Moore, and then in Actions pane, click New Local Move Request.
6.
In the New Local Move Request wizard, click Browse.
7.
Click Mailbox Database 1, and then click OK.
8.
Click Next.
9.
Verify that Skip the mailbox is selected, and then click Next.
Note If you receive an error message, ensure that all Exchange Server services on NYCEX03 and NYC-EX10 that are configured to start automatically are started, and try moving
the mailbox again.
11. In the console tree, click Move Request to verify the move request is complete.
Task 2: Create and configure a mailbox called Adventure Works Questions

1.
2.
3.
4.
Choose User Mailbox, and then click Next.
5.
Choose New user, and then click Next.
6.
Fill out the following information, and then click Next:
Name: Adventure Works Questions
User logon name (User Principal Name): AdventureWksQ
L4-2
Password: Pa$$w0rd
Confirm password: Pa$$w0rd
7.
On the Mailbox Settings page, type AdventureWksQ as the Alias, select the Specify the mailbox
database rather than using a database automatically selected check box, and then click Browse.
8.
Click Mailbox Database 1, click OK, and then click Next.
9.
Click Next again, click New, and then click Finish.
10. In the details pane, right-click Adventure Works Questions, and then click Manage Full Access
Permission.
11. In the Manage Full Access Permission wizard, click Add.
12. In the Select User or Group dialog box, select George Schaller, and then click OK.
13. Click Manage and then click Finish.
Task 3: Create a moderated recipient account for the company president George
Schaller, and designate a moderator role to the company presidents administrative
assistant, Parna Khot
1.
2.
In the Exchange Management Shell, type following cmdlet, and then press Enter.
Set-Mailbox Identity George ModerationEnabled $True ModeratedBy Parna
3.
To verify whether the cmdlet was successful, in the Exchange Management Shell, type following
cmdlet, and then press Enter.
Get-Mailbox Identity George | Ft Name, ModeratedBy
4.
Verify that the output of this cmdlet displays George Schaller under Name column, and
{Contoso.com/Accounting/Parna Khot} under ModeratedBy column.
Task 4: Create a resource mailbox, and configure auto-accept settings for the
Adventure Works Project Room
1.
In the console tree, under Recipient Configuration, click Mailbox.
2.
3.
In the New Mailbox Wizard, select Room Mailbox, and then click Next.
4.
Verify that New user is selected, and then click Next.
5.
Name: ProjectRoom
User logon name (User Principal Name): ProjectRoom
6.
In the Mailbox Settings page, type ProjectRoom as the Alias, select the Specify the mailbox
database rather than using a database automatically selected check box, and then click Browse.
7.
Click Mailbox Database 1, click OK, and then click Next.
8.
Click New, and then click Finish.
9.
In the results pane, click ProjectRoom, and in the Actions pane, click Properties.
10. Click the Resource General tab.

11. Select the Enable the Resource Booking Attendant check box, and then click OK.
Note If you do not enable this option, the resource will not process meeting requests,
even if you configure other settings.
L4-3
Task 5: Create a moderated distribution list for the Adventure Works Project, and
designate an administrator
1.
In the console tree, under Recipient Configuration, click Distribution Group.
2.
In the Actions pane, click New Distribution Group.
3.
Verify that New group is selected, and then click Next.
4.
Under Group Type, verify that Distribution is selected.
5.
Name: Adventure Works Project
Alias: AdventureWorksProject
6.
7.
In the work pane, select the Adventure Works Project group.
8.
In the Actions pane, click Properties.
9.
Click the Members tab.
10. Click Add, select the following users by holding down the CTRL key, and then click OK:
George Schaller
Ian Palangio
Wei Yu
Paul West
11. Click the Mail Flow Settings tab.

12. Select Message Moderation, and then click Properties.
13. Select the Messages sent to this group have to be approved by a moderator check box.
14. In the Specify group moderators section, click Add.
15. Select George Schaller, and then click OK.
16. Click OK two more times.
Task 6: Administratively set an Out of Office auto-reply for a user by using Exchange
Control Panel
1.
L4-4
2.
Type https:// NYC-EX10.Contoso.com/ecp in the Windows Internet Explorer address bar and
then press Enter.
3.
Log on as Contoso\Administrator, with the password, Pa$$w0rd.
4.
On the main page, on the upper-left side, under Mail>Options: click Manage My Organization,
and then under Select what to manage, click Another User.
5.
In the Select Mailbox window, type George and then click the search button.
6.
In the Select Mailbox window, click on George Schaller and then click OK.
7.
On the main page, under Shortcuts to other things you can do, click Tell people youre on
vacation.
8.
Under Automatic Replies select the option button next to Send automatic replies.
9.
On the bottom of the main page, click Save.
10. Close Internet Explorer.
Task 7: Configure and manage public distribution groups by using Exchange Control
Panel
1.
2.
Type https://NYC-EX10.contoso.com/ecp in the Internet Explorer address bar and then press Enter.
3.
Log on to Exchange Control Panel as Contoso\Administrator, with the password, Pa$$w0rd.
4.
Click Distribution Groups.
5.
Under Distribution Groups, click New.
6.
In the New Group window, in the Display Name box, type Sales.
7.
Type Sales as the Alias.
8.
Type Sales Department as the Description.
9.
Expand the Membership section, and then click Add.
10. In the Select Members window, double-click the following mailboxes, and then click OK:
Manoj Syamala
Rohinton Wadia
Paul West
11. Expand Membership Approval.

12. Click Owner Approval, and then click Save.
Note This ensures that the group owner approves all requests that are added to the
group.
13. Close the Exchange Control Panel.
14. Click Start, click All Programs, and then click Internet Explorer.
15. Type https://NYC-EX10.contoso.com/ecp in the Internet Explorer address bar.
16. Log on to Exchange Control Panel as Contoso\Wei, with the password, Pa$$w0rd.
17. In the left pane, select Groups.
18. In the Public Groups I Belong to section, click Join.
19. In the All Groups window, select Sales, and then click Join.
20. Click Close, and then close the Exchange Control Panel.
21. Click Start, click All Programs, and then click Internet Explorer.
L4-5
22. Type https://NYC-EX10.contoso.com/owa in the Internet Explorer address bar and then press
Enter.
23. Log on to Outlook Web App as Contoso\Administrator, with the password, Pa$$w0rd.
24. Double-click the Request to Join Distribution Group message in the Inbox.
25. In the Request to Join Distribution Group message pane, click Approve.
26. Close Outlook Web App.
Task 8: Upgrade distribution groups whose aliases contain spaces

1.
On NYC-EX10, if necessary, open the Exchange Management Console.
2.
and then click Distribution Groups.
3.
Read the warning message which is displayed because All Company is a distribution group created in
Exchange Server 2003 whose alias contains a space, and then click OK.
4.
In the All Company Properties window, click Apply, read the error message, and then click OK.
Results: After this exercise, you should have used the following Exchange Server 2010 management tools:
Exchange Management Console, Exchange Management Shell, and Exchange Control Panel. Using these
tools, you should have moved mailboxes from Exchange Server 2003 to Exchange Server 2010, and you
should have created the following: a mailbox on Exchange Server 2010, a resource mailbox, a moderated
distribution group, and a moderated recipient account. Using the Exchange Control Panel, you should
also have set Out of Office replies, and established public distribution groups. You also should have edited
a distribution group created in Exchange Server 2003 and upgraded the distribution group to Exchange
Server 2010.
L4-6
Exercise 2: Configuring Email Address Policies and Address Lists

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

2.
In the Actions pane, click New E-mail Address Policy.
3.
In the New E-Mail Address Policy wizard, type Adventure Works as the policy name.
4.
Verify that the All recipient types is selected, and then click Next.
5.
Under Step 1 select the Recipient is in a Company check box.
6.
Under Step 2, click specified.
7.
In the Specify Company dialog box, type Adventure Works, click Add, and then click OK.
8.
In the New E-Mail Address Policy dialog box, click Next, and then click Add
9.
In the SMTP E-mail Address dialog box, click First name.last name (john.smith).
10. Click Select the accepted domain for the e-mail address, click Browse, click Adventureworks.com, and then click OK.
11. Click OK, and then click Next.
12. Verify Immediately is selected, and then click Next.
Task 2: Verify that addresses are applied correctly

1.
In the console tree, under Recipient Configuration, click Mailbox.
2.
In the results pane, double-click George Schaller.
3.
In the Properties dialog box for George Schaller, click the E-Mail Addresses tab, and view the
current email addresses that are assigned.
4.
Click the Organization tab.
5.
Type Adventure Works for the Company, and then click Apply.
6.
Click the E-Mail Addresses tab, view the current email addresses that are assigned, and then click
OK. Microsoft Exchange should have assigned the new adventureworks.com email address when
the company change was made.
Task 3: Upgrade the email address policy from Exchange Server 2003 to Exchange
Server 2010
1.
2.
Run following cmdlet. Press Enter at the confirmation prompt:
Set-EmailAddressPolicy "Default Policy" -IncludedRecipients AllRecipients
3.
After the command has completed, ensure that you can now edit the Default Policy email address
policy using Exchange Management Console.
L4-7
Task 4: Upgrade the default address lists from Exchange Server 2003 to Exchange
Server 2010
1.
2.
Run following cmdlets. Press Enter at each confirmation prompt:
Set-AddressList "All Users" -IncludedRecipients MailboxUsers

Set-AddressList "All Groups" -IncludedRecipients MailGroups
Set-AddressList "All Contacts" -IncludedRecipients MailContacts
Set-GlobalAddressList "Default Global Address List" -RecipientFilter {(Alias -ne $null and (ObjectClass -eq 'user' -or ObjectClass -eq 'contact' -or ObjectClass -eq
'msExchSystemMailbox' -or ObjectClass -eq 'msExchDynamicDistributionList' -or
ObjectClass -eq 'group' -or ObjectClass -eq 'publicFolder'))}
3.
After the command completes, ensure that you can now edit the address lists by using Exchange
Management Console.
Important After you complete the upgrade process, you will not be able to edit either
email address policies or address lists by using Exchange System Manager in Exchange Server
2003.
4.
On NYC-EX10, in Exchange Management Console, under Organization Configuration, click

Mailbox.
5.
In the results pane, click the Address lists tab.
6.
In the Actions pane, click New Address List.
7.
In the Name box, type Companies, and then click Next.
8.
Select None under Include these recipient types.
9.
Task 5: Create a new address list for Adventure Works recipients

1.
In the console tree, under Organization Configuration, click Mailbox.
2.
In the results pane, click the Address Lists tab.
3.
In the Actions pane, click New Address List.
4.
In the Name box, type Adventure Works, and then click Browse.
5.
In the Select Address List dialog box, select Companies, and then click OK.
6.
Click Next, verify that All Recipient types is selected, and then click Next.
7.
In the Step 1 box, select the Recipient is in a Company option.
8.
In the Step 2 box, click specified.
9.
In the Specify Company dialog box, type Adventure Works, click Add, and then click OK.
10. Click Preview, and then click OK.
L4-8
11. Click Next, verify that Immediately is selected, and then click Next.
Task 6: Verify the new address list is available in Office Outlook

1.
Start 10165A-NYC-CL1-B and log on as Contoso\Administrator, with the password, Pa$$w0rd.
2.
Open Microsoft Outlook 2010.
3.
In the ribbon, click Address Book.
4.
Under Address Book, click the down arrow to display the options. Notice that under the Companies
container displays and includes the address lists Adventure Works.
5.
Close all open windows, and log off NYC-CL1.
Task 7: Move the Default Offline Address Book generation server from Exchange
Server 2003 to Exchange Server 2010
1.

Mailbox, and then click the Offline Address Book tab.
2.
In the results pane, click Default Offline Address List, and then in the Actions pane, click
Properties.
3.
Notice that generation server is NYC-EX03, and then click Cancel.
4.
In the results pane, click Default Offline Address List, and then in the Actions pane, click Move.
5.
In the Move Offline Address Book window click Browse, and then in Select Mailbox Server, click
NYC-EX10, click OK, and then click Move.
6.
On the Completion page, click Finish.
7.
In the results pane, click Default Offline Address List, and then in Actions pane, click Properties.
8.
On Default Offline Address List properties, click the Distribution tab.
9.
Under Client Support, clear all check boxes except Outlook 2003 SP2 or later (Version 4).
10. Under Distribution Points, select both Enable Web-based Distribution and Enable public folder
distribution.
Note You will enable public folder distribution of Offline Address Lists if your company is
running Office Outlook 2003 clients. Office Outlook 2007 or later uses web-based
distribution of Offline Address Lists.
11. Click Add, and in the Microsoft Exchange dialog box, click OK.
12. Click OAB (Default Web Site), and then click OK. Ensure that NYC-EX10 is listed under the Server
column, and then click OK.
Task 8: Create a new offline address book for the Adventure Works address list to
support both Office Outlook 2003 and Outlook 2007 clients
1.

Mailbox, and then click the Offline Address Book tab.
2.
In the Actions pane, click New Offline Address Book.
3.
In the Name box, type Companies.
4.
Click Browse, select NYC-EX10, and then click OK.
5.
Clear the Include the default Global Address List check box.
6.
Select the Include the following address lists check box.
7.
Click Add, expand Companies, click Adventure Works, and then click OK.
8.
Click Next, and then select the Enable Web-based Distribution and Enable public folder
distribution check boxes.
9.
Click Add, and in the Microsoft Exchange dialog box, click OK.
10. Click OAB (Default Web Site), click OK, and then click Next.
L4-9
Results: After this exercise, you should have created and verified an address list for the Adventure Works
users, moved email address policy, address lists and an offline address book from Exchange Server 2003 to
Exchange Server 2010, and created an offline address book for Adventure Works users on Exchange
Server 2010.
L4-10
Exercise 3: Performing Bulk Recipient Management Tasks

Task 1: Add a header to the .csv file exported from the Human Resources system
1.
On NYC-EX10, click Start, point to All Programs, click Accessories, and then click Notepad.
2.
Click the File menu, and then click Open.
3.
Change the Files of Type to All Files.
4.
Browse to D:\Labfiles\Users.csv, and then click Open.
5.
At the top of the file, replace Add Header Here with FirstName,LastName,Password.
Note The Import-CSV cmdlet uses this header to name each column of imported
information. You can then reference these names to view and manipulate information.
6.
Click the File menu, and then click Save.
7.
Close Notepad.
Task 2: Modify the CreateUsersLab.ps1 script to import Adventure Works users from
a .csv file
1.
Click Start, point to All Programs, click Accessories, and then click Notepad.
2.
Click the File menu, and then click Open.
3.
Change the Files of Type to All Files.
4.
Select D:\Labfiles\CreateUsersLab.ps1, and then click Open.
5.
In Section 1, define the following settings:
6.
$db: Mailbox Database 1
$upndom: Contoso.com
$ou: Adventureworks
$csvFile: D:\Labfiles\Users.csv
In Section 4, apply the following settings:
Replace all instances of property1 with firstname.
Replace all instances of property2 with lastname.
Replace all instances of property3 with password.
7.
Click the File menu, and then click Save.
8.
Close Notepad.
Task 3: Create the AdventureWorks Organizational Unit

1.
On NYC-EX10, click Start, click Administrative Tools, and then click Active Directory Users and
Computers.
L4-11
2.
In the console tree, right-click Contoso.com, expand New, and then click Organizational Unit.
3.
In the New Object Organizational Unit dialog box, in the Name box, type AdventureWorks, and
then click OK.
Task 4: Run CreateUsersLab.ps1 to import the Adventure Works users

1.
2.
Type D:\Labfiles\CreateUsersLab.ps1, and then press Enter.
Task 5: Set mailbox limits for all Adventure Works users

1.
In Exchange Management Shell, run the following cmdlets:
Get-Mailbox OrganizationalUnit Adventureworks
Get-Mailbox OrganizationalUnit Adventureworks | Set-Mailbox IssueWarningQuota 100MB

ProhibitSendQuota 150MB
Results: After this exercise, you should have created all of the additional Adventure Works users with an
Exchange Management Shell script and set the storage quota.
L4-12
Module 5: Managing Client Access
Lab A: Upgrading and Configuring Client

Access Servers
Exercise 1: Configuring Client Access Servers
Task 1: Configure an external client access domain for NYC-EX11
1.
2.
Expand Microsoft Exchange On-Premises (nyc-ex11.contoso.com). In the left pane, expand

Server Configuration, and then click Client Access.
3.
In the Actions pane, click Configure External Client Access Domain.
4.
On the Server selection page, type mail.contoso.com as the domain name, and then click Add.
5.
In the Select Client Access Server dialog box, click NYC-EX11, and then click OK.
6.
Click Configure. In the Microsoft Exchange dialog box, click Yes, and then click Finish.
7.
In the results pane, click NYC-EX11, and then in the work pane, double-click owa (Default Web
Site).
8.
On the General tab, verify that the External URL field has been changed to
https://mail.contoso.com/owa, and then click OK.
Task 2: Prepare a Server Certificate request for NYC-EX11
L5-1
1.
In the left pane, click Server Configuration. In the results pane, click NYC-EX11.
2.
In the Actions pane, click New Exchange Certificate to open the New Exchange Certificate wizard.
3.
On the Introduction page, as the friendly name for the certificate, type Contoso Mail Certificate,
and then click Next.
4.
On the Domain Scope page, click Next.
5.
On the Exchange Configuration page, expand Client Access server (Outlook Web App), and then
select both the Outlook Web App is on the Intranet and Outlook Web App is on the Internet
check boxes. Verify that mail.contoso.com displays in the second text box.
6.
Expand Client Access server (Exchange ActiveSync), and then verify that the Exchange Active
Sync is enabled check box is selected.
7.
Expand Client Access server (Web Services, Outlook Anywhere, and Autodiscover), and then
enter mail.contoso.com as the external host name for your organization.
8.
Ensure that both the Autodiscover used on the Internet check box and the Long URL option are
selected. In the Autodiscover URL to use field, delete all entries except for
autodiscover.contoso.com.
9.
Expand Legacy Exchange Server, and then click Use legacy domains. Ensure that
legacy.contoso.com is the only entry in the form Domain name to use for legacy servers, and
then click Next.
10. On the Certificate Domains page, click Next.
11. On the Organization and Location page, enter the following information:
Organization: Contoso
Country/region: United States
City/locality: New York
State/province: NY
12. Click Browse, type CertRequest as the File name, and then click Save.
Task 3: Request the certificate from the CA

1.
Click the Folder icon in the taskbar, and then click Documents.
2.
Right-click CertRequest.req, and then click Open.
3.
In the Windows dialog box, click Select a program from a list of installed programs, and then
click OK.
4.
In the Open with dialog box, click Notepad, and then click OK.
5.
In the CertRequest.req Notepad window, press the Ctrl+A keys to select all the text, and then
press Ctrl+C to copy and save the text to the clipboard.
6.
Close Notepad.
7.
Click Start, click All Programs, and then click Internet Explorer.
8.
Connect to https://nyc-dc1.contoso.com/certsrv.
9.
Log on as Administrator using the password Pa$$w0rd.
10. On the Welcome page, click Request a certificate.

11. On the Request a Certificate page, click advanced certificate request.
L5-2
12. 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.
13. 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.
14. In the Certificate Template drop-down list box, click Web Server, click Submit, and then click Yes.
15. On the Certificate Issued page, click Download certificate.
16. In the File Download dialog box, click Save.
17. In the Save As dialog box, click Save.
18. In the Download complete dialog box, click Open.
19. In the Certificate dialog box, on the Details tab, click Subject Alternative Name. Verify that the
certificate includes several subject alternative names, including mail.contoso.com,
autodiscover.contoso.com, and legacy.contoso.com, and then click OK.
Task 4: Import and assign the new certificate to the IIS Exchange Service
1.
In the Exchange Management console, click Server Configuration.
2.
Click Contoso Mail Certificate, and in the Actions pane, click Complete Pending Request.
3.
On the Complete Pending Request page, click Browse.
4.
In the Favorites drop-down list, click Downloads.
5.
Click certnew.cer, and then click Open.
6.
Click Complete, and then click Finish.
7.
In the Exchange Management Console, click Server Configuration.
8.
In the results pane, click NYC-EX11. In the bottom pane, click Contoso Mail Certificate.
9.
In the Actions pane, click Assign Services to Certificate.
10. On the Select Servers page, verify that NYC-EX11 displays, and then click Next.
L5-3
11. On the Select Services page, select the Internet Information Services (IIS) check box, click Next,
click Assign, and then click Finish.
Task 5: Verify Outlook connectivity to the Exchange 2010 server

1.
On NYC-CL1, log on as Alan using the password Pa$$w0rd.
2.
Click Start, click All Programs, click Microsoft Office, and then click Microsoft Outlook 2010.
3.
On the Microsoft Outlook 2010 Startup page, click Next.
4.
On the E-mail Accounts page, click Next.
5.
On the Auto Account Setup page, click Next.
6.
On the Configuring page, click Finish.
Note If Microsoft Outlook 2010 cannot connect to the server, ensure that all of the
Microsoft Exchange Server 2010 services on NYC-EX11 that are set to Automatic start are
started. Start all services that have not started, and try connecting again.
7.
In the User Name dialog box, click OK.
8.
On the Help Protect and Improve Microsoft Office page, click Dont make changes, and then
click OK.
9.
In Outlook 2010, click the File tab, and then click Account Settings.
10. In the drop-down list, click Account Settings.

11. Click Alan@contoso.com, and then click Change.
12. Verify that the server is listed as NYC-EX11.contoso.com, click Cancel, and then click Close.
13. Close Outlook 2010.
Results: After this exercise, you should have installed a server certificate from the internal certification
authority (CA) on the Exchange Server 2010 server. You should also have also verified Outlook 2010 client
connectivity to the Exchange Server 2010 server.
L5-4
Exercise 2: Upgrading Client Access Services from Exchange Server 2003 to

Task 1: Install the server certificate on NYC-EX03-B
1.
On NYC-EX11 server, in the Exchange Management Console, click Server Configuration.
2.
In the results pane, click Contoso Mail Certificate and then in the Actions pane, click Export
Exchange Certificate.
3.
In the Export Exchange Certificate Wizard, click Browse, enter the name Contosomail, and then click
Save.
4.
In the Export Exchange Certificate Wizard, in the Password box, type Pa$$w0rd and then click
Export, and on the Completion window, click Finish.
5.
On NYC-EX03, click Start, and then click Run.
6.
In the Run window, type \\NYC-EX11\c$\Users\Administrator.CONTOSO\Downloads and then

press Enter.
7.
Copy the Contosomail.pfx file from NYC-EX11 to the desktop of NYC-EX03.
8.
Click Start, point to Administrative Tools, and then click Internet Information Services (IIS)
Manager.
9.
In Internet Information Services (IIS) Manager, expand NYC-EX03 (local computer), expand Web
Sites, and then expand Default Web Site.
10. Right-click Default Web Site, and then click Properties.
11. On the Directory Security tab, under Secure communications, click Server Certificate. When the
Welcome to the Web Server Certificate Wizard opens, click Next.
12. On the Server Certificate page, click Import a certificate from a .pfx file, and then click Next.
13. On the Import Certificate page, click Browse. In the Open dialog box, click the Desktop button.
Click contosomail.pfx, and then click Open.
14. On the Import Certificate page, click Next.
15. On the Import Certificate Password page, in the Password box, type Pa$$w0rd, and then click
Next.
16. On the SSL Port page, ensure that 443 is listed as the SSL port, and then click Next.
17. On the Imported Certificate Summary page, click Next, and then click Finish.
18. On the Directory Security tab, under Secure communications, click Edit.
19. Click Require secure channel (SSL), and then click OK.
20. Click OK to close the Default Web Site Properties dialog box.
21. On the Inheritance Overrides dialog box, click Select All, and then click OK.
22. Close the Internet Information Services (IIS) Manager Window.
23. Close the Windows Explorer window.
Task 2: Configure NYC-EX03 to use forms-based authentication
L5-5
1.
On NYC-EX03 click Start, point to All Programs, point to Microsoft Exchange, and then click
System Manager.
2.
In the Exchange System Manager, expand Administrative Groups, expand First Administrative
Group, expand Servers, expand NYC-EX03, expand Protocols, expand HTTP, and then click
Exchange Virtual Server.
3.
Right-click Exchange Virtual Server, and then click Properties.
4.
In the Exchange Virtual Server Properties dialog box, click the Settings tab.
5.
Select the Enable Forms Based Authentication check box, and then click OK. Click OK again at the
Exchange System Manager prompt.
6.
Close the Exchange System Manager.
7.
Open the Services console, and restart the Microsoft Exchange Information Store service.
Task 3: Configure the Exchange 2003 URL for Outlook Web App
On NYC-EX11, open the Exchange Management Shell, and configure the Exchange Server 2003 URL
for Outlook Web App by running following cmdlet:
Task 4: Modify the DNS records to use the Exchange 2010 Client Access server
1.
On NYC-DC1, in Administrative Tools, click DNS, expand Forward Lookup Zones, and expand
Contoso.com.
2.
Assign the mail.contoso.com alias to NYC-EX11.contoso.com using the following steps:
In DNS console, right-click Contoso.com and then click New Alias (CNAME)
In New Resource Record window, in Alias name field type mail, and in Fully qualified domain
name (FQDN) for target host, type NYC-EX11.contoso.com, and then click OK.
3.
Assign the autodiscover.contoso.com alias to NYC-EX11.contoso.com using the steps described

above.
4.
Assign the legacy.contoso.com alias to NYC-EX03.contoso.com using the steps described above.
Task 5: Verify Outlook Web App connectivity for Exchange Server 2003 and
Exchange Server 2010 mailboxes
1.
On NYC-CL1, open Windows Internet Explorer. On the Welcome to Internet Explorer 8 page, click
Ask me later.
2.
Connect to Outlook Web App by using https://mail.contoso.com/owa. Verify that you can log on
as user Contoso\George whose mailbox is located on Exchange Server 2010. Close Internet Explorer.
Note If you cannot connect to the server, ensure that all of the Microsoft Exchange Server
2010 services on NYC-EX10 that are set to Automatic start are started. Start all services that
have not started, and try connecting again.
3.
On NYC-CL1, open Internet Explorer and then connect to Outlook Web App by using
https://legacy.contoso.com/exchange. Verify that you can log on as user Contoso\Bart whose
mailbox is located on Exchange Server 2003. Close Internet Explorer.
Note If you cannot connect to the server, ensure that all of the Microsoft Exchange Server
services on NYC-EX03 that are set to Automatic start are started. Start all services that have
not started, and try connecting again.
L5-6
4.
On NYC-CL1, open Internet Explorer and then connect to Outlook Web App by using
https://mail.contoso.com/owa. Verify that you can log on as user Contoso\Bart whose mailbox is
located on Exchange Server 2003. Close Internet Explorer.
5.
Log off of NYC-CL1.
Results: After this exercise, you should have configured the client access interoperability between
To prepare for the next lab
When you finish this lab, do not shut down the virtual machines or revert them to their initial state.
The virtual machines are required to complete the next lab in this module.
L5-7
Lab B: Configuring Client Access Servers for

Outlook Web App and Exchange ActiveSync
Exercise 1: Configuring Outlook Anywhere
Task 1: Configure Outlook Anywhere on NYC-EX11
1.
On NYC-EX11, click Start, point to Administrative Tools, and then click Server Manager.
2.
Click Features. In the Features list, verify that the RPC over HTTP Proxy feature displays.
3.
On NYC-EX11, if required, open the Exchange Management Console.
4.
In the Exchange Management Console, expand Server Configuration, and then click Client Access.
5.
Click NYC-EX11, and in the Actions pane, click Enable Outlook Anywhere.
6.
On the Enable Outlook Anywhere page, in the External host name box, type Mail.contoso.com.
Under Client authentication method, click NTLM authentication, and then click Enable.
7.
8.
Close all open windows, and then restart NYC-EX11.
Task 2: Configure the Outlook profile to use Outlook Anywhere

1.
On NYC-CL1, log on as Contoso\Luca by using the password Pa$$w0rd.
2.
Click Start, and then click Control Panel. In the Search box, type Mail. Right-click Mail (32-bit), and
then click Open.
3.
In the Mail Setup - Outlook dialog box, click E-mail Accounts.
Note If you get a message that the server is unavailable, ensure that all of the Microsoft
Exchange Server 2010 services on NYC-EX10 that are set to Automatic start are started. Start
all services that have not started, and try connecting again.
4.
In the E-mail Accounts dialog box, click Luca@contoso.com, and then click Change.
5.
On the Server Settings page, click More Settings.
6.
In the Microsoft Exchange dialog box, on the Connection tab, select the Connect to Microsoft
Exchange using HTTP check box, and then click Exchange Proxy Settings.
7.
In the Microsoft Exchange Proxy Settings dialog box, complete the following information:
Use this URL to connect to my proxy server for Exchange (https://): mail.contoso.com
Connect using SSL only: enable (default)
On fast networks, connect using HTTP first, then connect by using TCP/IP: enable
On slow networks, connect using HTTP first, then connect by using TCP/IP: enable (default)
Proxy authentication setting: NTLM Authentication (default)
8.
Click OK, and then click OK again to close the Microsoft Exchange dialog box.
9.
On the Change Account page, click Next.
10. On the Change Account page, click Finish.

11. On the E-mail Accounts page, click Close, and then click Close again to close the Mail Setup Outlook dialog box.
Task 3: Verify Outlook Anywhere connectivity

1.
Wait until NYC-EX11 finishes restarting, and then log on as Contoso\Administrator by using the
password Pa$$w0rd.
2.
On NYC-CL1, open Microsoft Outlook 2010.
3.
If an Outlook dialog box appears, click No.
4.
Verify that the Microsoft Outlook 2010 connection indicator displays as Online with Microsoft
Exchange.
Note If Outlook cannot connect to the server, verify that all of the Exchange Server services
on NYC-EX11 that are set to start automatically are started. Start all services that have not yet
started, and try connecting again.
L5-8
5.
Press and hold the Ctrl key, and then right-click the Microsoft Outlook 2010 icon in the Windows 7
operating system notification area. You may need to click the up arrow icon in the Windows 7
notification area to view the Outlook 2010 icon.
6.
Click Connection Status. Confirm that the Conn column lists HTTPS as the connection method, and
then click Close.
7.
Press and hold Ctrl, click the Microsoft Outlook 2010icon in the Windows taskbar notification area
and then click Test E-mail AutoConfiguration.
8.
In the Password box, type Pa$$w0rd.
9.
Clear the Use Guessmart and Secure Guessmart Authentication check boxes.
10. Click Test. View the information that displays on the Results tab.
11. Click the Log tab to view how the client completed Autodiscover.
12. Close the Test E-mail AutoConfiguration dialog box.
13. Close Microsoft Outlook, and then log off NYC-CL1.
Results: After this exercise, you should have enabled Outlook Anywhere, and configured a client profile to
use Outlook Anywhere. You also should have verified the Outlook Anywhere functionality.
Exercise 2: Configuring Outlook Web App

Task 1: Configure IIS to use the internal CA certificate
L5-9
1.
On NYC-EX11, click Start, point to Administrative Tools, and then click Internet Information
Services (IIS) Manager.
2.
Expand NYC-EX11 (Contoso\Administrator), expand Sites, expand Default Web Site, and then
click owa.
3.
In the center pane, and under IIS, double-click SSL Settings. Notice that SSL is required by default.
4.
Under Sites, click Default Web Site, and in the Actions pane, click Bindings.
5.
In the Site Bindings dialog box, click the https instance associated with the * IP Address, and then
click Edit.
6.
In the SSL Certificate drop-down list, verify that Contoso Mail Certificate is selected
7.
Click OK, click Close, and then close the Internet Information Services (IIS) Manager.
Task 2: Configure Outlook Web App settings for all users

1.
On NYC-EX11, click Start, point to All Programs, click Microsoft Exchange Server 2010, and then
click Exchange Management Console.
2.
In the console tree, expand Microsoft Exchange On-Premises, expand Server Configuration, and
then click Client Access.
3.
In the work pane, select NYC-EX11, and in the result pane, right-click owa (Default Web Site), and
then click Properties.
4.
Click the Authentication tab, and verify that Use forms-based authentication is selected.
5.
Under Logon Format, click User name only, and then click Browse.
6.
Click contoso.com, and then click OK.
7.
Click the Segmentation tab, click Tasks, and then click Disable. Click Rules, and then click Disable.
Click OK twice.
8.
Open the Exchange Management Shell. At the Exchange Management Shell prompt, type setowavirtualdirectory owa (Default Web Site) ForceSaveFileTypes .doc, and then press Enter.
9.
Type set-owavirtualdirectory owa (Default Web Site) GzipLevel Off, and then press Enter.
10. Type Set-OwaVirtualDirectory -identity Owa (Default Web Site) FilterWebBeaconsAndHtmlForms ForceFilter, and then press Enter.
11. Type IISReset /noforce, and then press Enter.
Note If you get a message that the service did not start, open the Services Microsoft
Management Console (MMC) from the Administrative Tools folder. Right-click the World
Wide Web Publishing Service and click Start. Wait for the service to start, and then close
the Services MMC.
12. Close the Exchange Management Shell.
Task 3: Configure an Outlook Web App Mailbox Policy for branch managers
L5-10
1.
On NYC-EX11, in Exchange Management Console, expand Organization Configuration, and then

click Client Access.
2.
In the Actions pane, click New Outlook Web App Mailbox Policy.
3.
In the New Outlook Web App Mailbox Policy page, type Branch Managers Policy as the Outlook
Web App mailbox policy name.
4.
In the list of features, click Change Password, and then click Disable.
5.
6.
Under Recipient Configuration, click Mailbox.
7.
Click the Organizational Unit column heading to sort the view by organizational units (OU).
8.
Select all the users in the Branch Managers OU, right-click, and then click Properties.
9.
On the Mailbox Features tab, click Outlook Web App, and then click Properties.
10. Select the Outlook Web App mailbox policy check box, and then click Browse.
11. Click Branch Managers Policy, and then click OK three times.
Task 4: Verify the Outlook Web App configuration

1.
On NYC-EX10, open Internet Explorer.
2.
In the address field, type https://mail.contoso.com/owa, and then press Enter.
3.
Log on to Outlook Web App as Contoso\Dylan using the password Pa$$w0rd. Note that Dylan is
not a member of the Branch Managers OU, and then click OK.
4.
Verify that the Tasks folder does not display in the user mailbox.
5.
On the Outlook Web App page, click Options.
6.
On the Organize E-Mail tab, verify that you cannot create a new Inbox rule.
7.
Close, and then reopen Internet Explorer.
8.
In the address field, type https://mail.contoso.com/owa, and then press Enter.
9.
Log on to Outlook Web App as Contoso\Ian using the password Pa$$w0rd. Note that Ian is a
member of the Branch Managers OU, and then click OK.
10. Verify that the Tasks folder displays in the user mailbox.
11. On the Outlook Web App page, click Options and then click See All Options.
12. In the left pane, click Settings. Notice that you do not have an option to change passwords.
Results: After this exercise, you should have configured Outlook Web App on NYC-EX11. This
configuration includes verifying that the internal CA certificate is assigned to the default web site, and
configuring Outlook Web App settings for all users, as well as for specific users. You also should have
verified the Outlook Web App settings.
Exercise 3: Configuring Exchange ActiveSync

Task 1: Verify the Exchange ActiveSync virtual directory configuration
L5-11
1.
On NYC-EX11, in the Exchange Management Console, expand Server Configuration, and then click
Client Access.
2.
In the result pane, click NYC-EX11, and in the work pane, click the Exchange ActiveSync tab.
3.
Right-click Microsoft-Server-ActiveSync, and then click Properties.
4.
Review the information on the General tab.
5.
Click the Authentication tab. Notice that Basic authentication is enabled. This is acceptable,
because you typically would use SSL to secure the credentials in transit. After reviewing these settings,
click OK.
Task 2: Create a new Exchange ActiveSync mailbox policy

1.
On NYC-EX11, if required, open the Exchange Management Console.
2.
In the console tree, expand Organization Configuration, and then click Client Access.
3.
In the Actions pane, click New Exchange ActiveSync Mailbox Policy.
4.
In the Mailbox policy name box, type EAS Policy 1.
5.
Select the following check boxes:
Allow non-provisionable devices
Require password
Enable password recovery. This will enable users to recover their Windows Mobile password
through the Exchange Control Panel.
6.
Click New to create the mobile mailbox policy.
7.
Read the completion summary, and then click Finish. Notice the Exchange Management Shell
command that was used to create the new mobile mailbox policy.
8.
Right-click EAS Policy 1, and then click Properties. Notice that the General tab has additional
options.
9.
Click the Password tab. Notice the additional password-option list that now displays, but was
previously not available when creating the mobile mailbox policy.
10. On the Sync Settings tab, review the configuration options. Confirm that the Allow attachments to
be downloaded to device check box is selected.
11. On the Device tab, review the configuration options.
12. On the Device Applications tab, review the configuration options. To implement these settings, you
must have an Enterprise Client Access License for each mailbox.
13. On the Other tab, review the options for allowing or blocking specific applications, and then click OK.
14. In the console tree, expand Recipient Configuration, and then click Mailbox.
15. In the result pane, right-click Adam Carter, and then click Properties.
16. Click the Mailbox Features tab, click Exchange ActiveSync, and then click Properties.
17. In the Exchange ActiveSync Properties dialog box, click Browse.
18. Select EAS Policy 1, and then click OK.

19. Click OK twice to save and apply the changes.
Task 3: Configure Exchange ActiveSync Access settings

1.
On NYC-EX10, open Internet Explorer, and connect to https://nyc-ex10.contoso.com/ecp.
2.
Log on as Contoso\Administrator using the password Pa$$w0rd.
3.
On the Manage My Organization page, click Phone&Voice. This is where the administrator
manages ActiveSync Access and ActiveSync Device Policies in Exchange Control Panel.
4.
Under Exchange ActiveSync Access Settings, click Edit.
5.
In the Exchange ActiveSync Settings window, configure following settings:
L5-12
Connection settings: Quarantine Let me decide to block or allow later
Quarantine notification emails: Click Add, and in the Select Administrators window, click
Administrator, and then click OK.
Enter text to include in emails: Type the following message: Your device has been quarantined.
Please contact your administrator.
6.
Click Save.
7.
Under Device Access Rules, click New.
8.
In the Exchange ActiveSync Device Access Rule window, review the options to define Device family, to
define Device model, and to configure device access state to Allow access, Block access or Quarantine
Let me decide to block or allow later, and then click Cancel.
9.
Log off Exchange Control Panel
Results: After this exercise, you will have configured the Exchange Server 2010 server environment to
support Microsoft Exchange ActiveSync. You also will have enhanced the security configuration by
creating a more secure Exchange ActiveSync Mailbox policy, and by configuring Exchange ActiveSync
Access settings.
Module 6: Managing Message Transport
Lab: Migrating and Managing Message

Transport
To prepare for this module
1.
On NYC-EX11, click Start, right-click Network, and then click Properties.
2.
Click Change adapter settings.
3.
Right-click Local Area Connection 2, and then click Properties.
4.
Click Internet Protocol Version 4 (TCP/IPv4), and then click Properties.
5.
Change the IP address to 10.10.11.21, click OK, and then click Close.
6.
Open a command prompt, type Ipconfig /registerdns, and then press Enter.
7.
Open the Services management console.
8.
Right-click Microsoft Exchange Active Directory Topology, click Restart, and then click Yes.
Ensure that all Microsoft Exchange services that are configured for Automatic are started.
9.
Close all open Windows.
Exercise 1: Configuring Internet Message Transport
L6-1
Task 1: Test Internet mail delivery by using the Exchange Server 2003 connector
1.
On NYC-EX11, start Internet Explorer, and connect to https://NYC-EX11.contoso.com/OWA.
2.
Log on as Contoso\Alan, with the password, Pa$$w0rd.
3.
On the Microsoft Outlook Web App page, click OK.
4.
Create and send a new email message to Info@Internet.com with the subject, Test Mail to
Internet.
5.
On NYC-EX03, click Start, point to All Programs, point to Microsoft Exchange, and then click
System Manager.
6.
In the left pane, expand ContosoOrg(Exchange), expand Administrative Groups, expand First
Administrative Group, expand Servers, expand NYC-EX03, and then click Queues.
7.
In the Queues pane, verify that the Internet Mail Connector [10.10.0.201](SMTP Connector)
queue has a Number of messages count of 0.
Note If the Internet Mail connector queue is not empty, verify that the Simple Mail Transfer
Protocol (SMTP) service is running on NYC-SVR1.
8.
In Exchange System Manager, in the left pane, expand ContosoOrg(Exchange), expand Tools, and
then click Message Tracking Center.
9.
In the right pane, in the Sender field, enter Alan@contoso.com, in the Server field, enter NYCEX03, and then click Find Now.
L6-2
10. In the Origination Time pane, double-click the last message, and then, in the Message History
window, verify successful delivery to NYC-SVR1.
11. On NYC-SVR1, click Start, point to All Programs, point to Accessories, and then click Command
Prompt.
12. At the command prompt, type telnet nyc-ex03 smtp, and then press Enter.
13. Type helo, and then press ENTER.
14. Type mail from:info@internet.com, and then press ENTER.
Response: 250 2.1.0 info@internet.com....Sender OK
15. Type rcpt to:Alan@contoso.com, and then press ENTER.
Response: 250 2.1.5 alan@contoso.com
16. Type data, and then press ENTER.
Response: 354 Start mail input; end with <CRLF>.<CRLF>
17. Type Subject: Test from Internet, and then press ENTER.
18. Press the Period key, and then press ENTER.
19. Type Quit, and then press ENTER.
20. On NYC-EX11, start Internet Explorer, and then connect to https://NYC-EX11.contoso.com/OWA.

21. Log on as Contoso\Alan, with the password, Pa$$w0rd.
22. Verify that the mail with the subject Test from Internet has arrived in the Inbox, and then close
Internet Explorer.
Task 2: Configure a Send connector to the Internet

1.
2.

3.
In the Hub Transport pane, click the Send Connectors tab.
4.
5.
In the New Send Connector window, in the Name box, type Internet Send Connector.
6.
In the Select the intended use for this Send connector list, click Internet, and then click Next.
7.
8.
In the Address field, type *, click OK, and then click Next.
9.
On the Network settings page, click Route mail through the following smart hosts, click Add,
and then click IP address.
10. In the IP address box, type 10.10.0.201, click OK, and then click Next.
11. On the Configure smart host authentication settings page, click Next.
12. On the Source Server page, ensure that NYC-EX10 is listed, and then click Next.
13. On the New Connector page, click New, and then click Finish.
Task 3: Configure a Receive connector to accept Internet messages
L6-3
1.
In Exchange Management Console, expand Server Configuration, click Hub Transport, and then, in
the Hub Transport pane, click NYC-EX10.
2.
In the NYC-EX10 pane, click New Receive Connector.
3.
In the New Receive Connector window, in the Name box, type Internet Receive Connector.
4.
In the Select the intended use for this Receive connector list, click Custom, and then click Next.
5.
On the Local Network Settings page, click Next.
6.
In the Remote Network Settings page, click the red X to delete the entry, and then click Add.
7.
In the Address or address range box, type 10.10.0.201, click OK, and then click Next.
8.
On the New Connector page, click New, and then click Finish.
9.
In the NYC-EX10 pane, double-click Internet Receive Connector.
10. In the Internet Receive Connector window, on the General tab, in the Protocol logging level list,
click Verbose.
11. On the Permission Groups tab, select the Anonymous users check box, and then click OK.
Task 4: Modify the Routing Group connector

1.
then click Exchange Management Shell.
2.
At the PS prompt, type Get-RoutingGroupConnector |fl, and then press ENTER.
3.
At the PS prompt, type Get-RoutingGroupConnector Identity First Routing

Group\Ex2003toEx2010 | Set-RoutingGroupConnector TargetTransportServers NYC-EX11
Cost 100, and then press ENTER.
4.
At the PS prompt, type Get-RoutingGroupConnector Identity Exchange Routing Group

(DWBGZMFD01QNBJR)\Ex2003toEx2010 | Set-RoutingGroupConnector
SourceTransportServers NYC-EX11 Cost 100, and then press ENTER.
Task 5: Configure message size restrictions and priority queuing

1.
2.
At the PS prompt, type Set-SendConnector Internet Send Connector MaxMessageSize 15MB,

and then press ENTER.
3.
Click Start, point to All Programs, point to Accessories, and then click Command Prompt.
4.
At the command prompt, type cd \Program Files\Microsoft\Exchange Server\V14\Bin, and

then press ENTER.
5.
At the command prompt, type notepad EdgeTransport.exe.config, and then press ENTER.
6.
In Notepad, select Edit in menu bar, and then click Find.
7.
In the Find window, type PriorityQueuingEnabled in the Find what field, and then click Find Next.
8.
Change the PriorityQueuingEnabled key value from value=false to value=true.
9.
Select File in menu bar, and then click Save.
L6-4
10. In Exchange Management Shell, type Restart-Service MSExchangeTransport, and then press
ENTER.
Task 6: Verify Internet message delivery from Exchange Server 2010.

1.
On NYC-EX11, start Internet Explorer, and then connect to https://NYC-EX11.contoso.com/OWA.
2.
3.
Create and send a new email message to Info@Internet.com with the subject, Test Mail #2 to
Internet.
4.
Open Exchange Management Console, expand Microsoft Exchange On-Premises, and then click
Toolbox.
5.
In the Toolbox pane, under Mail flow tools, double-click Queue Viewer.
6.
In the Actions pane, click Connect to Server.
7.
In the Connect to Server window, click Browse, select NYC-EX10, click OK, and then click Connect.
8.
In the Queues pane, verify that the [10.10.0.201] queue has a Message Count of 0. If the queue is
not in the list anymore, this means that the queue is empty.
9.
Close all open windows on NYC-EX11.
Results: After this exercise, you should have moved the Internet Mail connector from Exchange Server
2003 to Exchange Server 2010, configured Send and Receive connectors, modified the Routing Group
connector, implemented message size restrictions and priority queuing, and verified that message delivery
works correctly.
Exercise 2: Troubleshooting Message Transport

Task 1: Verify that the mail delivery functions as expected
L6-5
1.
2.
Log on as Contoso\Christine, with the password, Pa$$w0rd.
3.
On the Microsoft Outlook Web App page, click OK.
4.
Create and send a new email message to Alan, with the subject, Test Mail to NYC-EX11.
5.
6.
7.
Reply to the mail Test Mail to NYC-EX11 from Christine.
8.
On NYC-EX10, open the Inbox in Outlook Web App to verify that the mail arrived.
Task 2: Troubleshoot message transport

1.
On NYC-EX10, in Exchange Management Shell, type d:\ labfiles\Lab06Prep.ps1, and then press
ENTER.
2.
On NYC-EX10, in Internet Explorer, create and send a new email message to Alan with the subject,
Another Test Mail to NYC-EX11, and then close Internet Explorer.
3.
On NYC-EX11, in Outlook Web App, open the Inbox for Alan to verify if the new mail arrived.
4.
Result: Message is not in the Inbox.
5.
Switch to NYC-EX10, and then, in Exchange Management Console, click Toolbox.
6.
7.
On the Queues tab, double-click site2 to open the queue.
8.
Verify that the message that Christine sent to Alan is listed in the queue, and then click the Queues
tab.
9.
On the Queues tab, click Site2, and then scroll to the right to view the Last Error column.
10. Read the Last Error message in that Queue.

11. Click Start, point to All Programs, point to Accessories, and then click Command Prompt.
12. At the command prompt, type telnet nyc-ex11 smtp, and then press ENTER. Verify that you receive
a Connect failed error.
13. On NYC-EX11, in Exchange Management Console, expand Server Configuration, click Hub
Transport, and then in the Hub Transport pane, click NYC-EX11.
14. On the Receive Connectors tab, notice that only the Client NYC-EX11 connector exists. This is the
reason the server does not accept a port 25 connection.
15. On the Receive Connectors tab, click New Receive Connector.
16. In the New Receive Connector window, in the Name box, type Internal NYC-EX11.
17. In the Select the intended use for this Receive connector list, click Internal, and then click Next.
18. On the Remote Network settings page, click Next.
19. On the New Connector page, click New, and then click Finish.
L6-6
20. On NYC-EX10, in Exchange Management Console, click Toolbox.

21. In the Toolbox pane, under Mail flow tools, click Queue Viewer.
22. Right-click site2, and then click Retry to force an immediate retry of the message delivery. Verify that
the queue now has a message count of 0.
23. Switch to NYC-EX11, and then, in Outlook Web App, check Alans Inbox to verify that the message is
now delivered.
Results: After this exercise, you should have used the Routing Log Viewer to view your routing topology.
For troubleshooting, you will have used the Queue Viewer and Telnet to investigate the mail-flow
problem.
Module 7: Implementing Messaging Security
Lab A: Configuring Edge Transport Servers and Forefront Protection 2010 for Exchange Server
L7-1
Lab A: Configuring Edge Transport Servers

and Forefront Protection 2010 for Exchange
Server
Exercise 1: Installing an Edge Transport Server
Task 1: Verify and prepare the prerequisites for installing an Edge Transport server
1.
On NYC-SVR1, click Start, point to All Programs, point to Administrative Tools, and then click
Server Manager.
2.
In Server Manager, in the left pane, click Features, and then verify that .NET Framework 3.5.1
Features is listed in the Features Summary pane under Features.
3.
Click Remove Features.
4.
In the Select Features dialog box, remove the check mark next to SMTP Server, click Next, and then
click Remove.
5.
Click Close. When prompted to restart now, click No.
6.
In the left pane, click Server Manager (NYC-SVR1).
7.
In the Server Summary pane, under Computer Information, click Change System Properties.
8.
In the System Properties dialog box, on the Computer Name tab, click Change.
9.
In the Computer Name/Domain Changes dialog box, click More.
10. In the DNS Suffix and NetBIOS Computer Name dialog box, in the Primary DNS suffix on this
computer text box, enter contoso.com, and then click OK.
11. In the Computer Name/Domain Changes dialog box, click OK, and when the Information window
appears, click OK again.
12. In the System Properties dialog box, click Close.
13. In the Microsoft Windows dialog box, click Restart Now.
14. After the server has rebooted, log on as Administrator, with the password, Pa$$w0rd. At the
Removal Results page, click Close, and then close the Server Manager.
Task 2: Install an Edge Transport server

1.
On NYC-SVR1, click Start, point to All Programs, point to Accessories, and then click Command
Prompt.
2.
At the command prompt, type d:\Setup /mode:install /role:EdgeTransport

/InstallWindowsComponents /AdamLdapPort:50389 /AdamSslPort:50636, and then press Enter.
Wait for the installation to complete. The installation will take about 8-10 minutes.
3.
Restart NYC-SVR1. After the server has rebooted, log on locally as Administrator, with the password,
Pa$$w0rd.
Task 3: Configure DNS records for the Edge Transport server
L7-2
1.
On NYC-DC1, click Start, point to Administrative Tools, and then click DNS.
2.
Expand NYC-DC1, expand Forward Lookup Zones, select and then right-click Contoso.com, and
then click New Host (A or AAAA).
3.
In the New Host dialog box, in the Name (uses parent domain name if blank) text box, type NYCSVR1, in the IP address text box, type 10.10.0.201, click Add Host, click OK, and then click Done.
4.
Right-click Contoso.com, and then click New Mail Exchanger (MX).
5.
In the New Resource Record dialog box, in the Fully qualified domain name (FQDN) of mail
server text box, type NYC-SVR1.contoso.com.
6.
Click OK, and then close the Domain Name System (DNS) Manager.
Results: After this exercise, you should have verified and installed the prerequisites to install an Edge
Transport server, installed the Edge Transport server role on a server, and configured the DNS records for
the Edge Transport server.
Exercise 2: Configuring Edge Transport Servers

Task 1: Configure an Edge subscription
L7-3
1.
On NYC-SVR1, click Start, point to All Programs, point to Microsoft Exchange Server 2010, and
2.
In Exchange Management Shell, at the command prompt, type New-EdgeSubscription -FileName

c:\nyc-svr1.xml, and then press Enter.
3.
At the confirmation prompt, type Y, and then press Enter.
4.
Click Start, in the search text box, type \\nyc-ex10\c$, and then press Enter.
5.
Copy c:\nyc-svr1.xml to \\nyc-ex10\c$.
6.
7.

8.
In the Hub Transport pane, click the Edge Subscriptions tab.
9.
In the Actions pane, click New Edge Subscription.
10. In the New Edge Subscription window, next to Active Directory Site, click Browse. Select DefaultFirst-Site-Name as the Active Directory site, and then click OK.
11. Next to Subscription file, click Browse. Browse to drive C, click NYC-SVR1.XML, click Open, and
then click New.
12. On the Completion page, click Finish.
Task 2: Verify that Edge synchronization is working, and that AD LDS contains data
1.
2.
In Exchange Management Shell, at the command prompt, type Start-EdgeSynchronization, and

then press Enter.
3.
At the PS prompt, type Test-EdgeSynchronization -FullCompareMode, and then press Enter.
4.
Ensure that the displayed results include RecipientStatus: Synchronized. If not, you need to wait for
another minute and then run Test-EdgeSynchronization -FullCompareMode again.
5.
At the command prompt, type Get-User -Identity Christine | ft Name, GUID, and then press Enter.
6.
Write down the first eight characters of the globally unique identifier (GUID) in your notes.
7.
Switch to NYC-SVR1, click Start, point to All Programs, point to Accessories, and then click
Command Prompt.
8.
At the command prompt, type LDP, and then press Enter.
9.
In the LDP window, on the menu bar click Connection, and then click Connect.
10. In the Connect window, in the Server box type NYC-SVR1, in the Port box type 50389, and then
click OK.
11. Click Connection on the menu bar, and then click Bind.
L7-4
12. In the Bind window, in the Bind type pane, click Bind as currently logged on user, and then click
OK.
13. Click View on the menu bar, and then click Tree.
14. In the Tree View dialog box, clear any entry in the BaseDN field, and then click OK.
15. In the LDP window, in the left pane, double-click OU=MSExchangeGateway to expand it.
16. Double-click CN=Recipients,OU=MSExchangeGateway.
17. Using the GUID that you recorded in Step 6, locate the recipient that starts with CN=<GUID>. After
you find the recipient, double-click the recipient GUID, and then review the data that is available for
this recipient.
Task 3: Configure and verify Internet message delivery

1.

click Hub Transport.
2.
Click the Send Connectors tab.
3.
Double-click EdgeSync - Default-First-Site-Name to Internet.
4.
Click the Network tab, select Route mail through the following smart hosts, and then click Add.
5.
In the IP address field, type 10.10.0.10, and then click OK.
6.
Click the Address Space tab, and then click Edit.
7.
In the SMTP Address Space dialog box, in the Cost field, type 1, and then click OK twice.
8.
In the Exchange Management Shell, at the PS prompt, type Start-EdgeSynchronization, and then
press Enter.
9.
At the PS prompt, type Exit, and then press Enter.
10. Start Windows Internet Explorer, and then connect to https://NYC-EX10.Contoso.com/owa.

11. Log on as Contoso\Christine, with the password, Pa$$w0rd.
12. On the Microsoft Outlook Web App page, click OK.
13. Create and send a new email to Info@Internet.com with the subject Test Mail to Internet.
14. Switch to NYC-SVR1, open Exchange Management Console, and then click Toolbox.
15. In the Toolbox pane, under Mail flow tools, double-click Queue Viewer.
16. On the Queues tab, make sure that all queues are empty.
Results: After this exercise, you should have configured Edge subscription between an Exchange Server
organization and an Edge Transport server. You will also have verified that synchronization works
correctly, and verified the data in the AD LDS database of the Edge Transport server. Finally, you will have
configured and verified Internet message delivery.
Exercise 3: Configuring Forefront Protection 2010 for Exchange Server

Exercise Setup
Before you begin the exercise, you must perform the following steps:
L7-5
1.
2.
In Hyper-V Manager, click 10165A-NYCSVR1-B, and then in the Actions pane, click Settings.
3.
4.
Browse to C:\Program Files\Microsoft Learning\10165\Drives, click ForeFrontInstall.iso, click

Task 1: Install Forefront Protection 2010 for Exchange Server

1.
On NYC-SVR1, click Start, in the Search field, type D:\ForefrontExchangeSetup.exe, and then press
Enter.
2.
In the Setup Wizard window, on the License Agreement page, click I agree to the terms of the
license agreement and privacy statement, and then click Next.
3.
On the Service Restart page, click Next.
4.
On the Installation Folders page, click Next.
5.
On the Proxy Information page, click Next.
6.
On the Antispam Configuration page, click Enable antispam later, and then click Next.
7.
On the Microsoft Update page, click I don't want to use Microsoft Update, and then click Next.
8.
On the Customer Experience Improvement Program page, click Next.
9.
On the Confirm Settings page, click Next. Wait for the installation to complete, which will take about
5 minutes.
10. On the Installation Results page, click Finish. Close the Windows Explorer window.
Task 2: Configure Forefront Protection 2010 for Exchange Server

1.
On NYC-SVR1, click Start, point to All Programs, point to Microsoft Forefront Server Protection,
and then click Forefront Protection for Exchange Server Console.
2.
In the Evaluation License Notice window, click OK.
3.
In the Microsoft Forefront Protection 2010 for Exchange Server Administrator Console, in the left
pane, click Policy Management.
4.
In the Policy Management pane, under Antimalware, click Edge Transport.
5.
On the Antimalware - Edge Transport page, in the Engines and Performance pane, select the Scan
with all engines option.
6.
In the Scan Actions pane, in the Action list in the Virus row, select Delete.
7.
On the Antimalware - Edge Transport page, click Save.
8.
In the Policy Management pane, expand Global Settings, and then click Advanced Options.
9.
On the Global Settings - Advanced Options page, in the Threshold Levels pane, increase the value of
Maximum nested attachments to 50, and Maximum nested depth compressed files to 10.
10. Under Intelligent Engine Management, in the Engine management list, select Manual.
11. In the Update scheduling table, click Norman Virus Control, and then click the Edit Selected
Engines button.
L7-6
12. In the Edit Selected Engine dialog box, in the Update frequency pane, verify that the Check for
updates every check box is selected, type 00:30 in the box, and then click Apply and Close.
13. On the Global Settings - Advanced Options page, click Save.
14. In the Policy Management pane, expand Global Settings, and then click Scan Options.
15. On the Global Settings - Scan Options page, in the Scan Targets Transport pane, under Target
types, clear Internal, and then click Save.
16. Close the Microsoft Forefront Protection 2010 for Exchange Server Administrator Console.
Results: After this exercise, you should have installed and configured Forefront Protection 2010 for
Exchange Server on the Edge Transport server.

Exercise 1: Configuring Anti-Spam Filtering
Task 1: Configure DNS for Sender ID filtering
L7-7
1.
On NYC-DC1, click Start, point to Administrative Tools, and then click DNS.
2.
Expand NYC-DC1, expand Forward Lookup Zones, select and then right-click Contoso.com, and
then click Other New Records.
3.
In the Resource Record Type dialog box, in the Select a resource record type list, click Text (TXT),
and then click Create Record.
4.
In New Resource Record window, in the Text box, enter v=spf1 mx all, click OK, and then click
Done.
Task 2: Configure and verify global SCL for junk mail delivery
1.
2.
In the Exchange Management Console, click Edge Transport.
3.
In the Edge Transport pane, select NYC-SVR1, and then click the Anti-spam tab.
4.
In the Anti-spam pane, double-click Content Filtering.
5.
In the Content Filtering Properties window, click the Action tab.
6.
In the Action tab, clear the Reject messages that have a SCL rating greater than or equal to
check box, and then click OK.
7.
8.
In Exchange Management Shell, type Set-OrganizationConfig -SCLJunkThreshold 6, and then

press ENTER.
9.
At the PS prompt, type D:\labfiles\Lab7ex3.ps1, and then press Enter. This will send 11 messages
with the SCL ratings listed in the following table.
Mail sender
SCL level
Msg1@adatum.com
Msg2@adatum.com
Msg3@adatum.com
Msg4@adatum.com
Msg5@adatum.com
Msg6@adatum.com
Msg7@adatum.com
Msg8@adatum.com
Mail sender
SCL level
Msg9@adatum.com
Msg10@adatum.com
Msg11@adatum.com
L7-8
10. On NYC-EX10, start Internet Explorer, and then connect to https://NYC-EX10.contoso.com/OWA.

11. Log on as Contoso\Christine, with the password, Pa$$w0rd.
12. In the Mail pane, click Inbox. You should see three new messages in the Inbox. If not, wait for
another minute until they arrive.
13. In the Inbox pane, double-click the message from Msg10@adatum.com.
14. In the message window, on the toolbar, click Message Details.
15. In the Message details window, identify the SCL level of this message by looking for X-MSExchange-Organization-SCL in the Internet Mail Headers box. Click Close to close Message
Details.
16. In the Mail pane, click Junk E-Mail. You should see eight new messages in the Junk E-Mail folder
that have been identified as junk mail because their SCL levels were higher than 6. You can verify this
by looking at the Message Details of the messages.
17. Delete all messages in the Inbox and Junk E-Mail folders.
Task 3: Configure and verify content filtering to reject junk messages

1.
2.
In the Exchange Management Console, click Edge Transport.
3.
In the Edge Transport pane, select NYC-SVR1, and then click the Anti-spam tab.
4.
In the Anti-spam pane, double-click Content Filtering.
5.
In the Content Filtering Properties window, click the Action tab.
6.
In the Action tab, click Reject messages that have a SCL rating greater than or equal to check
box, configure the rating to 7, and then click OK.
7.
On NYC-EX10, in the Exchange Management Shell, type D:\labfiles\Lab7ex3.ps1, and then press
Enter. This will send the 11 messages again, but notice that all messages with a SCL level of 7 or
above are rejected as spam by the Content Filter agent. Thus, only three messages will reach
Christines Inbox, and the other messages are not delivered to the user's Junk E-Mail folder.
8.
9.
10. In the Mail pane, click Inbox. Notice the three new messages in the Inbox.
11. Delete all messages in the Inbox.
Task 4: Configure and verify an IP Allow list

1.
On NYC-SVR1, in the Exchange Management Console, click the Anti-spam tab.
2.
In the Anti-spam pane, double-click IP Allow List.
L7-9
3.
In the IP Allow List Properties window, click the Allowed Addresses tab.
4.
On the Allowed Addresses tab, click Add.
5.
In the Add Allowed IP Address window, in the Address or address range box, type 10.10.0.20, and
then click OK.
6.
On the Allowed Address tab, click OK.
7.
On NYC-EX10, in the Exchange Management Shell, type D:\labfiles\Lab7ex3.ps1, and then press
Enter. This will send the 11 messages again, but notice that now all the messages arrive in Christines
Inbox.
8.
On NYC-EX10, start Internet Explorer, and then connect to https://NYC-EX10/OWA.
9.
10. In the Mail pane, click Inbox. You should see 11 new messages in the Inbox.
11. Double-click a message, and review the Message Detail. The SCL rating should be -1. When the
sending SMTP server is added to the IP Allow List, content filtering is not applied to the messages.
12. Delete all messages in the Inbox.
Task 5: Configure a block list provider

1.
On NYC-SVR1, in the Exchange Management Console, click the Anti-spam tab.
2.
In the Anti-spam pane, double-click IP Block List Providers.
3.
In the IP Block List Properties window, click the Providers tab.
4.
On the Providers tab, click Add.
5.
In the Add IP Block List Provider dialog box, in the Provider name box type Spamhaus, in the
Lookup domain box type zen.spamhaus.org, and then click OK.
6.
Click OK to close the IP Block List Providers Properties dialog box.
Results: After this exercise, you should have configured a Sender ID for Contoso.com, and configured and
tested a global SCL junk mail delivery. You will also have configured and tested content filtering to reject
spam messages. Finally, you will have configured and tested an IP allow list, and configured a block list
provider.
L7-10
Exercise 2: Configuring Secure SMTP Messaging

Task 1: Verify the certificate, and check the Receive connector
1.
On NYC-SVR1, click Start, click Run, type mmc, and then click OK.
2.
On the File menu, click Add/Remove Snap-in.
3.
On left-pane, under Available snap-ins, click Certificates, and then click Add.
4.
In the Certificates snap-in window, click Computer account, click Next, and then click Finish.
5.
In the Add or Remove Snap-ins window, click OK.
6.
In the Console1 window, expand Certificates (Local Computer), expand Personal, and then click
Certificates.
7.
In the middle pane, double-click the NYC-SVR1 certificate.
Note This certificate is the self-signed certificate that was installed on the server when the
Edge Transport server role was installed. In a production environment, to enable domain
security, you would need to obtain a certificate from a public CA or exchange root
certificates with other organizations.
8.
Click OK, and then close Console1 without saving changes.
9.
Click Start, point to All Programs, point to Exchange Server 2010, and then click Exchange
Management Console.
10. In the Exchange Management Console, click Edge Transport.

11. In the Edge Transport pane, click NYC-SVR1, and then in the NYC-SVR1 pane click the Receive
Connectors tab.
12. On the Receive Connectors tab, double-click Default internal receive connector NYC-SVR1.
13. On the Authentication tab, ensure that both the Transport Layer Security (TLS) and Enable
Domain Security (Mutual Auth TLS) check boxes are selected, and then click OK.
Note In a real-world implementation of Domain Security, you might want to add one
dedicated Receive connector for Domain Security connections as a best practice
recommendation.
Note You also need to perform these same steps on the partners side before Domain
Security will work correctly.
Task 2: Configure Domain Security

Note In this lab, we only configure Domain Security so you understand the steps required.
The lab is not built to verify Domain Security, because the target messaging organization is
not configured. You would also need to perform these steps on the partners side for Domain
Security to work correctly.
L7-11
1.
2.

3.
Click the Send Connectors tab, and then double-click EdgeSync - Default-First-Site-Name to
Internet.
4.
On the Network tab, click Use domain name system (DNS) MX records to route mail
automatically, click Enable Domain Security (Mutual Auth TLS), and then click OK.
5.
Click Start, point to All Programs, point to Microsoft Exchange Server 2010, and then click
6.
In Exchange Management Shell, at the PS prompt, type the following command, and then press Enter.
Set-TransportConfig -TLSSendDomainSecureList adatum.com
7.
At the PS prompt, type the following command, and then press Enter.
Set-TransportConfig -TLSReceiveDomainSecureList adatum.com
8.
At the command prompt, type the following command, and then press Enter.
Get-TransportConfig |FL
9.
At the command prompt, type the following command, and then press Enter.
Start-EdgeSynchronization
Results: After this exercise, you should have viewed the Exchange servers computer certificate, checked
the Receive connector to ensure Domain Security is enabled, configured the Send connector, and added
the domain adatum.com to the Domain Secure list.
L7-12
Module 8: Implementing High Availability

Exercise 1: Deploying a Database Availability Group
Task 1: Create and configure a DAG
L8-1
1.
2.
In the console tree, expand Microsoft Exchange On-Premises, click Organization Configuration,
3.
In the results pane, click the Database Availability Groups tab.
4.
In the Actions pane, click New Database Availability Group.
5.
In the New Database Availability Group wizard, on the New Database Availability Group page,
type DAG1 in the Database availability group name field.
6.
Select the Witness Server check box, type NYC-DC1, select the Witness Directory check box, type
C:\FSWDAG1, and then click New.
7.
8.
In the work pane, on the Database Availability Group tab, right-click DAG1, and then click
Properties.
9.
In the DAG1 Properties window, click the IP Addresses tab, and then click Add.
10. In the Add database availability group IP address(es) window, in the Database availability group IP
addresses field, type 10.10.0.99, and then click OK.
11. In the DAG1 Properties window, click OK.
Task 2: Add Mailbox servers to the DAG, and configure the replication network
1.
In the work pane, on the Database Availability Group tab, right-click DAG1, and then click Manage
Database Availability Group Membership.
2.
In the Manage Database Availability Group Membership wizard, click Add.
3.
In the Select Mailbox Server dialog box, press the Ctrl key, click both NYC-EX10 and NYC-EX11,
and then click OK.
4.
In the Manage Database Availability Group Membership wizard, click Manage to complete the
changes, and then click Finish to close the wizard.
5.
On the Database Availability Group tab, click DAG1.
6.
In the DAG1 pane, on the Database Availability Group tab, right-click DAGNetwork01, and then
click Properties.
7.
In the DAG1\DAGNetwork01 Properties window, on the General tab, type Internal Heartbeat
Network for replication only in the Description of this network field, and then click OK.
8.
In the DAG1 pane, on the Database Availability Group tab, right-click DAGNetwork02, and then
click Properties.
L8-2
9.
In the DAG1\DAGNetwork02 Properties window, on the General tab, type MAPI Communication
Network in the Description of this network field, clear the Enable replication check box, and then
click OK.
Task 3: Create and verify a mailbox database copy

1.
In the Exchange Management Console, in the results pane, click the Database Management tab.
2.
In the results pane, click Accounting, and then in the Actions pane, click Add Mailbox Database
Copy. If then Add Mailbox Database Copy option is not available, click Refresh in the Actions pane.
3.
In the Add Mailbox Database Copy Wizard, click Browse to select the server to which to add the
copy.
4.
In the Select Mailbox Server dialog box, click NYC-EX11, and then click OK.
5.
In the Add Mailbox Database Copy wizard, click Add.
6.
Review the results, and then click Finish.
7.
In the Accounting pane, on Database Copies tab, right-click the empty space, and then click
Refresh. Now the Copy Status of Accounting on Mailbox server NYC-EX11 should display Healthy.
8.
Right-click the Accounting entry that has a Healthy copy status, and then click Properties.
9.
View Status, Copy queue length, and Replay queue length on the General tab, and then click the
Status tab.
10. On the Status tab, view the Seeding, Latest available log time, Last inspected log time, Last
copied log time, and Last replayed log time properties, and then click OK.
Task 4: Suspend the Accounting database copy on NYC-EX11

1.
In the Exchange Management Console, on the Database Management tab, click Accounting.
2.
In the bottom work pane, view the Copy Status column for each database copy.
3.
Right-click the Accounting entry that has a Healthy copy status, and then click Suspend Database
Copy.
4.
In the Suspend Mailbox Database Copy dialog box, type Software Updates being applied, and
then click Yes.
5.
In the bottom work pane, view the Copy Status column for each database copy. The copy status for
the database that is not mounted will change to Suspended.
Results: After this exercise, you should have created and configured a DAG and a mailbox database copy
of the Accounting database. You will also have verified the Accounting database copy and suspended it
on NYC-EX11.
Exercise 2: Deploying Client Access Servers
L8-3
Task 1: Add a host record for CASArray.adatum.com to the Contoso.com zone in

DNS
1.
On NYC-DC1, open the DNS management console from the Administrative Tools folder on the Start
menu.
2.
Expand Forward Lookup Zones, and then expand Contoso.com.
3.
Right-click Contoso.com, and click New Host (A or AAAA).
4.
In the New Host dialog box, type CASArray as the name, and 10.10.0.20 as the IP address.
5.
Click Add Host, click OK and then click Done.
6.
Close the DNS management console.
Task 2: Create a client access array for CASArray.contoso.com

1.
2.
In the Exchange Management Shell, at the PS prompt, type the following command, and then press
Enter.
New-ClientAccessArray Fqdn casarray.contoso.com Name CASArray.contoso.com Site

Default-First-Site-Name
Task 3: Configure the mailbox databases to use the client access array
1.
In the Exchange Management Shell, at the PS prompt, type Get-MailboxDatabase |ft

Name,RPCClientAccessServer, and then press Enter.
2.
At the PS prompt, type Get-MailboxDatabase |Set-MailboxDatabase RpcClientAccessServer

casarray.contoso.com, and then press Enter.
3.
At the PS prompt, type Get-MailboxDatabase |ft Name,RPCClientAccessServer, and then press

Enter. Verify that all databases use casarray.contoso.com as their RpcClientAccessServer.
Results: After this exercise, you should have created a client access array, and then assigned it to the
databases.
L8-4
Exercise 3: Testing the High Availability Configuration

Task 1: Create an SMTP connector associated with NYC-EX11
1.

Hub Transport.
2.
Click the Send Connectors tab, and then in the Actions pane, click New Send Connector.
3.
In the Name box, type Internet Mail, in the Select the intended use for this Send connector dropdown list, select Internet, and then click Next.
4.
5.
In the SMTP Address space dialog box, in the Address box, type *, click OK, and then on the
Address space page, click Next.
6.
On the Network Settings page, click Route mail through the following smart hosts, and then
click Add.
7.
In the Add smart host dialog box, click Fully qualified domain name (FQDN).
8.
In the Fully qualified domain name (FQDN) box, type

nyc-dc1.contoso.com, and then click OK.
9.
On the Network settings page, click Next.
10. On the Configure smart host authenticates settings page, ensure None is selected, and then click
Next.
11. On the Source server page, verify that NYC-EX11 is the only server listed, and then click Next.
12. Click New to create the connector, and then click Finish to close the wizard.
13. Restart the Microsoft Exchange Transport Service.
Task 2: Stop the SMTP server on NYC-DC1, and then send an email message
1.
On NYC-DC1, on the quick launch bar, click Server Manager.
2.
In the console tree, expand Configuration, and then click Services.
3.
In the results pane, right-click Simple Mail Transport Protocol (SMTP), and then click Stop.
4.
On NYC-EX10, open Windows Internet Explorer, and then connect to https://NYCEX11.contoso.com/owa.
5.
Log on as Contoso\Alan using the password Pa$$w0rd, click OK, and then click OK.
6.
Click New to create a new email message.
7.
In the To box, type George Schaller; jane@adatum.com.
8.
In the Subject box, type Shadow Redundancy.
9.
In the message body, type Test email, and then click Send.
Task 3: Use Queue Viewer to locate the message in the queue

1.
On NYC-EX11, in the Exchange Management Console, click Toolbox.
2.
3.
On the Queues tab, locate the entry with nyc-dc1.contoso.com as the next hop domain. If the
message is not visible, complete the following steps:
L8-5
a.
In the Actions pane, click Connect to Server. In the Connect to Server dialog box, click Browse.
b.
In the Select Exchange Server dialog box, click NYC-EX10, click OK, and then click Connect.
4.
On the Queues tab, click Create Filter.
5.
In the first drop-down menu select Delivery Type, in the second drop-down menu select Equals, in
the third drop-down menu select Shadow Redundancy, and then click Apply Filter.
6.
Task 4: Start the SMTP service on NYC-DC1 to allow queued message delivery
1.
On NYC-DC1, in Server Manager, expand Configuration, and then click Services.
2.
In the results pane, right-click Simple Mail Transport Protocol (SMTP), and then click Start.
Task 5: Verify that the messages are removed from the shadow redundancy queue
1.
On NYC-EX11, in the Queue Viewer, click the Queues tab.
2.
Click Remove Filter.
3.
Right-click the queue with a next hop domain of NYC-DC1.contoso.com, and click Retry.
4.
Task 6: Verify the copy status of the Accounting database, and resume the database
copy
1.

Mailbox.
2.
In the results pane, click the Database Management tab, and then click Accounting.
3.
In the bottom work pane, view the Copy Status column for each database copy, right-click the
Accounting entry that has a Suspended copy status, and then choose Properties.
4.
View Status, Copy queue length, and Replay queue length on the General tab, and then click on
OK.
5.
Right-click the Accounting entry that has a Suspended copy status, and then click Resume Database
Copy.
6.
In the Resume Mailbox Database Copy dialog box, click Yes.
7.
Wait until the copy status of the Accounting database copy on NYC-EX11 is Healthy.
Task 7: Perform a switchover on the Accounting database to make the NYC-EX11

copy active
1.
In the bottom work pane, view the Copy Status column for each database copy, right-click the
Accounting entry that has a Healthy copy status, and then click Activate Database Copy.
2.
In the Activate Database Copy dialog box, verify that None is selected, and then click OK.
3.
Wait until the copy status of the Accounting database copy on NYC-EX11 is Mounted.
L8-6
Task 8: Simulate a server failure

1.
On NYC-EX10, in the results pane, click the Database Management tab. Wait until the Accounting
database copy status for NYC-EX10 is Healthy.
2.
On the Host machine, in Hyper-V Manager, select 10165A-NYC-EX11-B, and then in the Actions
pane, click Turn Off. Click Turn Off.
3.
On NYC-EX10, in the Accounting pane, on the Database Copies tab, right-click the empty space,
and then click Refresh.
4.
View the status of the Accounting database in the results pane. The database copy on NYC-EX10 will
change to a status of Mounted, and the database copy on NYC-EX11 will have a status of
ServiceDown.
Results: After this exercise, you should have verified that the mailbox databases can be failed over and
switched between DAG servers, and that Hub Transport shadow redundancy is working properly.
Module 9: Implementing Backup and Recovery
Lab: Implementing and Recovery

Exercise 1: Implementing Disaster Recovery with DAGs
Task 1: Create and configure a DAG using the Exchange Management Shell
L9-1
1.
2.
At the PS prompt, type the following cmdlet, and then press Enter:

C:\FSWDAG1 DatabaseAvailabilityGroupIPaddresses 10.10.0.99
3.
At the PS prompt, type Add-DatabaseAvailabilityGroupServer DAG1 MailboxServer NYC-EX10,

and then press Enter.
4.
At the PS prompt, type Add-DatabaseAvailabilityGroupServer DAG1 MailboxServer NYC-EX11,

and then press Enter. If you get a warning message, you can ignore it.
5.
At the PS prompt, type Add-MailboxDatabaseCopy Mailbox Database 1 MailboxServer NYCEX11, and then press Enter. If you get an error message, make sure all Exchange services are started
on NYC-EX11m and try again.
Task 2: Configure a lagged copy of a mailbox database

1.
In the Exchange Management Shell, type Set-MailboxDatabaseCopy Mailbox Database 1\NYCEX11 ReplayLagTime 5.0:0:0, and then press Enter. This command delays committing transaction
logs to the Accounting database on NYC-EX11 for five days.
2.
At the PS prompt, type Suspend-MailboxDatabaseCopy Mailbox Database 1\NYC-EX11

ActivationOnly Confirm:$false, and then press Enter.
Task 3: Delete the lagged database copy, and reseed the database copy
1.
On NYC-EX11, open Windows Explorer.
2.
In a Windows Explorer window, browse to C:\Program Files\Microsoft\Exchange

Server\V14\Mailbox\Mailbox Database 1.
3.
In a Windows Explorer window, right-click Mailbox Database 1.edb, and then click Delete.
4.
In the Delete File dialog box, click Yes.
5.
Management Console.
6.
In the Exchange Management Console, expand Microsoft Exchange On-Premises (nycex11.contoso.com), expand Organization Configuration, and then click Mailbox.
7.
In the Mailbox pane, on the Database Management tab, click Mailbox Database 1.
8.
In the Mailbox Database 1 pane, on the Database Copies tab, on Mailbox Server NYC-EX11,
right-click Mailbox Database 1, and then click Suspend Database Copy.
9.
In the Suspend Mailbox Database Copy dialog box, click Yes.
L9-2
10. In the Mailbox Database 1 pane, on the Database Copies tab, on Mailbox Server NYC-EX11, rightclick Mailbox Database 1, and then click Resume Database Copy.
11. In the Resume Mailbox Database Copy dialog box, click Yes.
12. In the Mailbox Database 1 pane, on the Database Copies tab, right-click in the empty space, and
then click Refresh. Now the Copy Status of Mailbox Database 1 on Mailbox Server NYC-EX11 should
say Failed and Suspended.
13. In the Mailbox Database 1 pane, on the Database Copies tab, on Mailbox Server NYC-EX11, rightclick Mailbox Database 1, and then click Update Database Copy.
14. In the Update Database Copy wizard, on the Update Database Copy page, click Select a source
server for seeding, and then click Browse.
15. In the Select Mailbox Server dialog box, click NYC-EX10, and then click OK.
16. On the Update Database Copy page, ensure that the Delete them and continue the update
process option is selected, and then click Update.
1.
If a Microsoft Exchange dialog box appears, click Yes.
17. In the Completion pane, click Finish. Now the Copy Status of Mailbox Database 1 on Mailbox Server
NYC-EX11 should display as Healthy.
Results: After this exercise, you should have created and configured a DAG, added a lagged database
copy to the DAG, and reseeded the database copy.
Exercise 2: Backing Up Exchange Server 2010

Task 1: Populate a mailbox
1.
2.
In the Internet Explorer Address bar, type https://NYC-EX10.contoso.com/owa, and then press
ENTER.
3.
Log on as Contoso\Christine using the password Pa$$w0rd.
4.
Click OK to accept the default Microsoft Outlook Web App settings.
5.
Click New to create a new message.
6.
In the To box, type Kern.
7.
In the Subject box, type Message before Backup, and then click Send.
8.
Close Internet Explorer.
Task 2: Perform a backup of the active mailbox database using Windows Server
Backup
L9-3
1.
On NYC-EX10, click Start, click Administrative Tools, and then click Server Manager.
2.
In Server Manager, click Features, and then in the Features Summary pane, click Add Features.
3.
In the Add Features Wizard, expand Windows Server Backup Features, click Windows Server
Backup, and then click Next.
4.
On the Confirm Installation Selections page, click Install. When the installation finishes, click Close.
5.
Click Start, click Administrative Tools, and then click Windows Server Backup.
6.
In Windows Server Backup, in the Actions pane, click Backup Once.
7.
In the Backup Once Wizard, on the Backup Options page, select Different options, and then click
Next.
8.
On the Select Backup Configuration page, select Custom, and then click Next.
9.
On the Select Items for Backup page, click Add items, in Select Items window, select Local disk
(C:), and then click OK.
10. On the Select Items for Backup page, click Advanced Settings, click the VSS Settings tab, select
VSS full Backup, click OK, and then click Next.
11. On the Specify Destination Type page, verify that Local drives is selected, and then click Next.
12. On the Select Backup Destination page, in the Backup destination drop-down list, select Allfiles
(D:), and then click Next.
13. On the Confirmation page, click Backup. The backup will take approximately 10-15 minutes.
14. On the Backup Progress page, click Close.
15. Close Windows Server Backup.
Results: After this exercise, you should have added the Windows Server Backup feature, and created a
backup of all active databases.
L9-4
Exercise 3: Restoring a Database in a DAG

Task 1: Delete messages in a mailbox
1.
Open Internet Explorer.
2.
ENTER.
3.
Log on as Contoso\Kern using the password Pa$$w0rd.
4.
Click OK to accept the default Outlook Web App settings.
5.
Right-click the message with the subject Message before Backup, and then click Delete.
6.
In the left pane, right-click Deleted Items, and then click Empty Deleted Items.
7.
In the Empty Deleted Items box, click Yes.
8.
Task 2: Restore the databases using Windows Server Backup

1.
On NYC-EX10, click Start, click Programs, click Administrative Tools, and then click Windows
Server Backup.
2.
In Windows Server Backup, in the Actions pane, click Recover.
3.
In the Recovery Wizard, on the Getting Started page, verify that This Server (NYC-EX10) is selected,
4.
On the Select Backup Date page, click Next.
5.
On the Select Recovery Type page, click Applications, and then click Next.
6.
On the Select Application page, select the Do not perform a roll-forward recovery of the
application database check box, and then click Next.
7.
On the Specify Recovery Options page, click Recover to original location, and then click Next.
8.
On the Confirmation page, click Recover.
9.
On the Recovery Progress page, when the restore finishes, click Close.
10. Close Windows Server Backup.
Task 3: Verify the recovery

1.
Open Internet Explorer.
2.
Enter.
3.
Log on as Contoso\Kern using the password Pa$$w0rd.
4.
Verify that the message with the subject Message before Backup is found in the Inbox.
5.
Results: After this exercise, you should have deleted a message from a mailbox, recovered all Exchange
Server 2010 databases using Windows Server Backup, and verified that the recovery was successful.
Exercise 4: Recover a Lagged Database Copy to a Point in Time

Task 1: Delete messages and folders from the mailbox
L9-5
1.
On NYC-EX11, open Internet Explorer, connect to https://NYC-EX10.contoso.com/owa, and then

press Enter.
2.
Log on as Contoso\Spencer using the password Pa$$w0rd.
3.
Expand Inbox, expand OldEmail, and review the items and folders in the folder.
4.
Right-click OldEmail, click Delete, and then click Yes.
5.
In the left pane, right-click Deleted Items, and then click Empty Deleted Items.
6.
In the Empty Deleted Items box, click Yes.
7.
Task 2: Suspend the lagged database, and copy it to the target folder
1.
2.

Organization Configuration, and then click Mailbox.
3.
In the Mailbox pane, on the Database Management tab, click Mailbox Database 1.
4.
In Mailbox Database 1 pane, in the Database Copies tab, on Mailbox Server NYC-EX11, right-click
Mailbox Database 1, and then click Suspend Database Copy.
5.
In the Suspend Mailbox Database Copy dialog box, click Yes.
6.
Open a Windows Explorer window.
7.
In the Windows Explorer window, browse to C:\Program Files\Microsoft\Exchange

Server\V14\Mailbox\Mailbox Database 1.
8.
Select all files by pressing the CRTL+A keys, right-clicking on the selection, and then clicking Copy.
9.
Create a new folder in C:\Lag, and paste the files and folders into the C:\Lag folder.
Task 3: Configure the database recover time by deleting log files before merging
them into the database
1.
In a Windows Explorer window, verify that C:\Lag is the open folder. Click the Date modified column
header to sort the files by date and time.
2.
Delete all of the log files (E*.log files) created in the last 15 minutes.
3.
If there is a .chk file in the folder, delete the file.
4.
Click Start, point to All Programs, click Accessories, and then click Command Prompt.
5.
At the command prompt, type CD \Lag, and then press Enter.
6.
At the command prompt, type Eseutil.exe /r E00 /a /in, and then press Enter. This process will
replay the old transactional log files, and make the database as current as your provided log files.
7.
At the command prompt, type Eseutil.exe /P Mailbox Database 1.edb, press Enter, and then click
OK.
L9-6
8.
At the command prompt, type Eseutil.exe /mh Mailbox Database 1.edb, and then press Enter.
Verify that no errors are reported.
Task 4: Create and mount a recovery database for the lag database
1.
2.
At the PS prompt, type the following cmdlet, and then press Enter:
New-MailboxDatabase -Recovery -Name LagRecovery -Server NYC-EX11 -EDBFilePath

"C:\Lag\Mailbox Database 1.edb" -LogFolderPath "C:\Lag
3.
At the PS prompt, type Mount-Database LagRecovery, and then press Enter.
4.
At the PS prompt, type Get-MailboxStatistics Database LagRecovery, and then press Enter. This
will list all mailboxes that are part of the recovery database.
Task 5: Restore the mailbox from the recovery database, and verify successful
recovery
1.
In Exchange Management Shell, at the PS prompt, type the following cmdlet, and then press Enter:
New-MailboxRestoreRequest SourceStoreMailbox Spencer Low SourceDatabase LagRecovery

AllowLegacyDNMismatch TargetMailbox Lag TargetRootFolder Restore Spencer
Note Example of note reader aid. If you receive an error, ensure that all Microsoft
Exchange services on NYC-EX10 and NYC-EX11 that are configured to start automatically are
started. If any are not started, start them and run the command again.
2.
At the PS prompt, type Get-MailboxRestoreRequest, and then press Enter. Make sure the status
displays as Completed.
3.
On NYC-EX11, open Internet Explorer, connect to https://NYC-EX10.contoso.com/owa, and then

press Enter.
4.
Log on as Contoso\Lag using the password Pa$$w0rd, and then click OK.
5.
In the folder pane, expand Restore Spencer, expand Inbox, expand OldEmail, and verify that the
messages and folders are correct. You can now use Microsoft Outlook 2010 to move the required
messages to the original mailbox.
Results: After this exercise, you should have deleted messages and folders from a mailbox, suspended the
lagged database copy, and copied the lagged database to a different location. Then. you will have deleted
the transactional log files that included the changes you wanted to revert, the .chk file, and used ESEUTIL
to get the database to a clean shutdown state. Finally, you will have created a recovery database using the
database file from the lag database, and recovered a mailbox from the recovery database.
L10-1
Lab A: Configuring Transport Rules, Journal Rules, and Multi-Mailbox Search
Module 10: Configuring Messaging Policy and Compliance
Lab A: Configuring Transport Rules, Journal

Rules, and Multi-Mailbox Search
1.
2.
Expand Microsoft Exchange On-Premises, expand Organization Configuration, and then click
Hub Transport.
3.
4.
On the Introduction page, type Internet Connector as the connector name. In the Select the
intended use for this Send connector drop-down list, click Internet, and then click Next.
5.
6.
In the Address space field, type *, click OK, and then click Next.
7.
On the Network settings page, click Route mail through the following smart hosts, and then
click Add.
8.
In the IP address field, type 10.10.0.10, click OK, and then click Next.
9.
On the Configure smart host authentication settings page, click Next.
10. On the Source Server page, click Next, click New, and then click Finish.
Exercise 1: Configuring Transport Rules

Task 1: Create a transport rule that adds a disclaimer to all messages sent to the
Internet
1.
On NYC-EX10, in the Exchange Management Console, expand Organization Configuration, click

Hub Transport, and then click New Transport Rule.
2.
On the Introduction page, in the Name box, type Internet Email Disclaimer, and then click Next.
3.
On the Conditions page, in the Step 1: Select condition(s) area, select the sent to users that are
inside or outside the organization, or partners check box.
4.
In the Step 2: Edit the rule description by clicking an underlined value area, click Inside the
organization.
5.
In the Select scope dialog box, under Scope, click Outside the organization, and then click OK.
6.
On the Conditions page, click Next.
7.
On the Actions page, in the Step 1: Select actions area, select append disclaimer text and fallback
to action if unable to apply.
8.
In the Step 2: Edit the rule description by clicking an underlined value area, click disclaimer text.
9.
In the Specify disclaimer text box, type This email is intended solely for the use of the individual
to whom it is addressed, and then click OK.
10. On the Actions page, click Next.

11. On the Exceptions page, click Next, review the rule description, click New, and then click Finish.
Task 2: Enable message classifications for Outlook 2010 clients
L10-2
1.
2.
At the PS prompt, type new-messageclassification -Name CompanyConfidential displayname

Company Confidential -senderdescription Do not forward to the Internet, and then press
Enter.
3.
At the PS prompt, type cd c:\Program Files\Microsoft\Exchange Server\v14\scripts, and then

press Enter.
4.
At the PS prompt, type .\Export-OutlookClassification.ps1 > c:\classifications.xml, and then press

Enter.
5.
On NYC-CL1, click Start, type \\nyc-ex10\c$, and then press Enter.
6.
Copy the \\NYC-EX10\c$\classifications.xml file to drive C.
7.
In the User Account Control dialog box, in the User name box, type Administrator, in the
Password box, type Pa$$w0rd, and then click Yes.
8.
Click Start, type \\nyc-ex10\d$\Labfiles, and then press Enter.
9.
Double-click EnableClassification.reg, click Yes, and then click OK.
10. Close the Explorer window.

11. Close Exchange Management Shell window.
Task 3: Create a transport rule that blocks all messages with a Company Confidential
classification from being sent to the Internet
1.
On NYC-EX10, in the Exchange Management Console, in the Action pane, click New Transport Rule.
2.
On the Introduction page, in the Name box, type Internet Confidential Rule, and then click Next.
3.
On the Conditions page, in the Step 1: Select condition(s) area, select the marked with
classification check box.
4.
In the Step 2: Edit the rule description by clicking an underlined value area, click classification.
5.
In the Select message classification dialog box, click Company Confidential, and then click OK.
6.
On the Conditions page, click Next.
7.
On the Actions page, in the Step 1: Select action(s) area, select the send rejection message to
sender with enhanced status code check box.
8.
In the Step 2: Edit the rule description by clicking an underlined value area, click rejection
message.
9.
In the Specify rejection message text box, type Company confidential emails cannot be sent to
the Internet, and then click OK.
10. In Step2, click enhanced status code, type 5.7.1, and then click OK.
11. On the Actions page, click Next.
12. On the Exceptions page, click Next, review the rule description, click New, and then click Finish.
L10-3
Task 4: Enable AD RMS integration for the organization
1.
On NYC-DC1, open a Windows Explorer window, browse to

C:\inetpub\wwwroot\_wmcs\certification, right-click ServerCertification.asmx, and then click
Properties.
2.
In the Servercertification.asmx Properties dialog box, on the Security tab, click Edit.
3.
In the Permissions for Servercertification.asmx dialog box, click Add.
4.
In the Select Users, Computers, Service Accounts, or Groups dialog box, click Object Types, select
the Computers check box, and then click OK.
5.
In the Enter the object names to select field, type Exchange Servers; IIS_IUSRS, and then click OK
three times.
6.
On NYC-DC1, open a command prompt, type IISReset, and then press Enter. Wait for the service
restart, and then close the command prompt.
7.
8.
At the PS prompt, type set-irmconfiguration InternalLicensingEnabled:$true, and then press

Enter. This cmdlet enables AD RMS encryption for messages sent inside the organization.
Task 5: Configure a transport rule that applies the Do Not Forward AD RMS template
to all messages with the word confidential or private in the subject
1.
On NYC-EX10, in the Exchange Management Console, under Organization Configuration, click Hub
Transport.
2.
In the Action pane, click New Transport Rule.
3.
On the Introduction page, in the Name field, type Confidential E-Mail Rule.
4.
Verify that Enable Rule is selected, and then click Next.
5.
On the Conditions page, under Step 1, select the when the Subject field contains specific words
check box.
6.
Under Step 2, click the specific words link.
7.
In the Specify words dialog box, type Confidential, click Add, type Private, click Add, and then click
OK.
8.
Click Next.
9.
On the Actions page, under Step 1, select rights protect message with RMS template.
10. Under Step 2, click the RMS template link.

11. In the Select RMS template dialog box, click Do Not Forward, and then click OK.
12. Click Next twice, click New, and then click Finish.
Task 6: Configure a moderated group

1.
On NYC-EX10, in the Exchange Management Console, under Recipient Configuration, click

Distribution Group.
2.
In the middle pane, right-click Projects, and then click Properties.
3.
On the Mail Flow Settings tab, double-click Message Moderation.
L10-4
4.
In the Message Moderation dialog box, select the Messages sent to this group have to be
approved by a moderator check box.
5.
Under Specify group moderators, click Add.
6.
In the Select Recipient Entire Forest dialog box, click Andrea Dunker, and then click OK three
time. If a warning window appears, click OK.
Task 7: Test the transport rule configuration

1.
On NYC-CL1, open Microsoft Outlook 2010.
2.
Create a new message, and then send it to Carol@adatum.com.
3.
Create another message to Carol@adatum.com, click the Options tab, and then click the arrow on
the Permission button.
4.
Click Company Confidential, and then send the message.
5.
On NYC-DC1, open a Windows Explorer window. Browse to C:\inetpub\mailroot\queue folder, and

then double-click the .eml file in the folder.
6.
click OK. Click Notepad, and then click OK.
7.
Scroll to the end of the message, and verify that the disclaimer has been added to the message.
8.
Confirm that the second message did not arrive, and that you received a non-delivery report stating
that Company confidential email cannot be sent to the Internet.
9.
In Outlook 2010, create a new message, and then send it to the Projects distribution group.
10. Open Windows Internet Explorer, and connect to https://nyc-ex10.contoso.com/owa. Log on as

Contoso\Andrea, with the password, Pa$$w0rd. If prompted for mailbox language settings, click
OK.
11. Verify that the message to the Projects distribution list has arrived.
12. Open the email message from Terri Chudzik, and click Approve.
13. Create a new message with the subject of Private, and then send the message to Terri.
15. In Outlook, verify that Terri received the message and that it has the Do Not Forward template
applied. Verify that the Forward option is not available on the message.
16. Close Windows Explorer on NYC-DC1.
Results: After this exercise, you should have configured a transport rule that ensures that all messages
sent to users on the Internet include a disclaimer of which the legal department approves. Additionally,
you should have configured a transport rule that ensures that messages with a Company Confidential
classification are not sent to the Internet. You should also have configured a transport rule that applies the
Do Not Forward AD RMS template to all messages with the words confidential or private in the
subject. Finally, you should have configured a moderated group by using the All Company distribution
group.
Exercise 2: Configuring Journal Rules

Task 1: Create a mailbox for the IT department journaling messages
1.
On NYC-EX10, in the Exchange Management Console, click Recipient Configuration.
2.
In the Action pane, click New Mailbox to start the New Mailbox Wizard.
3.
On the Introduction page, ensure that User Mailbox is selected, and then click Next.
4.
5.
On the User Information page, type the following information, and then click Next:
First name: IT Journal Mailbox
User Logon name (User Principal Name): ITJournal
Password: Pa$$w0rd
L10-5
6.
On the Mailbox Settings page, type ITJournal as the Alias.
7.
Select the Specify the mailbox database rather than using a database automatically selected
check box, click Browse, click Mailbox Database 1, click OK, and then click Next.
8.
On the Archive Settings page, click Next.
9.
On the New Mailbox page, click New, and then click Finish.
Task 2: Create a journal rule that saves a copy of all messages sent to and from IT
department members
1.
In the Exchange Management Console, in the Organization Configuration work area, click Hub
Transport.
2.
In the Action pane, click New Journal Rule to start the New Journal Rule wizard.
3.
On the New Journal Rule page, in the Rule name box, type IT Department Message Journaling.
4.
Next to Send Journal reports to e-mail address, click Browse, click IT Journal Mailbox, and then
click OK.
5.
Under Scope, ensure Global all messages is selected.
6.
Select the Journal messages for recipient check box, and then click Browse.
7.
In the Select Recipient dialog box, click IT, and then click OK.
8.
On the New Journal Rule page, click New, and then click Finish.
Task 3: Test the journal rule

1.
On NYC-CL1, if required, open Outlook 2010.
2.
Create a new message, and then send it to Andrea Dunker. Andrea is a member of the IT group.
3.
Connect to Outlook Web App as Andrea, and confirm that the message was delivered. Reply to the
message.
4.
Connect to Outlook Web App as Contoso\ITJournal and verify that the journaled message is in the
Inbox.
5.
L10-6
Results: After this exercise, you should have created a mailbox for the IT department journaling messages,
and then created a journal rule that saves a copy of all messages sent to and from IT department
members.
L10-7
Exercise 3: Configuring Multi-Mailbox Search

Task 1: Create and configure the MailboxAuditor account
1.
On NYC-EX10, in the Exchange Management Console, click Recipient Configuration.
2.
In the Action pane, click New Mailbox to start the New Mailbox Wizard.
3.
On the Introduction page, ensure that User Mailbox is selected, and then click Next.
4.
5.
On the User Information page, type the following information, and then click Next:
First name: Mailbox Auditor
User Logon name (User Principal Name): MailboxAuditor
Password: Pa$$w0rd
6.
On the Mailbox Settings page, type MailboxAuditor as the Alias.
7.
Select the Specify the mailbox database rather than using a database automatically selected
check box, click Browse, click Mailbox Database 1, click OK, and then click Next.
8.
On the Archive Settings page, click Next.
9.
On the New Mailbox page, click New, and then click Finish.
10. In the recipient list, right click IT Journal Mailbox, and then click Manage Full Access Permission.
11. On the Manage Full Access Permission page, click Add, click Mailbox Auditor, and then click OK.
12. Click Manage, and then click Finish.
13. On NYC-DC1, open Active Directory Users and Computers, and then, in the Microsoft Exchange
Security Groups organizational unit (OU), double-click the Discovery Management group.
14. In the Discovery Management Properties dialog box, on the Members tab, click Add.
15. Type Mailbox Auditor, and then click OK twice.
16. On NYC-EX10, open Exchange Management Console, expand Microsoft Exchange On-Premises,
expand Recipient Configuration, and then click Mailbox.
17. In result pane, right-click Discovery Search Mailbox, and then select Manage Full Access
Permission.
18. Click Add.
19. Select Mailbox Auditor, and then click OK.
20. Click Manage and then click Finish.
Task 2: Test Multi-Mailbox Search configuration

1.
On NYC-CL1, in Outlook 2010, create and send a new message with the following configuration:
To: Sten; Carol@adatum.com
Subject: Customer Order
Message body. Here is the order for Carol at Contoso. Her customer number is 1111-1111.
L10-8
2.
Open a new instance of Internet Explorer on NYC-CL1, and then connect to https://NYCEX10.Contoso.com/owa. Log on as Contoso\MailboxAuditor, with the password, Pa$$w0rd. In
the Outlook Web App Regional Settings window, click OK.
3.
In the Outlook Web Access session, click Options, and then click See All Options.
4.
Click the arrow next to Mail> Options:Manage Myself.
5.
In the Select what to manage drop-down list, click My Organization.
6.
In the left pane, click Mail Control, and then under Multi-Mailbox Search, click New.
7.
In the Keywords box, type Customer Number.
8.
Expand Mailboxes to Search.
9.
Under Select mailboxes to search, click Add.
10. In the Select Mailbox window, click Terri Chudzik and click Add. Click Sten Faerch, click Add, and
then click OK.
11. Expand Search Name, Type, and Storage Location.
12. In the Search name field, type Customer Number Discovery. Select Copy the search results to the
destination mailbox.
13. Next to Select a mailbox in which to store the search results, click Browse.
14. In the Select Mailbox to Store Search Results window, click Discovery Search Mailbox, and then
click OK.
15. Select the Send me an e-mail when the search is done check box, and then click Save.
16. Wait until the search finishes, then, in the lower-right pane, click Open.
17. In the Outlook Web Access window, click OK.
18. In the Navigation pane, expand the new discovery folder named Customer Number Discovery.
19. Click the Results folder, and ensure that the message from Terri appears in the center pane.
Results: After this exercise, you should have configured and tested the Mailbox Auditor account and
tested Multi-Mailbox Search.
L10-9
Lab B: Configuring Archive Mailboxes and

Retention Policies
Exercise 1: Configuring Archive Mailboxes
Task 1: Create a mailbox database that will be used to store archive mailboxes
1.
2.
Expand Microsoft Exchange On-Premises, and then expand Organization Configuration.
3.
Click Mailbox.
4.
In the Action pane, click New Mailbox Database.
5.
In the New Mailbox Database wizard, in the Mailbox database name field, type Archive
Database, and then click Browse.
6.
Select NYC-EX11, click OK, and then click Next.
7.
On Set Paths page, click Next, and then click New.
8.
Click Finish.
Task 2: Create an archive mailbox for all members of the IT group, and verify its
functionality
1.
On NYC-EX10, in Exchange Management Console, expand Recipient Configuration, and then click
Mailbox.
2.
Click the Organizational Unit tab.
3.
Select all users that are located in Contoso.com/IT OU by clicking the first name on the list, pressing
and holding the SHIFT key, and then clicking the last name on the list.
4.
Right-click the selected group of names, and then select Enable Archive on drop-down menu.
5.
Ensure that Create a local archive is selected, and then click Select a specific mailbox database
rather than having one selected automatically.
6.
Click Browse.
7.
Select Archive Database, and then click OK twice.
8.
On NYC-CL1, ensure that you are logged on as Terri, and then start Outlook 2010.
9.
When Outlook 2010 starts, ensure that the Archive Terri@Contoso.com mailbox is displayed in
the left pane.
Task 3: Create an archive policy that moves all messages from the primary mailbox to
the archive mailbox after 36 months
1.

click Mailbox.
2.
In the Actions pane, click New Retention Policy Tag.
3.
In Tag name field, type Move to archive after 36 months.
4.
In the Tag Type drop-down list, select Personal Folder.
5.
In Age limit for retention (days), type 1080.
6.
In the Action to take when the age limit is reached drop-down list, select Move to Archive.
7.
8.
In the Exchange Management Console, in the Actions pane, click New Retention Policy.
9.
In the Name field, type IT Archive Policy.
10. Click Add, select Move to archive after 36 months, and then click OK.
11. Click Next.
12. On Select Mailboxes, click Add.
13. In Select Mailbox Entire Forest, click Scope menu, and then click Modify Recipient Picker
Scope.
14. Click View all recipients in specified organizational unit, and then click Browse.
15. Click IT, and then click OK twice.
16. After the scope is changed, select all users in the list, and then click OK.
17. Click Next., click New, and then click Finish.
Results: After this exercise, you should have configured archive mailboxes for all members of the IT
group.
L10-10
L10-11
Exercise 2: Configuring Retention Policies

Task 1: Create and configure retention tags
1.

then click Mailbox.
2.
In the Actions pane, click New Retention Policy Tag.
3.
In the Tag name field, type Contoso - Deleted Items.
4.
In the Tag Type drop-down list, select Deleted Items.
5.
In the Age limit for retention (days) field, type 30.
6.
In Action to take when the age limit is reached, select Permanently Delete.
7.
In the Comments field, type Deleted Items are purged after 30 days.
8.
Click New., and then click Finish.
9.
On NYC-EX10, run Exchange Management Shell.
10. At the PS prompt, type the following cmdlet, and then press Enter.
New-RetentionPolicyTag "Contoso - DefaultMoveToArchive" -Type All -Comment "Items

without a retention tag are moved to archive after 1 year." -RetentionEnabled $true AgeLimitForRetention 365 -RetentionAction MoveToArchive
11. At the PS prompt, type the following cmdlet, and then press Enter.
New-RetentionPolicyTag "Contoso - BusinessCritical" -Type Personal -Comment "Business

Critical messages are moved to the archive after 3 years." -RetentionEnabled $true AgeLimitForRetention 1095 -RetentionAction MoveToArchive
12. Restore Exchange Management Console, and then verify that the Retention Policy Tags from steps
10 and 11 are created. You may need to refresh the view in the Exchange Management Console
before the new Retention Policy Tags are displayed.
Task 2: Create and configure retention policies for the Marketing group
1.

then click Mailbox.
2.
In the Actions pane, click New Retention Policy.
3.
In the Name field, type DeletedItems and Archive policy, and then click Add
4.
Select both the Contoso DefaultMoveToArchive and Contoso - Deleted Items tags, click OK,
5.
On the Select Mailboxes page, click Add.
6.
In Select Mailbox Entire Forest, click Scope menu, and then click Modify Recipient Picker
Scope.
7.
Click View all recipients in specified organizational unit, and then click Browse.
8.
Click Marketing, and then click OK twice.
9.
After the scope changes, select all users in the list, and then click OK.
10. Click Next., click New, and then click Finish.
Task 3: Create and configure retention policies for the Research group
1.
On NYC-EX10, run the Exchange Management Shell.
2.
At the PS prompt, type the following cmdlet, and then press Enter.
New-RetentionPolicy "Contoso-Production" -RetentionPolicyTagLinks "Contoso DefaultMoveToArchive","Contoso - Deleted Items","Contoso BusinessCritical
L10-12
3.
Restore Exchange Management Console.
4.
Expand Organization Configuration, and then click Mailbox.
5.
Click the Retention Policies tab.
6.
Ensure that policy Contoso-Production is created.
7.
Right-click the Contoso-Production policy, and then select Properties.
8.
Click the Mailboxes tab, and then click Add.
9.
In Select Mailbox Entire Forest, click the Scope menu, and then click Modify Recipient Picker
Scope.
10. Click View all recipients in specified organizational unit, and then click Browse.
11. Click Research, and then click OK twice.
12. After the scope changes, select all users in the list, and then click OK twice.
Results: After this exercise, you will have configured Retention Tags and retention policies for the
Marketing and Research groups.
Module 11: Securing Microsoft Exchange Server 2010

Exercise 1: Configuring Delegated Permissions
Task 1: Configure permissions for the IT group
L11-1
1.
On NYC-EX10, log on as Contoso\Administrator using the password Pa$$w0rd.
2.
Click Start, click All Programs, click Administrative Tools, and then open Active Directory Users
and Computers.
3.
Expand Contoso.com, double-click Microsoft Exchange Security Groups, and then double-click
Server Management.
4.
On the Members tab, click Add.
5.
In the Enter the object names to select field, type IT, and then press OK twice.
6.
7.
In the Exchange Management Shell, at the PS prompt, type Get-user OrganizationalUnit "IT" |
set-user RemotePowerShellEnabled $True, and then press Enter.
Task 2: Configure permissions for the SupportDesk group

1.
On NYC-EX10, in the Exchange Management Shell, at the PS prompt, run the following cmdlet:
New-RoleGroup Name SupportDesk roles Mail Recipients, "Mail Recipient Creation",

"Distribution Groups"
2.
On NYC-EX10, open the Exchange Management Console, expand Microsoft Exchange OnPremises, and then click Toolbox.
3.
Double-click Role Based Access Control (RBAC) User Editor.
4.
Log on as Contoso\Administrator using the password Pa$$w0rd.
5.
Click SupportDesk, and then click Details.
6.
Under Members, click Add.
7.
Add Andrea Dunker to the group, and then click OK.
8.
Click Save.
9.
Task 3: Verify delegated permissions

1.
On NYC-EX11, log on as Contoso\Terri using the password Pa$$w0rd, and then open the Exchange
Management Console.
2.

Organization Configuration, click Mailbox, and in the results pane, double-click the first mailbox
database (Accounting).
3.
Click the Limits tab, verify that you can modify the mailbox database settings, and then click Cancel.
L11-2
4.
Under Organization Configuration, click Hub Transport. Verify that many of the tabs normally
shown in this view are not available.
5.
On the Accepted Domains tab, double-click Contoso.com, verify that you cannot modify the
settings, and then click Cancel.
6.
Expand Recipient Configuration, click Mailbox, double-click one of the mailboxes, verify that you
cannot modify the mailbox properties, and then click Cancel.
7.
Log off of NYC-EX11.
8.
On NYC-EX10, open Internet Explorer, and connect to https://nyc-ex10.contoso.com/ecp.
9.
Log on as Contoso\Andrea using the password Pa$$w0rd, and then click Sign in. If the Regional
Settings page appears, click OK.
10. On the Mailboxes tab, click Alan Brewer, and then click Details.
11. Click Organization, verify that you can modify the user properties, and then click Save.
12. Click the Distribution Groups tab, double-click Marketing, and then verify that you can modify the
groups properties. For example, edit the description on the General tab, and then click Save.
13. Click Mailboxes, and verify that there is no option to create a new mailbox.
14. Close the Exchange Control Panel and close Internet Explorer.
Results: After this exercise, you should have configured delegated permissions.
Exercise 2: Configuring Audit Logging

Task 1: Verify permissions on the support@contoso.com account
1.
2.

Recipient Configuration, and then click Mailbox.
3.
In the central pane, right-click Customer Support.
4.
Click Manage Full Access Permission.
5.
Verify that Contoso\Andrea and Contoso\Arno are displayed, and then click Cancel.
6.
Repeat the above steps for the Manage Send As Permission.
Task 2: Enable audit logging on the support@contoso.com mailbox

1.
2.
Set-Mailbox -Identity "Customer Support" -AuditDelegate SendAs,SendOnBehalf

-AuditEnabled $true
3.
Minimize the Exchange Management Shell.
Task 3: Perform SendAs activity on the support@contoso.com mailbox
L11-3
1.
On NYC-EX10, open Internet Explorer, and then connect to https://nyc-ex10.contoso.com/owa.
2.
Log on as Contoso\Andrea using the password Pa$$w0rd. If the Regional Settings page appears,
click OK.
3.
Click New, and then in the Untitled Message window, click Options.
4.
Click Show From, and then click OK.
5.
In the From field, delete Andrea Dunker, and then type support@contoso.com.
6.
In the To field, type administrator.
7.
In the Subject field, type test message.
8.
In the message body, write some text, and then click Send.
9.
Close Microsoft Outlook Web App.
Task 4: Verify that the activity is logged

1.
On NYC-EX10, open Internet Explorer, and then connect to https://nyc-ex10.contoso.com/ecp.
2.
Log on as Contoso\Administrator using the password Pa$$w0rd.Click Roles and Auditing.
3.
Click Auditing.
4.
Click Run a non-owner mailbox access report.
5.
In the Start date field, enter 2011/January/01.
6.
In the End date field, enter tomorrows date.
7.
Click Select Mailboxes.
8.
Find the Customer Support mailbox, click Add, and then click OK.
9.
In the Search for access by drop-down list, select All non-owners, and then click Search.
L11-4
10. Verify that in the Search Results box, the Customer Support mailbox appears, and that in the Details
box, there is a description of the activity that you performed in Task 3.
11. Click Close
12. Exit the Exchange Control Panel.
Task 5: Verify the administrator audit logging configuration

1.
On NYC-EX10, restore the Exchange Management Shell, and run the following cmdlet:
Get-AdminAuditLogConfig
2.
In the results list, verify that AdminAuditLogEnabled is set to True. Review the other values in the
list.
3.
Minimize the Exchange Management Shell.
Task 6: Make a change to Terri Chudziks mailbox

1.
2.
Expand Recipient Configuration, click Mailbox, find Terri Chudzik on the list in the central pane,
right-click Terri Chudzik, and then select Properties.
3.
Click the Mailbox Settings tab, click Storage Quotas, and then click Properties.
4.
In the Deleted Item retention section, clear the Use mailbox database defaults check box, and then
in the Keep deleted items for (days) field, type 20.
5.
Click OK twice.
6.
Minimize the Exchange Management Console.
Task 7: Verify that the change was logged

1.
On NYC-EX10, restore the Exchange Management Shell, and run the following cmdlet:
Search-AdminAuditLog -Cmdlets Set-Mailbox -StartDate 01/01/2011 -EndDate (Tomorrows

date) ObjectID contoso.com/IT/Terri
2.
Review the results, and ensure they contain the action performed in Task 6. You might also see logs
about other actions on this account.
Results: After this exercise, you should have configured audit logging.
Exercise 3: Configuring RBAC Split Permissions

Task 1: Create a new role group called HRAdmins, and assign permissions
L11-5
1.
On NYC-EX10, restore the Exchange Management Shell.
2.
In the Exchange Management Shell, run the following cmdlets to create a new group and to assign
the appropriate permissions:
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
New-ManagementRoleAssignment -Role "Mail Recipients" -SecurityGroup "HRAdmins"

Delegating
3.
In the Exchange Management Shell, run the following cmdlet to assign a member to the HRAdmins
group:
Add-RoleGroupMember "HRAdmins" -Member Marko
4.
Open Active Directory Users and Computers console, expand Contoso.com and click on
Microsoft Exchange Security Groups.
5.
In the right pane click on HRAdmins security group and click Properties
6.
Click Managed By tab, click Change and type HRAdmins and press Enter.
7.
Select option Manager can update membership list and click OK.
8.
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 NYC-EX10, in the Exchange Management Shell, run the following cmdlet to find all of the regular
and delegating role assignments to the Mail Recipient Creation role:
Get-ManagementRoleAssignment -Role "Mail Recipient Creation" | Format-Table Name, Role,

RoleAssigneeName Auto
2.
After you see which groups have delegating 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
3.
On prompt, type A and press Enter.
4.
Repeat steps 1, 2 and 3 for both the Security Group Creation and Membership and the Mail
Recipients roles.
Task 3: Verify the permissions
L11-6
1.
On NYC-EX10, restore the Exchange Management Console, expand Recipients Configuration, click
Mailbox, and then in the Actions pane, click New Mailbox.
2.
On the New Mailbox page, click Next.
3.
4.
In the First name field, type Test, in the Last name field, type User, and then in the User logon
name field, type testuser.
5.
In both the Password field and the Confirm password field, type Pa$$w0rd.
6.
Click Next three times, and then click New.
7.
Ensure that the Failed message appears, and that you cannot create a user mailbox.
8.
Log off NYC-EX10.
9.
Log on to NYC-DC1 as Contoso\Administrator using the password Pa$$w0rd.
10. Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users
and Computers.
11. On the toolbar, click New User.
12. In the First name field, type Test, in the Last name field, type User, and then in the User logon
name field, type testuser.
13. In both the Password field and the Confirm password field, type Pa$$w0rd.
14. Click Next, and then click Finish.
15. Verify that you were able to create a new user in the Active Directory Users and Computers console.
16. Log on to NYC-EX11 as Contoso\Marko using the password Pa$$w0rd.
17. Open the Exchange Management Console, expand Recipients Configuration, click Mailbox, and
then in the Actions pane, click New Mailbox.
18. On the New Mailbox page, click Next.
19. On the User Type page, click Next.
20. In the First name field, type Test, in the Last name field, type User2, and then in the User logon
name field, type testuser2@contoso.com.
21. In both the Password field and the Confirm password field, type Pa$$w0rd.
22. Click Next three times, and then click New.
23. Ensure that you were able to create a user and a mailbox for the user.
24. Close the Exchange Management Console.
Results: After this exercise, you should have configured RBAC split permissions.
L12-1
Module 12: Monitoring and Troubleshooting Microsoft

Lab: Monitoring and Troubleshooting

Exercise 1: Monitoring Exchange Server 2010
Task 1: Create a new data collector set named Exchange Monitoring
1.
On NYC-EX10, click Start, click Administrative Tools, and then click Performance Monitor.
2.
In the navigation pane, expand Data Collector Sets, and then click User Defined.
3.
Click the Action menu, click New, and then click Data Collector Set.
4.
In the Create new Data Collector Set wizard, in the Name box, type Exchange Monitoring, select
Create manually (Advanced), and then click Next.
5.
Select the Performance Counter check box, and then click Finish.
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:
LDAP Search Time
LDAP Searches Timed Out per Minute
Long Running LDAP Operations/min
L12-2
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 Reliability and Performance Monitor, in the navigation pane, click Exchange Monitoring, click
the Action menu, click New, and then click Data Collector.
2.
In the Create new Data Collector wizard, in the Name box, type Mailbox Role Monitoring, select
Performance counter data collector, 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, and then click RPC Averaged Latency.
Press and hold the Ctrl key, click the following items, and then click Add:
RPC Num. of Slow Packets
RPC Operations/sec
RPC Requests
5.
In the Available counters object list, expand MSExchangeIS Mailbox, click Messages Queued for
Submission, and then click Add.
6.
In the Available counters object list, expand MSExchangeIS Public, click Messages Queued for
Submission, 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 set.
Task 4: Verify that the data collector set works properly

1.
In the Reliability and Performance Monitor, in the navigation pane, click Exchange Monitoring, click
the Action menu, and then click Start.
2.
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
NYC-EX10_DateTime, and then review the report.
4.
Close the Performance Monitor.
Results: After this exercise, you should have created a data collector set for monitoring NYC-EX10 that
uses the recommended performance counters.
L12-3
Exercise 2: Troubleshooting Database Availability

Preparation
1.
On NYC-EX10, ensure that all databases are mounted.
2.

d:\Labfiles\Lab12Prep2.ps1, and then press Enter. This script will simulate database failure.
3.
When prompted, type N, and then press Enter.
4.
Task 1: Identify the scope of the problem
1.
2.

3.
In the work pane, click the Database Management tab, and then view the list of databases, noting
that MailboxDB100 is not mounted.

1.
In the work pane, right-click MailboxDB100, and then click Mount database. Review the warning
message, and then click No.
2.
On NYC-EX10, click Start, click All Programs, click Administrative Tools, and then click Event
Viewer.
3.
In Event Viewer, in the navigation pane, expand Windows Logs, click 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.
Task 3: Run the Best Practices Analyzer

1.
2.
In the console tree, expand Microsoft Exchange On-Premises, and then expand Toolbox.
3.
In the work pane, double-click Best Practices Analyzer.
4.
In the Microsoft Exchange Best Practice Analyzer, if prompted, select Do not check for updates on
startup, select I dont want to join the program at this time, and then click Go to the Welcome
screen.
5.
On the Welcome to the Exchange Best Practices Analyzer page, click Select options for a new
scan.
6.
On the Connect to Active Directory page, click Connect to the Active Directory server.
L12-4
7.
On the Start a new Best Practices scan page, in the Enter an identifying label for this scan box,
type NYC-EX10 Scan, and then click Unselect all.
8.
In the Specify the scope for this scan box, select NYC-EX10, verify that Health Check is selected,
and then click Start scanning.
9.
On the Scanning completed page, click View a report of this Best Practices scan. Verify that there
are no errors listed that may have caused this issue.
Task 4: List the probable causes of the problem, and rank the possible solutions, if

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 5: Review the database configuration

1.

Mailbox.
2.
In the work pane, click the Database Management tab, and then click MailboxDB100.
3.
Right-click MailboxDB100 and then click Properties. Take note of the Database path.
4.
Click Start, click All Programs, click Accessories, and then click Windows Explorer.
5.
In the navigation pane, expand Computer, expand Local Disk (C:), expand Program Files, expand
Microsoft, expand Exchange Server, expand V14, and then expand Mailbox. Verify that the
MailboxDB100-NewPath folder does not exist.
6.
In the navigation pane, click MailboxDB100, and locate the database files. This is the actual location
of the database files. The configuration is pointing to the wrong path.
7.
Close the Windows Explorer window.
Task 6: Reconfigure and mount the database

1.
2.
In the Exchange Management Shell, type the follow cmdlet, and then press Enter:
Move-DatabasePath MailboxDB100 LogFolderPath C:\Program Files\Microsoft\Exchange

Server\V14\Mailbox\MailboxDB100 EdbFilePath C:\Program Files\Microsoft\Exchange
Server\V14\Mailbox\MailboxDB100\MailboxDB100.edb ConfigurationOnly force
3.
Type Y, and then press Enter.
4.
In the Exchange Management Shell, type the following cmdlet:
Mount-Database MailboxDB100
5.
L12-5
Press Enter, and then close the Exchange Management Shell.
Results: After this exercise, you should have used a troubleshooting technique to identify and fix a
Mailbox server problem.
Exercise 3: Troubleshooting Client Access Servers

Preparation
1.

d:\Labfiles\Lab12Prep3.ps1, and then press Enter.
2.
Task 1: Attempt to reproduce the problem

1.
On NYC-EX10, open Windows Internet Explorer, and connect to https://NYCEX10.contoso.com/owa.
2.
Note the error that displays in the browser: HTTP Error 401.2 Unauthorized.
L12-6
1.
On NYC-EX10, click Start, click All Programs, click Administrative Tools, and then click Event
Viewer.
2.
In the Event Viewer, in the navigation pane, expand Windows Logs, click Application, and then in
the Content pane, review recent events. There is nothing substantial to point to the current problem.
3.
In the navigation pane, click System, and then in the Content pane, review recent events
4.
Close the Event Viewer.
Task 3: Use the Test cmdlets to verify server health

1.
2.
In the Exchange Management Shell, type the following Test cmdlet:
Test-ServiceHealth
3.
Press Enter. Verify that the output does not return any errors.
4.
In the Exchange Management Shell, type the following Test cmdlet, and then press Enter:
Test-OwaConnectivity URL https://NYC-EX10.contoso.com/OWA -TrustAnySSLCertificate
5.
In the Windows PowerShell Credential Request dialog box, in the User name box, type
Contoso\Administrator, in the Password box, type Pa$$w0rd, and then click OK.
6.
Note the authentication errors.
7.
Task 4: List the probable causes of the problem, and rank the possible solutionsif

Problem
Possible solution
Internet Information Server (IIS) Configuration is not

configured correctly.
Modify the IIS configuration.
L12-7
Problem
Possible solution
Microsoft Outlook Web App authentication is not

configured correctly.
Modify Outlook Web App authentication

configuration.
Task 5: Configure the Outlook Web App settings
1.
2.
In the console tree, expand Microsoft Exchange On-Premises, expand Server Configuration, and
then click Client Access.
Note During this task, click OK to dismiss any messages that indicate that NYC- EX11 is not
accessible.
3.
In the upper portion of the work pane, click NYC-EX10, and then in the lower portion of the work
pane, select the Outlook Web App tab. Right-click owa (Default Web Site), and then click
Properties.
4.
In the owa (Default Web Site) Properties dialog box, click the Authentication tab, select Use
forms-based authentication, and then click OK.
5.
Review the Microsoft Exchange Warning, and then click OK.
6.
Click Start, click All Programs, click Accessories, and then click Command Prompt.
7.
At the command prompt, type iisreset, and then press Enter.
Note If you receive an error indicating that the service did not start, start the World Wide
Web Publishing Service in the Services management console.
8.
Close the command prompt.
Task 6: Verify that you have resolved the problem

1.
Open Internet Explorer, and connect to https://NYC-EX10.contoso.com/owa.
2.
Log on to Outlook Web App as Contoso\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.
L12-8
Module 13: Upgrading from Microsoft Exchange Server

2007 to Exchange Server 2010
L13-1
Lab: Upgrading from Exchange Server 2007

to Exchange Server 2010
Exercise 1: Installing Exchange Server 2010
Task 1: Verify the organizational prerequisites for Exchange Server 2010
1.
On ROM-EX10-C, click Start, click Computer, browse to D:\Labfiles, and then double-click
ExPDA.MSI.
2.
On the Microsoft Exchange Server Pre-Deployment Analyzer Tool Installation Wizard page,
click Next.
3.
On the End User License Agreement page, click I agree, and then click Next.
4.
On the Installation Directory page, click Next.
5.
On the Data Directory page, click Next.
6.
Click Finish. Microsoft Exchange Pre-Deployment Analyzer will start.
7.
On the first page, click Do not check for updates on startup, click I dont want to join the
program at this time, and then click Go to the Welcome Screen.
8.
Select the Select options for a new scan option.
9.
On the Connect to Active Directory page, ensure that ROM-DC1 is listed as an Active Directory
server, and then click Connect to the Active Directory server.
10. On the Start a New Scan page, in the Enter an identifying label for this scan box, type PreDeployment Scan, and then click Start scanning.
11. After the scan completes, click View a report of this Best Practices scan.
12. On the View Report page, review items to ensure that nothing critical appears (no items with red
mark).
13. Close the Microsoft Exchange Pre-Deployment Analyzer window.
Task 2: Install Exchange Server 2010 using a typical installation

1.
On ROM-EX10-C, click Start, click Run, type E:\setup.exe, and then click OK.
2.
3.
4.
5.
Click Next to begin Exchange Server 2010 setup.
6.
Next.
7.
On the Error Reporting page, click Next.
L13-2
8.
On the Installation Type page, click Typical Exchange Server Installation, select the
Automatically install Windows Server roles and features required for Exchange Server check
box, and then click Next.
9.
On the Configure Client Access Server external domain page, select the The Client Access server
role will be Internet-facing check box, type mail.adatum.com, and click Next.
10. On the Customer Experience Improvement Program page, click I dont want to join the
program at this time, and then click Next. A readiness check occurs to ensure that Exchange Server
is ready to install on the server. This check takes several minutes to complete.
11. If the validation checks fail because of a pending restart, click Cancel. In the Microsoft Exchange
dialog box, click Yes, and then restart the server.
12. After the server restarts, log on as Adatum\Administrator using the password Pa$$w0rd.
13. Click Start, click Run, type e:\setup.exe, and then click OK.
14. Click Step 3: Choose Exchange language option.
15. Click Install only languages from the DVD.
16. Click Step 4: Install Microsoft Exchange.
17. In the Resume Setup? dialog box, click No.
18. On the Introduction page, click Next.
19. On the License Agreement page, click I accept the terms in the license agreement, and then click
Next.
20. On the Error Reporting page, click Next.
21. On the Installation Type page, click Typical Exchange Server Installation, select the
Automatically install Windows Server roles and features required for Exchange Server check
box, and then click Next.
22. On the Configure Client Access Server external domain page, select the The Client Access server
role will be Internet facing check box, type mail.adatum.com, and click Next.
23. On the Customer Experience Improvement Program page, click I dont want to join the
program at this time, and then click Next. A readiness check occurs to ensure that Exchange Server
is ready to install on the server. This check takes several minutes to complete.
24. Click Install. The installation takes approximately 15-20 minutes to complete.
25. Click Finish, and then click OK.
26. Click Close, and the click Yes.
Results: After this exercise, you should have verified that the Exchange Server organization is ready for
the installation of Exchange Server 2010, and you should have installed Exchange Server 2010.
Exercise 2: Configuring Exchange Server Version Coexistence

Task 1: Create a test mailbox in Exchange Server 2010
L13-3
1.
On ROM-EX10, in the Exchange Management Console, expand Microsoft Exchange, and then
expand Microsoft Exchange On-Premises (rom-ex10.adatum.com). Wait for the initialization to
finish. Click OK to acknowledge that the server is not licensed.
2.
Expand Recipient Configuration, and then click Mailbox. Notice that the mailboxes are not marked
as legacy mailboxes as they are when you are upgrading Exchange Server 2003 to Exchange Server
2010.
3.
4.
On the Introduction page, click Next.
5.
6.
On the User Information page, in the First name box, type EX2010User.
7.
In the User logon name box, type EX2010User.
8.
In the Password and Confirm password boxes, type Pa$$w0rd, and then click Next.
9.
On the Mailbox Settings page, in the Alias box, accept the default alias.
10. Select Specify the mailbox database rather than using a database automatically selected, and
then click Browse.
11. Notice that you cannot select a mailbox database on an Exchange Server 2007 server. Click OK, and
then click Next.
12. On the Archive Settings page, click Next.
14. Ensure that mailbox EX2010User appears on the Mailbox list in the Exchange Management Console.
Task 2: Verify message delivery coexistence

1.
On ROM-EX10, click Start, point to All Programs, and then click Internet Explorer.
2.
In the Windows Internet Explorer Address bar, type https://ROM-EX10/owa, and then press Enter.
3.
Click Continue to this website (not recommended).
4.
Log on as Adatum\EX2010User using the password Pa$$w0rd.
5.
Click OK, and then click New.
6.
Click Continue to this website (not recommended).
7.
In the To box, type EX2010User; Administrator;test@contoso.com.
8.
In the Subject box, type Test Message from Exchange 2010, and then click Send. Wait a few
moments for the message to arrive in the mailbox.
9.
In the left pane, under the mailbox name, click Sent Items.
10. Expand Test Message from Exchange 2010, right-click EX2010User, and then click Open Delivery
Report.
11. Review the report that appears in a new window. Click Close.
L13-4
12. Open a new instance of Internet Explorer, and connect to https://ROM-EX07.adatum.com/OWA.

13. Log on as Adatum\Administrator using the password Pa$$w0rd.
14. Verify that the message from the EX2010User arrived. Reply to the message.
15. In the Internet Explorer window where you are logged in as EX2010User, verify that the reply arrived.
16. Click Start, and then click Run.
17. Type \\ROM-DC1\C$\inetpub\mailroot\queue. Verify that a message has been delivered to the
Queue folder on the ROM-DC1. This server is configured as the smart host on the Exchange Server
2007 send connector.
18. On ROM-DC1, click Start, click All Programs, click Accessories, and then click Command Prompt.
19. At the command prompt, type telnet ROM-EX07 smtp, and then press Enter.
20. Type helo, and then press Enter.
21. Type mail from:test@contoso.com, and then press Enter.
22. Type rcpt to:ex2010user@Adatum.com, and then press Enter.
23. Type data, and then press Enter.
24. Type Subject: Test from Internet, and then press Enter.
25. Press the Period key, and then press Enter.
26. Type Quit, and then press Enter.
27. On ROM-EX10, in the Internet Explorer window where you are logged in as EX2010User, verify that
the message from test@contoso.com arrived.
28. Close the Internet Explorer windows.
Task 3: Prepare a Server Certificate request for ROM-EX10

1.
On ROM-EX10, in the Exchange Management Console, click Server Configuration. In the results
pane, click ROM-EX10.
2.
In the Actions pane, click New Exchange Certificate to open the New Exchange Certificate Wizard.
3.
On the Introduction page, type Adatum Mail Certificate as the friendly name for the certificate,
4.
On the Domain Scope page, click Next.
5.
On the Exchange Configuration page, expand Client Access server (Outlook Web App), and then
select both the Outlook Web App is on the Intranet and Outlook Web App is on the Internet
check boxes. Verify that the internal domain name includes both the Exchange Server 2007 and the
Exchange Server 2010 Client Access server names, and that the external domain name is
Mail.adatum.com.
6.
Expand Client Access server (Exchange ActiveSync), and verify that the Exchange Active Sync is
enabled check box is selected.
7.
Expand Client Access server, (Web Services, Outlook Anywhere, and Autodiscover). Ensure that
both the Autodiscover used on the Internet check box and the Long URL option are selected.
8.
Click Legacy Exchange Server. Select the Use legacy domains check box, type ROMEX07.adatum.com as the domain name to use for legacy servers, and then click Next.
9.
L13-5
On the Certificate Domains page, click Mail.adatum.com, click Set as common name, and then click
Next.
10. On the Organization and Location page, enter the following information:
Organization: A Datum
Country/region: Italy
City/locality: ROME
State/province: ROME
11. Click Browse, type CertRequest as the File name, and then click Save.
Task 4: Request the certificate from the Certification Authority

1.
Click the Folder icon on the taskbar, and then click Documents.
2.
Right-click CertRequest.cer, and then click Open.
3.
click OK.
4.
In the Open with dialog box, click Notepad, and then click OK.
5.
In the CertRequest.cer Notepad window, press Ctrl+A to select all the text, and then press Ctrl+C
to save the text to the clipboard. Close Notepad.
6.
Click Start, click All Programs, and then click Internet Explorer.
7.
Connect to https://ROM-DC1.adatum.com/certsrv.
8.
Log on as Administrator using the password Pa$$w0rd.
9.
On the Welcome page, click Request a certificate.
10. On the Request a Certificate page, click advanced certificate request.
11. On the Advanced Certificate Request page, click Submit a certificate request by using a base64-encoded CMC or PKCS#10 file, or submit a renewal request by using a base-64-encoded
PKCS#7 file.
12. On the Submit a Certificate Request or Renewal Request page, click in the Saved Request field,
and then press Ctrl+V to paste the certificate request information into the field.
13. In the Certificate Template drop-down list, click Web Server, click Submit, and then click Yes.
14. On the Certificate Issued page, click Download certificate.
15. In the File Download dialog box, click Save.
16. In the Save As dialog box, click Save.
17. In the Download complete dialog box, click Open.
18. 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.
L13-6
Task 5: Import and assign the Internet Information Services Exchange services to the
new certificate
1.
In the Exchange Management Console, click Server Configuration.
2.
In the results pane, click ROM-EX10. In the bottom pane, click Adatum Mail Certificate.
3.
In the Actions pane, click Complete Pending Request.
4.
On the Introduction page, click Browse.
5.
Click Downloads, click certnew.cer, and then click Open.
6.
Click Complete, and then click Finish.
7.
Click Adatum Mail Certificate, and in the Actions pane, click Assign Services to Certificate.
8.
On the Select Servers page, verify that ROM-EX10 is listed, and then click Next.
9.
On the Select Services page, select the Internet Information Services check box, click Next, click
Assign, and then click Finish.
Task 6: Verify Outlook Web App coexistence

1.
On ROM-DC1, click Start, point to Administrative Tools, and then click DNS.
2.
Expand ROM-DC1, expand Forward Lookup Zones, and then click Adatum.com.
3.
Right-click adatum.com, and then click New Host (A or AAAA).
4.
In the New Host dialog box, type mail as the Name, and 10.10.10.30 as the IP address.
5.
Click Add Host, click OK, and then click Done.
6.
Close DNS Manager.
7.
Open Internet Explorer, and connect to https://mail.adatum.com/owa.
8.
Log on as Adatum\Ex2010user using the password Pa$$w0rd. Verify that the user can connect to
the Exchange Server 2010 mailbox.
9.
10. Reopen Internet Explorer, and connect to https://mail.adatum.com/owa.
11. Log on as Adatum\Anna using the password Pa$$w0rd. Verify that the web browser is redirected to
ROM-EX07, and that the user can connect to their Exchange Server 2007 mailbox.
Task 7: Move a test user from Exchange Server 2007 to Exchange Server 2010
1.
On ROM-EX10, in the Exchange Management Console, expand Recipient Configuration, and then
click Mailbox.
2.
In the Actions pane, click View, and then click Add/Remove Columns.
3.
Under Available columns, click Database, and then click Add. Click Move Up until Database is the
third item in the Displayed columns list, and then click OK.
4.
In the Results pane, click Andreas Herbinger, and then in Actions pane, click New Local Move
Request.
5.
In the New Local Move Request Wizard, click Browse.
6.
Click the mailbox database located on ROM-EX10, and then click OK.
7.
Click Next.
8.
9.
Click New.
10. Click Finish.
L13-7
11. In the console tree, click Move Request to verify the move request is complete. You may need to
click Refresh a few times before the move finishes.
12. Open Internet Explorer, and connect to https://mail.adatum.com/owa.
13. Log on as Adatum\Andreas using the password Pa$$w0rd. Click OK, and verify that the user can
connect to the Exchange Server 2010 mailbox.
Task 8: Check public folder accessibility

1.
On ROM-EX10, open Internet Explorer, and then connect to https://mail.adatum.com/owa.
2.
Log on as Adatum\Andreas using the password Pa$$w0rd.
3.
In the Outlook Web App window, click Public Folders. Verify that you receive an error message
indicating that there is no Exchange Server 2010 public folder server.
4.
Click Close, and then close Internet Explorer.
Task 9: Create a public folder database on ROM-EX10

1.
On ROM-EX10, in the Exchange Management Console, expand Organization Configuration, and

then click Mailbox.
2.
In the Actions pane, click New Public Folder Database.
3.
On the New Public Folder Database page, in the Public Folder database name box, type PFROM-EX10, and then click Browse.
4.
In the Select Mailbox Server dialog box, select ROM-EX10, and then click OK.
5.
Click Next.
6.
In Database file path box, type C:\Mailbox\PF-ROM-EX10\PF-ROM-EX10.edb.
7.
In the Log folder path box, type C:\Mailbox\PF-ROM-EX10.
8.
Task 10: Add a replica of the CustomerService public folder and System public
folders to ROM-EX10
1.
On ROM-EX07, open the Exchange Management Console.
2.
Click Toolbox, and then double-click Public Folder Management Console.
3.
Wait for the server to connect, and then click Default Public Folders.
4.
In the center pane, right-click CustomerService public folder, and choose Properties.
5.
On the Replication tab, click Add.
L13-8
6.
In the Select Public Folder Database window, click PF-ROM-EX10, and then click OK.
7.
In the CustomerService Properties window, click OK.
8.
On ROM-EX07, open the Exchange Management Shell.
9.
At the command prompt, type cd \Program Files \Microsoft\Exchange Server\Scripts, and then
press Enter.
10. Type.\AddReplicaToPFRecursive.ps1 TopPublicFolder \NON_IPM_Subtree ServertoAdd ROMEX10, and then press Enter.
Task 11: Verify transport and journaling rule coexistence

1.
On ROM-EX07, in the Exchange Management Console, expand Organization Configuration and

2.
On the Transport Rules tab, double-click External Disclaimer, and click Next. Review the
configuration of the hub transport rule, and then click Cancel.
3.
On the Journaling tab, double-click the Executive Journaling rule. Review the journal rule
configuration, and then click Cancel.
4.
On ROM-EX10, in the Exchange Management Console, expand Organization Configuration, and

5.
On the Transport Rules tab, verify that that the External Disclaimer is listed.
6.
Double-click External Disclaimer, click Next, and review the configuration of the hub transport rule.
Verify that the configuration is the same as the Exchange Server 2007 configuration. Note that the
disclaimer text now displays in an HTML format.
7.
Click Next twice. On the Exceptions page, select the except when the message is from member
of distribution list check box.
8.
In the Step 2 section, click distribution list.
9.
In the Specify sender distribution list dialog box, click Add, click ITAdmins, and then click OK
twice.
10. Click Next, click Update, and then click Finish.

11. On the Journal Rules tab, double-click the Executive Journaling rule.
12. Change the scope of the rule to External, and then click OK. In the Microsoft Exchange Warning
dialog box, click OK.
13. On ROM-EX07, in the Exchange Management Console, on the Transport Rules tab, double-click
External Disclaimer and review the configuration of the hub transport rule. Verify that the change
made to the rule in Exchange Server 2010 is not replicated on the Exchange Server 2007 rule. Click
Cancel.
14. On the Journaling tab, double-click the Executive Journaling rule. Verify that the change made to
the rule in Exchange Server 2010 is not replicated on the Exchange Server 2007 rule. Click Cancel.
Task 12: Verify administrative coexistence
L13-9
1.
On ROM-EX10, in Administrative Tools, open Active Directory Users and Computers.
2.
Expand adatum.com, and then expand the Microsoft Exchange Security Groups organizational
unit, and verify that both the Exchange Server 2007 and Exchange Server 2010 administrative groups
are listed.
3.
Double-click the Exchange Organization Administrators group. On the Members tab, verify that
three members are listed, and then click Cancel.
4.
Double-click the Organization Management group. On the Members tab, verify that the Exchange
Organization Administrators group has been added to the Organization Management group, and
then click Cancel.
5.
Review the membership for the Recipient Management and View-Only Organization
Management groups. Verify that the corresponding groups from Exchange Server 2007 have been
added to these groups.
Task 13: Move the remaining mailboxes from Exchange Server 2007 to Exchange
Server 2010
1.
On ROM-EX10, in the Exchange Management Console, under Recipient Configuration, click

Mailbox.
2.
Click the Database heading to sort the mailboxes by location.
3.
Select all of the mailboxes located on ROM-EX07, and then in Actions pane, click New Local Move
Request.
4.
In the New Local Move Request wizard, click Browse.
5.
Click the mailbox on ROM-EX10, and then click OK.
6.
Click Next.
7.
8.
9.
In the console tree, click Move Request to verify that the move requests have been queued, and that
two mailboxes at a time are moving.
Task 14: Move the Offline Address Book server to Exchange Server 2010
1.
On ROM-EX10, in the Exchange Management Console, under Organization Configuration, click

Mailbox.
2.
On the Offline Address Book tab, right-click Default Offline Address Book, and then click Move.
3.
On the Move Offline Address Book page, click Browse. Click ROM-EX10, click OK, click Move, and
then click Finish.
4.
Right-click Default Offline Address Book, and then click Properties.
5.
On the Distribution tab, clear both the Outlook 98 SP2 or later (Version 3) check box and the
Enable public folder distribution check box.
6.
Click Add, click ROM-EX10, and then click OK.
7.
Click ROM-EX07, click the red X to remove the server, and then click OK.
8.
Right-click Default Offline Address Book, click Update, and then click Yes.
9.
Open a Windows Explorer window, and browse to C:\Program Files\Microsoft\Exchange

Server\v14\ExchangeOAB. Verify that the ExchangeOAB folder contains a folder with a globally
unique identifier (GUID) name, and that the folder contains several .LZX files.
L13-10
10. Browse to C:\Program Files\Microsoft\Exchange Server\v14\ClientAccess\OAB. Verify that the

same folder and files are stored in this location.
Note If the files do not appear in the OAB folder, restart the Microsoft Exchange File
Distribution service on ROM-EX10, and look again.
Task 15: Migrate Internet message routing to Exchange Server 2010

1.
On ROM-EX10, in the Exchange Management Console, under Organization Configuration, click

Hub Transport.
2.
On the Send Connectors tab, right-click Internet Send Connector, and then click Properties.
3.
On the Source Server tab, click ROM-EX07, and click the red X to remove the server. Click Add, click
ROM-EX10, and then click OK twice.
4.
Expand Server Configuration, and then click Hub Transport.
5.
Double-click Default ROM-EX10. On the Permissions Groups tab, select the Anonymous users
check box, and then click OK.
Note The last two steps above assume that the Hub Transport server is receiving email
directly from the Internet. If you are using an Edge Transport server or alternate Simple Mail
Transfer Protocol (SMTP) gateway server, you will need to configure the Hub Transport
server to interoperate with these servers.
Task 16: Verify public folder replication, and remove Exchange Server 2007 replicas
1.
On ROM-EX10, if required, open Exchange Management Shell.
2.
At the command prompt, type Get-PublicFolderStatistics, and then press Enter.
3.
Verify that the CustomerService public folder is listed, and that it has an item count of 2.
4.
On ROM-EX10, open Internet Explorer, and then connect to https://mail.adatum.com/owa.
5.
Log on as Adatum\Andreas using the password Pa$$w0rd.
6.
In the Outlook Web App window, click Public Folders. Verify that the user can view the public folder.
7.
8.
In Exchange Management Shell, type cd \Program Files\Microsoft\Exchange

Server\v14\Scripts, and then press Enter.
9.
Type .\RemoveReplicaFromPFRecursive.ps1 TopPublicFolder \CustomerService

ServertoRemove ROM-EX07, and then press Enter. This command removes ROM-EX07 from the
replica list on the CustomerService public folder and any child folders.
L13-11
10. Type .\ReplaceReplicaonPFRecursive.ps1 TopPublicFolder \ -ServertoAdd ROM-EX10

ServertoRemove ROM-EX07, and then press Enter. This command replaces ROM-EX07 with ROMEX10 on the replica list for all non-system public folders and any child folders.
11. Type .\ReplaceReplicaonPFRecursive.ps1 TopPublicFolder \ -ServertoAdd ROM-EX10
ServertoRemove ROM-EX07, and then press Enter. This command removes ROM-EX07 from the
replica list on all system public folders.
12. In Exchange Management Console, click Toolbox, and then double click Public Folder
Management Console.
13. Click Default Public Folders. In the center pane, right-click CustomerService, and then click
Properties.
14. On the Replication tab, verify that only PF-ROM-EX10 is listed. Click OK, and then close the Public
Folder Management Console.
15. In the Exchange Management Console, under Organization Configuration, click Mailbox. On the
Database Management tab, right-click the mailbox database, and then click Properties.
16. On the Client Settings tab, under Default public folder database, click Browse.
17. Click PF-ROM-EX10, and then click OK twice.
Results: After this exercise, you should have verified that the Exchange Server versions are coexisting
without issues, and you should have migrated all resources and functionality from Exchange Server 2007
Exercise 3: Removing Exchange Server 2007

Task 1: Verify that Exchange Server 2007 can be removed
1.
On ROM-EX10, click Start, point to All Programs, and then click Internet Explorer.
2.
In the Internet Explorer address bar, type https://mail.adatum.com/owa, and then press Enter.
3.
Log on as Adatum\Anna using the password Pa$$w0rd.
4.
Click OK, and then click New.
5.
In the To box, type test@contoso.com.
6.
In the Subject box, type Test Message from Exchange 2010, and then click Send.
7.
In the left pane, click Sent Items.
8.
Right-click the message that you just sent, click Open Delivery Report, and then click Yes.
9.
Review the report that appears in a new window, and then click Close.
10. Click Start, and then click Run.
L13-12
11. Type \\ROM-DC1\C$\inetpub\mailroot\queue. Verify that a message has been delivered to the
Queue folder on ROM-DC1.
12. On ROM-DC1, click Start, point to All Programs, point to Accessories, and then click Command
Prompt.
13. At the command prompt, type telnet ROM-EX10 smtp, and then press Enter.
14. Type helo, and then press Enter.
15. Type mail from:test@contoso.com, and then press Enter.
16. Type rcpt to:anna@Adatum.com, and then press Enter.
17. Type data, and then press Enter.
18. Type Subject: Test from Internet, and then press Enter.
19. Press the Period key, and then press Enter.
20. Type Quit, and then press Enter.
21. On ROM-EX10, in Internet Explorer, verify that the message from test@contoso.com arrived.
Task 2: Remove Exchange Server 2007 from the organization

1.
On ROM-EX07, in the Exchange Management Console, under Server Configuration, click Mailbox.
2.
Right-click Mailbox Database, click Dismount Database, and then click Yes.
3.
Right-click Mailbox Database, click Remove, click Yes, and then click OK.
4.
Right-click Public Folder Database, click Remove, click Yes, and then click OK.
Note When you try to remove the public folder database, you might receive one of two
messages that prevent you from deleting the database. You might receive a message that
the object cannot be deleted because it contains messages. This message appears if not all of
the public folder contents have been removed from the public folder because not enough
time has passed since you ran to commands in Exercise 2, Task 16. If you get this message,
wait 5 minutes and try again. In a production environment, you would ensure that all public
folder contents have been removed from the database before deleting the database.
You might also receive a message that the object is read-only because it was created by a
future version of Exchange.
If you receive either message, complete steps 510, then continue with step 11. If you did
not receive these messages, skip to step 11.
L13-13
5.
Click Start, click Run, type Adsiedit.msc, and then press Enter.
6.
7.
In the Connection Settings dialog box, under Select a well known Naming Context, click
Configuration, and then click OK.
8.
Browse to Configuration\CN=Configuration,DC=adatum,DC=com\CN=Services\CN=Microsoft
Exchange\CN=AdatumOrg\CN=Administrative Groups\CN=Exchange Administrative Group
(FYDIBOHF23SPDLT), CN=Servers,CN=ROM-EX07,CN=InformationStore,CN=Second Storage
Group.
9.
Right-click Public Folder Database, click Delete, and then click Yes.
10. Close ADSIEdit.

11. Close all remaining open windows.
12. Open the Control Panel, and then click Programs.
13. Click Uninstall a program.
14. Click Microsoft Exchange Server 2007, and then click Uninstall.
15. On the Exchange Maintenance Mode page, click Next.
16. On the Server Role Selection page, clear all check boxes, and then click Next.
17. Wait for the readiness checks to complete. On the Readiness Checks page, click Uninstall.
18. When the uninstall finishes, shut down ROM-EX07.
Results: After this exercise, you should have verified that Exchange Server 2007 can be removed from the
organization, and you should have uninstalled Exchange Server 2007 from ROM-EX07.
L13-14

10165A ENU TrainerHandbook

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

10165A ENU TrainerHandbook

Hochgeladen von

Copyright:

Verfügbare Formate

M I C R O S O F T

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED

Product Number: 10165A

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED

Damir DizdarevicContent Developer

Siegfried JagottContent Developer

Vladimir MeloskiContent Developer

Stan ReimerContent Developer

Claudia WoodsMCT Technical Reviewer

Module 2: Deploying Microsoft Exchange Server 2010

Module 3: Configuring Mailbox Servers

Module 4: Managing Recipient Objects

Module 5: Managing Client Access

MCT USE ONLY. STUDENT USE PROHIBITED

Module 6: Managing Message Transport

Module 7: Implementing Messaging Security

Module 8: Implementing High Availability

Module 9: Implementing Backup and Recovery

Module 10: Configuring Messaging Policy and Compliance

Module 11: Securing Microsoft Exchange Server 2010

MCT USE ONLY. STUDENT USE PROHIBITED

Module 12: Monitoring and Troubleshooting Microsoft Exchange Server 2010

Appendix A: Understanding and Planning for Microsoft Exchange Online

Lab Answer Keys

MCT USE ONLY. STUDENT USE PROHIBITED

MCT USE ONLY. STUDENT USE PROHIBITED

About This Course

MCT USE ONLY. STUDENT USE PROHIBITED

About This Course

Windows Server 2008 Technology Specialist Skills

At least two years administering Exchange 2003 or Exchange 2007

Install and deploy Exchange Server 2010 in an Exchange Server organization.

Configure Mailbox servers and Mailbox server components.

About This Course

MCT USE ONLY. STUDENT USE PROHIBITED

Plan and configure messaging compliance.

Monitor and maintain the messaging system.

Upgrade an existing Exchange Server 2007 organization to Exchange Server 2010.

MCT USE ONLY. STUDENT USE PROHIBITED

About This Course

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

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

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

About This Course

Virtual Machine Environment

MCT USE ONLY. STUDENT USE PROHIBITED

Virtual Machine Configuration

Domain controller in the contoso.com domain.

Windows 7 client in the contoso.com domain.

Domain controller in the contoso.com domain.

Exchange 2003 SP2 server in the contoso.com domain.

Exchange 2003 SP2 server in the contoso.com domain.

Member server in the contoso.com domain.

Exchange 2010 server in the contoso.com domain.

Exchange 2010 server in the contoso.com domain.