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



v



vi



vii



viii



ix


Acknowledgments


x

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 Dizdarevic–Content 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 Jagott–Content 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 world’s 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 Meloski–Content 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 Reimer–Content Developer

Stan Reimer is president of S. R. Technical Services Inc., and he works as a consultant, trainer, and author. Stan has extensive experience 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 Woods–MCT 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 Lesson 2: New Exchange Server 2010 Features for Exchange Server 2007 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

i

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 Exchange Server 2007.

•

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 it’s needed.

Course Companion Content on the http://www.microsoft.com/learning/companionmoc/ Site: Searchable, easy-to-navigate digital content with integrated premium on-line resources designed to supplement the Course Handbook. •

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

•

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

Student Course files on the http://www.microsoft.com/learning/companionmoc/ Site: Includes the Allfiles.exe, a self-extracting executable file that contains all the files required for the labs and demonstrations. •

Course evaluation At the end of the course, you will have the opportunity to complete an online evaluation to provide feedback on the course, training facility, and instructor. •

To provide additional comments or feedback on the course, send e-mail to [email protected]. To inquire about the Microsoft Certification Program, send e-mail to [email protected].

About This Course

Virtual Machine Environment


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

v

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 Introducing Microsoft® Exchange Server 2010 Contents: Lesson 1: New Exchange Server 2010 Features for Exchange Server 2003 Administrators

1-3

Lesson 2: New Exchange Server 2010 Features for Exchange Server 2007 Administrators

1-21

Lesson 3: Upgrading to Exchange Server 2010

1-33

Lab: Planning the Hardware Requirements for Exchange Server 2010

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 Exchange Server 2003.

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 clients—including 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 roles−such as the Client Access server and the Hub Transport server−are 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 organization’s 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 organization’s 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 organization’s 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.


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 user’s 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 store’s 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 Exchange Server 2007.

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 organization’s 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, to Exchange Server 2010.


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 organization’s Exchange Server configuration data. In a migration, you install a new Exchange Server 2010 system, and then migrate the previous Exchange Server version’s 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 organization’s 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 organization’s 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 Exchange Server 2010. 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 Exchange Server 2010.

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 settings—both internally and externally—to 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 organization’s 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 design—information such as database size, high availability, and number of servers—and provides recommendations for your Mailbox server role requirements.



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 organization’s 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 organization’s 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


• Administration of Exchange Server organization

Start menu


• Management and administration of Exchange Server organization, and for bulk management tasks

Start menu


• Common administrative tasks

Exchange Control Panel URL


Deploying Microsoft® Exchange Server 2010

2-1

Module 2 Deploying Microsoft® Exchange Server 2010 Contents: Lesson 1: Installing Exchange Server 2010

2-3

Lab A: Installing Exchange Server 2010 SP1

2-26

Lesson 2: Verifying the Exchange Server 2010 Installation

2-32

Lab B: Verifying the Exchange Server 2010 SP1 Installation

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.


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.


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 coexistence−until all of your resources are moved to Exchange Server 2010−you 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 components—including the Exchange Management tools—only 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 • IIS 6 metabase compatibility • IIS 6 Management Console • Basic authentication • Windows authentication • Digest authentication • Dynamic content compression • .NET Framework extensibility • 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. • The default Web Server (IIS) server role and the following role services: • IIS 6 metabase compatibility • IIS 6 Management Console • Basic authentication • Windows authentication • .NET Framework extensibility

Microsoft Office 2010 Filter Pack The default Web Server (IIS) server role and the following role services: IIS 6 metabase compatibility IIS 6 Management Console Basic authentication Windows authentication .NET Framework extensibility

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

•

IIS 6 Management Console

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 Exchange Server 2010. •

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 domain’s 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 attributes—such as the proxy address—on 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 guest’s operating system, any temporary memory storage files in use, and related virtual machine files that are hosted on the host machine. Additionally, for each Exchange Server guest machine, you must 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 machine’s operating system.

•

You can deploy only management software—such as antivirus software, backup software, and virtual machine management software—on the physical root machine. You should not install any other server-based applications—such as Exchange Server, Microsoft SQL Server®, or AD DS—on the root machine. The root machine should be dedicated to running guest virtual machines.

•

Running Exchange servers as virtual machines can complicate performance monitoring. The performance data between the host and virtual machine is not consistent, because the virtual machine uses only some part of the host’s 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 DS—such as users and security groups—and 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 organization’s 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 Exchange Server 2010

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:] [/mode:] [/console] [/?][/targetdir:] [/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 • IIS 6 metabase compatibility • IIS 6 Management Console • Basic authentication • Windows authentication • Digest authentication • Dynamic content compression • .NET Framework extensibility

Yes or No

Windows Server 2008 features • WCF HTTP activation • RPC over HTTP Proxy

Yes or No

The main tasks for this exercise are as follows: 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 The main tasks for this exercise are as follows: 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 The main tasks for this exercise are as follows: 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.

In Hyper-V Manager, connect C:\Program Files\Microsoft 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 Exchange Server 2007.

•

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

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




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


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 server’s 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 B: Verifying the Exchange Server 2010 SP1 Installation

Lab Setup



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. The main tasks for this exercise are as follows: 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. The main tasks for this exercise are as follows: 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 Spoon’s 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 started before starting the other virtual machines.



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.

Client Access server Hub Transport server 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 Configuring Mailbox Servers 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

Lab: Configuring Mailbox Servers

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.


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.


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.


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 user’s 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 http://go.microsoft.com/fwlink/?LinkID=212663.



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

.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 database’s 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

Current transaction log file. This is the database’s 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.

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.

res00001.jrs 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.

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.

.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 tabs—Maintenance, Limits, and Client Settings—contain 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 http://go.microsoft.com/fwlink/?LinkID=212664.

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 unit’s 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 organization’s 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 Exchange Server 2010

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.


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 user’s 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 organization’s 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



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



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. The main tasks for this exercise are as follows: 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. The main tasks for this exercise are as follows: 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.

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


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.

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 started before starting the other virtual machines. 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 Supplement or modify the following best practices for your own work situations: •

When configuring mailbox server roles in coexistence, always start by analyzing your organization’s 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


Managing Recipient Objects

4-27

Lesson 4: Performing Bulk Recipient Management Tasks in Exchange Server 2010

4-37

Lab: Managing Exchange Server Recipients

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.


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.


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 company’s 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.

In the console tree, expand Microsoft Exchange On-Premises, expand Recipient Configuration, 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 user’s 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 user’s mailbox also removes the user’s 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 2010—as in Exchange Server 2007—are 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 mailbox’s 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 user’s 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 Carter’s 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 Carter’s 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 Exchange Server 2010.

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 mailbox’s 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 move’s 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 mailbox’s 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 client—such as Microsoft Office Outlook 2010—should 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 Khot’s 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 Duncan’s 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 options—or, booking policies—that you can use for configuring resource mailbox settings and for customizing the resource mailbox to meet your organization’s 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 resource’s 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 requirements—such 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 requirements—such 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 requirements—such as no conflicts.

BookInPolicy

Specifies a list of users for whom requests that meet the specified requirements are booked automatically without approval from a resource mailbox delegate.

ConflictPercentageAllowed

Specifies the maximum percentage of meeting conflicts for new recurring meeting requests.

DeleteAttachments

Specifies whether to remove attachments from all incoming messages.

EnableResponseDetails

Specifies the reasons for accepting or declining a meeting request in the response email message.

ForwardRequestsToDelegates

Specifies whether to forward incoming meeting requests to the resource delegates.

MaximumConflictInstances

Specifies the maximum number of conflicts for new recurring meeting requests.

RemoveOldMeetingMessages

Specifies whether to remove old and redundant updates and responses.

RemovePrivateProperty

Specifies whether to remove the private flag on incoming meeting requests.

RequestInPolicy

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


4-18


Setting

Description

RequestOutOfPolicy

Specifies a list of users who are allowed to submit appointment requests that do not meet specified requirements—such as no conflicts. A resource mailbox delegate still must approve all requests.

ResourceDelegates

Specifies a list of users who are resource delegates.

ScheduleOnlyDuringWorkHours

Specifies whether to allow meetings to be scheduled outside of work hours.

TentativePendingApproval

Specifies whether to mark pending requests as tentative on the calendar. The default 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.

In the console tree, expand Microsoft Exchange On-Premises, expand Recipient Configuration, 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 Contoso\Administrator, with the password, Pa$$w0rd.

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.


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 Exchange Management Shell 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 user’s 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 user’s 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 Exchange Server 2010



4-27

In Exchange Server 2010—as in previous Exchange Server versions—you 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.


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.

In the console tree, expand Microsoft Exchange On-Premises, expand Organization 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.

In the console tree, expand Microsoft Exchange On-Premises, expand Recipient Configuration, 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.

In the console tree, expand Microsoft Exchange On-Premises, expand Organization 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 Exchange Server 2010



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

Lesson 4

Performing Bulk Recipient Management Tasks in Exchange Server 2010



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.


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 cmdlets—such as Get-User—and 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 president’s 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 Moore’s 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 president’s 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 Contoso\Administrator, with the password, Pa$$w0rd.

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 Yu’s 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 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. 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. The main tasks for this exercise are: 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 [email protected]

•

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.

The main tasks for this exercise are: 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 [email protected].

•

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.

 To prepare for the next module When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the following steps: 1.


2.

Right-click the virtual machine name in the Virtual Machines list, and then click Revert.

3.


4.




6.


7.


8.




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 in the troubleshooting tips. For answers, refer to relevant lessons in the module. 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 Supplement or modify the following best practices for your own work situations: •

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.

MCT USE ONLY. STUDENT USE PROHIBITED 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

Lab A: Upgrading and Configuring Client Access Servers

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.


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.


Managing Client Access

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.


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. Exchange Server 2003

Exchange Server 2007


Office Outlook Web Access (OWA) /exchange /exchweb /public

Outlook Web Access /owa

Outlook Web App /owa

Microsoft Exchange ActiveSync® /microsoft-server-activesync

Exchange ActiveSync /microsoft-server-activesync

Exchange ActiveSync /microsoft-server-activesync

Outlook Anywhere /rpc



Outlook Mobile Access /oma

Discontinued

Discontinued

Not present in this version

Exchange Web Services /ews

Exchange Web Services /ews


Offline Address Book (OAB) /oab

OAB /oab







Unified Messaging /unifiedmessaging

Unified Messaging /unifiedmessaging


Autodiscover /autodiscover

Autodiscover /autodiscover



Exchange Control Panel /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 site—Exchange 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 user’s 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 user’s 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

Exchange Web Services

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 certificate’s 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 Exchange Server 2010 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

•

Exchange Web Services 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

•

Exchange Control Panel 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.


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 user’s 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 2010–only 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 site’s 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 user’s 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 user’s 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 user’s 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 user’s 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 server–based features with an external URL. This URL is used to access the website from external locations. By default, the external URL is blank. For Internet-facing Client Access servers, 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 create—if necessary—a 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 server’s design can have a significant impact on users’ satisfaction with the messaging system. All clients—including MAPI clients such as Microsoft Outlook 2010—connect 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


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 The main tasks for this exercise are as follows: 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 Exchange Server 2010 The main tasks for this exercise are as follows: 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: Set-OWAVirtualDirectory NYC-EX11\OWA* -Exchange2003URL https://legacy.contoso.com/exchange

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

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.

3.

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.

4.

Log off of NYC-CL1.

Results: After this exercise, you should have configured the client access interoperability between Exchange Server 2010 and Exchange Server 2003.

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


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 (New in Exchange Server 2010)

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. Exchange Control Panel (New in Exchange Server 2010)

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 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 1–15 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 user’s 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 Client Access server.

2.

When Microsoft Outlook 2010 starts for the first time, Outlook 2010 uses the user’s 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 user’s display name

•

Separate connection settings for internal and external connectivity

•

The location of the user’s 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./autodiscover/autodiscover.xml

•

https:///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 user’s 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:///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.


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 object—such as a transparent graphic or an image—that 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.


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 rarely—or never—connect to the internal network. The devices also do not require Active Directory accounts, so you cannot use Group Policy objects (GPOs) to manage the client settings.

Implementing Exchange ActiveSync Policies

Exchange ActiveSync policies provide one option for securing mobile devices. When you apply the policy to a user, the mobile device automatically downloads the policy the next time the device connects to the Client Access server.

Exchange 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 mailbox’s 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 user’s 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



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. The main tasks for this exercise are as follows: 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. The main tasks for this exercise are as follows: 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. The main tasks for this exercise are as follows: 1.

Verify the Exchange ActiveSync virtual directory configuration.

2.

Create a new Exchange ActiveSync mailbox policy.

3.

Configure Exchange ActiveSync 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

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


2.


3.


4.




6.


7.


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 servers—even in small organizations—because 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 Managing Message Transport Contents: Lesson 1: Overview of Message Transport

6-3

Lesson 2: Configuring Message Transport

6-20

Lab: Migrating and Managing Message Transport

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. After completing this module, you will be able to: •

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

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 agent—such as a third-party connector—to a foreign messaging system.

•

Messages submitted by the store driver. This method is used to retrieve messages from the sender’s 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 queues—mailbox delivery queue or remote delivery queue—depending 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 queues—one queue for each database—exist 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 user’s 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 sender’s Outbox, and then submits them to the submission queue. The responding store driver mechanism places a copy of the message into the Hub Transport server’s 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 sender’s Outbox to the sender’s 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 sender’s Outbox. The store driver on the notified Hub Transport server role picks up the message from the sender’s 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 user’s 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 user’s 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 user’s Outbox in the user’s 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 user’s Mailbox server. The FQDN determines the Active Directory site of the user’s 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 message’s deletion from the transport databases is delayed until the transport server verifies that all of the message’s 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 message’s 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 link’s 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 SMTP or telnet .

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 Christine’s 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. After completing this lesson, you will be able to: •

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 policies—such as journaling rules—you 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 Exchange Management Console.

2.

In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand Organization Configuration, and then click Hub Transport.

3.

On the Global Settings tab, double-click Transport Settings.

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 organization’s users to the remote domain. The settings for remote domains determine the Exchange Server organization’s 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 entry’s 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 user’s 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 sender’s 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 message’s 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 sender’s 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 user’s user account. By default, the user’s 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 Organization Configuration, and then click Hub Transport.

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 organization’s SMTP domain as the address space, and then configure the other Send connector’s 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



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. The main tasks for this exercise are as follows: 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 [email protected] 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 Alan’s 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 [email protected] 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. The main tasks for this exercise are as follows: 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.

 To prepare for the next module 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.


Important Start the 10165A-NYC-DC1-B virtual machine first, and ensure that it is fully started before starting the other virtual machines.



6-43

5.


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 troubleshooting tips. For answers, refer to relevant lessons in the module. 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

Lab B: Configuring Anti-Spam Filtering

7-51


Implementing Messaging Security

Module Overview



7-2

In any Microsoft® Exchange Server organization—whether coexistent or not—you 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. After completing this module, you will be able to: •

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

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 organization’s 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 organization’s 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 organization’s 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 Edge Transport server.

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 Edge Transport server.

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 servers—and 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 organization’s 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

SMTP Send connector

Description

• • •

EdgeSync – 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 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 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 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.


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 connector–related 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 organization’s security. After completing this lesson, you will be able to: •

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?

MCT USE ONLY. STUDENT USE PROHIBITED 7-21 Implementing Messaging Security

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.


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 Setup



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 Contoso\Administrator, with the password, Pa$$w0rd.

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-NYC–SVR1-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. The main tasks for this exercise are as follows: 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. The main tasks for this exercise are as follows: 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=. 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 mail’s 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 [email protected], 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-NYC–SVR1-B, and then, in the Actions pane, click Settings.

3.


4.

Browse to C:\Program Files\Microsoft Learning\10165\Drives, click ForeFrontInstall.iso, click Open, and then click OK. On NYC-SVR1, close the AutoPlay dialog box.

Scenario

Virus prevention is critical to your organization’s 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. The main tasks for this exercise are as follows: 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 organization’s 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. After completing this lesson, you will be able to: •

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 Edge Transport server. 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 server’s IP address on an RBL, the server rejects the message, and other filters are not applied.

The Edge Transport server compares the sender’s 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 recipient’s Safe Senders List, the message is sent to the user’s 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 user’s mailbox.

What Is Sender ID Filtering?



7-38

Sender ID filtering—or 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 sender’s 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 domain’s DNS records. The SPF record is a single text (.txt) record in the DNS database that identifies each domain’s 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 organization’s 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 domain’s 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 scanners—such as content filtering—are 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 sender’s 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 sender’s 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 sender’s 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 sender’s 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 user’s Junk Email folder. If the SCL value for a message is lower than the SCL delete, reject, quarantine, and Junk Email folder threshold values, then the Mailbox server delivers the message to the user’s 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.


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

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 server’s 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 . This cmdlet specifies the domain to which you want to send domain-secured e-mail. Set-SendConnector -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 . This cmdlet specifies the domain from which you want to receive domain secured e-mail. Set-ReceiveConnector -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 partner’s 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 CA’s 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 B: Configuring Anti-Spam Filtering

Lab Setup

7-51




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 machines are running.

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. The main tasks for this exercise are as follows: 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 message’s 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. The main tasks for this exercise are as follows: 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 partner’s 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 Server’s 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.



2.


3.


4.

Right-click 10165A-NYC-DC1-B, and then in the Actions pane, click Start. Connect to the virtual machine



6.


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 in the troubleshooting tips. For answers, refer to relevant lessons in the module. 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 Supplement or modify the following best practices for your own work situations:

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

Lab: Implementing High Availability

8-40


Implementing High Availability


Updating Your Skills from Microsoft ® Exchange Server 2003 or Exchange Server 2007 to Exchange Server 2010 SP1

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 2010—including those that are coexisting with Exchange Server 2003 or Exchange Server 2007—can survive the failure of a single server, or even multiple servers. You can implement high availability for all the server roles in Exchange Server 2010. After completing this module, you will be able to: •

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

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 Quorum is maintained when more than half the votes are online

Supported and recommended for cluster continuous replication (CCR)

Supported

Node and Disk Majority

The nodes in the cluster and a witness disk have a vote Quorum is maintained when more than half the votes are online

Supported and recommended for single copy clusters (SCCs)

Not supported

No Majority: Disk Only

Only the quorum shared disk has a vote Quorum is maintained 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 -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 database’s 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 Replication–File Mode

Continuous replication creates a passive database copy on another Exchange Server computer in the DAG, and then uses asynchronous log shipping to maintain the copies. The continuous replication–file mode, 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 target—or passive node—tells 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 Replication–Block Mode

Continuous replication–block 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 DAG’s 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.


Click Start, click All Programs, click Microsoft Exchange Server 2010, and then click Exchange 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 database’s 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 Server–specific event logs located in the Applications and Services node. The two specific logs that are of interest for high availability are the High Availability and MailboxDatabaseFailureItems logs.

Exchange Server 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 http://go.microsoft.com/fwlink/?LinkId=213763. 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). After completing this lesson, you will be able to: •

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 redundancy−which is the case for Exchange 2003 servers and Exchange 2007 servers−the 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 message’s 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 Hub’s 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. After completing this lesson, you will be able to: •

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 company’s 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: •

0

Local database is not allowed to be mounted

•

1

Local database is allowed to be mounted

The DACP protocol is: •

During Active Manager start up, DACP is set at 0.

•

In Datacenter Activation Coordination mode, the server tries to communicate with all other Exchange servers that are members of the DAG to find a member that has its DACP bit set at 1.



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 DAG’s 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 -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 site’s 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 –ActiveDirectorySite

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 –ActiveDirectorySite -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 site’s DAG’s servers, and then run the following cmdlet:



8-38

Restore-DatabaseAvailabilityGroup -ActiveDirectorySite -AlternateWitnessServer

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 –ActiveDirectorySite

3.

If required, reconfigure the DAG to use the primary site’s witness server. To do this, run the following cmdlet:

Set-DatabaseAvailabilityGroup –WitnessServer

4.

Manually reseed or allow replication to update the primary data center’s 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 –ActivateOnServer

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 machines are running.

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. The main tasks for this exercise are as follows: 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. The main tasks for this exercise are as follows: 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 organization’s requirements are met. You should verify Hub Transport redundancy, and manual and automatic failover of mailbox databases when a server outage occurs. The main tasks for this exercise are as follows: 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; [email protected], 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



2.


3.


4.

Repeat the steps for 10165A-NYC-EX10-B, and 10165A-NYC-EX11-B.

5.




7.


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?

Real-World Issues and Scenarios 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 Supplement or modify the following best practices for your own work situations: •

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 Implementing Backup and Recovery 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

Lab: Implementing Backup and Recovery

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. After completing this module, you will be able to: 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. After completing this lesson, you will be able to: 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 organization’s 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.


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 company’s 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. After completing this lesson, you will be able to: 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 Server–aware, 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 system’s 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.

Client Access server

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 2010’s 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 volume’s 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 volume’s 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 2010—can 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 system’s 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 Server–only backup feature. You need to back up at least a complete volume to create an Exchange Server–aware 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.


On NYC–EX10, 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 information−such as files, an Exchange Server 2010 database, or even a mailbox−rather 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. After completing this lesson, you will be able to: 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 Christine’s 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.


Use the following command to repair Christine’s 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 organization’s 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 simultaneously−the 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 file’s 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 command. If the database is still in Dirty Shutdown state, use ESEUTIL /P 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 -Server -EDBFilePath "\.edb" -LogFolderPath ""

Next, run the following command to mount the recovery database: Mount-Database

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

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 -SourceDatabase -AllowLegacyDNMismatch -TargetMailbox -TargetRootFolder

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

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 backup—including the System State backup—and 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 Server’s 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 server’s 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



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. The main tasks for this exercise are as follows: •

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:

New-DatabaseAvailabilityGroup –Name DAG1 –WitnessServer NYC-DC1 -WitnessDirectory 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. The main tasks for this exercise are as follows: 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. The main tasks for this exercise are as follows: 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. The main tasks for this exercise are as follows: 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.



2.


3.


4.

Repeat steps 1-3 for 10165A-NYC-EX10-B, and 10165A-NYC-EX11-B.

5.




7.


8.




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 troubleshooting tips. For answers, refer to relevant lessons in the module. Issue

Troubleshooting tips

Recover deleted mailbox items quickly. Restore fails during an emergency situation.

Best Practices Related to Implementing Backup and Recovery Supplement or modify the following best practices for your own work situations: 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

Lab A: Configuring Transport Rules, Journal Rules, and Multi-Mailbox Search

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


Configuring Messaging Policy and Compliance


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 infrastructures—including their email infrastructures—can 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.


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 organization’s 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 corporation’s 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.


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 organization’s 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 organization’s 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 message’s distribution scope, and you can define the conditions that trigger the journaling action by specifying criteria such as an individual user, sender, or the recipient’s 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.


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 organization’s 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 rules—whether they apply to Hub Transport or Edge Transport servers—are 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 attributes—headers, recipients, senders, or other parts of the message—Exchange Server uses to identify the email messages to which it applies a transport rule action. If the email message data matches a transport rule condition’s 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 rule’s 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 message—such 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.

This e-mail and attachments are intended for the individual or group addressed.

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 classification’s 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 organization’s 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 information—such as financial reports, product specifications, customer data, and confidential email messages—from intentionally or accidentally getting into the wrong hands.

Restrict Access to an Organization’s 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 recipient’s 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 recipient’s authorization. If the AD RMS cluster denies the user’s 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 cluster’s private key and re-encrypts the content key with the recipient’s 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 recipient’s computer. The application examines both the license and the recipient’s account certificate. Exchange Server then grants the user access as per the content author’s 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 recipient’s 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 rule—such as applying a disclaimer or modifying the message—can be applied to the unencrypted message. After other transport agents have inspected the message, 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 organization’s AD RMS cluster will display in the Outlook Web App preview pane without requiring additional add-ons, or that the user’s 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 organization’s 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 moderator’s 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 moderator’s 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 organization’s mailboxes based on specific criteria. This lesson describes how to configure and utilize message journaling and Multi-Mailbox Search in Exchange Server 2010.


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 information—such as the recipient’s address, the sender’s 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 agent—which 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 server—these include messages that journal rules processed previously in the Internal and External scopes.

Journal rules configured on a Hub Transport server apply to the entire Exchange Server organization. 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 message’s 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 messages—or both—will be journaled. All messages that the recipient sends or receives are journaled.

4.

Send a test message to a journal recipient. Log on to the journal recipient mailbox, and then reply to the message.


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 mailbox’s 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 mailbox’s 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 organization’s 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 organization’s journaling mailboxes, and limit access to only those individuals who have a direct need for access. Ensure that legal representatives approve your plan to 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 arise—such 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 query—if required—before 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 user’s mailboxes, you can also perform Multi-Mailbox Searches on items that users have deleted. Under some circumstances—such as a court order or lawsuit—it 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 [email protected] -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 user’s 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 Contoso\Administrator, with the password, Pa$$w0rd.

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. The main tasks for this exercise are: 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 group’s 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 [email protected]. 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.


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.


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; [email protected]

•

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 Sten’s 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.


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 user’s 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 user’s regular mailbox. The user can then move the PST folders—or any other messages—into 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 components—such as backup capacity—to 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.


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 retained—such 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 user’s 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 Exchange Management Shell.

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 [email protected]

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 user’s 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 user’s 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 folders—such as the Inbox folder—and 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 folders—which require users to move items to a managed folder based on retention settings—Retention 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 folder’s 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





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. The main tasks for this exercise are: 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 user’s Deleted Items mailbox folder must be permanently deleted after 30 days.

•

Items in a user’s 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. The main tasks for this exercise are: 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




2.


3.


4.




6.


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 in the troubleshooting tips. For answers, refer to relevant lessons in the module. 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



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 Supplement or modify the following best practices for your own work situations: •

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 organization’s 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


• Administration and management of Exchange Server 2010 objects

Start menu


• Performing Multi-mailbox search

/ecp virtual folder

11-1

Module 11 Securing Microsoft® Exchange Server 2010 Contents: Lesson 1: Configuring Role Based Access Control


Securing Microsoft® Exchange Server 2010

11-3

Lesson 2: Configuring Audit Logging

11-29

Lesson 3: Configuring Secure Internet Access

11-35

Lab: Securing Exchange Server 2010

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.


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.


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 tools—including the Exchange Management Console, Exchange Management Shell, and Exchange Control Panel—use 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 Server–related 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 action—such as creating a mailbox—in 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 groups−the role holders−to 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


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


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


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 organization’s 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 Server—including servers and recipients—can 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 administrators—such as Exchange Server administrators—can 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 management—including creating and modifying distribution groups—using 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 Recipient 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 administrator—who is a member of the new group—will need to create the object, and then an Exchange Server administrator will need to configure the Exchange Server attributes on the object. 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 Server–specific objects (such as transport rules and distribution groups) and manage Exchange Server–related 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 partition—such as mailboxes and distribution groups—using 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 group—in shared permissions and RBAC split permissions—is 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 organization’s 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 Exchange Server 2007.

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.

Exchange Server 2003 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 Exchange Server 2010 role groups.

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 2010 role groups. Exchange Server 2007 administrative role

Exchange Server 2010 role group

Exchange Organization Administrator


Exchange Recipient Administrator

Recipient Management

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.


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 [email protected]. Run the following cmdlet: New-AdminAuditLogSearch -Cmdlets Set-Mailbox -StartDate 09/01/2010 -EndDate 01/16/2011 -StatusMailRecipients [email protected] -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 Mailbox—which may contain more sensitive information—consider 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 Chudzik’s 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 Terri’s 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 Terri’s and Candy’s 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 "[email protected]"

This command locates access attempts by administrators and delegates during 2010. Results are sent to email alias [email protected].



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.


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 [email protected].

5.

Access Terri’s mailbox as Candy Spoon and send an email message from Terri’s 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.


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 organization’s 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 Destination address: External IP address of the internal firewall



11-40

Destination port

Address Only required for POP3 access

143, 993

Source address: All Destination address: External IP address of the internal firewall Only required for IMAP4 access

587

Source address: All Destination address: External IP address of the internal firewall 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 Hub Transport server

80, 443

Source address: Internal IP address of the external firewall Destination address: Client Access server

110, 995

Source address: External IP addresses Destination address: Client Access server Only required for POP3 access

143, 993

Source address: External IP addresses Destination address: Client Access server Only required for IMAP4 access

587

Source address: External IP addresses Destination address: Hub Transport server Only required if POP3 and IMAP4 clients are using the SMTP client submission port to send SMTP e-mail

50636

Source address: Hub Transport servers on the internal network Destination address: Edge Transport server 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 Destination address: Edge Transport server 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 connections−such as Outlook Web App and Exchange ActiveSync−come 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 domain’s members, but not by other client computers. That’s 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 options—such as Outlook Anywhere or Exchange ActiveSync—cannot 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 organization’s 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 RSA’s 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 retrieve—not send—messages from user mailboxes. To enable clients to send email, you must configure the clients to use an SMTP server that relays the messages to both internal and external recipients.

To enable the POP3 and IMAP4 clients to send email, you must configure a Hub Transport server SMTP Receive connector to accept SMTP connections from the Internet. Configure the SMTP Receive connector to require authentication, so that only users with valid accounts in the Exchange Server 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 user’s 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 organization’s requirements, you need to configure permissions for the IT group and the SupportDesk group. The main tasks for this exercise are as follows: 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 [email protected] shared mailbox. The main tasks for this exercise are as follows: 1.

Verify permissions on the [email protected] account.

2.

Enable audit logging on the [email protected] mailbox.

3.

Perform SendAs activity on the [email protected] mailbox.

4.

Verify that the activity is logged.

5.

Verify the administrator audit logging configuration.

6.

Make a change to Terri Chudzik’s mailbox.

7.

Verify that the change was logged.

 Task 1: Verify permissions on the [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] mailbox. Include a date range from 01/01/2011 to tomorrow’s 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 Chudzik’s 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 (Tomorrow’s 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 organization’s 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. The main tasks for this exercise are as follows: 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.


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


2.


3.


4.






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 user’s 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. Clients cannot connect to the published sites, and they receive certificate errors.

Troubleshooting tip

Issue



11-55

Troubleshooting tip

Clients cannot connect to the published sites, and they receive “site not found” errors.


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 Supplement or modify the following best practices for your own work situations: •

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 many—or too few—permissions.

•

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

Lab: Monitoring and Troubleshooting Exchange Server 2010

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.


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.


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 Should be below 1,000 on 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 Should be below 1,000 on 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.


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.


Avg. Disk sec/Write

Displays the average time (in seconds) for writing data to the disk.


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)

Displays the number of messages queued for delivery in all queues.

Should be less than 3,000 and not more than 5,000.

Active Remote Delivery Queue Length

Displays the number of messages in the active remote delivery queues.

Should be less than 250 at all times.

Active Mailbox Delivery Queue Length

Displays the number of messages in the active mailbox queues.


Retry Mailbox Delivery Queue Length

Displays the number of messages in a retry state that are attempting to deliver a message to a remote mailbox.


Unreachable Queue Length

Displays the number of messages in the Unreachable queue.

Should not exceed 100.

Largest Delivery Queue Length

Displays the number of messages in the largest delivery queues.

Should be less than 200.

Poison Queue Length

Displays the number of messages 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

server’s 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 servers—or the thresholds themselves—to 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 object’s 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 problem’s source, and fixing it.


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 tools—such as the Reliability and Performance and Monitor—check the health of the Exchange Server processes. You can use the Queue Viewer to view the message status in transport queues. Tools such as Network Monitor and Telnet can help you troubleshoot network issues and message tracking, and the Routing Log Viewer can help you troubleshoot message delivery issues. There are many other tools—in addition to the Exchange Management Console, the Exchange Management Shell, and Active Directory Users and Computers—that 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 organization’s 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 Setup



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. The main tasks for this exercise are as follows: 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


MSExchangeIS Public


 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. The main tasks for this exercise are as follows:



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 which—if any—mailbox 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. The main tasks for this exercise are as follows: 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 solutions—if multiple options exist.

5.

Configure Outlook Web App settings.

6.

Verify that you have resolved the problem.

 Preparation Before you begin this exercise, complete the following steps: 1.

On NYC-EX10, open an Exchange Management Shell. At the prompt, type 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.


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 Contoso\Administrator, with the password, Pa$$w0rd.

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 solutions—if multiple options exist •

List the problems and possible solutions: 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.

 To prepare for the next module When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the following steps: 1.


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 started before starting the other virtual machines. 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.

Real-World Issues and Scenarios •

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 Supplement or modify the following best practices for your own work situations: •

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 person’s 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 Exchange Server 2010 Contents: Lesson 1: Upgrading from Exchange Server 2007 to Exchange Server 2010 Lab: 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.


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 Exchange Server 2010. •

Install the Exchange Server 2010 Client Access server. After you complete this installation, you should use this as the primary connection point for all client connections. This means that you should modify the AutoDiscover settings—both internally and externally—to 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 organization’s 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 connections—including Microsoft Office Outlook® Messaging Application Programming Interface (MAPI) connections—now 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 URL—such as https://mail.contoso.com—to 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 server’s 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 user’s mailbox. For example, if the user’s 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 name—for example, legacy.contoso.com—and 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 record—for example, legacy.contoso.com—in your external DNS infrastructure, and configure it to reference the Exchange Server 2007 Client Access server.

•

Create or modify the host record for Autodiscover—for 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 URL—for example, mail.contoso.com—and 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 objects—such as new mailboxes or a new offline address book—on a version of the Exchange Management Console that is the same as the target object. For example, you must create a new mailbox on an Exchange Server 2007 Mailbox server by using the 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 Administrators group.

Add users or groups to the View-Only Organization Management role group.

Assign users to the Exchange Recipient Administrators group.

Add users or groups to the Recipient Management role group.

Assign users to the Exchange Public Folder Administrators group.

Add users or groups to the Public Folder Management role group.

Assign users as server administrators for a specific Exchange Server 2007 server.

Create a custom role group that includes only server management roles, and with a scope limited to a single server.

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



2.

Ensure that the 10165A-ROM-DC1-C, 10165A-ROM-EX07-C, and 10165A-ROM-EX10-C virtual machines are running.

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.

 To prepare for this lab 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 Corporation’s 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. The main tasks for this exercise are as follows: •

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 [email protected].

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 [email protected] to [email protected].

9.

In Outlook Web App, verify that the message from [email protected] 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 Herbinger’s 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 to Exchange Server 2010.

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. The main tasks for this exercise are as follows: •

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 [email protected].

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 [email protected] to [email protected].

7.

In Outlook Web App, verify that the message from [email protected] 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 Supplement or modify the following best practices for your own work situations: •

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

Understanding and Planning for Microsoft® Exchange Online 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 organization’s 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. After completing this module, you will be able to: •

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

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 organization’s 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




Mailbox size

500 megabytes (MB)

25 gigabytes (GB) shared between the primary mailbox and archive mailbox

25 GB for the user’s mailbox plus unlimited archive mailbox storage

Outlook Web App (regular and light versions)

Yes

Yes

Yes

POP3

Yes

Yes

Yes



A-9

Feature




IMAP4

No

Yes

Yes

Outlook Anywhere (MAPI)

No

Yes

Yes

Microsoft Exchange ActiveSync®

No

Yes

Yes


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 company’s 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 organization’s 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 functionality−such as mailbox archiving−to 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 organization’s 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 company’s 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 company’s 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. After completing this lesson, you will be able to: •

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 company’s 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 company’s 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

Exchange Control Panel 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).


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 http://go.microsoft.com/fwlink/?LinkId=213772.

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 organization’s users by using exactly the same steps as booking meetings with users inside the organization. After completing this lesson, you will be able to: •

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 organization’s certificate to Microsoft Federation Gateway and downloading the Microsoft Federation Gateway certificate.

Organization Identifier

The organization identifier defines which of the Exchange organization’s 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 organization’s users. The following steps describe the communication flow when you configure this option, and a user in one organization invites another organization’s 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 user’s availability information from the user’s 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 partner’s 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 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 organization’s 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 organization’s 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 organization’s 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 started before starting the other virtual machines.

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 don’t 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.

In Hyper-V Manager, connect C:\Program Files\Microsoft 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.


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 don’t 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 then click Exchange Management Console.

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 don’t 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 Configuration, and then click Mailbox.

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

Lab: 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, and then click Mailbox.

2.

In the Content pane, select the Database Management tab.

3.

In the Actions pane, click New Public Folder Database.

4.

On the New Public Folder Database page, 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

Lab: Managing Exchange Server Recipients 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 Exchange Management Console.

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.

10. Click New, and then click Finish.

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 president’s administrative assistant, Parna Khot 1.

On NYC-EX10, click Start, click All Programs, click Microsoft Exchange Server 2010, and then click Exchange Management Shell.

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 you’re 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.

In the console tree, expand Microsoft Exchange On-Premises, expand Recipient Configuration, 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.

On NYC-EX10, in the Exchange Management Console, expand Organization Configuration, and then click Hub Transport.

2.

In the Actions pane, click New E-mail Address Policy.

3.

In the New E-Mail Address Policy wizard, type Adventure Works as the policy name.

4.

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. 13. Click New, and then click Finish.

 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. 12. Click New, and then click Finish.

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

On NYC-EX10, in Exchange Management Console, under Organization Configuration, click 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.

On NYC-EX10, in Exchange Management Console, under Organization Configuration, click Mailbox, and then click the Offline Address Book tab.

2.

In the Actions pane, click New Offline Address Book.

3.

In the Name box, type 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. 11. Click New, and then click Finish.



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. 13. Click Next, click New, and then click Finish.

 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 Don’t 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 [email protected], 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 Exchange Server 2010  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: Set-OWAVirtualDirectory NYC-EX11\OWA* -Exchange2003URL https://legacy.contoso.com/exchange

 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 Exchange Server 2010 and Exchange Server 2003.

 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 [email protected], 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. 13. Close Internet Explorer. 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 [email protected] 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 [email protected], 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:[email protected], and then press ENTER. Response: 250 2.1.0 [email protected] OK 15. Type rcpt to:[email protected], and then press ENTER. Response: 250 2.1.5 [email protected] 16. Type data, and then press ENTER. Response: 354 Start mail input; end with . 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.

On NYC-EX10, click Start, point to All Programs, point to Microsoft Exchange Server 2010, and 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 [email protected] 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 Alan’s 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



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 then click Exchange Management Shell.

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=. 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 Exchange Management Console, expand Organization Configuration, and then 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 [email protected] 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-NYC–SVR1-B, and then in the Actions pane, click Settings.

3.


4.

Browse to C:\Program Files\Microsoft Learning\10165\Drives, click ForeFrontInstall.iso, click Open, and then click OK. On NYC-SVR1, close the AutoPlay dialog box.

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

Lab B: Configuring Anti-Spam Filtering 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.

On NYC-SVR1, click Start, point to All Programs, point to Microsoft Exchange Server 2010, and then click Exchange Management Console.

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

[email protected]

7

[email protected]

8

[email protected]

7

[email protected]

7

[email protected]

8

[email protected]

6

[email protected]

8

[email protected]

7


Mail sender

SCL level

[email protected]

6

[email protected]

6

[email protected]

8


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 [email protected]. 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.

On NYC-SVR1, click Start, point to All Programs, point to Microsoft Exchange Server 2010, and then click Exchange Management Console.

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 Christine’s 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 Christine’s 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 partner’s 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 partner’s 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 Exchange Management Shell.

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 server’s 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

Lab: 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, and then click Mailbox.

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.

On NYC-EX11, in the Exchange Management Console, under Organization Configuration, click 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; [email protected].

8.

In the Subject box, type Shadow Redundancy.

9.

In the message body, type Test email, and then click Send.

10. Close Internet Explorer.

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


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:

New-DatabaseAvailabilityGroup –Name DAG1 –WitnessServer NYC-DC1 -WitnessDirectory 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.

Click Start, click All Programs, click Microsoft Exchange Server 2010, and then click Exchange 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.

In the Internet Explorer Address bar, type https://NYC-EX10.contoso.com/owa, and then press 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, and then click Next.

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.

In the Internet Explorer Address bar, type https://NYC-EX10.contoso.com/owa, and then press 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.

In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand 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



Module 10: Configuring Messaging Policy and Compliance

Lab A: Configuring Transport Rules, Journal Rules, and Multi-Mailbox Search  To prepare for this lab 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 [email protected].

3.

Create another message to [email protected], 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.

In the Windows dialog box, click Select a program from a list of installed programs, and then 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. 14. Close Internet Explorer. 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; [email protected]

•

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 – [email protected] 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.

On NYC-EX10, in Exchange Management Console, expand Organization Configuration, and then 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.

On NYC-EX10, in the Exchange Management Console, expand Organization Configuration, and 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.

On NYC-EX10, in the Exchange Management Console, expand Organization Configuration, and 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, and then click Next.

5.

On the Select Mailboxes page, click Add.

6.

In Select Mailbox – Entire Forest, click Scope menu, and then click Modify Recipient Picker Scope.

7.

Click View all recipients in specified organizational unit, and then click Browse.

8.

Click Marketing, and then click OK twice.

9.

After the scope changes, select all users in the list, and then click OK.


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

Lab: Securing 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.

In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand 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 group’s 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 [email protected] account 1.


2.

In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand 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 [email protected] 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 [email protected] 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 [email protected].

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 tomorrow’s 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 Chudzik’s 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 (Tomorrow’s 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 [email protected]. 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® Exchange Server 2010

Lab: Monitoring and Troubleshooting Exchange Server 2010 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 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.


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


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 don’t 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 multiple options exist •


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.


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 Before you begin this exercise, complete the following steps: 1.

On NYC-EX10, open an Exchange Management Shell. At the prompt, type 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.

 Task 2: Review the event logs


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 solutions—if multiple options exist •


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 don’t 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.


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 don’t 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 don’t 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. 13. Click New, and then click Finish.

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;[email protected].

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:[email protected], and then press Enter. 22. Type rcpt to:[email protected], 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 [email protected] 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, 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 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. 12. Click Next, click New, and then click Finish.

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

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.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. 19. Close Internet Explorer.



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. 12. Close Internet Explorer.

 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. 14. Close Internet Explorer.

 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 then click Hub Transport.

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 then click Hub Transport.

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 to Exchange Server 2010.


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 [email protected].

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:[email protected], and then press Enter. 16. Type rcpt to:[email protected], 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 [email protected] arrived. 22. Close Internet Explorer.

 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 5–10, 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

Recommend Documents