10233BD-ENU-TrainerHandbook

8/16/2019 10233BD-ENU-TrainerHandbook

http://slidepdf.com/reader/full/10233bd-enu-trainerhandbook 1/818

O F F I C I A L M I C R O S O F T L E A R N I N G P R O D U C T

10233BDesigning and Deploying Messaging

Solutions with Microsoft® ExchangeServer 2010 SP2



ii Designing and Deploying Messaging Solutions with Microsoft® Exchange Server 2010 SP2

Information in this document, including URL and other Internet Web site references, is subject to change

without notice. Unless otherwise noted, the example companies, organizations, products, domain names,

e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with

any real company, organization, product, domain name, e-mail address, logo, person, place or event is

intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the

user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in

or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical,

photocopying, recording, or otherwise), or for any purpose, without the express written permission of

Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property

rights covering subject matter in this document. Except as expressly provided in any written license

agreement from Microsoft, the furnishing of this document does not give you any license to these

patents, trademarks, copyrights, or other intellectual property.

The names of manufacturers, products, or URLs are provided for informational purposes only and

Microsoft makes no representations and warranties, either expressed, implied, or statutory, regarding

these manufacturers or the use of the products with any Microsoft technologies. The inclusion of a

manufacturer or product does not imply endorsement of Microsoft of the manufacturer or product. Links

may be provided to third party sites. Such sites are not under the control of Microsoft and Microsoft is not

responsible for the contents of any linked site or any link contained in a linked site, or any changes or

updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission

received from any linked site. Microsoft is providing these links to you only as a convenience, and the

inclusion of any link does not imply endorsement of Microsoft of the site or the products contained

therein.

© 2012 Microsoft Corporation. All rights reserved.

Microsoft and the trademarks listed at http://www.microsoft.com/about/legal/en/us/IntellectualProperty

/Trademarks/EN-US.aspx are trademarks of the Microsoft group of companies. All other trademarks are

property of their respective owners

Product Number: 10233B

Released: 03/2012

http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/EN-US.aspx










j. “Microsoft Partner Network Member” or “MPN Member” means a silver or gold-level Microsoft Partner

Network program member in good standing.

k. “Personal Device” means one (1) device, workstation or other digital electronic device that you

personally own or control that meets or exceeds the hardware level specified for the particular MOC

Course.

l. “Private Training Session” means the instructor-led training classes provided by MPN Members for

corporate customers to teach a predefined learning objective. These classes are not advertised or

promoted to the general public and class attendance is restricted to individuals employed by or

contracted by the corporate customer.

m. “Trainer Content” means the trainer version of the MOC Course and additional content designated

solely for trainers to use to teach a training session using a MOC Course. Trainer Content may include

Microsoft PowerPoint presentations, instructor notes, lab setup guide, demonstration guides, beta

feedback form and trainer preparation guide for the MOC Course. To clarify, Trainer Content does not

include virtual hard disks or virtual machines.

2. INSTALLATION AND USE RIGHTS. The Licensed Content is licensed not sold. The Licensed Content is

licensed on a one copy per user basis, such that you must acquire a license for each individual that

accesses or uses the Licensed Content.

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

a. If you are a Authorized Learning Center:

i.

If the Licensed Content is in digital format for each license you acquire you may either:

1.

install one (1) copy of the Licensed Content in the form provided to you on a dedicated, secure

server located on your premises where the Authorized Training Session is held for access and

use by one (1) End User attending the Authorized Training Session, or by one (1) MCT teaching

the Authorized Training Session, or

2.

install one (1) copy of the Licensed Content in the form provided to you on one (1) Classroom

Device for access and use by one (1) End User attending the Authorized Training Session, or by

one (1) MCT teaching the Authorized Training Session.

ii. You agree that:

1. you will acquire a license for each End User and MCT that accesses the Licensed Content,

2.

each End User and MCT will be presented with a copy of this agreement and each individual

will agree that their use of the Licensed Content will be subject to these license terms prior to

their accessing the Licensed Content. Each individual will be required to denote their

acceptance of the EULA in a manner that is enforceable under local law prior to their accessing

the Licensed Content,

3.

for all Authorized Training Sessions, you will only use qualified MCTs who hold the applicable

competency to teach the particular MOC Course that is the subject of the training session,

4. you will not alter or remove any copyright or other protective notices contained in the

Licensed Content,



5. you will remove and irretrievably delete all Licensed Content from all Classroom Devices and

servers at the end of the Authorized Training Session,

6. you will only provide access to the Licensed Content to End Users and MCTs,

7. you will only provide access to the Trainer Content to MCTs, and

8. any Licensed Content installed for use during a training session will be done in accordance

with the applicable classroom set-up guide.

b. If you are a MPN Member.

i. If the Licensed Content is in digital format for each license you acquire you may either:

1. install one (1) copy of the Licensed Content in the form provided to you on (A) one (1)

Classroom Device, or (B) one (1) dedicated, secure server located at your premises where

the training session is held for use by one (1) of your employees attending a training session

provided by you, or by one (1) MCT that is teaching the training session, or

2. install one (1) copy of the Licensed Content in the form provided to you on one (1)

Classroom Device for use by one (1) End User attending a Private Training Session, or one (1)

MCT that is teaching the Private Training Session.

ii.

You agree that:

1. you will acquire a license for each End User and MCT that accesses the Licensed Content,

2. each End User and MCT will be presented with a copy of this agreement and each individual

will agree that their use of the Licensed Content will be subject to these license terms prior

to their accessing the Licensed Content. Each individual will be required to denote their

acceptance of the EULA in a manner that is enforceable under local law prior to their

accessing the Licensed Content,

3. for all training sessions, you will only use qualified MCTs who hold the applicable

competency to teach the particular MOC Course that is the subject of the training session,

4.

you will not alter or remove any copyright or other protective notices contained in the

Licensed Content,

5.

you will remove and irretrievably delete all Licensed Content from all Classroom Devices and

servers at the end of each training session,

6. you will only provide access to the Licensed Content to End Users and MCTs,

7. you will only provide access to the Trainer Content to MCTs, and

8.

any Licensed Content installed for use during a training session will be done in accordance

with the applicable classroom set-up guide.

c. If you are an End User:

You may use the Licensed Content solely for your personal training use. If the Licensed Content is in

digital format, for each license you acquire you may (i) install one (1) copy of the Licensed Content in

the form provided to you on one (1) Personal Device and install another copy on another Personal

Device as a backup copy, which may be used only to reinstall the Licensed Content; or (ii) print one (1)

copy of the Licensed Content. You may not install or use a copy of the Licensed Content on a device

you do not own or control.



d. If you are a MCT.

i.

For each license you acquire, you may use the Licensed Content solely to prepare and deliver an

Authorized Training Session or Private Training Session. For each license you acquire, you may

install and use one (1) copy of the Licensed Content in the form provided to you on one (1) Personal

Device and install one (1) additional copy on another Personal Device as a backup copy, which may

be used only to reinstall the Licensed Content. You may not install or use a copy of the LicensedContent on a device you do not own or control.

ii. Use of Instructional Components in Trainer Content. You may customize, in accordance with the

most recent version of the MCT Agreement, those portions of the Trainer Content that are logically

associated with instruction of a training session. If you elect to exercise the foregoing rights, you

agree: (a) that any of these customizations will only be used for providing a training session, (b) any

customizations will comply with the terms and conditions for Modified Training Sessions and

Supplemental Materials in the most recent version of the MCT agreement and with this agreement.

For clarity, any use of “customize” refers only to changing the order of slides and content, and/or

not using all the slides or content, it does not mean changing or modifying any slide or content.

2.2

Separation of Components. The Licensed Content components are licensed as a single unit and youmay not separate the components and install them on different devices.

2.3 Reproduction/Redistribution Licensed Content. Except as expressly provided in the applicable

installation and use rights above, you may not reproduce or distribute the Licensed Content or any portion

thereof (including any permitted modifications) to any third parties without the express written permission

of Microsoft.

2.4 Third Party Programs. The Licensed Content may contain third party programs or services. These

license terms will apply to your use of those third party programs or services, unless other terms accompany

those programs and services.

2.5 Additional Terms. Some Licensed Content may contain components with additional terms,

conditions, and licenses regarding its use. Any non-conflicting terms in those conditions and licenses also

apply to that respective component and supplements the terms described in this Agreement.

3. PRE-RELEASE VERSIONS. If the Licensed Content is a pre-release (“beta”) version, in addition to the other

provisions in this agreement, then these terms also apply:

a. Pre-Release Licensed Content. This Licensed Content is a pre-release version. It may not contain the

same information and/or work the way a final version of the Licensed Content will. We may change it

for the final version. We also may not release a final version. Microsoft is under no obligation to

provide you with any further content, including the final release version of the Licensed Content.

b. Feedback. If you agree to give feedback about the Licensed Content to Microsoft, either directly or

through its third party designee, you give to Microsoft without charge, the right to use, share and

commercialize your feedback in any way and for any purpose. You also give to third parties, without

charge, any patent rights needed for their products, technologies and services to use or interface with

any specific parts of a Microsoft software, Microsoft product, or service that includes the feedback. You

will not give feedback that is subject to a license that requires Microsoft to license its software,

technologies, or products to third parties because we include your feedback in them. These rights



survive this agreement.

c. Term. If you are an Authorized Training Center, MCT or MPN, you agree to cease using all copies of the

beta version of the Licensed Content upon (i) the date which Microsoft informs you is the end date for

using the beta version, or (ii) sixty (60) days after the commercial release of the Licensed Content,

whichever is earliest (“beta term”). Upon expiration or termination of the beta term, you will

irretrievably delete and destroy all copies of same in the possession or under your control.

4. INTERNET-BASED SERVICES. Microsoft may provide Internet-based services with the Licensed Content,

which may change or be canceled at any time.

a. Consent for Internet-Based Services. The Licensed Content may connect to computer systems over an

Internet-based wireless network. In some cases, you will not receive a separate notice when they

connect. Using the Licensed Content operates as your consent to the transmission of standard device

information (including but not limited to technical information about your device, system and

application software, and peripherals) for internet-based services.

b.

Misuse of Internet-based Services. You may not use any Internet-based service in any way that couldharm it or impair anyone else’s use of it. You may not use the service to try to gain unauthorized access

to any service, data, account or network by any means.

5. SCOPE OF LICENSE. The Licensed Content is licensed, not sold. This agreement only gives you some rights

to use the Licensed Content. Microsoft reserves all other rights. Unless applicable law gives you more

rights despite this limitation, you may use the Licensed Content only as expressly permitted in this

agreement. In doing so, you must comply with any technical limitations in the Licensed Content that only

allows you to use it in certain ways. Except as expressly permitted in this agreement, you may not:

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

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

•

publicly display, or make the Licensed Content available for others to access or use;• install, sell, publish, transmit, encumber, pledge, lend, copy, adapt, link to, post, rent, lease or lend,

make available or distribute the Licensed Content to any third party, except as expressly permitted

by this Agreement.

• reverse engineer, decompile, remove or otherwise thwart any protections or disassemble the

Licensed Content except and only to the extent that applicable law expressly permits, despite this

limitation;

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

using the Licensed Content;

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

use; or

•

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

6. RESERVATION OF RIGHTS AND OWNERSHIP. Microsoft reserves all rights not expressly granted to you in

this agreement. The Licensed Content is protected by copyright and other intellectual property laws and

treaties. Microsoft or its suppliers own the title, copyright, and other intellectual property rights in the

Licensed Content. You may not remove or obscure any copyright, trademark or patent notices that

appear on the Licensed Content or any components thereof, as delivered to you.



7. EXPORT RESTRICTIONS. The Licensed Content is subject to United States export laws and regulations. You

must comply with all domestic and international export laws and regulations that apply to the Licensed

Content. These laws include restrictions on destinations, End Users and end use. For additional

information, see www.microsoft.com/exporting.

8. LIMITATIONS ON SALE, RENTAL, ETC. AND CERTAIN ASSIGNMENTS. You may not sell, rent, lease, lend or

sublicense the Licensed Content or any portion thereof, or transfer or assign this agreement.

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

10. TERMINATION. Without prejudice to any other rights, Microsoft may terminate this agreement if you fail

to comply with the terms and conditions of this agreement. Upon any termination of this agreement, you

agree to immediately stop all use of and to irretrievable delete and destroy all copies of the Licensed

Content in your possession or under your control.

11. LINKS TO THIRD PARTY SITES. You may link to third party sites through the use of the Licensed Content.

The third party sites are not under the control of Microsoft, and Microsoft is not responsible for the

contents of any third party sites, any links contained in third party sites, or any changes or updates to thirdparty sites. Microsoft is not responsible for webcasting or any other form of transmission received from

any third party sites. Microsoft is providing these links to third party sites to you only as a convenience,

and the inclusion of any link does not imply an endorsement by Microsoft of the third party site.

12. ENTIRE AGREEMENT. This agreement, and the terms for supplements, updates and support services are

the entire agreement for the Licensed Content.

13. APPLICABLE LAW. a. United States. If you acquired the Licensed Content in the United States, Washington state law governs

the interpretation of this agreement and applies to claims for breach of it, regardless of conflict of laws

principles. The laws of the state where you live govern all other claims, including claims under stateconsumer protection laws, unfair competition laws, and in tort.

b. Outside the United States. If you acquired the Licensed Content in any other country, the laws of that

country apply.

14. LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the laws of

your country. You may also have rights with respect to the party from whom you acquired the Licensed

Content. This agreement does not change your rights under the laws of your country if the laws of your

country do not permit it to do so.

15. DISCLAIMER OF WARRANTY. THE LICENSED CONTENT IS LICENSED "AS-IS," "WITH ALL FAULTS," AND "AS

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



16. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. TO THE EXTENT NOT PROHIBITED BYLAW, YOU CAN RECOVER FROM MICROSOFT CORPORATION AND ITS SUPPLIERS ONLY DIRECTDAMAGES UP TO USD$5.00. YOU AGREE NOT TO SEEK TO RECOVER ANY OTHER DAMAGES, INCLUDINGCONSEQUENTIAL, LOST PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES FROM MICROSOFTCORPORATION AND ITS RESPECTIVE SUPPLIERS.

This limitation applies to

o anything related to the Licensed Content, services made available through the Licensed Content, or

content (including code) on third party Internet sites or third-party programs; and

o

claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence,

or other tort to the extent permitted by applicable law.

It also applies even if Microsoft knew or should have known about the possibility of the damages. The

above limitation or exclusion may not apply to you because your country may not allow the exclusion or

limitation of incidental, consequential or other damages.

Please note: As this Licensed Content is distributed in Quebec, Canada, some of the clauses in this agreement

are provided below in French.

Remarque : Ce le contenu sous licence étant distribué au Québec, Canada, certaines des clauses dans cecontrat sont fournies ci-dessous en français.

EXONÉRATION DE GARANTIE. Le contenu sous licence visé par une licence est offert « tel quel ». Toute

utilisation de ce contenu sous licence est à votre seule risque et péril. Microsoft n’accorde aucune autre garantie

expresse. Vous pouvez bénéficier de droits additionnels en vertu du droit local sur la protection dues

consommateurs, que ce contrat ne peut modifier. La ou elles sont permises par le droit locale, les garanties

implicites de qualité marchande, d’adéquation à un usage particulier et d’absence de contrefaçon sont exclues.

LIMITATION DES DOMMAGES-INTÉRÊTS ET EXCLUSION DE RESPONSABILITÉ POUR LES DOMMAGES. Vouspouvez obtenir de Microsoft et de ses fournisseurs une indemnisation en cas de dommages directs uniquement

à hauteur de 5,00 $ US. Vous ne pouvez prétendre à aucune indemnisation pour les autres dommages, y

compris les dommages spéciaux, indirects ou accessoires et pertes de bénéfices.

Cette limitation concerne:

• tout ce qui est relié au le contenu sous licence , aux services ou au contenu (y compris le code)

figurant sur des sites Internet tiers ou dans des programmes tiers ; et

• les réclamations au titre de violation de contrat ou de garantie, ou au titre de responsabilité

stricte, de négligence ou d’une autre faute dans la limite autorisée par la loi en vigueur.

Elle s’applique également, même si Microsoft connaissait ou devrait connaître l’éventualité d’un tel dommage.

Si votre pays n’autorise pas l’exclusion ou la limitation de responsabilité pour les dommages indirects,

accessoires ou de quelque nature que ce soit, il se peut que la limitation ou l’exclusion ci-dessus ne s’appliquera

pas à votre égard.

EFFET JURIDIQUE. Le présent contrat décrit certains droits juridiques. Vous pourriez avoir d’autres droits prévus

par les lois de votre pays. Le présent contrat ne modifie pas les droits que vous confèrent les lois de votre pays

si celles-ci ne le permettent pas.

Revised December 2011



x Designing and Deploying Messaging Solutions with Microsoft® Exchange Server 2010 SP2



Designing and Deploying Messaging Solutions with Microsoft® Exchange Server 2010 SP2 xi

AcknowledgmentsMicrosoft Learning would like to acknowledge and thank the following for their contribution towards

developing this title. Their effort at various stages in the development has ensured that you have a good

classroom experience.

Stan Reimer – Content Developer

Stan Reimer is president of S. R. Technical Services Inc, and he works as a consultant, trainer and author.

Stan has extensive experience consulting on Active Directory and Exchange Server deployments for some

of the largest companies in Canada. Stan is the lead author for two Active Directory books for Microsoft

Press, and is currently working on an Exchange Server 2010 Best Practices book, also for Microsoft Press.

For the last six years, Stan has been writing courseware for Microsoft Learning, specializing in Active

Directory and Exchange Server courses. Stan has been an MCT for 11 years.

Byron Wright – Content Developer

Byron Wright is a partner in a consulting firm, where he performs network consulting, computer systems

implementation, and technical training. Byron is also a sessional instructor for the Asper School of

Business at the University of Manitoba, teaching management information systems and networking. Byron

has authored and co-authored a number of books on Windows servers, Windows Vista, and ExchangeServer, including the Windows Server 2008 Active Directory Resource Kit.

Andrew J. Warren – Content Developer

Andrew Warren (MCSE, MCITP, and MCT) has more than 22 years of experience in the IT industry, many of

which have been spent in writing and teaching. He has been involved as the subject matter expert (SME)

for the 6430B course for Windows Server 2008 and the technical lead on a number of other courses. He

also has been involved in TechNet sessions on Microsoft® Exchange Server 2007. Based in the United

Kingdom, he runs his own IT training and education consultancy.

Siegfried Jagott – Technical Reviewer

Siegfried Jagott is a Principal Consultant and Team Lead for the Messaging and Collaboration team inSiemens IT Solutions located in Munich, Germany. He has planned, designed, and implemented some of

the world’s largest Windows and Exchange Server infrastructures for international customers. Additionally,

he hosted a monthly column for Windows IT Magazine called “Exchange & Outlook UPDATE: Outlook

Perspectives.” He writes for international magazines and lectures about Windows and Exchange Server-

related topics. He received an MBA from Open University in England, and is a Microsoft Certified Systems

Engineer (MCSE) since 1997.



xii Designing and Deploying Messaging Solutions with Microsoft® Exchange Server 2010 SP2

Contents

Module 1: Introduction to Designing a Microsoft® Exchange Server 2010 Deployment

Lesson 1: Gathering Business Requirements 1-3

Lesson 2: Identifying Additional Requirements 1-12Lesson 3: Introduction to Service Level Management 1-24

Lesson 4: Analyzing the Current Messaging Environment 1-36

Lesson 5: Overview of Microsoft Office 365 1-52

Lab: Introduction to Designing an Exchange Server 2010 Deployment 1-59

Module 2: Designing Microsoft Exchange Server 2010 Integration with the Current

Infrastructure

Lesson 1: Designing the Network Infrastructure 2-3

Lesson 2: Designing the AD DS Infrastructure 2-16

Lesson 3: Designing the DNS Infrastructure 2-32

Lesson 4: Planning Exchange Server Administration 2-40

Lab: Designing Exchange Server Integration with the

Current Infrastructure 2-55

Module 3: Planning and Deploying Mailbox Services

Lesson 1: Overview of Mailbox Services in Exchange Server 2010 3-3

Lesson 2: Designing Mailbox Servers 3-8

Lesson 3: Designing Recipient Management 3-21

Lesson 4: Designing a Public Folder Architecture 3-37

Lab: Planning and Deploying Mailbox Services 3-51

Module 4: Planning and Deploying Client Access Services in Microsoft® Exchange Server 2010

Lesson 1: Overview of the Client Access Server Role 4-3

Lesson 2: Designing Client Access Server Deployment 4-14

Lesson 3: Designing Client Access 4-34

Lesson 4: Designing Client Access Policies 4-48

Lab: Planning and Deploying Client Access Services in

Exchange Server 2010 4-57

Module 5: Planning and Deploying Message Transport in

Microsoft Exchange Server 2010Lesson 1: Designing Message Routing for Exchange Server 2010 5-3

Lesson 2: Designing Hub Transport Servers 5-13

Lesson 3: Designing the Message Routing Perimeter 5-29

Lab: Planning and Deploying Message Transport in




Designing and Deploying Messaging Solutions with Microsoft® Exchange Server 2010 SP2 xiii

Module 6: Planning and Deploying Messaging Security

Lesson 1: Designing Message Security 6-3

Lesson 2: Designing Antivirus and Anti-Spam Solutions 6-16

Lab: Planning and Deploying Messaging Security 6-32

Module 7: Planning and Deploying Messaging Compliance

Lesson 1: Designing Transport Compliance 7-3

Lesson 2: Designing AD RMS Integration with Exchange Server 2010 7-12

Lesson 3: Designing Message Journaling and Archiving 7-20

Lesson 4: Designing Messaging Records Management 7-30

Lab: Planning and Deploying Messaging Compliance 7-37

Module 8: Planning and Deploying High Availability

Lesson 1: Introduction to High Availability Planning in


Lesson 2: Designing High Availability for Mailbox Databases 8-14

Lesson 3: Designing High Availability for Other Server Roles 8-25

Lesson 4: Designing Site Resilience 8-32

Lab: Planning and Deploying High Availability 8-45

Module 9: Planning a Disaster Recovery Solution

Lesson 1: Planning for Disaster Mitigation 9-3

Lesson 2: Planning Exchange Server Backup 9-17

Lesson 3: Planning Exchange Server Recovery 9-27

Lab: Planning a Disaster Recovery Solution 9-41

Module 10: Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

Lesson 1: Planning Exchange Server Monitoring 10-3

Lesson 2: Planning Exchange Server Troubleshooting 10-19

Lab: Planning Exchange Server 2010 Monitoring and Troubleshooting 10-27

Module 11: Upgrading to Microsoft® Exchange Server 2010

Lesson 1: Overview of Upgrading to Exchange Server 2010 11-3

Lesson 2: Planning the Upgrade from Exchange Server 2003 to


Lesson 3: Planning the Upgrade from Exchange Server 2007 toExchange Server 2010 11-28

Lab: Upgrading to Microsoft Exchange Server 2010 11-41



xiv Designing and Deploying Messaging Solutions with Microsoft® Exchange Server 2010 SP2

Module 12: Integrating Microsoft Exchange Server 2010 with Other Messaging Systems

Lesson 1: Designing Exchange Server 2010 Integration with Other

Messaging Systems 12-3

Lesson 2: Designing Exchange Server 2010 Integration with

Federated Partners 12-15


Office 365 12-22

Lesson 4: Designing Single Sign-On for Office 365 12-35

Lab: Integrating Exchange Server 2010 with Other Messaging Systems 12-40

Appendix A: Unified Messaging in Microsoft® Exchange Server 2010

Lesson 1: Planning the Unified Messaging Infrastructure A-3

Lesson 2: Planning the Unified Messaging Configuration A-17

Lesson 3: Planning the Unified Messaging Integration with Office

Communications Server A-29

Lab Answer Keys Appendix

Module 1 Lab: Introduction to Designing an Exchange Server 2010

Deployment L1-1

Module 2 Lab: Designing Exchange Server Integration with the

Current Infrastructure L2-11

Module 3 Lab: Planning and Deploying Mailbox Services L3-19

Module 4 Lab: Planning and Deploying Client Access Services in

Exchange Server 2010 L4-35

Module 5 Lab: Planning and Deploying Message Transport in

Exchange Server 2010 L5-45Module 6 Lab: Planning and Deploying Messaging Security L6-55

Module 7 Lab: Planning and Deploying Messaging Compliance L7-65

Module 8 Lab: Planning and Deploying High Availability L8-75

Module 9 Lab: Planning a Disaster Recovery Solution L9-93

Module 10 Lab: Planning Exchange Server 2010 Monitoring and

Troubleshooting L10-91

Module 11 Lab: Upgrading to Microsoft Exchange Server 2010 L11-99

Module 12 Lab: Integrating Exchange Server 2010 with Other

Messaging Systems L12-103



About This Course xv

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

course objectives.

Course Description

This course teaches you how to design and deploy an Exchange Server 2010 messaging system. You will

learn how to identify business and technical requirements for the design and then translate those needs

into specific Exchange Server 2010 configuration options. This course discusses how to design various

features of Mailbox, Hub Transport, and Client Access server roles. Some features that are discusses

include message transport, security, high availability, disaster recovery, upgrades, and coexistence with

other messaging systems.

Audience

This course is intended for the IT Pro audience who is responsible for the Exchange Server messaging

environment in an enterprise. He or she is the senior administrator, or “engineer” who acts as a technical

lead over a team of administrators. This person is a third level of support in addition to the Exchange

Recipient Administrator, which is the first level and the Exchange Server Administrator, which is thesecond level. In an effort to ensure that end users have the best possible messaging experience, this

person also evaluates new technologies and tools.

The candidate is responsible for the planning and deployment of the Exchange Servers in an enterprise

environment. He or she should have a minimum of two years of experience administering, deploying,

managing, monitoring, upgrading, migrating, and designing Exchange Server.

Student Prerequisites

This course requires that you meet the following prerequisites:

• At least two years of experience working with Microsoft® Exchange Server

•

At least six months of experience working with Exchange Server 2010 or Exchange Server 2007• At least two years of experience administering Windows Server®, including Windows Server 2008

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

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

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

• Experience working with Microsoft Windows PowerShell®

Course Objectives

After completing this course, students will be able to:

• Gather the information required to design a messaging system.

• Design the integration of Exchange Server with the current infrastructure.

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

• Design the Client Access server deployment.

• Design the Hub Transport server and Edge Transport server deployments.

• Plan and deploy messaging security.

• Plan and deploy a messaging policy and compliance solution.



xvi About This Course

• Plan a highly available Exchange Server 2010 deployment.

• Plan a disaster recovery solution in Exchange Server 2010.

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

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

Server 2010.

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

Course Outline

This section provides an outline of the course:

Module 1, “Introduction to Designing a Microsoft Exchange Server 2010 Deployment.” Before you can

begin designing your organization’s new messaging system, you must first understand why your

organization plans to deploy the messaging system and the state of the current messaging system. Most

organizations need an information technology (IT) infrastructure to ensure business tasks are performed

correctly. Before you deploy new IT technologies, administrators must understand and be able to present

clearly to decision makers the way in which these new technologies will address existing and new business

requirements. By understanding this, you will learn how to begin designing your organization’s newmessaging system.

Module 2, “Designing Exchange Server 2010 Integration with the Current Infrastructure” teaches you

what networking components must be in place, and how they must be configured to properly support

Exchange Server 2010.

Module 3, “Planning and Deploying Mailbox Services“ explains how the mailbox services design includes

the physical design of the Mailbox servers, including the storage system. You will also learn how it

includes the design of recipient management and public folder architecture.

Module 4, “Planning and Deploying Client Access Services in Microsoft® Exchange Server 2010.” The

messaging clients access the Exchange Server mailboxes through the Client Access server role. Because of

the importance of this server role, you must understand how it works, and how to design the Client Access

server deployment. This module describes how to design the Client Access server role deployment in

Exchange Server 2010

Module 5, “Planning and Deploying Message Transport in Microsoft Exchange Server 2010.” After you

have defined the business requirements of your organization and have a good understanding of the

current network environment, the next step is to design message routing—both within the organization,

and between the organization and other organizations connected to the Internet. This module describes

how to design message routing.

Module 6, “Planning and Deploying Messaging Security.” In this module you will learn about ensuring

that the messaging system is as secure as possible. This includes planning for message security, which

ensures that messages sent within the organization, and to and from the Internet, meet the organization’s

compliance and security requirements. A second consideration for planning the security is implementing

an antivirus and anti-spam solution that prevents malicious e-mails from entering the Exchange Server

organization.

Module 7, “Planning and Deploying Messaging Compliance” teaches you how Microsoft Exchange Server

2010 provides a wide range of messaging compliance features that you can use for more than just simple

messaging and calendaring. You will also learn how you can use messaging compliance features to

control message transport, apply Rights Management Services (RMS), implement journaling and archiving,

and manage messages.



About This Course xvii

Module 8, “Planning and Deploying High Availability” describes how high availability ensures that

messaging systems built on Exchange Server 2010 can survive the failure of a single server, or even

multiple servers.

Module 9, “Planning a Disaster Recovery Solution” explains how to ensure that you meet SLA

requirements by planning how Microsoft Exchange Server 2010 will be backed up and restored.

Module 10, “Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting” describes how

to perform routine monitoring, and where necessary, make adjustments to your Microsoft Exchange

Server 2010 servers. By understanding how to implement a monitoring program and knowing what and

how to monitor, you can optimize your Exchange servers.

You will also learn how to troubleshoot problems with Exchange Server 2010. Planning an effective

troubleshooting methodology and familiarization with the troubleshooting tools helps you to quickly and

efficiently resolve even complex problems.

Module 11, “Upgrading to Microsoft Exchange Server 2010” provides an overview of the options that

organizations have when choosing to implement Exchange Server 2010, and provides details on how to

upgrade an existing Microsoft Exchange Server 2003 or Exchange Server 2007 organization to Exchange

Server 2010.

Module 12, “Integrating Microsoft Exchange Server 2010 with Other Messaging Systems.” Integration

with other messaging systems is useful when you are migrating from a legacy messaging system to

Exchange Server 2010. Integration with federated partners that are also using Exchange Server 2010

allows you share information with partner organizations. Integration with Exchange Online allows you to

expand the messaging system in your organization without adding additional servers. In this module you

will learn about how to integrate Exchange Server 2010 with other messaging systems.

Appendix A, “Unified Messaging in Microsoft Exchange Server 2010” describes how to plan the Unified

Messaging 2010 infrastructure, configuration, and integration with Office Communications Server 2007.



xviii About This Course

Course MaterialsThe following materials are included with your kit:

• Course Handbook A succinct classroom learning guide that provides all the critical technical

information in a crisp, tightly-focused format, which is just right for an effective in-class learning

experience.

• Lessons: Guide you through the learning objectives and provide the key points that are critical to

the success of the in-class learning experience.

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

in the module.

• Module Reviews and Takeaways: Provide improved on-the-job reference material to boost

knowledge and skills retention.

• Lab Answer Keys: Provide step-by-step lab solution guidance at your finger tips when 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 theAllfiles.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].

http://www.microsoft.com/learning/companionmoc/









About This Course xix

Virtual Machine EnvironmentThis section provides the information for setting up the classroom environment to support the business

scenario of the course.

Virtual Machine Configuration

In this course, you will use Hyper-V deployed on Windows Server 2008 to perform the labs.

Important: At the end of each lab, you must revert the virtual machine back to the state the virtual

machine was in before the lab started. To revert a virtual machine, perform the following steps: 1. InHyper-V Manager, right click the virtual machine name and click Revert. 2. In the Revert dialog box,

click Yes.

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

Virtual machine Role

10233B-VAN-DC1 Domain controller in the Adatum.com domain

10233B-VAN-EX1 Exchange 2010 server in the Adatum.com domain



10233B-VAN-EDG Exchange 2010 Edge Transport server

10233B-VAN-CL1 Client computer in the Adatum.com domain

10233B-NYC-DC1 Domain controller in the Contoso.com domain

10233B-NYC-SVR2 Member server in the Contoso.com domain

Software Configuration

The following software is installed on each VM:

• Windows Server 2008 R2 Enterprise

• Windows 7

• Exchange Server 2010

• Microsoft Office 2007, Service Pack 2

Classroom Setup

Each classroom computer will have the same virtual machine configured in the same way. All of the

aforementioned virtual machines are deployed in each student computer.



xx About This Course

Course Hardware Level

To ensure a satisfactory student experience, Microsoft Learning requires a minimum equipment

configuration for trainer and student computers in all Microsoft Certified Partner for Learning Solutions

(CPLS) classrooms in which Official Microsoft Learning Product courseware are taught.

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

• Dual 120 GB hard disks 7200 RM SATA or better*

• 8 GB RAM

• DVD drive

• Network adapter

• Super VGA (SVGA) 17-inch monitor

• Microsoft Mouse or compatible pointing device

• Sound card with amplified speakers

*Striped

In addition, the instructor computer must be connected to a projection display device that supports SVGA

1024 x 768 pixels, 16-bit colors.



1-1

Module 1

Introduction to Designing a Microsoft®Exchange Server 2010 Deployment

Contents

Lesson 1: Gathering Business Requirements 1-3

Lesson 2: Identifying Additional Requirements 1-12

Lesson 3: Introduction to Service Level Management 1-24Lesson 4: Analyzing the Current Messaging Environment 1-36

Lesson 5: Overview of Microsoft Office 365 1-52

Lab: Introduction to Designing an Exchange Server 2010 Deployment 1-59



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

Module Overview

Before you can begin designing your organization’s new messaging system, you must first understand

why your organization plans to deploy the messaging system, and understand the state of the current

messaging system. Most organizations need an information technology (IT) infrastructure to ensure

business tasks are performed correctly. Before you deploy new IT technologies, administrators must

understand and be able to present clearly to decision makers the way in which these new technologies

will address existing and new business requirements.

After completing this module, you will be able to:

• Describe the business requirements gathering process.

• Identify additional requirements.

• Describe service level management.

• Analyze the current messaging environment.

• Describe Office 365 and Exchange Online.



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

Lesson 1

Gathering Business Requirements

In this lesson, you will gather business requirements for a Microsoft Exchange Server 2010 deployment.

Identifying business requirements helps determine the benefits of, and rationale for, the deployment

project.

After completing this lesson, you will be able to:

• Describe the importance of business requirements.

• Define the functional business requirements for a project.

• Define service level agreements (SLAs).

• Identify types of regulatory and organizational compliance requirements.

• Identify project constraints.




What Are Business Requirements?

Organizations invest in technology to solve business problems, or to provide new opportunities. Business

requirements typically dictate reasons for an organization’s proposed new technology implementation.

Business Requirements

To operate more effectively, an organization must address its many needs, or business requirements.

Business requirements can take many different forms. For example, an organization may need to:

• Become more efficient. Most businesses are very competitive, and strive to be more efficient than

their competitors. When evaluating new technologies, these organizations typically will invest in thetechnology if it will improve efficiency.

• Meet an external requirement. Forces outside an organization — such as government or business

partners — may impose requirements. For example, government regulations may require archival of

certain email for a specified time, or business partners may enforce specific security requirements for

email communication between locations.

• Avoid disruptions to business processes. A current technology may meet most business requirements.

However, if the current technology is unreliable, an organization may invest in a new technology that

provides the requisite reliability and availability.

• Explore new business areas or solutions. Organizations sometimes use technologies to pursue new

business opportunities. For example, deploying web-based tools for selling products and services hassignificantly increased the business potential for many organizations.

Importance of Business Requirements

A technology deployment is more likely to address an organization’s needs if business requirements are

defined clearly and concisely at the project’s inception. Additionally, it is easier to measure a project’s

success if the project team is knowledgeable about the business problems that the project must solve.




What Are Functional Requirements?

Functional requirements define a technology’s expected behavior by describing a system’s specific

behaviors. You derive functional requirements from business requirements. Business requirements define

the problem to address, while functional requirements define how the proposed technology should solve

that problem.

Note For example, an organization may define a business requirement that all email to

and from a partner organization must be secure. The resulting functional requirement is

that the servers running Exchange Server 2010 and handling email sent between the twoorganizations must be configured to require encryption for all messages.

Note A use case typically accompanies each functional requirement. A use case describes

an activity performed within the organization, and the activity’s intended outcome. For

example, a use case might specify steps that a user inside the organization must follow

when sending an email message to someone at the partner organization, given the business

requirement that any message sent across a network connection must be secure. In this

example, the use case defines the functional requirement (encryption of all email) and

subsequently tests whether the deployment (the specific steps the user must follow)

addresses the functional requirement.

Functional Specification

Functional requirements help create the functional specification — which serves as a contract between the

customer and the design team — describes the proposed solution in exacting detail, and forms the basis

for project plans and schedules. The customer is the technology consumer, and is usually the business

sponsor and user.




The functional specification is important because it:

• Establishes an agreement between the team and the customer. This enables the team to determine

the correct solution to meet the customer’s expectations.

• Provides in-depth project details to help the team determine if it is building the correct solution. This,

in turn, makes the solution easier to validate and verify.

• Enables the team to estimate budgets and schedules. The quantity of resources and their respective

skill sets are difficult to determine without the specific detail that a functional specification provides.

Note In addition to functional specifications, every design has nonfunctional

specifications. Nonfunctional specifications do not define what the system does, but rather

how the system will perform and/or the quality of service it will provide. Common

nonfunctional specifications include system availability, maintainability, performance,

reliability, and scalability.




Defining Service Level Agreements

Service level agreements (SLAs) are understandings reached between an organization and its IT

department that define expected infrastructure performance levels. It is important to define an SLA,

because it documents the service expectations and requirements that an organization expects the IT

department to deliver. SLAs may define several categories of expected performance, including:

• Availability. For example, an SLA may require that all users can access their mailboxes on the

Exchange servers 99.99 percent of the time during business hours, and 99.9 percent of the time

during nonbusiness hours.

• Performance. For example, an SLA may specify that all messages sent between company locations are

received within 60 seconds, 99 percent of the time.

• Recovery. For example, an SLA may stipulate that if a mailbox server fails, all mailboxes on that server

will be restored within eight hours.

Types of SLAs

The SLAs that organizations use can vary from informal to very structured:

• Informal SLAs often are not documented, but rather are general expectations for system performance

that are well known. For example, an organization may have an internal, unwritten policy that certain

servers are never restarted during business hours.

•

Formal SLAs typically are documented extensively, and detail expectations determined fromnegotiations between service providers and business customers. These SLAs may define exact

expectations for each system component, and may include penalties if expectations are not met.

Often, the most formal SLAs are negotiated between business customers and outsourced IT providers.

Best Practice: If an organization does not have any written SLAs, it is very important when beginning any

deployment project to identify and document informal SLAs. Clearly identifying the expected system

performance enables future validation of the project’s success.




Negotiating SLAs

SLAs have a significant impact on a project’s scope and budget, so it is important to define them at the

project’s inception.

Business requirements, plus functional and nonfunctional requirements, typically are the basis for initial

SLA negotiations. In most cases, the project team and business sponsors negotiate the final SLA details.

Initial requirements may set very high expectations. However, meeting those high expectations can bequite expensive. For example, say an SLA requires that messages are delivered between company

locations within 60 seconds, 100 percent of the time. The only way to meet this expectation may be to

deploy fully redundant systems throughout the organization. The cost of this would likely be prohibitive.

Thus, the organization may negotiate a more acceptable performance level at a more reasonable cost.




Discussion: Identifying Regulatory and Organizational ComplianceRequirements

Email is often used to communicate significant amounts of business information, including confidential

materials such as customer data or business intelligence. In many countries, governments have imposed

compliance requirements that mandate how organizations ensure data confidentiality.

Discussion Questions

Based on your experience, consider the following questions:

Question: In what type of business does your organization participate? What are thelegislated compliance requirements for your organization?

Question: What additional compliance requirements does your organization have?

Question: What issues do regulatory and organizational compliance requirements raise for

your organization? How are you addressing these issues? What are the gaps between the

requirements and the solutions?

Question: Are the compliance solutions based on policy or technology? In other words, doesyour organization only have written policies that define what users can do, or is there a

technological solution in place to enforce some or all of the requirements? If you are using a

policy-based solution, how do you enforce policies?




Identifying Project Constraints

Project constraints define the project’s parameters. Project constraints often set limits on what you can

accomplish. For example, if the project has a fixed budget, the budget becomes a constraint that defines

parameters for what you can accomplish.

Types of Project Constraints

There are three categories of project constraints: resource, schedule, and feature constraints.

• Resource constraints. A project’s budget is a common resource constraint. If the proposed budget

cannot meet the projected personnel costs, equipment costs, and software costs, the project cannotcontinue. Additionally, a project may have additional resource constraints:

• The appropriate personnel may not be available, or their training may not be sufficient to

complete the project.

• Computer resources or equipment may not be accessible.

• Schedule constraints. A project schedule also may restrict what the project can accomplish. For

example, many organizations do not allow changes to the IT environment during specific times,

such as during the end of the corporate fiscal year, or peak business cycles. If a project is due for

completion during one of these periods, the project scope may require modification. In large

organizations, a project may be constrained by the schedule of other projects.

•

Feature constraints. Organizations may restrict features that are included in a project. For example,a requirement may exist to provide users with mobile device access to Exchange Server mailboxes.

However, if the proposed solution cannot address this requirement, the project might be canceled.

Additionally, requiring email encryption might necessitate issuing a smart card to all mobile users.

However, the organization might not have the organizational maturity, necessary infrastructure, or

budget to do so.




Negotiating Project Constraints

The project team must identify constraints early in the project, as these constraints can significantly

impact the solution design.

The project team and business sponsors often negotiate project constraints, business requirements, and

SLAs. The budget may seem like a firm constraint, but if increasing the budget results in meeting an

important business requirement or SLA level, you may decide to adjust the budget or remove a featurefrom the solution design.




Lesson 2

Identifying Additional Requirements

Business requirements are not the only factors to consider when designing a messaging system.

Additional needs can add to the project design, or constrain a project’s design by limiting or strictly

defining which business requirements the project can address.


• Identify additional stakeholders for a project.

• Define technology requirements.

• Identify IT requirements.

• Identify security requirements.

• Identify user requirements.

• Resolve conflicting requirements.






Identifying Stakeholders

Use the following process to determine which stakeholders should be consulted regarding a messaging

system deployment:

1. Identify a small group of the most critical and obvious stakeholders, and the personnel who have the

highest level of IT infrastructure understanding.

2. Present this group with a high-level description document of the project scope and business

requirements. The description document does not need to be detailed, but should include the parts

of the organization that the project may impact.

3.

Allow this group to identify all other organizational parties or groups that the new technology’s

deployment will affect.

4.

Gather additional information, if necessary, to verify the description document’s accuracy. For each

group that is listed, briefly describe its contribution to the project.

5.

Select one or more group members to act as stakeholders and the group’s representatives.




Defining Technology Requirements

IT personnel are one of the most important stakeholder groups in an Exchange Server 2010 deployment.

Typically, they have a thorough understanding of the current technology environment. This means that

they understand the current environment’s limitations, and can detail the project’s necessary

technological requirements.

What Are the Technology Requirements?

Every organization has technology requirements that affect an Exchange Server 2010 deployment. One of

the most important considerations in a deployment project is the current technology infrastructure. Inalmost all cases, the Exchange Server 2010 deployment must integrate with the existing environment.

Components to consider in the existing infrastructure include:

1. Server room equipment. This includes infrastructure such as air conditioning, uninterruptible power

supply (UPS), redundant power sources, and fire-suppression equipment. Server room equipment also

may include physical security to ensure that only authorized personnel enter the room. In most cases,

modifications to server room equipment are not included in the Exchange Server 2010 deployment

project or budget. Therefore, available equipment may impact deployment.

2.

Storage technologies. Most large organizations have implemented SANs for applications such as

Exchange Server, which stores a large amount of data. If an organization has a significant monetary

investment in this solution, the Exchange Server 2010 deployment likely will have to use the SAN

solution, regardless of whether an alternative solution provides more benefits. On the other hand, ifthe SAN is operating at maximum capacity, the Exchange Server 2010 project must implement

alternative storage solutions. Exchange Server 2010 provides options such as continuous cluster

replication (CCR) for providing data redundancy, and supports new technologies such as Internet

small computer system interface (iSCSI).




3. Backup and recovery solutions. The Exchange servers must be included in the regular backup process.

If an organization has an existing corporate backup solution, the Exchange servers must use that

solution. This may constrain the project’s design for backing up Exchange servers. For example, the

backup solution may have limited capacity, which may require a small backup window for the

Exchange Server environment. You also will need to consider the changes made to Exchange

Server 2010 to support Volume Shadow Copy Service (VSS) backups and features (such as CCR)

when planning the Exchange Server integration into the current backup solution.

4.

Network infrastructure. The Exchange Server 2010 deployment must integrate with the current

network infrastructure. The local area network (LAN) or wide area network (WAN) environments may

constrain the available messaging bandwidth, which in turn may impact whether SLA-mandated

message delivery times can be met. As part of the project design, you must consider whether to

include network upgrades, or renegotiate the SLA.

5. Active Directory infrastructure. Exchange Server 2010 is integrated tightly with AD DS, but it can

operate in almost any Windows Server® 2008 Active Directory environment. However, the Active

Directory configuration—such as the site configuration—and the locations of the domain controller

and global catalog server can impact Exchange Server 2010 performance significantly. If the Active

Directory environment is not designed for optimal performance, redesigning the Active Directory

configuration or modifying an optimal Exchange Server design may be necessary.

6. Data center configuration and location. Some organizations place all their servers in a single location,

or data center, while other organizations may choose to distribute servers across multiple data

centers. This may be for a variety of reasons, including: to provide primary data center redundancy to

take advantage of potential cost-savings of operating the data center in a low-cost region, or because

the original data center is no longer large enough to house the required servers. To some extent,

branch offices that include one or more servers can also be considered data centers. If your

organization has multiple data centers or larger branch offices, this will impact your Exchange Server

deployment plan.

7. User distribution. In small organizations, the design of your Exchange Server infrastructure does not

need to consider user distribution; they are all probably located in a single office. However, if you areplanning to implement Exchange Server in an organization that supports thousands of users, the

chances are that they will be distributed across multiple locations. In addition, even in small

organizations, users need to access their email and related services from home, or from a remote

network. It is important that when you plan your Exchange Server implementation, you consider

carefully how your users are distributed, and from where they typically access email. These

considerations have an impact on the location and number of Exchange Server roles that you must

deploy.




Identifying IT Requirements

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

deployment project may need to be compatible with current IT policies and processes. Business

requirements typically drive adoption of new technologies. However, the IT department — which can

include messaging administrators, messaging engineers, and help desk personnel — is responsible for

actual technology deployment and operation, and therefore, is an important project stakeholder.

Identifying IT Department Requirements

A project’s business requirements may differ from IT department needs. When discussing the project withIT representatives, ask the following questions:

1.

What are the IT concerns about the project? Introduction of any new technology likely will raise IT

concerns, which may include potential disruptions to other IT systems, the training needs for IT

personnel who have to manage a new technology, or the impact to current IT processes of a new

solution.

2. What are the current IT pain points that the project may address? IT departments often have long-

standing concerns or issues with organizational processes. Sometimes these issues result from a

limitation in the current technology. By exploring messaging-related issues with the IT department,

you may be able to incorporate a solution into the Exchange Server 2010 design.

3. What are the IT requirements for accepting a new technology? Many organizations have very detailed

transition-to-production requirements that must be addressed before the IT department can accept a

new technology. These requirements may include detailed documentation on deploying and

managing new technologies, and training for those who have to manage new technologies.




Identify IT Policies and Processes

The Exchange Server 2010 deployment project must follow IT processes and policies during and after

deployment. For example, if an organizational policy mandates that you use a specific vendor for

purchasing all network and server components, the Exchange Server 2010 deployment project must

follow that policy. This may impact the project design if the vendor does not have a specific component

available, or it may impact the project schedule if delays occur in obtaining products from the vendor.

Interview IT managers and procurement personnel to identify and procure documentation for relevant

policies and processes that the project should follow.




Identifying Security Requirements

Another essential stakeholder group consists of those who create and enforce an organization’s security

policies. Messaging is an integral part of most organizations’ business processes, so it is imperative to

identify any security issues early, and include their solutions in the project’s design.

Identifying Security Requirements

Virtually all IT projects have security requirements. Any project that includes a messaging component is

likely to have security requirements, because of the importance of messaging and its inherent security

risks. The security officer is the most important stakeholder you can interview to identify securityrequirements. However, you also should interview network and server administrators, and business

managers to identify additional security requirements.

To identify security requirements, ask the following questions:

• What are the organization’s security risks? There are many possible answers to this question,

including:

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

system.

• Authentication traffic and message-access traffic are at risk for capture when users access their

mailboxes with Microsoft Office Outlook® Web App for Exchange Server 2010. A security risk

also occurs if users save confidential attachments on unsecured client computers.• Mobile client computers are difficult to secure and frequently are lost or stolen.

• Internet-facing Simple Mail Transfer Protocol (SMTP) servers must accept anonymous and

unauthenticated connections, and must be able to send email using the same connection types;

this does not provide security for messages, and may expose potentially private or confidential

information. Additionally, the server is exposed to Internet attacks.




• Messages on mailbox servers may contain private or confidential information that is at risk if

unauthorized users access the data, or if the server is compromised.

• How are the security requirements currently addressed? Almost all organizations have addressed at

least some security requirements. For example, virtually all organizations have implemented antivirus

and anti-spam solutions. Most organizations use Secure Sockets Layer (SSL) to secure Outlook Web

App traffic.

• What gaps exist between security requirements and current solutions? One of the most difficult

security gaps to address is with SMTP email. Virtually all SMTP email is sent in clear text, or is

Multipurpose Internet Mail Extensions (MIME) encoded. Organizations can implement features such

as Secure MIME (S/MIME) or Transport Layer Security (TLS), but the functionality is limited and may

be difficult to implement or manage.

• What general security requirements or guidelines must the messaging project follow? Most

organizations have general security requirements that apply to all projects and may require that:

• All user authentication traffic is encrypted on internal and external networks.

• Private customer information must never be exposed to the Internet.

•

All servers are located in a locked facility that l imits access to authorized personnel.

Negotiating Security Requirements

Security requirements can sometimes conflict with business requirements. For example, a business

requirement may state that customers can request and receive information about their account via email.

However, the security requirement may state that confidential customer information is never sent

unencrypted on the Internet.

Security requirements often place restrictions on what a project can accomplish. A technical solution may

meet or exceed business requirements, but if the person who is responsible for defining security

requirements does not consider it secure, it may need revision, or you may need to remove the business

requirement.




Identifying User Requirements

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

users.

Identifying User Requirements

User requirements may differ from business sponsor requirements. For example, the business sponsor

is most likely to be interested in the functionality that the system provides, while users typically are

interested in the system’s ease of use, or how it enables them to perform tasks more efficiently.

Identify user requirements by interviewing users and help-desk or support personnel who work mostclosely with users. During this interview, ask the following types of questions:

• How do users currently utilize email?

• Is there email functionality that users would like to have, that the current system does not make

available?

• What types of messaging clients does the organization use?

• What other messaging clients would the users like to have?

• What problems do users experience with the current messaging system? Why are users experiencing

the issues? Is the problem due to technology limitations, or a lack of user knowledge or training? Is

the problem due to a policy limitation, such as mailbox size restrictions?• What user training will be required when you implement the new system?

• What security requirements exist for client access to user mailboxes?

• How much do users utilize the messaging system? Can you characterize the activity level of users as

light, medium, or heavy? How many users fall into each category?

• Are there groups of users with special security needs, performance requirements, or functionality

concerns?




Note User requirements are very important to a messaging system’s ultimate success or

failure. If the first user experience with a new system is negative (possibly because the

system is difficult to use or does not meet expectations) it is very difficult to achieve broad

user acceptance of the system. As much as possible, ensure that your solution addresses

user requirements, and that users receive the required training for the new system.






Lesson 3

Introduction to Service Level Management

Service level management is the process of defining and monitoring service levels. This is an essential tool

to ensure that an organization’s IT provider meets business needs. Availability is one of the most

commonly monitored services within an organization. An SLA defines the requirements for service

availability and other service characteristics. You should base all of the objectives that an SLA lists and that

service level management monitors, on business requirements. As you devise SLAs, you should consider

disaster recovery.


• Describe SLAs.

• Describe service level management.

• Describe high availability.

• Define business requirements and service level management.

• Define disaster recovery requirements.

• Create SLAs.




What Are Service Level Agreements?

An SLA is an agreement—which typically is signed—between an IT group and an organization. It is

important to define an SLA early, because it documents the service expectations and requirements that an

organization expects the IT service provider to deliver. An SLA might be written for the availability of a

specific system component, a specific service, or an entire system.

A successful SLA might result from hours of negotiation, but the final agreement might be a single-page

document that you discuss at a SLA Review. An SLA is successful if it delivers what is requested, offers a

simple representation of the service’s complexity and component architecture, documents measures on

performance, and is in a suitable format. If the SLA meets its objectives, it does not need to be a complexdocument.

SLA and System Design

It is important to define SLAs before designing and implementing an information system. You should

design the system to meet SLAs. A more highly-available system typically has a higher cost than a less

available system, and you can factor in the cost when negotiating SLA agreements.

When negotiating an SLA, initial demands typically are high. However, when faced with the actual costs

associated with extreme high availability, the organization typically reduces its demands to more

reasonable levels.

Internal SLAs

An internal SLA is between the IT department and other departments in the same organization.

An internal SLA between two departments within one organization rarely has legal consequences, but

does describe the relationship, expectations, and timescale for service deliveries. Thus, it is binding

because it represents an agreement between two parties who should make every attempt to meet the

documented service levels.






What Is Service Level Management?

Service level management is the process of defining and managing — via monitoring, reporting, and

reviewing — an organization’s required and expected service levels. It aligns business needs with delivery of

IT services. The goal of service level management is to successfully deliver, maintain, and improve IT

services in a cost-effective manner.

Service Level Management Tasks

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

Task Description

Create a servicecatalog

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

Negotiate SLAs An SLA is a mutually agreed-upon and negotiated agreement between the ITprovider and the business. An SLA and availability requirements are important partsof service level management, but must not be viewed as an endpoint whenproviding IT services.

Monitor the

service levels

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

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




(continued )

Task Description

Report theservice level

Using the service catalog and the SLA, reports should be designed and scheduled. Ifrequired, real-time SLA criteria monitoring should be conducted. The thresholds,alerts, notifications, and actions for real-time criteria monitoring should be

considered, and service performance measured against them. You can complete aservice-level review at required intervals with the customer departmentrepresentative, using reports produced from historical data and the monitoringfunction.

Review theservice levelagreement

The SLA review provides an opportunity to review performance against SLAobjectives, and more importantly, to gather perceptions and opinions from businessrepresentatives on any service changes. If any service levels are perceived to bebreached, but are not highlighted by the service review or reports, there might beissues with the SLA criteria and objectives. Issues might include providing additionalresources to support new services or service levels, if these resources were notinitially considered. You should work with the business representatives to identifyany issues from the previous period, and any current issues that you need to addressbefore the next review.

Monitoring, Reporting, and Reviewing

It is critical that you perform the monitoring, reporting, and reviewing tasks in the service level

management process. Without these tasks, the value of an SLA is reduced significantly. For example, if you

do not perform monitoring, you can never be sure that you are adhering to the SLA. The level of service

provided may be below negotiated levels, and no corrective actions are taken. If the SLA is not updated to

reflect business changes, then the existing SLA may no longer be relevant, and additionally, the SLA may

not evaluate new business processes and systems appropriately.




What Is Availability?

Availability refers to a level of service that applications, services, or systems provide, and is expressed

as the percentage of time that a service or system is available. Highly available systems have minimal

downtime, whether planned or unplanned, and are available more than 99 percent of the time,

depending on the needs and the budget of the organization. For example, a system that is unavailable

for 8.75 hours per year would have a 99.9 percent availability rating.

To improve availability, you must implement fault-tolerance mechanisms that mask or minimize how

service component failures and dependencies impact the system. You can achieve fault tolerance by

implementing redundancy to single points of failure.

Defining Availability Requirements

Service availability is a complex issue that spans many disciplines. You can take many different approaches

to deliver the required availability levels, and each approach has its own cost implications.

Availability requirements must be expressed so that there are no misunderstandings about the

implications. Miscommunication concerning service level expectations between the customer and the IT

organization can result in inappropriate business decisions, such as unsuitable investment levels and

customer dissatisfaction.

Different Availability Requirements

One requirement for 99.5 percent availability can be different from another requirement for 99.5 percentavailability. One requirement may state the availability of the hardware platform alone, while another may

state the availability of complete end-to-end service. Even the definition for complete end-to-end service

availability can vary. It is important to understand how each availability requirement is to be measured.

For example:

• If all hardware and software on the primary server are functioning correctly and the application is

ready to accept all user connections, then does the solution provide 100 percent availability?




• If there are 100 users, but 25 cannot connect because of a local network failure, then does the

solution still provide 100 percent availability? In this situation, the solution meets the 100 percent

availability expectations of 75 percent of the users, but for the rest of the users, it does not. How do

we consider this as part of the availability since all of the users are not affected?

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

•

If all 100 users can connect, but the service is degraded with only two out of three customer

transactions being available, or performance is poor, how does this affect availability measurements?

The availability measurement period also can have a significant effect on the definition of availability. For

example, a requirement for 99.9 percent availability over a one-year period allows 8.75 hours of

downtime, whereas a requirement for 99.9 percent availability over a rolling four-week window allows

only 40 minutes of downtime per period.

Outages

It also is necessary to identify and negotiate downtime periods for planned maintenance activities,

service pack updates, and software updates. These are scheduled outages, and typically not included as

downtime when calculating the system’s availability. You typically calculate availability based on

unplanned outages, such as a system crash. However, you have to negotiate exactly which outages youconsider to be downtime.

For example: Service Availability of 99.9%:

Contoso, Ltd has 100 databases. Over a four week period, 100 databases are down for 1 hour each.

That’s a total downtime of 60*100=6,000 database minutes of downtime. Given that four weeks

consist of 40,320 minutes, the total number of database minutes in Contoso during the period was

100*40,320=4,032,000 database minutes. If we divide 6,000 by 4,032,000 we get .0015 downtime, which

is a database availability of 99.85 percent.




Business Requirements and Service Level Management

Business requirements help IT providers understand business processes. IT systems exist to support

business processes. However, many times the IT provider is isolated from the business processes that need

support. If the IT provider understands the processes that various business units use, then the provider is

better able to anticipate and meet the organization’s business requirements. Service level management

provides the interface between the organization and the IT provider, so that the IT provider can deliver

solutions in line with the business requirements at an acceptable cost.

You should interview stakeholders and other key positions within the organization to determine business

requirements, which should include: requirements for usage, business processes, mission-criticalapplications, and plans for growth.

Priority Definition

You can effectively support business requirements by negotiating each service’s priority. This identifies

where to target resources.

Some measures that can help you define the service’s priorities are:

• The number of impacted users, and the impact’s severity.

• The number of impacted external customers of the organization, and the impact’s severity.

• The number of other services affected, and the impact’s severity.

For example, consider the loss of an internal messaging system. This would be considered a major

problem for many users. Furthermore, if the organization’s business processes use the messaging system

to communicate extensively with external customers, it likely is an even higher priority than if only internal

users are affected.




Budget Negotiation

It is important to set the correct expectations for all stakeholders when discussing service level

management. Stakeholders might have unrealistic expectations for availability, and must be prepared to

provide the budget to ensure desired availability levels.

In many cases, the first draft of availability requirements that you present includes almost no downtime.

The costs to provide high availability can be significant. And the costs tend to increase for systems withvery high availability. For example, it is relatively inexpensive to update a system from 99.9 percent

availability to 99.99 percent availability. It is much more expensive to update a system from 99.99 percent

availability to 99.999 percent availability.

You must include the cost of availability requirements as part of negotiating an SLA. In many cases, a

lower level of availability is acceptable when the actual cost of availability is known.

However, you may be able to negotiate increased budget levels if a potential service outage is more costly

than the budget change required for increased availability.




Disaster Recovery and Service Level Management

In addition to accepted availability levels, an SLA must include acceptable recovery times after a disaster

occurs. A disaster can be the loss of any IT system, and can range from hardware and software failures, to

data corruption, to the loss of an entire data center.

To plan for recovery from a disaster, prepare a disaster recovery plan. This plan contains detailed steps

that will help you recover from a disaster. In most cases, there are multiple methods to recover from

disaster. The acceptable recovery time that is defined in the SLA for each system involved determines the

methods you include in the disaster recovery plan. The SLA describes how to recover all necessary data

and services, and the maximum acceptable time that recovery should take.

Designing for Disaster Recovery

You should negotiate an SLA when developing any new IT system. You also need to determine the

disaster recovery plans during the initial development of any new IT system. The options for disaster

recovery are a direct result of an overall system design. Failure to address disaster recovery concerns

during the design process can result in future expensive and disruptive changes.

Disaster recovery planning can include:

• Implementing redundant hardware in servers.

• Storing backup data offsite.

•

Maintaining local copies of recent backups.

• Maintaining spare hardware in the event of a disaster.

• Synchronizing data between two servers.

• Synchronizing data between two data centers.




Creating Service Level Agreements

When developing an SLA, it is important to start by examining the documented services that the service

catalog makes available, as well as any existing performance metrics you gather when establishing the

baseline setup. When you complete baseline setting, the discussion can focus on whether the services are

adequate, or if they need improvement. You also can clarify the business’s service level priorities.

An SLA must include:

• Availability definitions, such as:

•

Responsiveness requirements

• Allowed downtime — planned and unplanned

• Allowed recovery time

• Data-loss tolerance

• Security requirements

• A process for problem resolution escalation

• Actions to take if the SLA is not met




Requirements for SLA Objectives

The following table lists the SLA objectives you must include:

Objective Reason

Support businessobjectives

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

Be specific andmeasurable

If an SLA objective is not specific and measurable, it is impossible to impartially judge whether it is met. This leads to confusion and misunderstandingbetween the IT provider and the business areas it serves.

Be attainable If an SLA objective is not attainable, then it should be abandoned. Considereverything when deciding whether an objective is attainable. In some cases,attaining the objective might be as simple as adjusting the time allocated formaintenance. In other cases, an increased budget may be required.

Bring value to theorganization

Consider the impact of attaining the SLA objectives. Organizational resourcesare scarce, and the allocation of those resources must be made based on theservice level priority in question. It does not make sense to waste staff time andbudget on low-value objectives that are expensive to attain.




Lesson 4

Analyzing the Current Messaging Environment

Once you have gathered the messaging infrastructure requirements, the next step is to analyze the

current network and messaging environment. Analyzing the current environment helps determine the

gaps between the current messaging infrastructure, and the requirements and goals of the intended

messaging infrastructure. This information provides a starting point for determining the appropriate

design and implementation plan for the Exchange Server 2010 deployment.


• Analyze the physical network infrastructure.

• Analyze the name resolution services infrastructure.

• Analyzing the Active Directory infrastructure.

• Analyze an existing messaging infrastructure.

• Identify the usage statistics for a messaging system.

• Identify additional infrastructure requirements.

• Analyze administrative models and processes.

•

Analyze a change control process.




Analyzing the Physical Network Infrastructure

To determine how your existing network will support an Exchange Server 2010 messaging environment,

build a complete picture of your network infrastructure — including site locations, connection types, and

router and switch configuration details.

Important As you collect information about the current network infrastructure or any

other component in the current environment, you also should ensure that you collect

information about any planned environment changes. These changes may interfere with the

Exchange Server 2010 deployment, or may result in changes to your design.

Elements of the Physical Network Infrastructure

Consider the following elements of the physical network infrastructure:

• The number, geographic locations, and link speed of all sites where network services exist. It is

important to identify all locations that make up the network infrastructure, such as buildings,

campuses, and branch offices. You also must determine the connection types and network speed for

each location.

• A routing topology map that illustrates the physical sites and the IP subnets in use at those sites. This

map is useful in planning or integrating with the Active Directory site design, which in turn has a

profound impact on Active Directory replication and message routing.

• Bandwidth, latency, and current usage. Bandwidth is the transmission speed over a network

connection in kilobits per second (Kbps). Latency refers to the time it takes (in milliseconds) to

transfer data between two points. Both of these factors combine to determine how much data can be

transmitted in a set time period over the network. You can use this information, the current

applications using the network, and the number of users at various sites and their use patterns, to

create a design for your Exchange Server organization that provides a satisfactory user experience.

When mapping site locations and connections, determine the type and speed of network




connectivity, and factor in the latency introduced by the distances between sites. The project may

need to include network upgrades to provide Exchange servers with adequate bandwidth for the

messaging service.

• Use of virtual local area networks (VLANs). Determine the current use of any VLAN configurations

within your networking infrastructure. If required, ensure that you configure these VLANs, or have the

ability to configure them, to pass the traffic that the existing and intended messaging system isexpected to generate.

• Firewall configuration requirements. Depending on your deployment plan, you should determine any

firewall configuration requirements for the implementation and synchronization of an Edge Transport

server, which you should place within a secured perimeter network.

• Nontechnical constraints. These include geographical, political, or cost-related restrictions resulting

from a change or upgrade of network links between sites.




Analyzing the Name Resolution Services Infrastructure

Name resolution services translate network addresses to computer names, and vice versa. The DNS

provides the required name resolution services for AD DS, and for internal and external name resolution.

Exchange Server 2010 depends upon DNS for locating Active Directory domain controllers, global catalog

servers, other Exchange servers, and remote domains. All SMTP servers also use DNS mail exchanger (MX)

resource records for routing outbound mail.

Name Resolution Services Infrastructure

There are many factors to consider regarding the name resolution services infrastructure:• What type of DNS software do you currently use? Is it able to handle service (SRV) resource records?

• Who maintains and administers the organization’s internal and external DNS servers and zone

information? What are the IP addresses of all DNS servers?

• Who assigns DNS names and domains within the organization? Is there a centralized authority for

DNS namespace planning and control?

• Where are internal DNS servers located on the network?

• How many DNS zones are currently managed within the environment? Are the DNS zones Active

Directory–integrated?

•

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

records been configured for internal and external zones?




Analyzing the Active Directory Infrastructure

AD DS planning and administration is tied closely with messaging service delivery. In many organizations,

the same team is responsible for both. For messaging systems, AD DS is important because it is the

mechanism by which the mail transport agent decides which recipients are local, and where their

mailboxes are stored. Many organizations have already migrated to AD DS, which means that the most

important design and service decisions have already been made.

Active Directory Infrastructure

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

• Active Directory Site Configuration. Unlike Exchange 2000 Server and Exchange Server 2003,

Exchange Server 2010 does not require configuration of a separate routing topology. Exchange

Server 2010 uses the Active Directory site topology to determine where messages are routed in the

organization. Because of this new dependency, it is important to have a solid understanding of the

current Active Directory site topology, including:

• Number of configured sites.

• Subnet configurations and their site association.

• IP site links and their member sites.

•

IP site link costs and replication schedules.

• Number of domain controllers and global catalog servers in each site.

• Active Directory forest and domain topology. To effectively integrate Exchange Server 2010 into your

current Active Directory structure, you must understand the following:




• Does your organization consist of a single forest or multiple forests? The complexity of the

Exchange deployment depends on the complexity of the Active Directory forest topology. A

single forest provides the richest set of mail system features, and provides effective

administration. You can create multiple forests to address specific situations, such as when a

merger or acquisition takes place.

•

How many domains exist? Are there explicit trust relationships between them? What trustrelationships exist with external domains? If you have a resource forest or multiple forests in your

organization, a trust relationship may be required. If your topology includes multiple forests that

contain Exchange Server 2010, or if your implementation requires a forest-to-forest trust

between forests containing Exchange Server 2010, the minimum Active Directory forest

functional level for each forest must be Windows Server 2003. The Active Directory domain

functional level must be the Microsoft Windows 2000 Server native or Windows Server 2003 for

all domains in the Active Directory forest in which you will install Exchange Server 2010.

• Domain controller and global catalog server configuration. As you analyze each Active Directory site,

document the configuration and location of each domain controller and global catalog server. A Hub

Transport server must be able to communicate directly with a global catalog server to perform Active

Directory lookups. You may have to add a global catalog server to each site to ensure availability.

Also, at least one domain controller in each Active Directory site that contains Exchange Server 2010

must be running either the latest 32-bit or 64-bit edition of Windows Server 2003, or the latest 32-bit

or 64-bit edition of Windows Server 2008.

• Group Policy configuration. Many organizations use Active Directory Group Policy to provide

centralized management and security of users, groups, computers, and other directory objects.

Document the organization of servers in AD DS and how Group Policy is applied to the organizational

units that contain server computer accounts.

• Schema master configuration. Because Exchange Server 2010 requires an update to the Active

Directory schema, it is important to document who controls both the schema master and the

associated rights to make schema modifications. To support Exchange Server 2010, the domain

controller that is the schema master must be running either the latest 32-bit or 64-bit edition ofWindows Server 2003, or the latest 32-bit or 64-bit edition of Windows Server 2008.

Migrating to AD DS

If your organization is migrating to AD DS during the messaging deployment, evaluate the following

factors when assessing the current directory:

• What directory service do you use currently? What are the revision and update levels installed on the

servers?

• What is the location of the existing directory servers? For performance reasons, it may be desirable to

install new directory servers in the same locations.

• What metadirectory, connector, or directory-synchronization tools are in use? Will any such tools be

installed during the messaging deployment?

• How is directory data partitioned? Is data for different applications kept separately in the directory?

• Are there existing directory access controls? If so, who controls and maintains them?

• Who owns the directory schema definition? How are changes managed?

• What physical sites and IP subnets exist? Will the number or location of these entities change because

of the messaging deployment?




Analyzing the Messaging Infrastructure

If your network contains an existing Exchange messaging environment, it is critical to assess and

document the specific functionality and configuration parameters before proceeding with the Exchange

Server 2010 deployment. The following sections discuss what information you should gather when

analyzing the current messaging infrastructure.

Capturing Current Information About the Messaging Environment

One way to capture most information about your current Exchange environment, your current Active

Directory environment, and other required settings, is to use the Microsoft Exchange Best PracticesAnalyzer (ExBPA) tool. The ExBPA provides an extensive transition report to assist in preparing to deploy

Exchange Sever 2010. You can also use the Microsoft Exchange Server Profile Analyzer tool, which assists

you in determining your typical user profile. This information can help with the process of server sizing or

capacity planning.

Additional Information About the Messaging Environment

In addition to the information that ExBPA and Exchange Server Profile Analyzer tools provide, you

also should document other information that you can use to roll back to a previous environment or

configuration, should the need arise. This information is also useful as reference material for comparing

your existing environment to the intended Exchange Server 2010 environment. Consider documenting the

following additional information:

•

Exchange Server hardware and software version. This includes data related to the processors, memory,

and disk storage. Additionally, it is important to document the version and service pack level of the

current Exchange Server software.

• Exchange Server configuration. This consists of data related to server roles—such as front-end servers

or SMTP gateway configurations—dedicated bridgehead servers, mailbox servers, and public folder

servers.




• Administrative roles. Document all Exchange administrators and administrative groups, and any

delegated permissions that have been performed.

• Routing group configuration. Include data that indicates each group’s routing master, names and

locations of servers, and detailed information about the connectors used between routing groups.

This information helps determine how you will transition this configuration to the Active Directory site

structure.

• Storage group and mailbox store configuration. This consists of the current mailbox store

configuration, database and log-file locations, and any policies that apply to the current mailbox

stores. Also take note of the current backup and restore plan for data recovery.

• SMTP namespaces. Document SMTP namespace for all domains for which your Exchange

organization has authority.

• Global settings for message delivery. Consists of a number of configuration settings that control

message delivery, including:

• Sender and Recipient filters

• Address filters

• Message size limits and message formats

• Anti-spam and antivirus settings. This includes information related to antivirus software installed

currently, and specific settings related to content filtering or the Intelligent Message Filter, IP Block

lists, IP Allow lists, and attachment blocking settings.

• Message security settings. This may include information related to the virtual server settings,

authentication and encryption settings, and secure relationships with other SMTP email domains.

• Load-balancing configuration. If you currently implement Network Load Balancing (NLB), document

the configuration so that you can easily migrate the settings to the new messaging infrastructure.

• Third-party add-on services. Be sure to document any third-party add-on services, including fax

solutions or voicemail systems. You must determine if the new system will need these services, anddevelop plans to decommission these services when they become unnecessary.

Integration Considerations

When integrating with an existing messaging environment, consider the following:

• Exchange Server 2010 does not support an in-place upgrade from any earlier Exchange version.

• The Exchange organization must be operating in native mode before you can introduce Exchange

Server 2010 servers into the environment. This means that only servers running Exchange Server 2003

or Exchange Server 2007 can exist in the organization.

• If your organization includes Exchange Server version 5.5, you must perform an upgrade to Exchange

Server 2003 before moving to Exchange Server 2010. To move messaging services and data from

Exchange Server 2003 to Exchange Server 2010, you must use the move mailbox functionality in





Identifying Messaging System Usage

Transitioning to a new messaging system requires a thorough understanding of current usage statistics for

your existing messaging system. This aids in estimating how the new messaging environment will perform,

and if any hardware upgrades are necessary to meet user demands.

The following sections provide information to help you identify messaging system usage within your

network environment.

Profiling the Client Environment

To facilitate planning for processor and memory configurations for your intended messagingenvironment, you must determine how users connect to your current environment. Collect the following

types of information:

• Client environment. Updating to a new messaging system often requires careful consideration of how

users will access their messages and other mailbox information. You may need to provide specific

connection methods based upon a user’s requirements or location. Consider the following when

determining the client environment:

• What operating system are the clients running? Some Office Outlook features are only available

on Windows Vista®. Older clients or Macintosh systems may provide lower functionality. For

using the messaging system, UNIX and Linux clients may be restricted to Internet message access

protocol version 4 (IMAP4), Post Office Protocol version 3 (POP3), or Office Outlook Web App.

• How many client computers exist, and where are they located on the network? These two factors

have a profound influence on the user’s messaging access experience, because slow networks or

heavy server loads are common causes of reported dissatisfaction. By understanding where users

are located, you can better determine client access bottlenecks within the messaging

environment.

• Are there plans to redeploy, update, or replace clients? These efforts may happen before, during,

or after the new messaging system deploys, and you can plan the deployment accordingly.




• Which client protocols are used to access email?

• Depending upon user requirements, many organizations deploy one or more of the following

client protocols:

• Messaging API (MAPI) clients

•

Hypertext Transfer Protocol/Secure (HTTPS) (Outlook Web App)• POP3/IMAP4

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

• Microsoft Exchange ActiveSync® or other mobile messaging clients

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

Profiling Messaging Statistics

A number of messaging statistics are useful for determining your current messaging environment’s usage.

Specific statistics include the following:

• Total size of user mailboxes

•

Size of all messages in specific folders, such as the Deleted Items or Sent Items folders

• Average number of messages received per day

• Average number of messages sent per day

• Average number of recipients of each sent message

• Attachment size statistics across all attachments

• Number of contacts in a mailbox

• Number of appointments in a mailbox calendar

• Average number of meeting requests received per day

Determine an extensive client user profile by using the Microsoft Exchange Server Profile Analyzer or

other third-party tools.

For more information: For additional documentation about the Microsoft Exchange Server Profile

Analyzer, see the “Microsoft Exchange Server Profile Analyzer (32 bit)” page on the Microsoft Download

Center website.

You can use Microsoft Windows Performance Monitor to obtain current usage patterns and statistics.

Exchange Server installs many of its own performance objects and counters to provide information about

Exchange Server services and resources. Specific objects and counters related to user statistics are listed in

the following table.

Object Counter

MSExchangeIS•

User Count• RPC Requests

MSExchange IS Mailbox • Messages Sent/min

• Messages Delivered/min

SMTP Server • Inbound Connections Current

• Message Bytes Sent/sec

• Message Bytes Received/sec




Identifying Additional Infrastructure Components

You may need to consider a number of additional components when documenting your current

messaging environment. If you understand the use of these additional components, you can determine

the new messaging environment’s requirements and provide insight on whether updated third-party

components are necessary.

Additional Infrastructure Components

Consider the following sample points when documenting information related to additional infrastructure

components within your current environment:• What is the current storage method for messaging databases?

• Many of the currently deployed messaging systems use direct attached storage (DAS). However,

many organizations are adopting network attached storage (NAS) and SAN devices because of

their growing capabilities and decreasing storage cost per gigabyte.

• The 64-bit architecture of Exchange Server 2010 provides new performance and scalability

opportunities. The increased memory that 64-bit makes available means that Exchange Server

2010 has tremendously different performance characteristics than Exchange Server 2003. 64-bit

code also reduces substantially the disk input/output (I/O) required for Exchange Server 2010.

• Today’s larger Exchange deployments typically require a high-performance SAN-based storage

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

• Have you integrated Windows Clustering services? It is important to document how you have

implemented Windows Clustering services within your messaging environment. There have been

changes and improvements related to high availability and clustering in Exchange Server 2010.

• What additional software has been integrated into the current messaging system? Examples of

additional software or services that may have been implemented include: archiving solutions, anti-

spam and antivirus solutions, backup solutions, and third-party high-availability solutions.




• Have you implemented a specific backup and disaster-recovery infrastructure? Many organizations

use a separate, high-speed network solution for backup and disaster-recovery purposes. It is

important to document this structure’s use and configuration to ensure that it is adequate for the

new Exchange Server 2010 infrastructure.

• How does your current messaging environment integrate with other systems? Be sure to document

this integration, such as with other messaging environments or network services. For example, do youneed to integrate or synchronize information with a Lotus Domino environment? Many organizations

also purchase solutions to provide integration into existing telephone messaging systems. All external

integration solutions need to be documented and evaluated to ensure functionality with Exchange

Server 2010.

Create an inventory of the products used in your environment, including: antivirus and anti-spam

solutions, storage management software, fax or unified messaging connectors, and system management

and monitoring tools.




Analyzing Administrative Models and Processes

Your organization’s administrative structure and processes have great influence over the IT infrastructure

design. Understanding the constraints inherent in a particular organization is a crucial part of assessing

the environment before you deploy the new messaging system. Areas to investigate include:

• Current organizational administrative model. In some organizations, IT management may be

centralized, while in other organizations, the responsibilities may be delegated to regional areas or

individual business units. The most common approach is a combination of the two scenarios, in which

some IT functions are centralized (such as network provisioning and security) while others (such as

user account management and mail administration) are delegated to geographic or businesssubdivisions.

• User account administrative model. In a centralized environment, a single group of administrators

may perform these tasks for all organizational users. In a decentralized environment, this

responsibility may lie with the messaging team, or with another team such as the human resources or

corporate security departments.

• Business unit structure. It is not necessary to explore exhaustively the interrelationships between an

organization’s business units or divisions. However, it is useful to examine some aspects of these

relationships. For example:

• Do separate business units or divisions require security boundaries between them? If so, you may

need a multiple-forest design, but this has implications for directory synchronization andmessage interchange.

• What are the requirements for communication between different business units? For example, is

a unified directory or address list necessary for the entire organization? Do different business

units need to be able to schedule appointments or otherwise collaborate? If so, you must

accommodate this with your messaging system design.




• How is cross-unit communication controlled? In other words, which group is responsible for

locating and resolving authentication, network, or protocol problems that hinder communication

between users and resources in different units?

• How is the messaging system funded? While this question might seem to be irrelevant from a

design standpoint, the answer is important. In many organizations, the business units that fund

the messaging systems want the initial design to specify accounting, chargeback, quota, andtracking features.

• Troubleshooting processes. Most large organizations have a well-defined troubleshooting process

that may include multiple support levels. The information about the current troubleshooting

processes is useful when you create the deployment plan and helps to ensure that the appropriate

administrators receive the necessary training for troubleshooting the Exchange Server 2010

deployment.




Analyzing the Change Control Process

The change control process varies greatly between organizations. Some organizations have not

implemented a formal change control process, while others implement strict change requests, approval,

and notification processes. It is important to understand how your organization manages changes to

ensure that all users and stakeholders are aware of and approve changes made to your messaging

environment.

Identifying Change Control Processes

Change is any modification, introduction, or elimination of an IT component that may affect an IT servicelevel, or the functionality of its environment or components. Key questions to ask regarding change

control processes include:

• How does the organization implement IT changes? You need to identify specific processes that take

place when you implement changes. These processes may include:

• IT infrastructure change approvals. Before you make changes, IT managers, architects, or security

personnel may have to provide approval. You need to document who the decision makers are,

and how they affect the change-approval process.

• Change notification. Before the change takes place, all affected users must be notified of the

change and any impact it may cause. It is important to document all current change-notification

processes, and the requirements specifying when change notifications are required.

• Emergency escalation notification processes. If issues arise during implementation of the

approved change, you will need to know whom to contact to provide troubleshooting and

recovery procedures.




• What are the time frames for making changes that may impact availability? Many organizations

implement SLAs with their internal users or customers. An SLA provides a guarantee that specific

network services will be available, and outlines acceptable outage time frames should an upgrade or

failure occur. Document all current SLAs that the organization uses to ensure that changes do not

impact legal requirements to users.

•

What are the risk management processes related to change management? A complete changecontrol process includes a risk analysis and processes for mitigating risks.




Lesson 5

Overview of Microsoft Office 365

Microsoft Office 365 delivers the same office productivity and collaboration tools found in Microsoft

Office—but through the cloud. When designing your Exchange Server 2010 deployment, it is important to

consider whether you can use all or part of Office 365 to enhance your messaging infrastructure.


• Describe Microsoft Office 365 features.

• Describe Exchange Online.

• Describe the Exchange Online design considerations.




What Is Microsoft Office 365?

Microsoft Office 365 provides your users with the tools to email, communicate, and share documents

through the Internet (or in a Cloud) without the requirement for your organization to purchase servers.

It provides your users with virtually anywhere-access to your their productivity applications and

collaboration tools. On the user’s client devices, Office 365 is implemented with software with which your

users are familiar: Office Word, Excel, OneNote, and PowerPoint. In addition, Office 365 provides email

and related services with Exchange Online.

For administrators, a cloud-based administrative console enables you to configure user accounts, grant

rights, manage permissions, and manage your Office 365 deployment.

Note Microsoft Office 365 replaces the Business Productivity Online Suite (BPOS). Existing

BPOS customers can transition to Office 365.

Office 365 consists of the following online services:

• Microsoft Office Professional Plus. Provides users with access to the latest versions of all the Office

desktop applications. Combined with Office Web Apps, users can access their content from almost

anywhere.

• Microsoft Exchange Online. Provides email, calendar, and contacts. Users can connect with a variety of

mobile devices, or use either Microsoft Office Outlook 2007 or Office Outlook 2010. Exchange Onlinealso helps to provide for improved message hygiene through the use of anti-spam and antivirus

software.

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

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

the Internet.

• Microsoft Lync™ Online. Enables your users to connect to their contacts with instant messaging (IM),

video calls, and online meetings.




• Microsoft Office Web Apps. Enables users to create, view, share, and edit their Microsoft Office

documents on the web. Users can use a wide variety of computing devices to access their content.

Note Devices require an Internet connection and a supported browsers such as Internet

Explorer.

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

These are:

• Microsoft Office 365 for professionals and small businesses. Designed for organizations with no more

than 25 users and provides the foundation Office 365 services: email, calendar, and website services.

• Microsoft Office 365 for midsize businesses and enterprises. Designed for any size organization that

requires the more advanced features of Office 365, such as:

• Advanced IT configuration and control

• Office Professional Plus

• AD DS

• Advanced archiving

• Dedicated administrator support

• Microsoft Office 365 for education. Provides a similar user experience to that of Office 365 for midsize

businesses and enterprises, but tailored for educational establishments.




What Is Exchange Online?

With Exchange Online, your users can access their email and related content from either Microsoft Office

Outlook, a supported web browser, or from a range of mobile devices.

Exchange Online has the following features:

• Extensive client support. Users can access Exchange Online content by using Microsoft Office Outlook,

including Outlook Anywhere, compatible web-browsers, or from POP client devices.

• Mobility. Mobile access is provided with the following features:

• Push email support

• Calendar and contacts through Exchange ActiveSync

• Compatible with many devices

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

• Emails, calendars, and contacts. Features include:

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

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

• A shared company directory, distribution groups, and shared contacts

•

Voicemail. Exchange Online voicemail is compatible with both on-premises PBX phone systems and

Lync Server 2010. In addition, Exchange Online provides voicemail preview, call answering rules, and

company auto-attendant.

• Data protection. Exchange Online is backed by an SLA that guarantees 99.9% uptime. In addition,

continuous data backup between is provided between globally-redundant datacenters. At the more

local level, deleted item retention and deleted mailbox recovery are both provided.




• Security. To help to provide for message hygiene, Microsoft Forefront Online Security for Exchange is

used to help to protect against virus and spam. In addition, continuous intrusion monitoring and

detection is provided, and all connections to the Exchange Online environment are implemented over

HTTPS to help keep access more secure.

• Archiving and compliance. Exchange Online has built-in email archiving and provides you with the

ability to search multiple user mailboxes at once. Exchange Online provides policies to automaticallyexpire email data or to preserve it for compliance purposes. In addition, flexible transport rules can be

used for applying disclaimers and other policies to email in transit.




Design Considerations for Exchange Online

If your organization has decided to implement Exchange Online, this will impact the design of your

Exchange Server deployment.

For example, you must consider whether you will implement Exchange Online only, or whether you intend

to deploy a hybrid solution in which both Exchange Online and an on-premises Exchange Server

environment will coexist; this is an important decision as it greatly impacts the other design decisions that

you make.

Note Even if you intend to implement Exchange Online only, but have an existing on-

premise Exchange Server environment from which you plan to migrate, this will require a

hybrid solution during the migration phase of the deployment project.

Deploying a hybrid solution requires additional design considerations and deployment steps. For example,

a hybrid solution requires:

• At least one Exchange Server 2010 server in your existing messaging infrastructure.

Note If you currently have either Exchange Server 2003 or Exchange Server 2007 servers,

get an Exchange Server 2010 Hybrid Edition license key from Microsoft support; this key

enables you to install Exchange Server 2010, and is used only to connect your Exchange

Server 2003 and Exchange Server 2007 servers to Exchange Online.

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

• Optionally, single sign-on. This enables your users to use their company network credentials to access

their online mailboxes. To enable single sign-on, you must deploy Active Directory Federation

Services (AD FS) version 2.0.




• Directory synchronization. This enables AD DS to replicate with the directory services within Exchange

Online. The directory synchronization tool has certain limitations:

• It must be installed on a 32-bit server.

• It cannot be installed on a domain controller.

•

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

• Digital certificates. Self-signed certificates can be used to help to secure communication between

client-side applications and the Exchange Online environment, but for some purposes, you must

implement public certificates.

Note Module 12 expands on these concepts.




Lab: Introduction to Designing an Exchange Server 2010Deployment

Lab Setup

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

Lab Scenario

You are a messaging engineer for A. Datum Corporation, an enterprise-level organization with multiple

locations. A. Datum is an international corporation involved in technology research and investment, and isplanning to upgrade from Exchange Server 2003 to Exchange Server 2010. A. Datum currently has three

remote sites, and their headquarters. The company is pursuing an aggressive expansion plan, and will be

adding two new office locations during the upgrade project.

Location Internal users Mobile users

London

CorporateHeadquarters

12,000 currently

10,000 after the newLondon office is ready

• 1,000 Outlook Web Access users

• 500 Outlook Anywhere and mobile client users

• 800 Office Outlook users connecting through a virtualprivate network (VPN)

London (new

office)

4,000 (anticipated) • 200 Outlook Web Access users

•

50 Outlook Anywhere and mobile client users

San Diego

Former headoffice ofTrey Research

500 • 50 POP3 client users

Vancouver 6,000 • 800 Outlook Web Access users





(continued )


Tokyo 5,000 • 1,000 Outlook Web Access users


•

200 Office Outlook users connecting through a VPN

Chennai (newoffice)

800 (anticipated) • 200 Outlook Web Access users

• 50 Office Outlook users connecting through a VPN

A. Datum has deployed a single Active Directory forest with a dedicated root domain named

Adatum.com, and three child domains in the same tree. These domains are:

• EU.Adatum.com

• NA.Adatum.com

• AS.Adatum.com

Additionally, the organization has deployed a domain named TreyResearch.net in the San Diego location.

This domain is configured as a separate tree in the Adatum.com forest.

Adatum_Info.vsd

Domains:




Domain Controller Locations:

London Messaging Detail:




Tokyo Messaging Detail:

Vancouver Messaging Details:




Requirements Interview Notes Document

Madeleine Kelly, CEO

The Board of Directors has just initiated a three-year plan that will result in A. Datum doubling in size.

Some of this growth is going to come from internal growth by expanding our current businesses, but the

plan also calls for a very aggressive acquisitions strategy. Much of my time for the next three years will be

spent identifying potential acquisitions anywhere in the world, and negotiating partnerships or takeovers.

Whatever messaging solution you create has to be very flexible and easily expanded.

Karen Toh, Vice President – Europe

My biggest complaint with the current email system is that it is technically obsolete. One of the groups I

manage is our International Sales Team. There are only 50 people on the team, but they are constantly

traveling throughout the world researching business opportunities. This team makes more money for this

company than any other group of people. They are also very knowledgeable about technology, and they

tell me that our current system is archaic compared to what other companies are using. This team wants

the latest and greatest in technology. This team needs to be able to access their email from anywhere in

the world at any time.

Marcel Truempy, CIO

In the last 5 years since I became CIO, our email system has changed from being a useful tool for business

to being a critical part of our business processes, and everybody notices when email is not available. To

give you an example, a couple of months ago all of the email servers in London were unavailable for 6

hours due to a virus outbreak. A couple of months before, one of the servers in Vancouver failed, and we

couldn’t send any email to and from Vancouver for 8 hours while the hardware vendors came in to fix the

hardware. This happened right in the middle of some critical business negotiations where we had to be

able to exchange documents rapidly. In both cases, the CEO and every other member of the executive

staff called me on my cell phone while I was at home. The most important requirement I have for this

email system is availability — this system has to be available always.

Scott MacDonald, Vice President – North America

The Security and Compliance Department for the organization is based in Vancouver, so they report to

me. The head of that department tells me that the rules for how we do business and, especially, how we

handle confidential or private information are changing all the time. Just about every country has laws

regulating what we can do with private customer information, but the rules are often not the same. This

gets very complicated for an international organization like ours, where some of that information is

crossing country borders. We need a messaging solution that we can use to enforce some of the

compliance requirements.

Gareth Chan, Vice President - Asia

A. Datum is establishing a very important partner relationship with Contoso, Ltd. Contoso, Ltd is a high-

tech research organization, and we are working on some very confidential projects with them. We need to

make sure that all of the email that we are sending between our company and Contoso, Ltd cannot beviewed by anyone else on the Internet.

Carole Poland, IT Manager

My biggest concern with this project is the budget. This company has a history of setting very high

expectations for a project, and then not providing the budget to do the job right. So whatever design you

come up with, we are going to have to be very conscious of the budget.




Shane DeSeranno, Network Operations Manager

The Network Operations department is responsible for managing all of the wide area networks (WAN)

links, the local area networks (LANs), and the firewalls. One of the restrictions that the Security department

placed on us recently is that we cannot allow any unencrypted traffic through our internal firewalls. We

can accept unencrypted traffic into our perimeter network, but not to the internal network.

Jason Carlson, Network Specialist

I can provide you with a Visio® diagram that has all of our WAN connections and our connections to the

Internet. Our network right now is quiet reliable, but we don’t have much available bandwidth between

company locations.

Tzipi Butnaru, Directory Services Manager

The company just finished upgrading all of the Active Directory domain controllers to Windows Server

2008, Service Pack 1. As part of the upgrade, we did a thorough review of our whole Active Directory

design. We don’t anticipate making any more changes to the Active Directory configuration for a while.

Conor Cunnigham, Messaging Services Manager

One of our biggest problems right now is all of the mobile users that we have to support. We have quite afew users using Outlook Web Access, and that seems to be working pretty well, although I do have some

security concerns with using Outlook Web App. A lot of our users work at home, and most of them are

using POP3 clients. I also have security concerns with these clients, but a bigger problem for them is

functionality. Users complain that they can’t easily access their calendar information or send meeting

requests. And we have more and more people asking for access to their email through cell phone devices.

Andreas Herbinger, Messaging Specialist

We currently have a mailbox size limit of 50 megabytes (MB) for all users. However, this limit is much too

small, and a lot of people have been able to convince their managers to approve an increase is size for

their mailboxes. At this point, almost half of the people in the company have an exception on their

mailbox limits, and most of these limits are at 100 megabytes (MB).

Luca Dellamore, Messaging Specialist

We currently have four administrative groups in our Exchange organization. We have an administrative

group for North America, one for Europe, and one for Asia (LondonAG, VancouverAG, and TokyoAG). The

extra administrative group contains all of the routing groups (RoutingGroupAG). In each location, we have

a group of Exchange administrators that have full administrative permissions for their administrative

group, but do not have any permission in the other administrative groups (LondonExAdmins,

VancouverExAdmins, and TokyoExAdmins). In London, we have a group of senior messaging specialists

who have full control over all administrative groups (EnterpriseExAdmins). This group is also the only

group that has administrative permissions over the routing administrative group.

We also have a routing group for each of the big company locations: the routing group in Vancouver is

called VancouverRG, and then we have LondonRG, and TokyoRG. I can send you the Visio with all of the

Exchange Servers in each location. We have a routing group connector between VancouverRG and

LondonRG, and between LondonRG and TokyoRG.

We use two SMTP namespaces: adatum.com and TreyResearch.net.

Note Your instructor may choose to perform this lab as a group discussion rather than an

individual activity.




Exercise 1: Evaluating an Existing Messaging Infrastructure

Scenario

In this exercise, you will complete two sections of a messaging infrastructure checklist.

To complete this exercise, review the existing A. Datum documentation:

•

Diagrams describing the A. Datum environment

• Interview notes from meetings with various personnel at A. Datum

The main tasks for this exercise are as follows:

1. Review A. Datum documentation.

2.

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

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

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

Task 1: Review A. Datum documentation• Review the following information:

• Adatum_Info.vsd

• Requirements interview notes document




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

Analysis document

• Complete the Current Network Infrastructure Analysis document.

A. Datum Current Network Infrastructure Analysis

Document Reference Number: JC310110/1

Document Author

Date

Jason Carlson

31st January 2010

Active Directory Infrastructure - Sites

Active Directory site name Directory servers in each site

LondonSite RD-LON-DC1

RD-LON-DC1

EU-LON-DC1

EU-LON-DC2

Additional notes

Active Directory Infrastructure – Forest and domain topology

Forest Domains in each forest

Additional notes




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

Analysis document

• Complete the relevant sections of the following document.

A. Datum Current Messaging Infrastructure Analysis


Document Author

Date

Jason Carlson

31st January 2010

Exchange Server Configuration

Server name Exchangeversion andSP level

Serverrole

Location

LON-MSG-FE1 ExchangeServer 2003

Front-end

server

London




(continued )

A. Datum Current Messaging Infrastructure Analysis


Additional notes

Exchange Organization information

Configuration Settings

Administrativegroups

Administrator

groups

Routinggroups

SMTPnamespaces

Additional notes

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

Infrastructure Analysis document.




Exercise 2: Creating a Requirements Document

Scenario

In this exercise, you will complete a requirements document for A. Datum Corporation.


1.

Discuss the questions.

2. Complete the appropriate sections in the Project Requirements Analysis document.

3. Discuss the components that you will need to include in the Exchange Server design to meet the

company requirements.

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

Task 1: Discuss the questions

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

1.

What are A. Datum Corporation’s requirements and pain points?2.

How can Exchange Server 2010 help address the requirements?

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

document

You will complete these sections as a group.

• Complete the relevant section of the following document.

A. Datum Project Requirements Analysis


Document AuthorDate

Jason Carlson31st January 2010

Summary of business requirements

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

Summary of functional requirements

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




(continued )

A. Datum Project Requirements Analysis

Summary of additional requirements

This section lists the additional requirements identified during the requirements analysis task.

Additional requirements may include data related to additional stakeholders, required technology,and user requirements:

Project priorities and constraints

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

Task 3: Discuss the components that you will need to include in the Exchange Server

design to meet the company requirements


• Discuss the following questions:

1.

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

business requirements?

2.


technical and additional requirements?

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




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

Scenario

In this exercise, you will discuss guidelines for setting budget expectations for projects.

The first of several budget reviews should happen early. The team needs to determine whether the projectis feasible. If the costs are very high, the team needs to start thinking about how much each of the

requirements will cost, and how cutting certain requirements will affect the budget.

The main task for this exercise is to answer the following questions.

Task: Answer the following questions

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

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

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




Exercise 4: Discussion: Refining the Scope of SLA Requirements

Scenario

Humongous Insurance is a large provider of life, disability, and health insurance. There are three locations

in the United States that perform administrative functions: New York, Los Angeles, and Dallas. Each office

has approximately 400 people. All users in these locations access their email internally by using the full

Office Outlook client, but occasionally also need to remotely access to their mail.

The Active Directory forest consists of a single domain (humongousinsurance.com) with each physical

location configured as a site. Each site has a single domain controller, a file server, and several application

servers that are used for specialized insurance software. Each domain controller is configured as a global

catalog server.

New York serves as a central hub for network communication. There is a 10-megabits per second (Mbps)

link from New York to Los Angeles, and another 10-Mbps link from New York to Dallas. Finally, there is a

10-Mbps Internet connection in New York. Other locations do not have direct Internet connectivity.

There are 85 independently owned sales offices throughout the United States. The sales offices are not

part of the humongousinsurance.com Active Directory forest. The software that the sales offices use to fill

out policy information sends applications as an encrypted attachment in email. As part of the ExchangeServer 2010 rollout, users in these offices will be given Humongous Insurance email accounts.

The initial plan for Exchange Server 2010 implementation includes configuring a single Exchange Server in

each physical location to service that location’s users. The Exchange Server in New York will also service

the sales offices. Each Exchange server will perform the roles of Mailbox server, Hub Transport server, and

Client Access server. An additional Exchange server in New York will perform the Edge Transport server

role.

The chief information officer (CIO) and chief operating officer (COO) created the first draft of high

availability requirements for the new Exchange Server 2010 system. These requirements are the starting

point for SLA development. In the role of the project’s technical lead, review this information and

determine what additional information is necessary to create a useful SLA.

In this exercise, you will refine the scope of SLA requirements.

High Availability Information Requirements document

Authors: Marcel Truempy (CIO) and Gregory Weber (IT Steering Committee Chairman)

The availability requirements for Exchange Server 2010 are:

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

• Messages must be delivered inside the organization within minutes.

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

• If an Exchange Server fails, users should experience very little disruption in service, and no mail

messages should be lost.

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





1.

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

2.

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

3. Discuss your solution with the class.

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

have created

• Review the requirements documentation.

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

1.

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

SLA.

2.

Complete the relevant section of the following document.

A. Datum Refining the Scope of SLA Requirements


Document Author

Date

Jason Carlson

31st January 2010

Questions

Task 3: Discuss your solution with the class

• Participate in the discussion led by your instructor.

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




To prepare for the next module

When you finish the lab, start the virtual machines that will be required for the next lab. To do this,

complete the following steps:

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

2.

In Hyper-V®

Manager, click 10233B-NYC-DC1 , and in the Actions pane, click Start.3. In the Actions pane, click Connect. Wait until the virtual machine starts.

4. Log on using the following credentials:

• User name: Administrator

• Password: Pa$$w0rd

• Domain: Contoso

5.

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




Module Review and Takeaways

Review Questions

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

2.

What are the key areas addressed by an SLA?

3.

What are some typical project constraints?

4. A. Datum has 50 databases. In a five week period, each database is unavailable for 30 minutes each.

What is the percent service availability as measured by the proportional uptime of the databases?

5. What would the database unavailability need to drop to — per database — to achieve 99.99% uptime?

Best Practices

Supplement or modify the following best practices for your own work situations:• If an organization does not have any written SLAs, it is very important when beginning any

deployment project to identify and document informal SLAs. Clearly identifying the expected system

performance enables future validation of the project’s success.

• As much as possible, ensure that your messaging solution addresses the needs of your users—if the

first user experience of a new system is positive, the system is more likely to be accepted.




• It is critical that the monitoring, reporting, and reviewing tasks in the service level management

process are performed; without these tasks, the value of an SLA is reduced significantly

• Ensure that the information you collect that relates to your existing infrastructure remains current;

that is, it includes any planned changes to the environment that may impact the Exchange Server

2010 deployment.



2-1

Module 2

Designing Microsoft® Exchange Server 2010 Integrationwith the Current Infrastructure

Contents

Lesson 1: Designing the Network Infrastructure 2-3

Lesson 2: Designing the AD DS Infrastructure 2-16

Lesson 3: Designing the DNS Infrastructure 2-32Lesson 4: Planning Exchange Server Administration 2-40

Lab: Designing Exchange Server Integration with the

Current Infrastructure 2-55



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

Module Overview

You will seldom deploy Microsoft® Exchange Server 2010 into an organization with no pre-existing IT

infrastructure. Consequently, it is important that you understand what networking components must be in

place, and how they must be configured in order to properly support Exchange Server 2010.


• Design the network infrastructure.

•

Design the Active Directory® infrastructure.• Design the Domain Name System (DNS) infrastructure.

• Plan Exchange Server 2010 administration.




Lesson 1

Designing the Network Infrastructure

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

understanding the configuration of these components helps to ensure that your Exchange Server

organization operates optimally.


• Identify the network requirements for Exchange Server deployments.

• Identify the Internet access considerations for client access.

• Identify the network considerations for client access.

• Identify the network considerations for message routing.




Identifying the Network Requirements for Exchange Server 2010Deployments

The four network cornerstones of a successful Exchange Server 2010 deployment are: Active Directory

Domain Services (AD DS), DNS, an appropriately configured routing infrastructure, and Internet

connectivity.

AD DS

Exchange Server 2010 uses AD DS to store configuration information, and to share directory data with

Windows® servers.If your organization already has AD DS implemented, you must understand the changes that you must

make to AD DS to support Exchange Server 2010.

If your organization does not currently have AD DS implemented, then you can consider making less

constrained design decisions when planning your Exchange Server 2010 deployment; however, you must

consider how best to migrate from your existing directory service.

When you begin planning your Exchange Server 2010 deployment, consider the following facts relating to

AD DS:

• Schema and related changes. When you deploy Exchange Server 2010, you must make certain

schema and configuration changes to AD DS. In larger organizations, you must plan for these

changes carefully. For example: support teams that are involved in the process of making schemachanges may differ from support teams involved in deploying and maintaining the messaging

infrastructure. There may also be applications deployed within the organization that will be impacted

by the required schema changes. In smaller organizations, these changes may have a less significant

impact on users or installed applications. In addition, smaller organizations often use a single team of

support staff for all infrastructure projects.




• Site configuration. Exchange 2000 Server and Exchange Server 2003 both used routing groups as a

means for determining the optimum delivery path for messages within an organization. Exchange

Server 2010 uses the AD DS site configuration. The current site configuration might be entirely

suitable for optimizing message delivery, but it may also not be. You may need to reconfigure the

existing site configuration to better support the Exchange Server 2010’s needs. This may involve

modifying the AD DS site configuration directly, or overlaying an Exchange Server 2010 specific site

configuration.

• Placement of domain controllers and global catalog servers. Exchange Server 2010 requires access to

both domain controllers and global catalog servers in order to perform various functions, including

message routing and delivery, distribution list expansion, and accessing address lists and email

address policies. You must ensure that you deploy sufficient domain controllers and global catalog

servers in each site.

DNS

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

for:

• Enabling messaging servers in remote organizations to resolve the name and IP address of servers

within your organization that are responsible for handling inbound Simple Mail Transfer Protocol

(SMTP) email.

• Enabling messaging servers in your organizations to resolve the name and IP address of servers within

other organizations that are responsible for handling their inbound SMTP email.

• Supporting the resolution of names to IP addresses for internal SMTP communications between Hub

Transport servers within your organization.

• Supporting the resolution of names to Edge Transport server IP addresses, or other SMTP relays, for

Hub Transport servers within your organization.

• Supporting the resolution of names to Hub Transport server IP addresses, for the Edge Transport

servers or other SMTP relays within your organization.

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

Routing Topology

The purpose of an AD DS site is to define a geographic boundary that represents a collection of servers

and services that are connected with high-speed, low-latency network devices. Typically computers within

an AD DS site need not be too concerned about the availability of network bandwidth. When computers

in a different geographic location are connected to the first location, if the devices that interconnect them

introduce too much latency, or do not provide sufficient bandwidth, the AD DS administrators create a

new AD DS site for the new location. The administrators also configure the site connections between the

two sites. These site connectors are a logical representation of the underlying network devices that

interconnect the two locations. They define a cost and an AD DS replication interval and schedule.

Both Exchange Server 2007 and Exchange Server 2010 use the existing AD DS site configuration to make

message routing decisions. Therefore it is important that the existing site configuration is properly

configured, and that the necessary Exchange Server 2010 services are deployed to each site. The existing

routing topology and the AD DS site configuration that maps to it may not be ideally suited to supporting

your Exchange Server 2010 deployment.




Internet Connectivity

Email is a critical communications tool. Without email, an organizations’ functionality is impaired. Most

organizations use email as a primary external communications mechanism. The Internet provides the

mechanism through which this communication is routed. Your organization probably already has a

connection to the Internet, and you must consider the current configuration when planning the Exchange

Server 2010 deployment.




Identifying the Internet Access Considerations for Client Access

Many organizations allow their employees to access their email and related data from locations other

than the corporate intranet. However, often there is no single way in which employees access this data.

For example, some users may choose to use a web browser to access their email, while others use mobile

devices such as a mobile phone installed with Windows Mobile®. In addition, the computers with which

users access their data might not be managed computers, and consequently, security issues might be

more of a concern.

When planning client access from the Internet, you must consider the following factors:

• Device types. The type of device with which a user accesses their remote messaging data will vary.

Some users will use a web browser, others will use Windows Mobile® devices, while others will use an

email client that supports protocols such as Post Office Protocol 3 (POP3) or Internet Message Access

Protocol 4 (IMAP4). You must understand the security implications and protocols used by each of

these devices, and these implications on your organization.

• DNS configuration. It is important that remote client computers and devices are able to resolve

designated names, in order to access messaging services. For example, the external URL name of the

Client Access server role for a remote user must resolve to the appropriate reverse proxy interface in

the corporate perimeter network. Likewise, since an email program is configured with the name of a

remote POP3 server for mail retrieval, the client computer must have a mechanism for resolving the

name to the appropriate IP address.

Note It is tempting to use IP addresses when configuring email clients, rather than usingserver fully qualified domain names (FQDNs). Avoid this practice, as it creates additionalmanagement issues. For example, if the server providing an email client service changes,you must update the configuration of all affected client computers. Additionally, digitalcertificates that are provided to enable authentication and encryption between clients andservers are configured with a subject name that matches the designated server’s publishedFQDN; if an IP address is used, this will at best raise an error on the client, and at worst,prevent email retrieval.




• Firewall ports. Understanding the type of device and the protocol being used by the client enables

you to configure the firewalls that separate the clients from the Exchange Server 2010 server. Your

aim should always be to open a port only if its use is unavoidable. Remember that in addition to the

external Internet-facing firewall and the internal perimeter network firewall, you must consider the

Windows firewall configuration. The following table describes the common clients and their

respective protocols and the ports used.

Client type Protocol and port

Microsoft Outlook®Web App

HTTPS; TCP port 443

Microsoft ExchangeActiveSync®

HTTPS; TCP port 443

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

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

Outlook Anywhere HTTPS; TCP port 443

• Certificates. Because of the importance of using SSL secure network traffic between Client Access

servers and messaging clients, you must ensure that you deploy the appropriate certificates on the

Client Access servers. You can secure all client connections to the Client Access server using SSL.

Note By default, the Client Access server is configured with a self-signed certificate that isnot trusted by clients. You should remove this certificate, and install a certificate from atrusted certification authority (CA).

An important consideration when planning the use of certificates is identifying the source of the

certificates. Exchange Server 2010 can use self-signed certificates, or certificates issued by either a

public or private CA. Each type of certificate has benefits and disadvantages. In Exchange Server 2010,although you can use the self-signed certificates for internal communication—such as for securing

SMTP connections between Hub Transport servers—we do not recommend this. Similarly, you also

can use these self-signed certificates to secure client connections to Client Access servers, but because

none of the client computers trust this certificate, we do not recommend this solution either. Rather,

you should consider obtaining a certificate from a public CA or internal CA for all Client Access

servers.

For clients to connect to the Client Access server using SSL without receiving an error message, the

names on the certificate must match the names that the clients use to connect to the server. For

example, if your users connect to the Outlook Web App site using a URL such as

https://mail.contoso.com, and they connect to the IMAP4 server using a name such as

IMAP.contoso.com, you need to ensure that the certificates you use support both server names.

Additionally, if you enable Autodiscover access from the Internet, your certificate also must support a

name such as Autodiscover.contoso.com.

You can implement this configuration by using the following options:

• Obtain a separate certificate for each client protocol that requires a unique name. This may

require multiple certificates for all Client Access servers. This may also require multiple websites in

Internet Information Services (IIS). This is the most complicated option to configure.




• Configure all clients to use the same server name. For example, you could configure all clients to

use the server name mail.contoso.com, and obtain a certificate for just that one name.

• Obtain a certificate with multiple subject alternative names. Most public CAs support the use of

multiple names in the certificate’s subject alternative name extension. When you use one of these

certificates, clients can connect to the Client Access server using any of the names listed in the

subject alternative name.• Use a certificate with a wildcard name. Most public CAs also support the use of wildcards in the

certificate request. For example, you could request a certificate using the subject of

*.contoso.com, and use that certificate for client connections.

Note Not all clients support wildcard certificates. Microsoft Office Outlook, WindowsInternet Explorer®, and Window Mobile 6 or newer clients support wildcard certificates, butyou need to verify this functionality for all messaging clients that are used in yourorganization before deploying these certificates.

• Public computer access. It is possible that users will use public computers to access their messaging

data. For example, a user might use a computer located in an Internet café to read their email.Because public computers are unmanaged, they are unmanageable. You must plan carefully for what

type of access you will allow from public computers. For example, if users are using Outlook Web

Access to access their email and any attachments, you can impose limitations on how message

attachments are handled.

• Mobile device security. Mobile devices—especially mobile phones—are prone to becoming lost or

stolen. If these devices contain sensitive corporate or private information and data, there is a

corresponding security risk posed by these devices. You must configure client access to mitigate the

security risks.

• High availability. Your users rely on your messaging environments so that they can perform critical

business tasks, and it is extremely important for your messaging solution to be available when

required. High availability is a commonly used term that refers to a specific technology orconfiguration that helps to ensure service availability. In Exchange Server 2010, all client access to the

Mailbox role is handled by the Client Access role—even Messaging Application Programming

Interface (MAPI)-based client communication. Consequently, it is more important than ever that the

Client Access server role is highly available to your Internet-based clients. Exchange Server 2010 uses

client access arrays to provide for this high availability. A client access array is a load-balanced

collection of Client Access servers that are contained in a single site.

To create a client access array, you first must deploy multiple Client Access servers. Next, you need to

use either hardware or software-based network load balancing (NLB) to create a cluster. Then, add

the name for the network load-balanced cluster into DNS. After adding the DNS record, you can

create the client access array and assign it to an AD DS site using the New-ClientAccessArray

cmdlet. Finally, you must assign the client access array to each of the mailbox databases in the siteusing the Set-MailboxDatabase cmdlet with the –RpcClientAccess parameter to specify the name

of the client access array.

A client access array can exist only in a single AD DS site. Therefore, you would need to create a client

access array in each AD DS site that needs to load balance Client Access servers.




• Load balancing. It is important that client access requests are serviced in a timely manner. The

provision of multiple Client Access servers in a client access array not only improves high availability

of the client access role, but also distributes the workload amongst the Client Access servers in the

array.




Identifying the Network Considerations for Client Access

Many of the considerations of providing Internet-based client access apply equally to the local network

environment. Firewall configuration, certificates, load-balancing, and high availability all remain factors in

your design, whether the client is local or remote. However, it is important to understand how the Client

Access role fits within the context of your existing network infrastructure, and to consider any changes

that you might need to make to that infrastructure to better support the role.

Note Implementing Exchange Online may introduce additional Client Access Server

configuration changes. It is important that you consider your Exchange Onlineimplementation when designing your Client Access Server network configuration. Forfurther information about the changes that may be introduced by Exchange Onlinedeployments, refer to Module 12.

AD DS

The Client Access server role uses AD DS, and specifically the global catalog service, to locate the site that

contains a user’s mailbox. Consequently, you must ensure that each Client Access server has local access

to a global catalog server.

Perimeter Network Configuration

Because the server running the Client Access server role must be a member server in an AD DS domain,

you cannot deploy the Client Access server role in a perimeter network. Instead, use an application layer

firewall, such as Microsoft Forefront® Threat Management Gateway, to publish the Client Access server

services to the Internet.

Site Design

In Exchange Server 2010, all messaging clients accessing an Exchange Server 2010 mailbox connect to a

Client Access server. For users to access their mailbox, you must deploy a Client Access server in the same

site as the Mailbox server.




Note Client access to public folder content is handled by the Mailbox server rather thanthe Client Access server role.

Note In Exchange Server 2007 or earlier Exchange Server versions, MAPI clients such asOffice Outlook connect directly to Mailbox servers. In Exchange Server 2010, with theintroduction of the Remote Procedure Call (RPC) Client Access service, MAPI clients nolonger connect directly to the Mailbox servers for mailbox access.

Deploying Client Access servers in an environment with multiple AD DS sites adds complexity to

deployment planning, particularly when you consider the options for providing Internet access to those

Client Access servers.

In a single-site scenario, the Client Access server communicates directly with Mailbox servers. In a

multiple-site scenario, clients are directed to a Client Access server located in the same site as the Mailbox

server, or a Client Access server in a remote site might proxy a request to a Client Access server in the

same site as the Mailbox server. The option you select for a multiple-site scenario depends on whether

clients can connect directly to a Client Access server in the same site as their mailbox.

If you have multiple AD DS sites, you can provide Internet access to each site’s Client Access server. Toenable this option, you must configure an external URL for each Client Access server. You also must

ensure that clients can resolve the URL name in DNS, and can connect to the Client Access server using

the appropriate protocol.

Public Key Infrastructure

Certificates, and the authorities that issue and maintain them, form part of your Public Key Infrastructure

(PKI).

Generally, you should deploy a certificate issued by a public CA if users access the Client Access server

from the Internet. In this scenario, it is important that the clients trust the certificate.

However, you could consider using an internal or private CA, only if computers that are members of the

internal domain access the Client Access server. In this scenario, by deploying an Enterprise CA, you canautomate the process of distributing and managing certificates and certificate revocation lists.




Identifying the Network Considerations for Message Routing

When you begin to plan your message routing infrastructure, there are a number of important factors

regarding the existing network infrastructure that you must consider.

Routing Topology

By default, Hub Transport servers use direct relay to other Hub Transport servers for messages that must

be routed to other AD DS sites. That is, they establish a direct connection using SMTP over Transmission

Control Protocol (TCP) port 25 to the target Hub Transport server. To facilitate this, it is important that an

efficient Transmission Control Protocol/Internet Protocol (TCP/IP) routed infrastructure exists betweengeographic locations represented by site objects in AD DS.

Site Design

The Hub Transport server uses the site-link cost assignment to determine a routing; the originating Hub

Transport server uses IP site-link costs to determine the lowest cost path to the destination site. It is

therefore important that the AD DS site configuration — including the site-link costs — are configured

appropriately to support efficient message routing. If they are not, and you are unable to reconfigure

them due to other AD DS-aware applications having different needs than Exchange Server 2010, you can

do one of the following:

• Configure one or more AD DS sites in your organization as Exchange Server 2010 hub sites. When a

hub site exists along the least-cost routing path between two Hub Transport servers, the messages

are routed to a Hub Transport server in the hub site for processing before they are relayed to thedestination server. The Hub Transport server routes a message through a hub site only if it exists

along the least-cost routing path. The originating Hub Transport server always calculates the lowest-

cost route first, and then checks if any of the sites on the route are hub sites. If the lowest-cost route

does not include a hub site, the Hub Transport server will attempt a direct connection.




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

• Configure Exchange-specific routing costs. You also can modify the default message routing topology

by configuring an Exchange-specific cost to an AD DS IP site link. If you assign an Exchange server-

specific cost to the site link, the Hub Transport server uses this attribute instead of the AD DS-

assigned cost to determine the least-cost routing path.

Note Use the Set-AdSiteLink –Identity ADsitelinkname –ExchangeCost value cmdlet toassign Exchange specific routing costs. You also can use the Set-AdSiteLink –IdentityADsitelinkname – MaxMessageSize value cmdlet to assign a maximum message size limitfor messages sent between AD DS sites.

Edge Configuration

In Exchange Server 2010, internal message routing is handled by the Hub Transport server role. In typical

deployments, we recommend that you deploy one or more Edge Transport servers in your perimeter

network to handle external message routing to and from the Internet. If you are not deploying an Edge

Transport server, you will need to configure the Hub Transport server to enable inbound and outbound

mail flow.

Note To enable inbound mail flow, configure an SMTP Receive connector to acceptanonymous connections on port 25 using a network interface that is accessible from theInternet. To enable outbound email flow, configure an SMTP Send connector with anaddress space of “*”that can use DNS or a smart host to send messages to the Internet.

If you are using the Hub Transport server to send and receive email from the Internet, you should

configure antivirus and anti-spam agents on the Hub Transport server.

We strongly recommend that you use an Edge Transport server role or some other SMTP relay server tosend and receive messages from the Internet. If you are using an SMTP gateway server other than an

Exchange Server 2010 Edge Transport server role, you still will need to configure the SMTP Send

connector and SMTP Receive connector. The only difference is that you should configure the SMTP

gateway server as the smart host on the SMTP Send connector, and accept only connections from the

SMTP gateway server on the SMTP Receive connector. As an alternative to managing your own Edge

Transport server role, you should also consider Exchange Hosted Services.

Once you have established the precise mechanism that you will use to handle external message routing,

you must consider the firewall settings between the corporate network, the perimeter network, and the

Internet. Server-to-server communications between the internal and perimeter network is over

Transmission Control Protocol (TCP) port 25. Likewise, communication between SMTP hosts on the

Internet is over TCP port 25. If you intend supporting remote clients that use POP or IMAP for mail

retrieval, you must consider providing SMTP connectivity to enable those clients to send email. It is

convention to use TCP port 587 to support client SMTP relaying; this port must be open on the external

firewall.




Global Catalog

Routing decisions made by the Hub Transport server are based on information stored in AD DS.

Consequently, you must ensure that each Hub Transport server has local access to a global catalog server

to ensure that it can perform the necessary routing queries.

Note Routing decisions made by Edge Transport servers are based on information storedin AD DS Lightweight Directory Services (AD LDS).

Exchange Online

If you rely solely on an Exchange Online messaging solution within your organization, then there is no

message routing within your organization. However, in hybrid deployment, in which both an on-premises

and an Online Exchange environment will coexist, messages flow from the Internet to your on-premises

Exchange servers. Where applicable, messages then flow from your on-premises Exchange servers to the

recipients’ mailboxes in the cloud. Consequently, implementing Exchange Online may introduce

additional message routing considerations. For example, you must deploy at least one Exchange Server

2010 SP1 Hub transport in your organization.

Note For further information about the changes that may be introduced by ExchangeOnline deployments, refer to Module 12.




Lesson 2

Designing the AD DS Infrastructure

Exchange Server 2010 depends on AD DS to store the Exchange Server 2010 specific configuration and

recipient information. This means that the AD DS design can have a significant impact on the Exchange

Server 2010 design, and on the performance of the Exchange Servers and messaging clients. This lesson

describes the AD DS requirements for Exchange Server 2010, and the implications that the AD DS design

has on the Exchange Server 2010 design.


• Identify the AD DS design owners.

• Design the AD DS forest.

• Design the AD DS domain.

• Design the AD DS sites for Exchange Server 2010.

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

• Design a domain controller placement strategy.

• List the considerations for modifying the current AD DS design.

•

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




Identifying the AD DS Design Owners

In most small or medium-sized organizations, the same administrator or administrator group is likely

responsible for the AD DS and Exchange Server 2010 infrastructure. Larger organizations often split these

roles between two different teams, who must work together because of the inter-relationship between the

AD DS and Exchange Server 2010 designs.

Note Exchange Server 2010 uses a split permissions model, which distinguishes betweenAD DS permissions and Exchange Server 2010 permissions. This makes it easier to separate

the administrative tasks between the two services. However, during the design phase, theAD DS and Exchange Server 2010 design teams must work together to ensure an optimalAD DS and Exchange Server 2010 design.

Who Are the AD DS Design Owners?

AD DS design owners may be an individual administrator, or group of administrators, who are responsible

for the overall AD DS infrastructure design and management. This group usually includes business

stakeholders and technical directory services specialists. Additionally, in most organizations, the design

owners include personnel responsible for the regular AD DS administration.

The AD DS design owners are responsible for any changes to the AD DS environment that may impact the

entire forest. For example, in most organizations, the design owners must approve all schema changes,

including new domains, or forests.

Note From an administrative point of view, the members of the forest Schema Adminsand Enterprise Admins groups can be considered the AD DS design owners. However, thesegroups should be used only to implement decisions that the actual design owners make.




Some organizations may have multiple teams of AD DS design owners. These organizations typically have

multiple AD DS forests. In most cases, the organization created these forests to establish security

boundaries between its different parts. Thus, each forest is likely to have a different group of owners.

If an organization has multiple teams of AD DS design owners, you may need to negotiate with all teams

during the Exchange Server 2010 design.

Importance of Working with the AD DS Design Owners

You must review the AD DS design as part of the Exchange Server 2010 design process, during which you

identify issues where the AD DS design is not optimized for Exchange Server 2010. When you identify

these issues, you then must work with the AD DS design owners to understand the current design’s

rationale, and to explore options for changing it.

If you identify issues with the AD DS design that may impact the Exchange Server 2010 design, you might

convince the AD DS design owners to modify the AD DS design. In other cases, the AD DS design owners

may have good reasons for why they cannot change the design, and you may need to modify the

Exchange Server 2010 design.




Designing the AD DS Forest

The AD DS forest design can impact the Exchange Server 2010 design significantly. The Exchange Server

2010 organization boundary is always the same as the AD DS forest boundary. Although you can deploy

Exchange Server 2010 in a multiple forest environment, it is complicated to design this type of Exchange

Server 2010 deployment.

AD DS Forest Options

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

•

No forest. If you do not deploy AD DS, you still can deploy an Exchange Server 2010 computerrunning the Edge Transport server role. The Edge Transport server role stores server configuration

information in Active Directory Lightweight Directory Services (AD LDS), rather than AD DS.

• Single forest. In this topology, you install Exchange Server in a single AD DS forest that spans the

entire organization. The same forest contains all user and group accounts, and all of the Exchange

Server 2010 configuration information.

• Resource forest. In this topology, you install Exchange Server 2010 in an AD DS forest that does not

contain the user and group accounts. Organizations that require a secure boundary between the

administration of AD DS and Exchange Server 2010 use this design. In a resource forest, you

designate one forest for accounts and authentication, and another for Exchange Server.

•

Cross-forest. In this topology, you install Exchange Server 2010 into multiple, different AD DS forests.Organizations that are highly distributed typically deploy this topology, as it enables different

organizational groups to retain management ownership of a forest. In this topology, each forest has a

complete Exchange Server 2010 deployment, and a unique Exchange Server organization object.




Exchange Server 2010 Design in a Single Forest Environment

The Exchange Server 2010 organization boundary must correlate to the AD DS forest boundary. This

means that the single forest deployment is the easiest Exchange Server 2010 deployment to configure

and manage. The single forest option offers the following advantages:

• Provides the richest set of email system features with the simplest deployment. In a single forest, you

do not need to complete any additional actions to enable features such as calendar access, publicfolder access, or a common Global Address List (GAL).

• Provides a streamlined administrative model. In a single forest, you do not need to configure trust

relationships or manage multiple Exchange Server 2010 administrative groups.

• Takes advantage of an existing AD DS structure. If you have already deployed AD DS, you can use the

existing structure, domain controllers, and the Global Catalog servers. Thus, you do not have to

deploy new servers.

A single forest has one disadvantage — administrators must determine how to share or divide

management responsibilities for AD DS and Exchange Server 2010 objects.

Best Practice A single forest means that the Exchange Server 2010 design anddeployment is significantly simpler than any other option. Therefore, you should always usea single forest unless there are highly compelling reasons to use multiple forests.

Exchange Server 2010 Design in a Resource Forest Environment

If your organization has multiple forests, the preferred method for implementing Exchange Server is to

create an Exchange resource forest. In this scenario, you set up a separate AD DS forest that you dedicate

to running Exchange Server 2010 and hosting mailboxes. This is known as an Exchange resource forest.

User accounts are contained in one or more forests, known as accounts forests.

A resource forest environment requires a one-way trust between the accounts forest and the Exchange

resource forest, so users in the accounts forest can access mailboxes in the Exchange resource forest. Each

mailbox that you create in the Exchange resource forest must have a disabled user object in the Exchangeresource forest and an enabled user account in the accounts forest. Additionally, the accounts forest

account must have access to log on to the linked mailbox that you create on the Exchange Server 2010

servers.

In a resource forest environment, the GAL is created in the Exchange Server 2010 resource forest. You may

not need to configure directory synchronization between the two forests if you configure all of the

required user properties in the Exchange resource forest. However, you will need to configure

synchronization between the forests if the accounts forest manages account attributes, or if you want to

automate configuration of the Exchange Server 2010 resource forest’s accounts and mailboxes.

Exchange Server 2010 Design in a Cross-Forest Environment

An organization with a cross-forest topology has multiple AD DS forests, each containing an Exchangeorganization. Unlike an Exchange Server 2010 resource forest topology, this design does not separate user

accounts from their mailboxes. Rather, a user account and its associated mailbox are in the same forest.

The Exchange organizations share no information, by default, which complicates a cross-forest design.

This means that information such as the GAL, availability data, and public folders, is not available between

the organizations. Additionally, information—including mailbox rules and delegate permissions—does not

move when you move users between the Exchange organizations.




Other issues that may arise with a cross-forest design include:

• Synchronization of availability information and public folder information between forests.

• Distribution groups from one forest are represented as a contact in the other forests, so you cannot

view the group’s members. Group membership does not expand until mail is sent to the forest

containing the group that the contact represents.

• Synchronization of directory objects between forests.

Exchange Online

Implementing Exchange Online may introduce a number of design changes, depending upon your

intended messaging configuration. If you plan to implement an Exchange hybrid deployment, consider

the following factors:

• Exchange hybrid deployments currently support single sign-on with only a single AD DS forest in

your on-premises AD DS. If you intend to implement a hybrid deployment, plan to implement a

single AD DS forest.

• Single label SMTP domain names are not supported. For example, although Contoso.com is

acceptable, Contoso is not. When planning your AD DS forest name, ensure that you avoid usingsingle label SMTP domain names.

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

deployments.

• To implement Active Directory Federation Services (AD FS) and single sign-on within your hybrid

deployment, the user principal name (UPN) of the forest root must be Internet-routable.

Consequently, you must give careful consideration to the internal AD DS forest domain name. For

example, Contoso.local or Contoso.Priv are not Internet-routable, while Contoso.com is. If your

current AD DS forest root UPN is not Internet-routable, it might be sufficient to change the UPN

suffix of all your existing users to a valid, registered, and routable domain suffix; this is a minor

change.




Designing the AD DS Domain

You can deploy Exchange Server 2010 in several different domain configurations. Although deploying

Exchange Server 2010 in a single domain environment may be the simplest design, there is very little

difference between deploying Exchange Server 2010 in a single domain, or in a single forest with multiple

domains.

Domain Deployment Options

A domain is a grouping of security principals and other objects that you administer collectively. You can

deploy domains in many configurations within different organizations. A single domain is the mostcommon domain deployment for small and medium-sized businesses, while larger organizations will have

multiple domains. Larger organizations often create domains based on organizational or geographic

distinctions. There are three primary domain configurations within a single forest:

• Single domain

• Multiple domains in the same AD DS tree. In this configuration, there is a single, top-level parent

domain, and all of the domains share a contiguous DNS namespace with that parent domain.

• Multiple domains in multiple AD DS trees. In this configuration, there are multiple top-level parent

domains with multiple DNS namespaces.

Note Regardless of how many domains and trees are in a forest, the first domain youdeploy in the forest always is the forest root domain. By default, this domain contains theSchema Master and Domain Naming Master roles, and the Schema Admins and EnterpriseAdmins security groups. Exchange Server uses the forest root as a location for its securitygroups.




Domain Design Implications for Exchange Server 2010

Provided that all domains are in the same AD DS forest, there are few design implications for the

Exchange Server 2010 implementation. In a single forest, all domains share the same schema,

configuration information, and global catalog information. This means that the domain boundaries are

transparent to Exchange Server 2010 services, and to Exchange recipients.

Note The functional level for all AD DS forest domains in which you deploy ExchangeServer 2010 must be Microsoft Windows® 2000 Server native mode or higher. One reasonis that Exchange Server 2010 allows only universal security groups or universal distributiongroups to be mail-enabled. Additionally, when you prepare the AD DS forest for theExchange Server 2010 installation, several Exchange universal security groups are createdthat set permissions on Exchange configuration objects. You can create universal securitygroups only in a domain that is in Windows 2000 Server native mode or higher.

There are two domain options that may impact the Exchange Server 2010 design in a multiple domain

environment:

• Create a dedicated domain for the Exchange Server 2010 servers. Some organizations may choose to

deploy a separate domain for all Exchange Servers and Exchange Server administrators.

One advantage of this is that the Exchange Server administrators also can be the dedicated domain

administrators. This means that the administrators can perform all administrative tasks on the

Exchange Server 2010 servers without requiring any administrative rights in other AD DS domains. To

manage recipients in other domains, you must add the Exchange administrators to the Exchange

Recipient Administrators group.

A primary disadvantage of deploying a dedicated Exchange Server 2010 domain is the extra cost that

results from deploying and managing an additional domain. You should deploy at least two domain

controllers for the Exchange Server 2010 domain, and this configuration may require additional

domain controllers for the domain in other locations.

Instead of deploying a dedicated domain for the Exchange Server 2010 servers, consider using theExchange Server 2010 Administrator role to delegate Exchange Server 2010 permissions. Users or

groups that you assign to this role receive full administrative permissions to the specific Exchange

Server 2010 computer.

• Deploy Exchange Server 2010 in a multi-tree forest. The main reason for deploying multiple trees in a

forest is to create separate namespaces for different organizational business units. This configuration

often requires separate SMTP addresses for the different business units’ users. By default, Exchange

Server 2010 creates SMTP addresses for all users based on the domain name of the forest root

domain. You can easily modify the default SMTP address assignment by creating additional accepted

domains, and then configuring email address policies to assign the required email addresses to the

different business units’ users.




Designing the AD DS Sites for Exchange Server 2010

In an organization with multiple locations, the AD DS site design has a significant impact on the Exchange

Server 2010 design. Exchange Server 2010 and messaging clients use AD DS sites to locate domain

controllers, and to define message routing.

How Exchange Server 2010 Uses AD DS Sites

Exchange Server 2010 is a site-aware application, which means that Exchange Server 2010 servers

are aware of which site they are in, and use this information while providing messaging services. The

Microsoft Exchange AD DS Topology service determines and updates the site attribute of the ExchangeServer 2010 object. Exchange Server 2010 servers also can retrieve and use the site information for other

Exchange Server 2010 servers.

The Exchange Server 2010 server roles use AD DS site membership information as follows:

• The Mailbox server role uses AD DS site membership information to determine which Hub Transport

servers are located in the same AD DS site as the Mailbox server. The Mailbox server then submits

messages for routing and transport to a Hub Transport server that is in the same site.The Client

Access server role uses AD DS site information to provide efficient access to user mailboxes. When the

Client Access server role receives a user connection request, it queries AD DS to determine which

Mailbox server is hosting both the user’s mailbox and the server’s site membership. If the Client

Access server that received the initial user connection is not in the same site as the user’s Mailbox

server, then the connection is redirected or “proxied” to a Client Access server in the same site as theMailbox server.




• The Hub Transport server role retrieves information from AD DS to determine the organization’s

internal and external mail routing. When a message is submitted to the Exchange Transport service,

the categorizer queries AD DS for information about where the message must be delivered. If

the recipient’s mailbox is on a Mailbox server in the same AD DS site as the Hub Transport server, it

delivers the message directly to that mailbox. If the recipient’s mailbox is on a Mailbox server in a

different AD DS site, then the message is relayed to a Hub Transport server in that site, which then

delivers it to the Mailbox server.The Unified Messaging server role uses AD DS site membership

information to determine which Hub Transport servers are located in the same AD DS site as the

Unified Messaging server. The Unified Messaging server submits messages for routing and transport

to a Hub Transport server in the same site as the Unified Messaging server. The Hub Transport server

also queries AD DS to match a telephone number — or other UM property such as the user’s Mailbox

server — to a recipient account. The Hub Transport server delivers the message to a Mailbox server

within its same AD DS site, or relays the message to another Hub Transport server, which then delivers

it to a Mailbox server that is outside the AD DS site.

Considerations for Designing Exchange Server 2010 Sites

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

•

Understand the rationale for the current AD DS site design. Organizations that have deployed AD DSwill already have implemented a site design that likely is based on AD DS design best practices. AD

DS sites are designed to decrease replication traffic between company locations and client logon

traffic across slow network connections, and to optimize site-aware applications, such as Distributed

File System (DFS).

• Consider using a centralized Exchange Server 2010 deployment. You do not have to deploy Exchange

Server 2010 servers in each AD DS site. If high bandwidth and reliable network connections link all of

your organization’s locations — regardless of the distance between offices — you should consider

implementing a centralized messaging system in which all Exchange Server 2010 servers are in one

central location. Because all Exchange Server 2010 servers — and other required services such as

domain controllers and DNS servers — are on the same fast network, this design will produce the best

Exchange Server 2010 performance. However, note that the most important reason not to implementa centralized design is if the network bandwidth between company locations cannot support it. If the

requirements for user experience and availability cannot be met by connecting to a central location,

you may have no choice but to position servers in the remote sites.

• Consider creating a dedicated AD DS site for Exchange Server 2010 servers. If you use a centralized

design for Exchange Server 2010 servers, or if you deploy several Exchange Server 2010 servers in a

data center, you should consider creating a dedicated AD DS site that contains all of the Exchange

Server 2010 servers in the location. You should also consider including domain controllers and Global

Catalog servers that are dedicated to providing directory services for the Exchange Server 2010

servers in that dedicated AD DS site. This design enables more predictable Exchange Server 2010

performance, because other clients are not using the domain controllers for authentication.Consider

modifying the AD DS site design. If the AD DS site configuration results in an inefficient Exchange

Server 2010 design, you may need to modify it. For example, you may configure two company

locations as a single site. If you need to deploy Exchange Server 2010 servers in both locations, you

should consider configuring separate sites to optimize domain controller access for Exchange Server2010 servers and messaging clients.




Deploying Exchange Server 2010 Servers in AD DS Sites

Exchange Server 2010 has a much stronger reliance on AD DS sites than previous Exchange Server

versions. Therefore, you must consider the AD DS site configuration when you design the Exchange Server

2010 deployment.

Considerations for Deploying Exchange Server 2010 Servers in AD DS Sites

Consider the following information when deciding whether to deploy Exchange Server 2010 servers in an

AD DS site.

•

The first decision you must make when designing the Exchange Server 2010 deployment is whetherto place a server running the Mailbox server role in the AD DS site. If there are a sufficient number of

users in the company location, and you do not want their client access traffic to cross a network link

to another location, then you must place one or more Mailbox servers in the site.

• If you place a Mailbox server in the site, you also must place a Hub Transport server role and Client

Access server role in the site. At least one Hub Transport server must be available in the site to route

messages to the site’s Mailbox server. You also must deploy a Client Access server in the site to enable

users to access Office Outlook 2007 or Office Outlook 2010 client features, including Autodiscover

and Availability services, or to access their mailboxes via Outlook Web App or Outlook Anywhere.

• You should deploy a Unified Messaging server in the site if you are using the Unified Messaging

features, and if you deploy a supported Voice over IP (VoIP) gateway in the site.

Note You can deploy all Exchange Server 2010 server roles—except the Edge Transportserver and clustered mailbox servers—on the same server. This means that in a small site, asingle computer can hold all of the required server roles.




Designing a Domain Controller Placement Strategy

As part of the AD DS site design, you must also consider the domain controller and global catalog server

placement. The location and capacity of these domain controllers can impact Exchange Server 2010 and

messaging client performance significantly.

How Exchange Servers Locate Domain Controllers

Like other AD DS clients, Exchange Server servers locate domain controllers and global catalog servers by

querying DNS for the Service locator (SRV) resource records associated with each domain controller and

global catalog server. The service (SRV) resource records for domain controllers and global catalog serversare registered with different variations to enable locating domain controllers and global catalog servers

using several methods. One method in which the DNS records are registered, is by site name. This enables

computers running Exchange Server 2010 to find domain controllers and global catalog servers in the

local AD DS site.

Each Exchange Server 2010 server is configured dynamically with its site each time it authenticates to AD

DS. As part of the authentication process, the site name is stored in the registry. If the computer running

Exchange Server 2010 is a domain controller, the server determines its site by comparing its IP address to

the site configuration information that the AD DS configuration partition stores.

Planning the Domain Controller and Global Catalog Placement

Consider the following when you are planning the domain controller and global catalog placement:

• Deploy at least one domain controller and global catalog server in each site that contains an

Exchange Server 2010 server. To ensure a positive user experience, all Exchange Server servers and

Office Outlook users must have fast access to a global catalog server.




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

•

For security and performance reasons, you should not run Exchange Server 2010 on computers that

also function as Windows domain controllers, as this configuration may cause performance issues in

all but the smallest deployments.

Note You cannot promote a member server running Exchange Server 2010 to become adomain controller. Once you install Exchange Server 2010, changing its role from a memberserver to a domain controller, or vice versa, is not supported.

• As a general guideline, you should implement Exchange processors to global catalog server

processors in an 8:1 ratio in each site, assuming that the processors are similar models and speeds. In

some situations, however, if AD DS includes a large number of users or you have large distribution

lists, you may need more global catalog servers.




Discussion: Considerations for Modifying the Current AD DS Design

The Exchange design may require some AD DS changes. However, it can be difficult to modify the AD DS

design in a large, complex organization.

Discussion Questions

Based on your experience, consider the following questions:

Question: What impact might result from changing the AD DS design in a large, complex

company?

Question: How can you balance the complications of modifying the current AD DS design

with the optimal Exchange Server-based design?

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

design?




Planning for AD DS Preparation to Support the Exchange Server 2010Deployment

To install Exchange Server 2010, you must run the Exchange Server 2010 setup command to prepare the

AD DS forest for the installation. In smaller organizations, it is quite probable that a single individual will

prepare AD DS to support Exchange Server when deploying the first Exchange Server. In larger

organizations, different teams of support staff may be involved in the various stages of the preparation

process.

You can use the setup command with the following switches:

Setup switch Explanation

/PrepareAD /OrganizationName:”organizationname”

• Prepares the global Exchange objects in AD DS, creates the ExchangeUniversal Security Groups in the root domain, and prepares the currentdomain.

• Must be run by a member of the Enterprise Admins group.

/PrepareLegacyExchangePermissions

• Is necessary if the organization contains Exchange Server 2003 servers.

• Modifies the permissions assigned to the Enterprise Exchange Serversgroup to allow the Recipient Update Service to run.

• Must be run by a member of the Enterprise Admins group.

/PrepareSchema•

Prepares the schema for the Exchange Server 2010 installation.• Must be run by a member of the Enterprise Admins and Schema Admins

groups.




(continued )

Setup switch Explanation

/PrepareDomain

/PrepareDomaindomainname

/PrepareAllDomains

• Prepares the domain for Exchange Server 2010 by creating a new globalgroup in the Microsoft Exchange System Objects container calledExchange Install Domain Servers.

•

Is not required in the domain where /PrepareAD is run.

• Can prepare specific domains by adding the domain’s FQDN, or prepareall domains in the forest.

• Must be run by a member of the Enterprise Admins and Domain Adminsgroups.

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

Options for Preparing AD DS

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

• In an organization that is not running an earlier Exchange Server version, and which has a single

domain in the AD DS forest, you do not need to prepare AD DS before installing the first Exchange

Server. In this scenario, you can just install Exchange Server 2010, and all of the AD DS schema

changes are implemented during the installation.

• If the user account that you are using to update the schema is a member of the Schema Admins and

the Enterprise Admins group, you do not need to run /PrepareLegacyExchangePermissions and

/PrepareSchema before running /PrepareAD. If your account has the necessary permissions, the

/PrepareAD process also configures the legacy permissions and makes the required schema changes.

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

•

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

• Prepares the permissions if /PrepareLegacyExchangePermissions has not been run, and the command

is run by an Enterprise Admins group member.

• Creates the Microsoft Exchange container in the Configuration partition in AD DS, and populates the

container with all the child containers required to install Exchange Server 2010 computers.

• Creates a new organizational unit (OU) in the AD DS domain named Microsoft Exchange Security

Groups, and then creates the security groups that are used to assign permissions in the Exchange

organization.

Note The security groups that are created in the Microsoft Exchange Security Groups OUare management role groups that use role-based access control (RBAC) to assignpermissions in the Exchange organization.




Lesson 3

Designing the DNS Infrastructure

Name resolution is an important foundation network service. Without it, many applications would be

unable to function correctly. This is true of Exchange Server 2010, which uses DNS in many ways. This

lesson explores the considerations surrounding DNS when you are planning to implement Exchange

Server 2010.


•

List the considerations for DNS.

• Describe split DNS.

• Design a DNS infrastructure for Exchange Server.




Considerations for DNS

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

Correctly Configured DNS

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

• Ensure that all host records are correctly registered. Use of a dynamic name service — such as

Windows DNS — ensures this is achieved. If Exchange Server 2010 servers do not correctly register

their names and the services that they are running, they will not be contactable. By default, Exchange

Server 2010 registers with and performs queries against the DNS server configured on the TCP/IPproperties of the installed network adapter. You can change this default behavior by modifying the

Internal DNS Lookups and External DNS Lookups settings on the Exchange Server 2010 property

sheet by using the Exchange Management Console.

• Configure the DNS suffix for each Exchange Server. Exchange servers supporting the Mailbox, Hub

Transport, Client Access, or Unified Messaging roles must be members of an AD DS domain; their

FQDN is automatically derived from the local hostname appended with the AD DS domain name.

However, it is important to remember you must manually configure the primary DNS suffix of the

Edge Transport servers in your perimeter network to match your currently configured default

authoritative accepted domain.

• Configure Edge Transport server DNS resolver settings. The Edge Transport server sits in the

perimeter network and may be installed with two network interface cards (NICs), one of which isInternet-facing, the other of which is internally connected. You must configure the network interface

that is connected to the external network to use a public DNS server for name resolution. This enables

the Edge server to resolve SMTP domain names to mail exchanger (MX) resource records, and route

mail to the Internet. You must configure the internal NIC to use a DNS server in the perimeter

network.




• If your Edge Transport server has a single NIC, use the Internal DNS Lookups tab and the External

DNS Lookups tab to configure the appropriate DNS settings to enable appropriate name resolution.

You can access the DNS settings for your Edge Transport server by using the Exchange Management

Console, and then viewing the properties of your Edge Transport server.

• Ensure that the Edge Transport servers and the Hub Transport servers are able to use DNS host

resolution to locate each other. You must manually create host records for the Hub Transport serversin a forward lookup zone on the DNS server in the perimeter network. Additionally, you must create

host records for Edge Transport servers in a forward lookup zone on the internal DNS servers.

• Avoid using single label domains. As discussed previously, this has long been a recommendation from

Microsoft, but with Exchange hybrid deployments, single label domain names are not supported.

Note In earlier Exchange Server versions, the Windows Internet Name Service (WINS) wasrequired in order to support multi-domain environments. This is no longer a requirement inExchange Server 2010.

Disjoint Namespace

In addition to ensuring the preceding steps have been performed, you must also consider the impact of a

disjoint DNS namespace on the Exchange organization. Typically, the primary DNS suffix of the computers

in an AD DS domain is the same as the DNS domain name. For example, in the domain Adatum.com,

computers will typically have a primary DNS suffix of Adatum.com. However, you may require the domain

name and the primary DNS suffix to be different from one another; this is called a disjointed namespace.

For instance, following a merger or acquisition, you may have a topology with a disjointed namespace.

In Exchange Server, there are two supported disjointed namespace scenarios:

• The domain controller is disjointed. Computers that are members of this domain can be either

disjointed, or not disjointed. In this scenario, the primary DNS suffix of the domain controller is not

the same as the DNS domain name, but computers in the domain — including Exchange servers and

Office Outlook client computers — can have a primary DNS suffix that either matches the primary DNS

suffix of the domain controller, or matches the DNS domain name.

• A member computer in an AD DS domain is disjointed, even though the domain controller is not. In

this scenario, the primary DNS suffix of a computer on which Exchange Server 2010 is installed does

not match the DNS domain name; thus the member computer is disjointed. Member computers that

are running Office Outlook can have a primary DNS suffix that either matches the primary DNS suffix

of the disjointed Exchange server, or matches the DNS domain name.

Note To support either of these scenarios, you must modify the msDS-AllowedDNSSuffixes AD DS attribute on the domain object container. You must add all ofthe DNS suffixes to the attribute. In addition, to make sure that the DNS suffix search listcontains all DNS namespaces that are deployed within the organization, you must configure

the search list for each computer in the domain that is disjointed.




DNS Required Records

In order to support messaging with third parties on the Internet, it is necessary for you to create and

configure two DNS namespaces:

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

network.

• The external namespace is used by third parties on the Internet to locate your servers so that they

may route messages to your organization.

To enable Internet messaging functionality, you must make a number of configuration changes to your

external DNS zone. These changes include:

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

SMTP hosts.

• Adding a Sender Policy Framework (SPF) resource record in the external DNS zone that defines which

of your SMTP hosts is allowed to send email on behalf of your organization.




What Is Split DNS?

If you want to have a matching internal and external DNS namespace, that can pose certain problems;

however, split DNS can provide a solution to these problems. For example, in a non-split DNS

configuration for the domain Adatum.com, you might have a DNS zone that looks like the following

example:

Host Record type IP address

www A 131.107.1.200

Relay A 131.107.1.201

Webserver1 A 192.168.1.200

Exchange1 A 192.168.0.201

When a client computer on the Internet wants to access the SMTP relay using the published name of

relay.adatum.com, it queries the DNS server that returns the result 131.107.1.201. The client then

establishes a connection over SMTP to that IP address.

However, the client computers on the corporate intranet also use the published name of

relay.adatum.com. The DNS server returns the same result — a public IP address of 131.107.1.201. The

client now attempts to establish a connection to the returned IP address by using the external interface ofthe publishing computer. Depending upon the client configuration, this may or may not be successful.

By configuring two zones for the same domain name — one on each of two DNS servers — you can avoid

this problem.




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


www CNAME Webserver1.adatum.com

Relay CNAME Exchange1.adatum.com

Webserver1 A 192.168.1.200

Exchange1 A 192.168.0.201

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


www A 131.107.1.200

Relay A 131.107.1.201

MX Relay.adatum.com

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

the appropriate internal or external IP address.




Designing a DNS Infrastructure for Exchange Server

Your DNS infrastructure must be capable of meeting your Exchange Server organization’s needs. These

needs include:

• Server-to-server resolution. When any Exchange Server needs to communicate with any other

Exchange Server, they must be able to determine the appropriate IP address for a specific host name.

For example, if a Hub Transport server wishes to route mail to another Hub Transport server in

another site, it must first determine which computer is providing the Hub Transport server role in the

remote site. Then, it must resolve the returned name into the appropriate IP address.

• Client-to-server resolution. When client computers—either attached to the internal network or

connected to the Internet—want to connect to a server, they must be able to resolve the designated

name to the appropriate IP address. For example, a client computer using Outlook Web Access and

provided with the external URL of a Client Access server in the user’s site, must resolve that name to

the external IP address of the publishing host in the perimeter network.

• Outbound delivery from the Hub Transport server to the Edge Transport server. To ensure proper

routing of messages from the internal network to the Edge Transport server in the perimeter network,

the Hub Transport servers must be able to resolve the FQDNs of the Edge Transport servers as

defined in the Edge Subscription, to the appropriate IP address in the perimeter network. You must

add these records to the internal DNS zone.

•

Outbound delivery from the Edge Transport Server to the Internet. To ensure delivery of email fromthe Edge Transport Server to the Internet, you must configure name resolution on the Edge Transport

servers. Configure the use of either a public DNS server, or configure an internal DNS server with

appropriately configured forwarding.

• Inbound delivery to the Edge Transport Server from the Internet. To ensure successful delivery of

email from the Internet to the Edge Transport servers, you must configure appropriate MX and host

(A or AAAA) resource records in a publicly accessible DNS server. This enables third-party

organizations to locate your Edge Transport servers.




• Inbound delivery from the Edge Transport Server to the Hub transport server. In order to ensure

successful delivery of email from the Edge Transport servers to the Hub Transport servers, you must

configure the Edge Transport servers’ internal NIC to use a DNS server on the perimeter network that

hosts a zone to which you have added the necessary Hub Transport server host records.

Note By default, in Exchange hybrid deployments, messages are routed to the on-premises Exchange servers and then, where necessary, routed onwards to the ExchangeOnline environment for those users whose mailboxes are hosted online. However, if youwish to have email routed primarily to the Exchange Online environment, perhaps to takeadvantage of the message hygiene services provided by Forefront Online Protection forExchange (FOPE), you can configure this behavior in the Online Portal, or in your DNS MXrecords, or within FOPE.




Lesson 4

Planning Exchange Server Administration

To ensure that your Exchange organization functions optimally, you must secure the organization

properly. Part of the process of securing the Exchange organization involves planning and implementing

an appropriate administrative model. This enables you to determine which users can perform specific

administrative tasks.


•

Describe Exchange Server 2010 permissions.

• Describe the split permissions model.

• Describe the default Role Based Access Control configuration.

• Design a custom management delegation strategy.

• Design a management tool strategy.

• Manage Exchange Server 2010.




Exchange Server 2010 Permissions

Exchange Server 2010 implements a permissions model known as Role Based Access Control (RBAC). The

RBAC permissions model defines which administrative tasks specific users can perform. With RBAC, you no

longer have to modify and manage access control lists (ACLs) on Exchange Server or AD DS objects. In

Exchange Server 2010, RBAC controls the administrative tasks that users can perform, and the extent to

which they can administer their own mailbox and distribution groups.

RBAC assigns permissions to users in two primary ways, depending on whether the user is an

administrator or end user:

• Management role groups. RBAC uses management role groups to assign permissions to

administrators. These administrators may require permissions to manage the Exchange Server

organization or some part of it. Some administrators may require limited permissions to manage

specific Exchange Server features, such as compliance or specific recipients. To use management role

groups, add users to the appropriate built-in role group, or to a custom role group. RBAC assigns

each role group one or more management roles that define the precise permissions that RBAC grants

to the group. Management role groups use several underlying components to define how RBAC

assigns permissions:

• Role holder. A role holder is a user that you can add to a role group. When a mailbox becomes a

role-group member, RBAC grants it all of the permissions that the management roles provide. To

add mailboxes to a role group, you can either add the user account to the group in AD DS, or use

the Add-RoleGroupMember cmdlet.

• Management role group. The management role group is a universal security group that contains

mailboxes that are role group members. Management role groups are assigned to management

roles. The combination of all the roles assigned to a role group defines everything that users

added to that role group can manage in the Exchange Server organization.




• Management role. A management role is a container for a group of management role entries.

These entries define the tasks that users can perform if RBAC assigns them the role using

management role assignments.

• Management role entries. A management role entry is a cmdlet—including its parameters—that

you add to a management role. By adding cmdlets to a role as management role entries, you are

granting rights to manage or view the objects associated to that cmdlet.• Management role assignment. A management role assignment assigns a management role to a

role group. Once you create a management role, you must assign it to a role group so that the

role holders can use it. Assigning a management role to a role group grants the role holders the

ability to use the cmdlets that the management role defines.

• Management role scope. A management role scope is the scope of influence or impact that the

role holder has once RBAC assigns a management role. When assigning a management role, use

management scopes to target which objects that role controls. Scopes can include servers, OUs,

recipient objects, databases, and more.

Note Database scopes were introduced in Exchange Server 2010 SP1 enabling you to

target specific databases based on database lists or filterable database properties.

• Management role assignment policies. Management role assignment policies are used to assign 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. When you create a role assignment policy, you define everything

users can do with their mailboxes. For example, a role assignment policy may allow users to set

display names, set up voice mail, and configure Inbox rules. Another role assignment policy might

allow users to change their company information, such as addresses or phone numbers, use text

messaging, and set up distribution groups. Every user with an Exchange Server 2010 mailbox—

including administrators—receives a role assignment policy by default.

•

Direct User Role Assignment. You also can use Direct User Role Assignment to assign permissions.

Direct User Role Assignment is an advanced method for assigning management roles directly to a

user or Universal Security Group, without the need to use a role group or role assignment policy.

Direct User Role Assignment is useful when you need to provide a granular set of permissions to a

specific user only. However, we recommend that you avoid using Direct User Role Assignment, as it is

significantly more complicated to configure and manage.

Question: What requirements does your organization have for assigning Exchange Server

permissions? Does your organization use a centralized or decentralized administration

model? What special permissions will you need to configure?




What Are Split Permissions?

In small organizations, it is often the case that the same group of people is responsible for administering

AD DS and Exchange Server. In larger organizations, it is usual to separate the management of AD DS

from other applications, including Exchange Server.

To help address this need for administrative separation, Exchange Server 2010 introduced split

permissions, enabling a degree of separation for the administration of these two facets of your messaging

infrastructure.

•

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

appropriate role groups can create security principals.

• Active Directory split permissions. Permissions to create security principals in the AD DS domain

partition are completely removed from any Exchange Server user, service, or server. No option is

provided in RBAC to create security principals. Creation of security principals in AD DS must be

performed using AD DS management tools. You can choose to implement Active Directory split

permissions during Setup.

Note Active Directory split permissions was introduced in Exchange Server 2010 SP1. Youmust run setup to enable Active Directory split permissions.

If your organization requires a split permissions model, use the RBAC split permissions model; this model

provides more flexibility while providing almost the same administrative separation as Active Directory

split permissions.

Note Exchange servers and services can create security principals in the RBAC splitpermissions model; this is not true with Active Directory split permissions.




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

• Your organization requires that security principals, such as users and groups, be created using only

the AD DS management tools or only by users who are granted specific permissions in AD DS.

• You want to completely separate the ability to create security principals from those who manage the

Exchange organization.

• You want to perform all distribution group management, including creation of distribution groups

and adding and removing members of those groups, using AD DS management tools.

• You don't want Exchange servers, or third-party programs that use Exchange on their behalf, to

create security principals.




What Is the Default Role Based Access Control Configuration?

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

administrative permissions to user groups.

Built-in Role Groups

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

assignments to or from most role groups.

Role group Description

OrganizationManagement

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

View-Only OrganizationManagement

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

Recipient Management Role holders have access to create or modify Exchange 2010 recipientswithin the Exchange Server organization.

UM Management Role holders can manage the Unified Messaging features within theorganization, such as Unified Messaging server configuration, mailboxproperties, prompts, and auto-attendant configuration.

Discovery Management Role holders can perform searches of mailboxes in the Exchangeorganization for data that meets specific criteria.

Records Management Role holders can configure compliance features, such as retention policytags, message classifications, and transport rules.

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




(continued )

Role group Description

Help Desk Role holders can perform limited recipient management.

Public Folder

Management

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

Delegated Setup Role holders can deploy previously provisioned Exchange servers.

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

Management Role Assignment Policies

Management role assignment policies associate end-user management roles with users. You do not

configure administrative permissions with management role assignment policies. Rather, you use

management role assignment policies to configure what changes users can make to their mailbox settingsand to distribution groups that they own. Every user with an Exchange Server 2010 mailbox receives a role

assignment policy, by default. You can:

• Decide which role assignment policy to assign by default.

• Choose what to include in the Default Role Assignment Policy.

• Override the default policy for certain mailboxes.

• Choose not to assign role assignment policies by default.

Role Assignment Components

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

mailboxes:

• Mailbox. Mailboxes are assigned a single role assignment policy. When a mailbox is assigned a role

assignment policy, the policy is applied to the mailbox. This grants the mailbox all of the permissions

that the management roles provide.

• Management role assignment policy. The management role assignment policy is an object in

Exchange Server 2010. Users are associated with a role assignment policy when you create their

mailboxes or change the role assignment policy on their mailboxes. The combination of all the roles

included in a role assignment policy defines everything that associated users can manage on their

mailboxes or distribution groups.

• Management role assignment. Management role assignments link management roles and role

assignment policies. Assigning a management role to a role assignment policy grants users the abilityto 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.




Designing a Custom Management Delegation Strategy

Exchange Server 2010 includes a Default Role Assignment Policy that provides end users with the most

commonly used permissions. For most organizations, you do not need to modify the configuration.

However, you can change the management role assignment policy if your organization has specific

requirements regarding how users can interact with their mailboxes or groups.

Working with Assignment Policies

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

•

Change the default permissions on the Default Role Assignment Policy by adding or removingmanagement roles. For example, if you want to enable users to perform additional tasks on their

mailboxes, you can identify the management role that grants them the necessary permissions, and

add the role to the Default Role Assignment Policy.

• Define a new role assignment, and then configure that role assignment to be the default for all

mailboxes. Use the Set-RoleAssignmentPolicy cmdlet to replace the built-in Default Role Assignment

Policy with your own. When you do this, RBAC assigns the role assignment policy that you specify to

new mailboxes, by default.

Note When you change the Default Role Assignment Policy, RBAC does not assign thenew Default Role Assignment Policy automatically. You will need to use the Set-Mailbox

cmdlet to update previously created mailboxes to the new Default Role Assignment Policy.

• Configure additional role assignment policies, and assign the policies to a mailbox manually. Use the

RoleAssignmentPolicy parameter on the New-Mailbox, Set-Mailbox, or Enablemailbox cmdlets. When

you assign an explicit role assignment policy, the new policy takes effect immediately and replaces

the previously assigned explicit role assignment policy. If you have many different user groups with

special needs, you can create role assignment policies for each group.




Configuring a Custom Role Group

In addition to the built-in role groups, you also can create custom role groups to delegate specific

permissions within the Exchange Server organization. Use this option when your ability to limit

permissions is beyond the scope of the built-in role groups.

RBAC enables complete flexibility in how you assign permissions in an Exchange Server 2010 environment.

For example, RBAC enables you to assign permissions to a group of administrators in a branch office whoonly need to manage recipient tasks for branch-office users, and mailboxes on branch office Mailbox

servers. To implement this scenario, you would:

1. Create a new role group, and then add the branch office administrators to the role group. You can

use the New-RoleGroup cmdlet to create the group. When you create the group, you must specify

the management roles. Additionally, you also can specify the management scope for the role.

2. Assign management roles to the branch office administrators. To delegate permissions to a custom

role group, you can use one or more of the default built-in management roles, or you can create a

custom management role that is based on one of the built-in management roles. Exchange Server

2010 includes approximately 70 built-in management roles that provide granular levels of

permissions. To view a complete list of all the management roles, use the get-managementrole

cmdlet. To view detailed information about a management role, type get-managementrole rolename| FL, and then press Enter.

Note You also can configure a new management role rather than use one of the existingmanagement roles. To do this, use the New-ManagementRole cmdlet to create a custommanagement role based on one of the existing management roles. You can then add andremove management role entries as needed. By default, the new management role inheritsall of the permissions assigned to the parent role. You can remove permissions from the roleas necessary, by using the Remove-managementroleentry cmdlet. However, it can becomplicated to create a new management role or remove unnecessary management roleentries, so we recommend that you use one of the existing roles whenever possible.

3. Identify the management scope for the management role. For example, in the branch office scenario,

you could create a role assignment with an OU scope that is specific to the branch office OU.

4. Create the management role group using the information that you collect. Use the New-RoleGroup

cmdlet to create the link between the role group, the management roles, and the management

scope. For example, consider the following cmdlet:

New-RoleGroup – Name BranchOfficeAdmins –roles “Mail Recipients”, “Distribution Groups”,

“Move Mailboxes”, “Reset Password”, “Mail Recipient Creation” –User BranchOfficeAdmins

–RecipientOrganizationalUnitRestriction Contoso.com/BranchOffice.

It does the following:

•

Creates a new role group named BranchOfficeAdmins.

• Assigns the Mail Recipients, Distribution Groups, Move Mailboxes, Reset Password, and Mail

Recipient Creation management roles to the BranchOfficeAdmins role group.

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

domain.




Designing a Management Tool Strategy

All Exchange Server administration tools, including Exchange Management Console, Exchange

Management Shell, and Exchange Control Panel, use RBAC to determine user permissions. Therefore,

permissions are consistent regardless of which tool you use; this is because when you define RBAC

permissions, you can define precisely which Exchange Management Shell cmdlets a user can run, and

which objects the user can modify.

Exchange Management Console

The Exchange Management Console uses the Microsoft Management Console (MMC) 3.0 paradigm of afour-pane environment. These four components are the console tree, the result pane, the work pane, and

the action pane. The Exchange Management Console’s unique feature is its console tree, which has four

main nodes: Organization Configuration, Server Configuration, Recipient Configuration, and Toolbox.

These four nodes have four distinct functions:

• The Organization Configuration node contains all configuration options for each Exchange Server role

that affects the messaging system’s functionality. This node allows you to configure database

management, ActiveSync policies, journal and transport rules, message-formatting options, and email

domain management.

• The Server Configuration node contains the configuration options for each Exchange Server in the

organization. Settings that you can manipulate include: server diagnostic-logging settings, product-

key management, and per-server Outlook Web App configuration.• The Recipient Configuration node contains the configuration and creation tasks for mailboxes,

distribution groups, and contacts. You also can use it to move or reconnect mailboxes.

• The Toolbox node contains 12 utilities and tools that you can use to monitor, troubleshoot, and

manage Exchange Server. These tools include Exchange Best Practices Analyzer, Public Folder

Management Console, Messaging Tracking, and Database Recovery Management.




You also can use the Exchange Management Console to manage both onsite and hosted Exchange Online

environments.

Note The root node of the console tree now also includes two tabs in the Content pane.The Organizational Health tab displays a report on the overall status of the Exchangeorganization with information on the number of databases, servers and Client AccessLicenses that have been deployed. The Customer Feedback tab is where both the CustomerExperience Improvement Program can be enabled, and links to Exchange documentationcan be found.

Exchange Management Shell

The Exchange Management Shell and the Exchange Management Console run on top of Windows

PowerShell™ version 2.0 command-line interface. They use cmdlets, which are commands that run within

Windows PowerShell. Each cmdlet completes a single administrative task, and you can combine cmdlets

to perform complex administrative tasks.

In Exchange Management Shell, there are approximately 700 cmdlets that perform Exchange Server

management tasks, and even more non-Exchange Server cmdlets that are in the basic WindowsPowerShell shell design.

Exchange Management Shell is more than just a command-line interface that you can use to manage

Exchange Server 2010. Exchange Management Shell is a complete management shell that offers a

complex and extensible scripting engine that has sophisticated looping functions, variables, and other

programmatic features so that you can create powerful administrative scripts quickly.

Windows Remote PowerShell

Exchange Server 2010 builds on the success of Exchange Server 2007 usage of Windows PowerShell 1.0,

by leveraging its remote Windows PowerShell functionality within Windows PowerShell 2.0. By using the

remote Windows PowerShell feature, Exchange Server 2010 includes many new features.

Exchange Control PanelThe Exchange Control Panel is a new feature in Exchange Server 2010. It enables end users and Exchange

Server specialists to manage many aspects of the messaging environment from a secure web page that

includes inbox rules, public groups, account information, call answering rules, and retention policies.

You can assign permissions to Exchange Control Panel users by assigning and customizing one of the

preconfigured RBAC groups.

The Exchange Control Panel runs on the Client Access servers, and you access it either from the Options

menu in Outlook Web App, or by visiting https://Server/ecp.

The Exchange Control panel supports the following user roles:

• End users

• Outlook Web App options

• Email subscriptions

• Group management

• Mobile phone management




• Exchange administrators and specialists

• Mailbox creation and management

• Distribution group management

• Legal discovery

•

Message tracking

• Role assignment user interface

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




Demonstration: How to Manage Exchange Server 2010

In this demonstration, you will review how to navigate the Exchange Management Console, and use it to

manage Exchange Server. You will also review how to create a mailbox, and how to use Windows

PowerShell command-line interface scripting and pipelining to change the address on multiple mailboxes.

The instructor also will describe basic cmdlet aliases. Finally, your instructor will demonstrate the Exchange

Control Panel.

Use the Exchange Management Console

1.

Open the Exchange Management Console.2. Note the console’s layout: console tree on the left, content pane in the middle, and actions pane on

the right.

3. Notice that the console tree has four nodes: Organization Configuration, Server Configuration,

Recipient Configuration, and Toolbox.

4. Expand each console tree section to view the available nodes.

5. In the console tree, expand Organization Configuration, click Mailbox, and then view the

information available in the Content pane.

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

the Content pane.

7. In the console tree, expand Recipient Configuration, click Mailbox, and then view the information

in the Content pane.




Use the Exchange Management Shell

The instructor will run the following cmdlets:

• Get-Mailbox

• Get-Mailbox | Format-List

•

Get-Mailbox | fl

• Get-Mailbox | Format-Table

• Get-Mailbox | ft Name, Database, IssueWarningQuota

• Get-Help New-Mailbox

• Get-Help New-Mailbox -detailed

• Get-Help New-Mailbox -examples

• $Temp = "Text"

• $Temp

•

$password = Read-Host "Enter password" –AsSecureString

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

Database 1" -Name ChrisAshton -OrganizationalUnit Users -Password $password -FirstName

Chris -LastName Ashton -DisplayName "Chris Ashton" -ResetPasswordOnNextLogon $true

Use the Exchange Control Panel

The instructor will perform the following steps:

1. Open Exchange Control Panel as a standard user.

2.

Open Exchange Control Panel as an administrator, and review and compare the settings.

Question: Does the Exchange Management Console organization seem logical to you? Why

or why not?

Question: Does the Exchange Management Console have the same functionality as it did in

previous Exchange Server versions? What is different about this version?

mailto:[email protected]







Lab: Designing Exchange Server Integration with theCurrent Infrastructure

Lab Setup

For this lab, you will use the available virtual machine environment. Before beginning the lab, you must



2.

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

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

Contoso\Administrator using the password Pa$$w0rd.

Lab Scenario

Contoso, Ltd is planning to deploy Exchange Server 2010. You are a messaging consultant from A. Datum

Corporation, and have been tasked with verifying that the existing network infrastructure is suitable to

support Exchange Server 2010.

Once you have determined that the prerequisites are met, you will prepare the AD DS forest so that the

server deployment team can begin the Exchange Server 2010 deployment.

Note Your instructor may choose to perform this lab as a group discussion rather than anindividual activity.




Exercise 1: Evaluating the Current Network Infrastructure at Contoso

Scenario

In this exercise, you will examine the current network infrastructure. You will determine whether it is

suitable to support Exchange Server 2010, and make recommendations about any necessary changes.

The main tasks for this exercise are as follows:1. Review the supplied documentation.

2. Answer questions relating to the documentation.

3. Complete a report that provides information about necessary changes required to the network and

AD DS infrastructure, to enable support for Exchange Server 2010.

Task 1: Review the supplied documentation

• Review the diagram and read the supporting documentation.

Sites




Supporting Documentation

Email thread of correspondence with Ed Meadows:

Ed Meadows

From: Jason Carlson [[email protected]]

Sent: 1 February 2010 14:00

To: [email protected]: Re: Contoso Exchange Server 2010 project

Thanks; that’s really helpful.

Yes, we can delegate tasks to specified individuals. We’ll discuss what you need when I get there. See you

next week.

Jason.

----- Original Message -----

From: Ed Meadows [[email protected]]

Sent: 31 January 2010 13:30

To: [email protected]

Subject: Contoso Exchange Server 2010 project

Attachments: Contoso.vsd

Jason,

Please find attached the Visio diagram of our three AD DS sites. All three sites are connected, logically,

with the DefaultIPSiteLink site link, and with default values.

The New York City office is our head office, and supports around 500 users. Branch Office 1 has 100 users,

while the other branch has only 30 users – hence the RODC. Our only Internet connection is from the NYC

offices. We have a couple of DCs there.

Our namespace is pretty straightforward; Contoso.com is the only domain.

We’d like to be able to delegate administration of specified Exchange administration tasks to couple of

individuals out at Branch Office 1. Is that easy to do? I hope all this helps, and see you here in New York

next week.

Ed




Task 2: Answer questions relating to the documentation

Question: Based on the supplied information, is there anything you might need to

reconfigure before deploying Exchange Server?

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

Task 3: Complete a report that provides information about necessary changes required

to the network and AD DS infrastructure to enable support for Exchange Server 2010

• Complete the following proposal document by answering the questions.

Contoso Exchange Server network infrastructure


Document Author

Date

Jason Carlson

11th February 2010

Requirement Overview

To determine what changes, if any, are required to the existing network and AD DS infrastructure tosupport Exchange Server 2010.

Proposals

Question: The internal and external DNS zone names are the same for Contoso — i.e. Contoso.com.What issue does this raise for clients connecting to their mailboxes using Outlook Web App fromtheir home computers?

Question: What DNS records must you configure in the external Contoso.com DNS zone?

Question: How do you propose to support the messaging needs of users in Branch Office 2?

Question: What messaging client will you deploy to Branch Office 2?

Question: What server role must you consider deploying in the head office to facilitate inboundand outbound messaging to and from the Internet?

Question: How many Client Access servers do you envisage needing?

Question: How many Hub Transport servers are required?

Question: Ed Meadows has explained that the administrators at the Branch Office 1 site needs tobe able to perform limited recipient management tasks. To which built-in role group should youassign these branch administrators?

Note Be prepared to discuss your proposed design with the class.

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

infrastructure report.




Exercise 2: Determining Suitability for Exchange Server 2010

You must verify that the AD DS environment and the server meet all prerequisites for installing Exchange

Server 2010. Use the following checklist to verify that the prerequisites are met.

Prerequisite Achieved?

AD DS domain controllers: Windows Server 2003 SP1 or later Yes or No

AD DS domain and forest functional level: Windows Server2003 or higher

Yes or No

DNS requirements Yes or No

Exchange Server 2010 schema changes Yes or No

AD DS management tools Yes or No

Microsoft .NET Framework 3.5 or later Yes or No

Windows Remote Management Yes or No

Windows PowerShell 2.0 Yes or No

2010 Office System Converter: Microsoft Filter Pack Yes or No

Web Server Internet Information Services (IIS) server role alongwith the following role services:

• ISAPI Extensions

• IIS 6 Metabase Compatibility

• IIS 6 Management Console

• Basic Authentication

• Windows Authentication

• Digest Authentication

•

Dynamic Content Compression• .NET Framework Extensibility

Yes or No

Windows Server 2008 features:

• WCF Hypertext Transfer Protocol (HTTP) Activation

• RPC over HTTP Proxy

Yes or No


1. Evaluate the AD DS requirements.

2. Evaluate the DNS requirements.

3.

Evaluate the server requirements.

Task 1: Evaluate the AD DS requirements

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

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

3.

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




Task 2: Evaluate the DNS requirements

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

Task 3: Evaluate the server requirements

1. On NYC-SVR1, evaluate whether the required Windows Server 2008 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 whether your organization meets the AD DS, DNS,

and server requirements for installing Exchange Server 2010. You should have identified the additional

components that need to be installed or configured to meet the requirements.




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

Scenario

Now that you have identified which prerequisites are not met in the current AD DS and server

configuration, you need to update the environment to meet them.

The main tasks for this exercise are as follows:1. Install the Windows Server 2008 server roles and features.

2. Prepare AD DS for the Exchange Server 2010 installation.

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

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

Server 2010:

• AD DS Snap-Ins and Command-Line Tools

• .NET Framework 3.5.1

• RPC over HTTP Proxy

• For IIS:

• Digest Authentication

• Dynamic Content Compression

• IIS 6 Management Console

2.

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

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

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

click Settings.

2. Click DVD Drive, and then click Image File.

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

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

5. On NYC-SVR1, from a command prompt, run the Exchange Server setup program with the

setup /PrepareAD parameter. Configure an Exchange organization name of Contoso.

Results: After this exercise, you should have prepared the AD DS and server configuration for the

Exchange Server 2010 installation.




Exercise 4: Configuring Exchange Server Delegation

Scenario

You must help Ed Meadows achieve his objective of delegating various management tasks to branch

administrators. To meet the management requirements, you need to ensure that Adam Carter is added to

the Help Desk group.

The main task for this exercise is as follows:

• Configure permissions for Adam Carter, the branch administrator.

Task: Configure permissions for Adam Carter, the branch administrator

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

• Full name: Adam Carter

• User logon name: Adam


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

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


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

following steps:

1. On the host computer, start Hyper-V Manager.

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

3. In the Revert Virtual Machine dialog box, click Revert.

4.

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

5. In the Virtual Machines pane, click 10233B-VAN-DC1, and then in the Actions pane, click Start.

Note Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully startedbefore starting the other virtual machines.

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

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

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





Review Questions

1. If you determine that your current site configuration does not support your Exchange Server routing

requirements, what options do you have?

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

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

4. What issue does configuring a split DNS solution resolve?

Best Practices

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

• Avoid using IP addresses to define servers on clients. If the server providing an email client service

changes, you must update the configuration of all affected client computers to match the new IP

address. Additionally, digital certificates that are provided to enable authentication and encryptionbetween clients and servers are configured with a subject name that matches the designated server’s

published FQDN. If an IP address is used, this will at best raise an error on the client, and at worst,

prevent email retrieval.

• Only open required ports on your firewalls. Aim to minimize the open ports by being selective about

what client types you will support.




• Use a self-signed certificate only for small deployments, or for testing purposes. Replace the self-

signed certificate as soon as possible after deployment.

• A single forest means that the Exchange Server 2010 design and deployment is significantly simpler

than any other option. Therefore, you should always use a single forest unless there are highly

compelling reasons to use multiple forests.



3-1

Module 3

Planning and Deploying Mailbox Services

Contents:

Lesson 1: Overview of Mailbox Services in Exchange Server 2010 3-3

Lesson 2: Designing Mailbox Servers 3-8

Lesson 3: Designing Recipient Management 3-21

Lesson 4: Designing Public Folder Architecture 3-37Lab: Planning and Deploying Mailbox Services 3-51



3-2 Planning and Deploying Mailbox Services

Module Overview

Microsoft® Exchange Server 2010 includes some major improvements to mailbox services when

compared to previous versions of Exchange Server. For example, the disk input/output (I/O) requirement

for Exchange Server 2010 is approximately 70 percent less than what is required for Exchange Server 2007.

To optimize your mailbox services performance in Exchange Server 2010, you must consider these

improvements when designing your mailbox services.

The mailbox services design includes the physical design of the Mailbox servers, including the storage

system. It also includes the design of recipient management and public folder architecture.


• Describe mailbox services in Exchange Server 2010.

• Design Mailbox servers.

• Design recipient management.

• Design public folder architecture.



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

Lesson 1

Overview of Mailbox Services in Exchange Server 2010

The improvements in mailbox services in Exchange Server 2010 include improved resource scheduling,

user-managed distribution groups, and the ability to move mailboxes between databases while users are

logged on. One particularly important area of improvement is disk performance, which is enabled by

changes in the database structure.


•

Describe the new mailbox services in Exchange Server 2010.

• Describe the storage changes in Exchange Server 2010.

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

• Identify the information that is required to design Mailbox servers.




New Mailbox Services Features in Exchange Server 2010

Key Points

Exchange Server 2010 includes many new features for mailbox services. You need to be aware of these

features when designing the implementation of mailbox services, because they may have special

requirements that increase the resource load on Mailbox servers.

Some new mailbox services features in Exchange Server 2010 are:

• Personal archives. You can enable personal archives for each user with a mailbox on an Exchange

Server 2010 Mailbox server. The personal archives are an alternative to personal folders (PST) files,which are stored locally.

• Calendar repair. Each Exchange Server 2010 Mailbox server runs the Calendar Repair Assistant on a

configurable schedule. The Calendar Repair Assistant corrects calendar inconsistencies.

• Resource configuration in the Exchange Management Console. Resource mailboxes were introduced

in Exchange Server 2007, but you could manage them only in the Exchange Management Shell. In

Exchange Server 2010, you can use the Exchange Management Console to manage the most

common settings for resource mailboxes.

• Live mailbox moves. In Exchange Server 2010, you can move mailboxes from one database to another

while users are logged on and using their mailbox. Previous versions of Exchange Server required

users to be logged out of their mailboxes during a move.

• User-managed distribution groups. It is now possible for users to create their own distribution groups

by using Microsoft Office Outlook® 2010 or Outlook Web App. This decreases the workload of

Exchange administrators.

• Bulk management. You can perform more bulk management tasks from within the Exchange

Management Console than in previous versions of Exchange Server. Now, you can edit recipient

properties and send email to recipients.

Question: Do you expect that these new features will have an impact on your organization?




Storage Changes in Exchange Server 2010

Key Points

Exchange Server 2010 includes many changes to the way storage is used. The improvements in storage

utilization in Exchange Server 2010 allow you to take advantage of new trends in storage, such as large

slower and inexpensive disks instead of small fast expensive disks..Some of the changes to storage include:

• Removal of storage groups. Previous versions of Exchange Server allowed you to place multiple

databases that shared a single set of transaction logs, into a storage group. In Exchange Server 2010,

each database exists independently, and has its own set of transaction logs.

• Removal of single instance storage. Previous versions of Exchange Server stored a message only once

in the database, if the message was addressed to multiple recipients in the same mailbox database.

Exchange Server 2010 stores a message copy in each user’s mailbox when the message is addressed

to multiple recipients in the same mailbox database. This makes disk access more sequential, and

improves read performance. The addition of database compression prevents the mailbox database

from increasing in size when compared to previous versions of Exchange Server.

• Database is a peer to the server. Previous versions of Exchange Server managed a database as a

subcomponent of a server. In Exchange Server 2010, databases are managed at the organization level.

A database is linked to a server, but is not a subset of a server. This is an important concept for

Database Availability Groups (DAGs), where multiple copies of a database can exist on multiple

servers.

• Disk I/O is optimized for commodity storage. Exchange Server 2010 reduces disk Input/Output

Operations Per Second (IOPS) by up to 70% over Exchange Server 2007. This is done primarily by

making as many disk operations as possible sequential rather than random. Mailbox databases have

been restructured in Exchange Server 2010 to support this. As a consequence, you can consider using

cheaper and larger disks for data storage, such as SATA disks. You can also consider using just a

bunch of disks (JBOD) rather than Redundant Array of Independents Disks (RAID).

Question: How will changes to storage in Exchange Server 2010 affect your organization?




Designing Storage for Large Mailboxes

For many users, access to email is critical for them to perform their jobs. Email is used for communication

internally with colleagues and externally with partners and customers. The amount of data kept in

mailboxes continues to grow, and all of this data must be searchable.

New generations of hard disks are getting larger, but spin rates and seek times are not improving.

Sequential read rates are increasing as a result of greater data density, but random access read rates are

the same. Exchange Server 2010 takes advantage of the increasing disk size, so that you can offer larger

mailboxes to users without increasing cost or decreasing performance. With the I/O improvements in

Exchange Server 2010, you can use larger and less expensive disks in many scenarios. Disk I/O relates tothe number of mailboxes stored on a disk rather than the volume of mailbox data stored on the disk.

Large mailboxes reduce the disk I/O requirements for a Mailbox server because they reduce the number

of mailboxes that are stored on a disk. Fewer mailboxes on a disk results in lower disk I/O.

As a result of lower disk I/O, you can consider using large 7200 RPM disks rather than smaller, faster

15000 RPM disks. A typical 7200 RPM disk stores between 1 and 3 terabytes. A typical 15000 RPM disk

stores less than 1 terabyte. The 7200 RPM disks are significantly less expensive per gigabyte (GB).

Many Exchange administrators initially assume that mailboxes should be kept on one set of fast disks and

personal archives should be kept on another set of slower disks. However, if personal archives are kept on

the same set of disks as the mailboxes, then fewer mailboxes and archives are kept on the same set of

disks. Reducing the number of active mailboxes on the disk behaves similarly to having large mailboxes

on the disk. Overall disk I/O is reduced for the disk, and slower disks can be used for all data.




Information Required for Designing Mailbox Services

Key Points

To design mailbox services, you must identify the information required for both mailboxes and public

folders. Typically, the information you gather helps you to determine the size of databases that need to be

accommodated, and the processing load that those databases will place on the mailbox servers.

To design mailbox databases, you must consider the following factors related to mailboxes:

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

•

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

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

database size.

• Service level agreements (SLAs). To meet the recovery requirements, you may need to keep databases

small so that restore times are reduced.

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

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

• Size of public folders. Larger public folders combined with a greater number of public folders

increases overall database size.

•

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

are required.

• Type of client. Office Outlook 2003 requires public folders for performing free/busy searches, and

downloading offline address books.

Question: What other information would you want to gather before designing mailbox

servers?




Lesson 2

Designing Mailbox Servers

In Exchange Server 2010, a Mailbox server manages and maintains mailbox databases and public folder

databases. When you design a Mailbox server, a primary consideration is storage configuration. However,

you also need to consider processor and memory requirements. And you need to consider high

availability as an option for mailbox databases through the use of DAGs.


•

Design mailbox sizing.

• Design Mailbox server database configurations.

• Design Mailbox server database disk storage.

• Design Mailbox server processor and memory requirements.

• Design Mailbox servers for high availability.

• Describe the considerations for virtualizing Mailbox servers.

• Design a test plan for evaluating disk storage options.




Designing Mailbox Sizing

Key Points

To design mailbox size, you must first understand the business needs that drive mailbox size. The business

needs for mailbox storage vary depending on the type of users. For example, a sales person who is forced

to delete older messages may lose valuable information, which results in lost sales, while general office

staff may have no need to keep a larger volume of mail for a longer term.

To select an appropriate mailbox size, you should consider:

•

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

• How long do messages need to be kept?

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

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

Cached Exchange Mode

When you deploy Office Outlook 2003 or later, you can use Cached Exchange Mode. Cached Exchange

Mode places a copy of the mailbox on the client computer, and it synchronizes the changes with the

Exchange server. After the mailbox is synchronized on the client computer, all requests to view or modify

a message or calendar item are performed on the locally cached copy of the mailbox.

In previous versions of Exchange Server, using Cached Exchange Mode increases the Mailbox serverperformance, because fewer requests are submitted to the Mailbox server. In Exchange Server 2010, using

Cached Exchange Mode does not increase Mailbox server performance, because of the changes in storage

architecture.

Users with a slow connection to the Exchange server typically experience a performance improvement

when using Cached Exchange Mode. However, as the size of the cached mailbox increases, performance

decreases. Increased random access memory (RAM) and faster disks in client computers can increase the

performance of locally cached mailboxes.




Personal Archives

Personal archives are a new feature in Exchange Server 2010. Personal archives address problems that you

might encounter if you archive data to PST files. PST files are problematic because they are difficult to

manage and because they might be stored in a location that is not backed up. This increases the risk of

losing messages.

The intent behind personal archives is to replace PST files. Messages are archived to the personal archiverather than to a PST file. The personal archive can be located either in the same mailbox database as the

associated mailbox or in a different mailbox database. Therefore, a personal archive decreases the size of a

user mailbox, but not the size of Exchange data. In fact, if PST files are imported, the overall size of

Exchange data might increase.

When you use Cached Exchange Mode and personal archives simultaneously, you reduce the amount of

data that is cached on the client. Only the content in the user mailbox is cached locally on the client, and

the content in the personal archive is not cached. This can improve overall client performance, while still

providing access to archived data as needed.

Additional Considerations

Some additional considerations are:• Do not assume that the mailbox quota size is the amount of disk space that is used for each mailbox.

Many mailboxes might not be filled to capacity. Find out what the actual usage is for mailboxes, and

then be prepared for the possibility that mailboxes will grow to the maximum size of the quota.

• Databases never shrink automatically. If you have a large mailbox database that you remove users

from, the mailbox database does not shrink automatically. Instead, empty white space remains inside

the database file. To physically shrink the database on the disk, you must perform an offline

defragmentation. Alternatively, you can create a new mailbox database, move mailboxes into the new

mailbox database, and the delete the old mailbox database.

• Deleted item retention affects mailbox database size. If you increase the deleted item retention limit

from the default value of 14 days, you need to plan for larger mailbox databases. The affect of

deleted item retention on mailbox size varies depending on the volume and size of messages

received by your users. Deleted items in the dumpster are not included when quotas are calculated

for a user’s mailbox. The deleted items in the dumpster are also not included when viewing the size of

the mailbox in the Exchange Management Console.

• A litigation hold increases mailbox size. When a litigation hold is enabled for a mailbox, no messages

are ever purged from the mailbox. In addition, all changes to mailbox items are tracked. If a l itigation

hold is left on for an extended period of time, the mailbox increases in size significantly.

• Deleted mailbox retention affects mailbox database size. If you increase the deleted mailbox retention

limit from the default of 30 days, the size of the mailbox database increases.

• Clients running the Post Office Protocol (POP3) may remove messages immediately. Unlike clients

running Messaging Application Programming Interface (MAPI) and Outlook Web App, clients runningPOP3 are sometimes configured to delete messages from the mailbox after the messages are

downloaded to the client. If you configure the POP3 clients in this way, mailboxes are much smaller

than those that the MAPI and Outlook Web App clients use.

Question: How many clients in your organization use Cached Exchange Mode?




Designing Mailbox Server Database Configuration

Key Points

In previous versions of Exchange Server, it is recommended that you keep the log files and database on

separate disks. That way, if the disk fails and the database is lost, you still have the log files available after

a restore and you can replay them to recover messages received since the last backup. In Exchange

Server 2010, the same recommendation still applies in small environments that do not use DAGs.

However, if there are multiple replicated copies of a database, you do not need to keep the transaction

logs and database separate, because a different replica is used for recovery instead of recovering from a

backup.

In Exchange Server 2010, it is a best practice to locate multiple databases on a single logical unit number

(LUN), because the disk I/O is random. You can separate transaction logs onto different physical disks to

increase performance, but this is not typically necessary. In most cases, because Exchange Server 2010 has

lower I/O requirements, you can keep transaction log files and database files on the same volume without

impacting performance.

You can separate log files from database file for recoverability when using backups. By storing database

files on log files on separate volumes or disks, you can replay transaction logs after a database restore

when the database was lost due to a failed volume or disk.

Disk Space Considerations

When you calculate the disk space requirements for a database on a Mailbox server, you need to considermore than just the mailbox databases. In most cases, you may want to enable indexing on databases to

speed up searches. Each index uses approximately 5 percent of the mailbox database disk space. This

index is placed in the same location as the database.

Single item recovery retains deleted messages in a database for a specified period of time. When you

enable single item recovery, the database size increases.




Previous versions of Exchange Server do not include personal archives. A personal archive is typically used

for longer term retention of mailbox content. If you enable personal archives, the database size may

increase.

You can use a recovery database in a variety of recovery scenarios to extract mailbox data. To use a

recovery database, you must have sufficient disk space available to restore the database and transaction

logs.

Exchange Server Editions

Exchange Server 2010 does not limit the of size of databases based on the edition of Exchange

Server 2010 that you select. The only database limitation based on the edition of Exchange Server 2010 is

the number of databases that are supported on each server. Exchange Server 2010 Standard Edition

supports up to 5 mounted databases on each server, and Exchange Server 2010 Enterprise Edition

supports up to 100 mounted databases on each server.




Designing Mailbox Disk Storage

Key Points

Because of the storage improvements in Exchange Serve 2010, you can consider using less expensive and

slower types of disk storage, which you might not have been able to consider for previous versions of

Exchange Server. However, ultimately you need to test the storage configuration that you select to ensure

it meets your needs.

Consider the following:

•

Replicated database copies increase the amount of storage space required. If your organization usesDAGs to replicate mailbox databases for high availability, consider the number of database copies

when you calculate how much disk space you need and what it costs.

• Slower disks have a significantly lower cost per GB than faster disks. The reduced disk I/O

requirements of Exchange Server 2010 mean that large capacity 7200 RPM disks are suitable for many

organizations. You can obtain 7200 RPM disks of equal size with the SATA or SAS interface. SAS disks

cost slightly more than SATA disks, but, in testing at Microsoft, SAS disks had a 50 percent lower

failure rate than SATA disks.

• Direct attached storage (DAS) is significantly cheaper than a storage area network (SAN). As a result,

DAS is preferable if you use DAGs to create multiple replicated copies of data. You can purchase

external drive arrays and use them to connect a large number of disks to a single server. The lower

reliability of DAS is mitigated by the multiple database copies in the DAG. If you have a SAN withavailable space then you might prefer to use the SAN for the higher reliability it provides.

• You can consider JBOD if you have three or more replicas of a database in a DAG. JBOD provides no

redundancy, but this is acceptable because the DAG has multiple database copies. JBOD is used with

DAS.




• Some organizations have a significant investment in SANs for all server storage. If you use a SAN, the

increased reliability may mean that you choose to implement fewer database copies in a DAG. You

can also keep some database copies on a SAN and others on DAS. Even when a SAN is used, having

two database copies is recommended.

• An Internet small computer system interface (iSCSI) SAN typically has lower performance than a Fibre

Channel SAN, but it is also significantly less expensive. If you use a SAN, the lower I/O requirements inExchange Server 2010 make iSCSI an option over Fibre Channel in a wide range of scenarios.

• Use RAID to increase the redundancy of the disk system if there are less than three database copies in

a DAG. A variety of RAID types are available to increase the performance and redundancy of the disk

system. RAID 10 is the best-performing RAID option, because it has the speed of a striped set and the

redundancy of mirroring. However, it is fairly expensive, because 50 percent of the disk space is used

for redundant data. You can use the Exchange 2010 Mailbox Server Role Requirements Calculator to

help you plan the storage configuration of Mailbox servers. This spreadsheet contains many

calculations to help you accurately estimate the hardware requirements to support a specific number

of users with a specific storage configuration. You can download this tool from the Microsoft website,

and it is updated regularly.

Question: Which disk configuration do you use in most of your servers?




Designing Mailbox Server Processor and Memory Requirements

Key Points

Exchange Server 2010 requires a 64-bit processor and operating system. Exchange Server 2010 supports

two specific processor architectures: AMD64 and Intel Extended Memory 64 Technology. It does not

support Itanium processors.

Exchange Server 2010 can take advantage of multicore processors. A multicore processor can process

multiple tasks at the same time. A typical server processor has four or more cores. If the processor

supports hyper-threading, Microsoft recommends that you disable hyper-threading. Hyper-threading

causes problems in capacity planning and offers little performance improvement.

The number of processor cores required for a Mailbox server varies, depending on the number of

mailboxes and how intensely they are used. For average usage, a single processor core can support

approximately 1,000 active mailboxes. Average usage is defined as a user who sends 10 messages a day

and receives 40 messages a day.

If the Mailbox server role is combined with other server roles, you must account for the processor

requirements of those other server roles. For average usage, a single server with the Mailbox, Client

Access, and Hub Transport server roles installed can support approximately 500 mailboxes.

Note The maximum recommended number of processor sockets is two per Mailbox

server. Up to four processor sockets are recommended for multi-role servers.

Memory Requirements

The memory requirements for Exchange Server 2010 vary depending on the number of mailboxes and

how intensely they are used. The minimum recommended RAM for a Mailbox server is 4 GB. A server that

combines multiple roles should have a minimum of 8 GB of RAM.




When calculating the memory required for your Mailbox server, take the minimum require and add

additional memory for each user based on their messaging volume. For each 50 messages per day sent or

received, you should allocate 3 megabytes (MB) per user. For example, if the average user in your

organization sends and receives 100 messages per day then you should allocate 6 MB per user in addition

to the minimum RAM for your Mailbox server configuration.




Designing Mailbox Servers for High Availability

Key Points

To implement high availability of mailbox databases, you use a DAG. A DAG allows you to replicate

mailbox databases to multiple servers. If the server that is servicing clients fails, a replica on another server

in the DAG begins to service client requests.

Note The high availability methods available in previous versions of Exchange Server are

not available in Exchange Server 2010.

Some considerations for implementing DAGs are:

• Mailbox database names must be unique in the Exchange Server organization. This may require you

to develop a naming convention. This naming convention should not include the server name,

because the database can move between DAG members.

• The storage path must be identical for all copies of a database. This means that all members of a DAG

should have the same disk configuration with the same drive letters. For increased flexibility, you can

use mount points instead of various drive letters, but this is not required.

• DAG implementation uses the Windows Server® 2008 operating system failover clustering feature.

This is only available in the Windows Server 2008 Enterprise and Datacenter operating system

editions. However, DAGs are supported for both the Exchange Server 2010 Standard and Enterpriseeditions.

• DAGs can be managed completely from within Exchange Server 2010 management tools. This

simplifies the process of DAG configuration, and masks the complexity of failover clustering from

administrators.




• A DAG cannot make public folder databases highly available. Public folders should use public folder

replication for high availability. However, public folder databases can exist on a server that is a

member of a DAG. Public folder replication can be used to make a public folder highly available.

• A server that is a member of a DAG can have additional server roles installed. For example, a server

that is a member of a DAG can have the Client Access and Hub Transport server roles installed.

Question: Will you consider implementing a DAG for your organization?




Virtualizing Mailbox Servers

All Exchange Server 2010 server roles can be virtualized. A virtualized implementation of Exchange

Server 2010 is supported when running on the Microsoft Hyper-V® technology or on any other

hypervisor that is validated in the Windows Server Virtualization Validation Program.

Some considerations for hardware requirements are:

• In general, when Exchange Server 2010 is running in a virtual machine, it has the same hardware

performance requirements as when it is not virtualized. The requirements for memory and processing

power are the same. For example, if your planning indicates that a server running ExchangeServer 2010 requires 16 GB of memory, a virtualized version of that server also requires 16 GB of

memory.

• Memory should not be oversubscribed. Exchange Server 2010 uses caching in memory to improve

performance. If memory is oversubscribed, Exchange Server 2010 does not have full control over

memory allocation in the virtual machine, which can reduce performance.

• Do not allocate virtual processors to virtual machines at a ratio higher than two virtual processors per

processor core. For example, if the physical host has two processors with six cores each, you should

not allocate more than 24 virtual processors.

Some considerations for storage are:

•

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

• Differencing or delta mechanisms such as snapshots are not supported. This is because the snapshot

mechanisms are not application-aware and, as a consequence, recovery to the snapshot is

unpredictable.

• Test virtual disk performance to be sure that it meets your needs. Virtual disk performance is typically

slightly lower than physical disk performance.




• Pass-through storage and iSCSI storage are both supported. However, iSCSI storage has reduced

performance if the network stack of the virtualization environment does not support jumbo frames.

Jumbo frames are supporting in Hyper-V on Windows Server 2008 R2, but they must be enabled in

the parent partition and the virtual machine.

You can use the virtual machine high availability that is provided by your virtualization environment with

Exchange Server 2010. This is supported even for servers that are part of a DAG. Some considerations forvirtual machine high availability are:

• The virtual machines must not save and then restore state when moved. All migration between hosts

must be an online migration, such as Hyper-V Live Migration, or else the virtual machines can be shut

down and restarted.

• Online migration methods must be supported by the hypervisor vendor.

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

boot process.




Designing a Test Plan for Server Performance

Key Points

To design a test plan for Mailbox server performance, you need to accurately understand how the server

will be used. This includes factors such as the number of mailboxes, the number of messages users will

send, and the type of clients that will be accessing mailboxes. If you do not accurately understand the

load that will be placed on the server, it is impossible to ensure that server performance will meet your

needs.

When you create your test environment, you should ensure that it replicates the conditions in your

production environment as closely as possible. This means that you should be using identical hardware,

software, and drivers on the test system and production system.

To test server performance, it is impossible to completely replicate the users in a production environment.

However, Microsoft provides two tools that you can use to generate simulated loads on the server:

• Exchange Load Generator (Loadgen). You can use this tool to create a simulated load of MAPI,

Outlook Web App, the Microsoft Exchange ActiveSync® technology, Internet Message Access

Protocol (IMAP), POP3, and Simple Mail Transfer Protocol (SMTP) clients on Exchange servers. You

can configure this tool based on the usage data you have gathered to determine whether the

performance is acceptable.

• Jetstress. You can use this tool to verify disk performance by simulating the Exchange Server database

and the log file loads that a specific number of users produce. It is also capable of simulating the loadgenerated by database replication in a DAG.

Note In many cases, you can use virtualization to test the functionality of proposed

configurations, including Exchange Server 2010. However, virtualization is not appropriate

for testing server performance unless the production Exchange server is also virtualized.

Question: Do you test server performance before implementation?




Lesson 3

Designing Recipient Management

In many ways, recipients are the focus of Exchange Server management, because they are the system

users. Exchange Server 2010 provides some new opportunities to improve recipient management over

previous versions of Exchange Server, such as more fine-grained control over recipient management for

administrators, and delegation of distribution group management. Other aspects of recipient

management include address lists, email address policies, system messages, resource mailboxes, and

mailbox moves.


• Design recipient management processes.

• Design address lists.

• Design address book policies.

• Design email address policies.

• Design system messages.

• Design distribution groups.

• Design resource mailboxes.

• Design mailbox moves.




Designing Recipient Management Processes

Key Points

Exchange Server 2010 provides a much greater level of flexibility in defining management permissions for

all aspects of Exchange Server 2010, including the management of recipients. By default, a number of

management role groups are created, which allow you to delegate management of specific tasks. For

example, the Recipient Management role group allows you to delegate recipient management tasks.

However, this management role group provides the ability to manage recipients for the entire

organization.

You can perform more customized delegation of management permissions by using management roles

and scopes. A management role defines the management tasks that can be performed, and the scope

defines the objects that the management role can be applied to. The scope can be defined based on

filters that use almost any recipient property or organizational unit (OU).

To delegate recipient management, you must:

1.

Define the users who will perform management tasks.

2. Assign the appropriate management roles to users or groups.

Management Tools

When you design recipient management processes, you need to consider which management tool is the

most appropriate for different management users.

• The Exchange Management Console is best suited for general management tasks, because it provides

a graphical interface that is easy to use. However some less commonly used options—such as creating

a recovery database—are not available.

• The Exchange Management Shell provides access to all management options. The scripting

capabilities make it well-suited for performing repetitive tasks. The Exchange Management Console

also has the ability to pipe output from one cmdlet as input to another cmdlet, which enables it to

support bulk operations such a creating many new user accounts simultaneously.




• The Exchange Control Panel provides access to a limited set of recipient management tasks. It is well-

suited for users who only need to perform those limited tasks. Because it is a web-based

administrative tool, users do not need to install an administrative application on a client computer.

Therefore, you can use this tool for performing remote administration. Tasks performed in the

Exchange Control Panel include multi-mailbox search, some recipient management tasks,

configuration of role-based access control (RBAC), and mobile device management.




Designing Address Lists

Key Points

Address lists are lists of recipients based on a Lightweight Directory Access Protocol (LDAP) query. The

purpose of an address list is to make it easier for users to select a recipient for a message or a meeting

request. Several address lists are created by default in Exchange Server 2010.

The default address lists are:

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

•

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

mailboxes.

• All Groups. This list contains all distribution groups.

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

• All Rooms. This list contains all room mailboxes.

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

In larger organizations, the default address lists may not entirely meet the needs of the organization. You

might want to create additional address lists that are specific to workgroups or regions. Creating

additional lists can make it easier to find appropriate recipients by providing smaller lists to look through.

You also can include the smaller lists in offline address books.

The default address lists are all automatically updated when new recipients are created. If you create

customized address lists, those address lists may not be automatically updated depending on the criteria

used to define them. Use the Update-AddressList cmdlet to force an address list to update when

required. Consider running a script as a scheduled task to automatically update customized address lists at

least once a day.




Exchange Cached Mode

When you configure an Office Outlook client to use Exchange Cached Mode, the client uses the offline

address book when possible. The default offline address book includes only the GAL. In this default

configuration, you browse the GAL by using the offline address book while you query the other address

lists from a global catalog server.

When you add new recipients to an Exchange Server organization, the recipients are not immediatelyavailable in the GAL of clients that use Exchange Cached Mode. The client needs to download a new copy

of the offline address book before the new recipients are listed in the GAL. The offline address book is

typically updated only once every 24 hours. To work around this, users can use the All Users list or other

appropriate address lists that are not cached.

Multiple Global Address Lists

You can create multiple GALs in an Exchange Server organization, although you would rarely use this

option. Each user still has only a single GAL address list, but the GAL that is available to a user varies. The

GAL that is available to a user is the GAL that has the smallest number of recipients and that the user is a

member of, unless address book policies (ABPs) are used. Multiple GALs are appropriate when a single

Exchange Server organization is used to provide email services for multiple organizations.

Hierarchical Address Book

An address book feature introduced in SP2 for Exchange Server 2010 is the hierarchical address book. You

can use this feature to organize the structure of the GAL to match your organization. To organize the

hierarchy, create distribution groups and set them as hierarchical groups. In many cases, distribution

groups already represent workgroups in your organization. The hierarchical address book feature allows

you to reuse those groups to create address books.




Designing Address Book Policies

Many organizations need only a single set of address lists, which all users share. However, if an

organization needs multiple GALs or different address lists for different groups of users, ABPs simplify the

management of those address lists. Individual mailboxes are associated with an ABP and receive the lists

specified in the ABP. ABPs are introduced in SP2 for Exchange Server 2010.

Each ABP contains:

• A GAL

•

An offline address list

• A room list

• One or more additional address lists

When you create the address lists for ABPs, consider which attributes should be used to identify the

address list and the GAL members. You should consider using custom attributes for this purpose, because

they can be configured on all recipient types. Some other attributes, such as Company, are not present for

all recipient types.

Scenarios for using ABPs

Some scenarios for using ABPs include:

•

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

• Differing address lists for departments in a single organization. A common GAL is used for all ABPs,

but each department can have different departmental address lists for internal use.

• Differing address lists for user groups in a school. Students can be assigned a GAL that includes only

their teacher and other students in their class, while teachers are assigned a GAL that includes all

addresses in the school.




Considerations for using ABPs

When you design ABPs, first identify the various user groups that need differing address lists. Then, create

the appropriate address lists, create ABPs that the address lists are assigned to, and then assign the ABPs

to mailboxes.

When you use ABPs, consider the following:

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

with SP2.

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

• A GAL in an ABP must contain, at a minimum, the objects defined in the other address lists that are

part of the ABP. The GAL should also contain the user that the ABP is assigned to.

• ABPs do not separate mailboxes in an Exchange organization. ABPs create separate address lists, but

they do not prevent users who have differing ABPs from sending messages to each other.

• To use ABPs, users must connect through either Exchange Web Services (EWS) or the Address Book

Service on a Client Access server. Outlook 2011 for Mac and Entourage 2008 clients query global

catalog servers directly to obtain address lists and do not use ABPs. If Outlook 2011 for Mac connectsfrom the Internet, you can configure it to use EWS instead of querying directly.

• Any address list except a GAL can be used as the room list in an ABP. This means that you can use an

empty address list in scenarios where users assigned an ABP do not need to book rooms.




Designing Email Address Policies

Key Points

You can use email address policies to apply email addresses to recipients. A single email address policy

can include multiple email addresses. This allows you to have multiple variations in user name or domain

name for each recipient.

The Default Policy applies to all recipients. In many organizations, the Default Policy is the only one

required, because all users have the same email address format. Larger organizations may need multiple

email address policies to provide varying address formats or domain names for some users. For example, a

recently purchased subsidiary may need to retain older email addresses to ensure that they receive

messages from clients that have not updated their address books with the company’s new email address.

When you create an email address policy with multiple email addresses, you must define one of the

addresses as the primary address. The recipient can receive messages at all defined email addresses, but

outgoing messages use the primary address as the Reply To address. When you change domain names or

email address formats for the organization, you should retain the old email addresses and add the new

email addresses as the primary address. Then as recipients outside your organization reply to messages,

they can add the new email addresses to their address books.

When you modify email address policies or create new ones, you can apply the changes immediately, or

schedule them to occur at a later time. By scheduling the policy application to occur outside of regular

business hours, you minimize the impact on the system.

Question: Do you see a need for multiple email address policies in your organization?




Designing System Messages

Key Points

Exchange Server 2010 allows you to customize system messages. You can use delivery status notifications

(DSNs) to notify internal and external senders about message delivery status. You can use quota messages

to inform users when their mailboxes are above the defined quota levels.

You can customize a DSN to add additional information, or to provide a better explanation of why the

error occurred. You could also modify a DSN to provide contact information for the person who can help

resolve the problem. You can format the custom DSN by using Hypertext Markup Language (HTML).

If you choose to customize DSN messages, you can customize them separately for internal and external

senders. When you provide contact information in a DSN, it may only be appropriate for internal senders.

You can customize quota messages to make the messages more user-friendly, or to provide contact

information. For example, in a warning message about a mailbox that is too large, you could provide

some information about how to request a larger mailbox quota.

Question: Will you customize quota messages for your organization?




Designing Distribution Groups

Key Points

When you create a new distribution group in Exchange Server 2010, it is created as a universal group. This

ensures that there are no problems with groups containing members from multiple domains. Distribution

groups that are upgraded from previous versions of Exchange Server may be Global groups and function

properly with Exchange Server 2010.

When designing distribution groups, you can perform the following tasks:

•

Designate an expansion server for a group. The expansion server is responsible for expanding thegroup membership list for delivery. This server is not required in Exchange Server 2010, but you can

use it to control processing load. If you do not specify an expansion server, then the first Hub

Transport server processing the message functions as the expansion server.

• Designate a group manager. Use this for delegating group membership management to a user in a

department or workgroup that is responsible for the group. The group manager can then manage

the membership of the group, which reduces the workload for Exchange Server administrators. In

many cases, a group manager is more responsive to requests for group membership changes than

Exchange Server administrators.

• Enable moderation. When you enable moderation, messages sent to the group must be approved by

a moderator before they are delivered to the group. This can be useful for ensuring that only

appropriate content is sent to a group. For example, a moderator could ensure that an All Usersgroup is not used by enthusiastic parents attempting to sell fund-raising chocolates for their children.

• Reuse security groups as distribution groups. If a security group is already configured with the

members that you want to use for a distribution group, then you can mail-enable an existing security

group. This avoids the need to maintain two separate membership lists. However, you must consider

who will manage the group membership, as often the task of managing distribution groups is

separate from managing security group membership.




• Allow users to join and leave distribution groups when appropriate. You can configure distribution

groups to allow users to join and leave distribution groups rather than requiring an Exchange Server

administrator to maintain the group membership. This allows users to join distribution groups that

receive information that is of interest to them. For example, in a research and development

department, there could distribution groups for various subject areas. You can also configure groups

to require manager approval for joining. Users cannot join and leave security groups. Security groups

have closed membership.

Dynamic Distribution Groups

The dynamic distribution group membership list is generated based on an LDAP query. The automatic

generation of the membership reduces the workload of Exchange Server administrators. However, to

successfully use dynamic distribution groups, you need to have sufficient recipient information in Active

Directory® Domain Services (AD DS) to create effective queries. For example, you may need to configure

recipient information such as Department, Company, or City.

The use of dynamic distribution groups does increase the load on domain controllers. However, the

increase is minimal unless dynamic distribution groups are being used very often.

Question: Will you use moderated groups in your organization?




Designing Resource Mailboxes

Key Points

You can use resource mailboxes for booking rooms and equipment. The main benefit of using resource

mailboxes is to provide a centrally accessible schedule for the resource so that users can see when it is

available. You have the option to automate the booking process, or designate a delegate to manage all

bookings.

When you configure a resource mailbox to automatically accept bookings, it reduces the delegate’s

management workload. It also makes it faster for users to confirm that the resource is booked. You can

define rules for when a resource mailbox will automatically accept a booking.

In-Policy and Out-of-Policy Requests

In-policy requests are those requests that meet the standard booking rules for the resource. You can

select which users will have in-policy requests automatically approved, and which still need to be

approved by a delegate. For example, you can configure a room resource for the marketing department

to automatically accept meeting request from users in the marketing department, but require meeting

requests from other users to be approved by a delegate.

The resource policy defines the rules that are in-policy. These rules include:

• Allow conflicting meeting requests. When this option is enabled, multiple users can book a resource

at the same time. In most cases, this is not appropriate.

• Allow repeating meetings. Some organizations choose not to allow this option, in order to prevent

users from booking resources unnecessarily.

• Allow scheduling only during working hours. Use of this option is often appropriate inside a building

that will not generally be available outside of work hours. However, it would not be appropriate to

use this option for a resource such as projectors or laptops that are used outside the organization.

• Reject repeating meetings that have an end date beyond the booking window. Use this option to

ensure that repeating meetings are not booked too far in the future.




• Booking window. This option defines how far in the future meeting requests can be scheduled. If this

window is too large, then a resource may be booked far in the future, but the person that booked the

resource may not actually require the resource by the time the distant meeting date arrives.

• Maximum duration. This option defines how long a given meeting can last.

• Maximum conflict instances. When a repeating meeting is being scheduled, a certain number of

conflicts can be allowed so that the entire meeting request is not rejected.

• Conflict percentage allowed. When a repeating meeting is scheduled, you can use this option to allow

a certain percentage of conflicts, so that the entire meeting request is not rejected.

Out-of-policy requests are those that do not meet the standard booking rules for the resource. Out-of-

policy requests must always be approved by a delegate. However, you can specify the users that can

submit out-of-policy requests. If a user is not allowed to submit out-of-policy requests, any out-of-policy

requests submitted by that user will be rejected, rather than waiting for delegate approval.

You need to decide the appropriate policy settings for each resource, who can book in-policy requests,

and who can book out-of-policy requests.

DelegatesIn addition to determining booking policies, you also need to decide which user or users should be the

delegate for a resource. The resource delegate is responsible for approving meeting requests that are not

automatically accepted, and for arbitrating conflicting requests. The delegate for a resource should be the

person responsible for managing that resource within the organization.

Question: Does your organization need to implement resource mailboxes?




Designing Mailbox Moves

Key Points

You can move mailboxes between mailbox databases and mailbox servers. Some of the reasons you might

want to move mailboxes are:

• Migration to a new server. When you purchase a new server, you will need to move mailboxes to the

new server before decommissioning the old server.

• Load balancing between servers. If one server is performing poorly because it is overloaded, you may

want to move some mailboxes to another server with sufficient resources to handle additionalmailboxes.

• Reduce database size. If a mailbox database becomes too large in size, it may be difficult to restore

during disaster recovery. You can create multiple smaller mailbox databases, and then move

mailboxes onto those databases.

• User moves between locations or departments. Often a mailbox database or mailbox server is

dedicated to a department or location. When a user moves to a different location or department, you

should also move the user mailbox to the appropriate mailbox database.

Online Mailbox Moves

Previous versions of Exchange Server do not support moving mailboxes when users are logged on. This

limits the timeframe for mailbox moves, and in some cases it results in migration projects lasting for anextended period of time.

In Exchange Server 2010, you can perform mailbox moves online with no user impact. This avoids the

need to schedule mailbox moves. However, to perform an online mailbox move to Exchange Server 2010,

the source server must be running Exchange Server 2007 with SP2 or Exchange Server 2010, and you must

initiate the move by using the New-MoveRequest cmdlet, rather than the Move-Mailbox cmdlet. When

you use the Exchange Management Console to move mailboxes, an online mailbox move is performed

when possible.




Question: Do you see a need for online mailbox moves in your organization?




Lesson 4

Designing Public Folder Architecture

You can use public folders as a repository for data in collaboration scenarios. You can also use them as a

central mailbox for a group of users, and as centralized calendars. Although Exchange Server 2010 de-

emphasizes public folders, they are still fully supported, and some organizations use them extensively.


• Analyze business requirements for public folders.

• Design Mailbox servers for storing public folders.

• Design public folder replication.

• Design client access to public folders.

• Plan the public folder hierarchy.

• Design public folder permissions.

• Describe options for transitioning away from public folders.




Analyzing Business Requirements for Public Folders

Key Points

Some organizations make little use of public folders, while others use them extensively, and may have

developed manual or automated business processes that require public folders. Because of the variation

in public folder use, you should start your public folder design by analyzing your organization’s business

requirements for public folders.

Information Required for Planning Public Folders

To clarify and determine business requirements for public folders, you should consider the followinginformation:

• What versions of Office Outlook does your organization use? If you use Office Outlook 2003 or earlier

versions, you still require public folders to store the offline address book and free/busy information.

• How many public folders has your organization implemented, and how much data does each public

folder store?

• How often are public folders used? Calculate how frequently public folders are accessed, and the

number of users who access them. Understanding public folder usage helps you plan the location and

capacity of the public folder servers. For example, high public folder usage may require you to use a

dedicated public folder server.

•

How are users of public folders distributed within the organization? Are the public folder usersprimarily in one location, or are they distributed across the organization’s locations? Do users from

the Internet need access to public folders?

• What function do the public folders serve? Some organizations use public folders only for basic

functions—such as storing company data—while other organizations use public folders for more

advanced functions—such as creating customized applications.




• Do the public folders support strategic business applications? Analyze the organization’s primary

business applications, and decide whether they are using public folders as a front-end system for

form-based and event-based applications.

• What are the plans for sharing the types of information that may be stored in public folders? For

example, is the organization considering deploying an intranet that uses the Microsoft SharePoint®

services or another kind of web server for sharing some types of company information?

Question: Does your organization use public folders, and if it does, what is the purpose?




Designing Mailbox Servers for Storing Public Folders

Key Points

Public folders are stored in public folder databases on Exchange Server 2010 Mailbox servers. By default, if

you specify that your organization includes Office Outlook 2003 or earlier clients when you install your

organization’s first Mailbox server, a public folder database is created on this first Mailbox server. No other

public folder databases are installed; however, you can create a public folder store on any other Mailbox

server in the organization.

Considerations When Designing Mailbox Servers to Host Public FoldersWhen designing storage space for the public folder database, consider the following factors:

• Item retention and deletion

• Average and maximum size of physical messages

• Maximum item storage time configured for each public folder

• Default maximum item storage time for the public folder database

• Projected growth rate for public folder usage

If your organization currently uses public folders, you can determine this information easily. If your

organization would like to use public folders now, but has not used them previously, you might need to

spend more time gathering the business requirements to determine how much space to dedicate to apublic folder database.

The processor and memory requirements for servers hosting a public folder database are the same as for

other Mailbox servers. If the server hosts both mailboxes and public folders, then each MAPI connection

requires the same amount of resources, whether connecting to the mailbox database or the public folder

database. If public folder data changes frequently, then the disk I/O, memory, and processing

requirements increase.




If your organization uses public folders extensively, you might choose to deploy one or more dedicated

public folder servers. Dedicated public folder servers may have different hardware requirements than

servers that are both Mailbox and public folder servers, depending on the number of users using the

public folders and the size of the public folder store. Because a Mailbox server can host only one public

folder database, the hardware requirements for the dedicated public folder server are likely to be

significantly less than a Mailbox server that has multiple mailbox databases.




Designing Public Folder Replication

Key Points

Organizations that use public folders extensively also frequently use public folder replication to provide

fault tolerance and better access for users in different locations. When you enable public folder

replication, the data in a public folder is synchronized between two or more servers. If one server is

unavailable, users can access the data from one of the remaining replicas. A public folder database can

exist on a Mailbox server that is part of a DAG, but the public folder database cannot be replicated by the

DAG.

Default Configuration for Public Folder Replication and Referrals

Exchange Server 2010 supports a single public folder tree, also known as the public folder hierarchy. The

public folder hierarchy is replicated to each Exchange Server 2010 Mailbox server configured with a public

folder database. By default, the content of public folders exists only on the public folder database where

the public folder was created, unless the public folders were replicated to other public folder databases.

By default, Office Outlook clients always try to access a replica of a public folder in the same Active

Directory site as the user mailbox. However, if a replica of the public folder does not exist in the site, users

can connect to public folder replicas in another Active Directory site. This process is called public folder

referral . By default, public folder referrals are enabled between Active Directory sites in Exchange Server

2010. If a public folder replica is located in more than one other site, the Exchange server refers the client

to the replica site based on the lowest IP site link costs between the sites.




Considerations for Designing Public Folder Replication and Referrals

When developing a public folder replication and referral strategy, it is important to consider the usage

patterns for public folders, the physical network between the organization’s locations, and the impact that

replicating public folders and referrals has on the network. When designing a public folder replication and

referral strategy, consider the following factors:

•

If network bandwidth is limited between company locations, optimize network usage by calculatingthe relative impact of public folder referrals and replication. The network utilization for public folder

referrals is easy to calculate. Simply calculate how much new content is added to the public folder on

a daily basis, and that is the network traffic that is created if you enable public folder replication. The

network traffic created by public folder referrals is more difficult to measure. You must determine

how many times a day users access the public folder contents, and what the average message size is

in the folder. To optimize replication, you should:

• Configure public folder replication only for public folders that do not change frequently and that

contain large messages.

• Use public folder referrals for public folders that change frequently and to which users must

always have access to the latest content.

• Schedule public folder replication during non-peak hours. In cases of limited bandwidth, and if

users do not need access to a current copy of the public folder contents, you can schedule public

folder replication to occur during non-business hours.

Note You can modify public folder referrals by using the Set-PublicFolderDatabase –iddatabasename –PublicFolderReferralServerList ‘Servername:Cost’ -UseCustomReferralServerList $True command in the Exchange Management Shell. This

command enables public folder referrals to the specified servers in different Active Directorysites, and assigns a cost to each server. If you set the UseCustomReferralServerList parameter to True, and you do not add servers to the PublicFolderReferralServerList parameter, public folder referrals are disabled.

• If the network bandwidth between company locations is not a significant issue, then the primary

considerations for using replication or referrals is server capacity and client performance. If you have a

Mailbox server in a remote site, or if you are deploying a dedicated public folder server, you should

enable public folder replication. This provides users with a more positive experience compared to

accessing public folders across a wide area network (WAN) connection. If you do not have a Mailbox

server capacity in the remote site, then use public folder referrals.

• If you have Office Outlook 2003 or earlier MAPI clients, you should enable replication for the system

folders that these clients require. These folders include the Schedule+ free/busy folders and the

offline address book folders. The offline address book folder includes up to three different versions of

the offline address book. Only replicate the offline address book versions that the Office Outlook

clients in your organization require.

Question: Why would you replicate the content of public folder?




Designing Client Access to Public Folders

Key Points

When designing public folder deployment in your organization, you also should plan for client access.

This includes two components: designing access to the public folder contents based on the messaging

client that users utilize, and designing the public folder hierarchy to ensure that user access to public

folders is as efficient as possible.

Designing Messaging Client Access to Public Folders

In Exchange Server 2010, users can access public folders only using MAPI clients such as Office Outlook2007, or earlier Office Outlook versions. In some earlier versions of Exchange Server, users could also

access the public folders by using an IMAP4 or network news transfer protocol (NNTP) client.

In most organizations, users on the internal network use Office Outlook to access email on the Exchange

server, so these users continue to have access to public folders. However, organizations rarely deploy

Office Outlook as a MAPI client for users outside the internal network. To provide access for these users,

you have three options:

• You can configure Outlook clients that connect from outside the network to use Outlook Anywhere.

Outlook Anywhere uses remote procedure call (RPC) over Hypertext Transfer Protocol Secure (HTTPS)

to connect to the Client Access server.

• You can provide access to the mailboxes and public folders through Outlook Web App. Earlier

versions of Outlook Web Access opened a new window to view public folders. Outlook Web App in

Exchange Server 2010 integrates public folders into the same interface as the mailbox.

• To provide access to public folders for IMAP4 and NNTP clients, you must leave the public folders on

an earlier Exchange Server version. Next, you must configure the clients and the network

infrastructure to enable the clients to connect to the Exchange server that is hosting the public folder.




If users use IMAP4 and NNTP primarily to post messages to public folders, consider mail-enabling the

public folder. When you mail-enable a public folder, this assigns an email address to the public folder

that enables users to send messages to the folder using any email client.

Note If web access to public folders is important in your organization, consider moving

the public folder content to a server running SharePoint.




Planning the Public Folder Hierarchy

Key Points

Exchange Server displays public folders as a hierarchy or tree. If you do not plan this hierarchy carefully,

the public folder structure can become complicated and inconsistent, making it difficult for users to locate

the information they need, and making public folder administration more complicated.

The following table lists the guidelines that you must consider when designing the public folder hierarchy.

Guideline Reason

Create hierarchical structureinto logical and consistentgroupings that are easy forusers to explore and access.

Typically, a public folder hierarchy is organized according to acompany’s business model, so that each top-level folder represents onedepartment within the company.

Use a consistent and logicalnaming scheme for publicfolders.

Users should be able to identify the contents of a public folder from thepublic folder name.

Create a public folderhierarchy that enables youto delegate administrativetasks.

By assigning the appropriate permissions at the top-level folders, youcan allow users to perform tasks such as adding permissions, or addingand removing folders within their department’s top level public folder.

Create a public folderhierarchy that can simplifyadministrative processes.

You can manage public folder settings such as permissions, folder size,and replication. Whenever possible, group public folders that require thesame configuration under a top-level folder, so that you can apply therequired settings to all of the folders in the hierarchy at the same time.




Designing Public Folder Permissions

Key Points

To ensure the simplified management of public folder infrastructure while providing users with effective

use of public folders, you need to plan the public folder permissions. When planning public folder

permissions, you need to consider administrative and client permissions.

Designing Administrative Permissions

The following table lists the guidelines that you must consider when designing administrative permissions

for public folders.

Guideline Reason

Identify a group ofadministrators who willadminister publicfolders.

Public folder administration includes managing folder creation permissions,assigning permissions to public folders, and defining public folder replication.This group of administrators should be the only group with permission tocreate and configure top-level public folders.

Plan to delegateadministrativepermissions for lower-level folders.

In most cases, the public folder users understand the public folderrequirements better than the messaging administrators. This means you candelegate the public folder administration tasks—such as creating new publicfolders and assigning client permissions—to advanced users. In manyorganizations, each department assigns a user or group of users the

responsibility of managing the department’s public folder.

Note If you want to provide users administrative access to public folders, use the public

folder permission roles. The folder owner role allows users to create new folders and to

assign permissions to lower-level folders, but it does not allow them to modify other public

folder settings, such as replication or folder size.




Designing Client Permissions

You use roles to manage client permissions to access public folders. A role is a permissions template that

grants clients the permissions they need to access folders and folder items. Use Office Outlook, the Public

Folder Management Tool, or the Exchange Management Shell to assign public folder roles.

You can apply client permissions to a user based on the following rules:

•

If the user is explicitly granted permission to the public folder, only those clients that have been

granted permission are applied to the user.

• If the user is a member of a distribution group that has permission to the public folder, the user’s

permissions are the least restrictive of either the group permissions or the default permissions for the

public folder.

• If the user is a member of multiple distribution groups, the user’s permissions are the least restrictive

of any distribution group or the default permissions for the public folder.

The following table lists the guidelines that you must consider when designing client permissions.

Guideline Reason

Create mail-enableduniversal groups toenable public folderpermissions.

You can grant access to public folders for individual users, but managinggroups is more efficient than managing individual users. Start by determiningthe users who require access to public folders, which folders they requireaccess to, and the level of access required to the public folders. Then creategroups for each unique set of permissions, assign permission roles to thegroups, and add users to the groups.

Plan for default andanonymouspermissions.

Default permissions are assigned to all authenticated users. In ExchangeServer 2010, the default group is assigned the Author permission role. Thismeans that all users can view the folder contents and can create new items inthe folder. If you have public folders containing confidential information, youmust modify the default permission.

Anonymous permissions are assigned to unauthenticated users, includingthose without a mailbox, and those who are not custom recipients in the

organization. However, an anonymous user is restricted to accessing publicfolder content that has been granted anonymous permissions. Because allOffice Outlook clients must be authenticated in order to access a usermailbox, you rarely allow anonymous access to public folders in ExchangeServer 2010.

Limit permissions athigher levels of thehierarchy.

When you create a new public folder, it inherits the permissions from theparent public folder. Limiting permissions in the parent folder ensures thatunnecessary permissions are not given to lower-level folders.

Note When permissions are modified on a parent folder, they are not inherited by the

child folders. However, you can propagate permissions from the parent folder to child

folders.

Question: Which users in your organization have permission to create new public folders?




Alternatives to Public Folders

Key Points

Public folders are still supported by Microsoft, and will be supported at least as long as Exchange Server

2010 is supported. However, public folders are deprecated. This means that you should be exploring

alternatives to public folders before creating additional public folders.

One of the most commonly used alternatives to public folders is SharePoint Server 2010 and SharePoint

Foundation 2010. SharePoint Server 2010 and SharePoint Foundation 2010 share a common core set of

features, but SharePoint Server 2010 has additional advanced features. Both are web-based platforms for

collaboration.

Some of the commonly used features in SharePoint are:

• Document libraries. Used to store documents that can be checked in and out, and tracked with

version control.

• Discussion groups. Used to provide a forum for communication, similar to postings in a public folder.

• Shared calendars. Can be used as a direct replacement for shared calendars in a public folder.

• Contacts. Can be linked with Office Outlook to provide a shared location for creating contacts.

SharePoint can also be integrated with Exchange Server 2010 to provide meeting workspaces. Meeting

workspaces are created as a site to support a meeting and are created automatically as part of the

meeting request. You can use the meeting workspace to store documents related to the meeting and to

have preliminary discussions.




Other Alternatives

If you do not require the advanced functionality in SharePoint, you can also consider using:

• Web-based discussion forums. If your only requirement is to provide discussion forums, there are a

wide variety of web-based discussion products available that you can use. Because the interface is

web-based, you do not need for special client software.

• NNTP servers. If your only requirement is to provide discussion forums, you also can consider using

an NNTP server. However, many users might not understand what an NNTP client is, which may lead

to increased user support requirements.

Question: Does your organization use SharePoint?




Lab: Planning and Deploying Mailbox Services

Lab Setup

For this lab, you will use the available virtual machine environment. Before you begin the lab, do the

following:


2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-CL1 virtual

machines are running.


Adatum\Administrator using the password Pa$$w0rd.

Lab Scenario

You are a messaging engineer for the A. Datum Corporation, an enterprise-level organization with

multiple locations. A. Datum Corporation is an international organization involved in technology research

and investment, and it is planning to upgrade from Exchange Server 2003 to Exchange Server 2010.

You have been tasked with reviewing the current messaging infrastructure and network topology, with a

goal of planning the deployment and configuration of mailbox services. You need to make proposals

about how best to address the needs of the various stakeholders in the organization.

Finally, you need to implement part of your proposed mailbox services design.

Note Your instructor may choose to perform this lab as a group discussion rather than as

an individual activity.






Her plan to use the SAN will also not result in high availability for Mailbox servers. The server itself will be

a single point of failure. Exchange Server 2010 does not support the use of single copy clusters like

Exchange Server 2007. A DAG will be required for high availability, and each server in the DAG maintains

a copy of the database. It would be incredibly inefficient to store multiple copies of the same data on the

same SAN.

For initial planning purposes, we need to assume that we’ll use a DAG with at least three database copies.Two copies will be located in the location with users, and one copy will be offsite for disaster recovery.

We currently have a mailbox size limit of 50 MB for all users. However, this limit is much too small, and

many people have been able to convince their managers to approve a size increase. Almost half of the

people in the company currently have an exception on their mailbox limits, with the limit at 200 MB or

more. During a meeting last week, the CIO mentioned that when we get to Exchange Server 2010, we

would set up a mailbox size limit of 500 MB for all users and a 1 GB limit for executives or other

exceptional cases. About 25 percent of the users will fall into the exceptional category. In addition, we

want to create personal archives for the users that are double the size of the mailbox to eliminate the use

of PST files.

I have some concerns with increasing the mailbox size to this limit. The back-up system in all of our offices

doesn’t have as much capacity as we would like. In some offices, we are still backing up to tape. Some ofthe tape backup systems can restore at only 50 GB per hour. According to the SLA that we have in place,

we are supposed to restore any failed database within an hour of failure.

Server Design Statistics

This is a standard profile that can be used for all mailbox servers. Based on the number of users in each

location, we can vary the amount of RAM and the size of the storage.

Server Hardware Characteristics

• Processor: 2 x six core processor, total SPECint Rate of 400

• Disks: 2000 GB, 7.2K revolutions per minute (RPM) SAS 3.5”

Tier 1: User Messaging Statistics • Number of mailboxes: 25 percent of total on each Mailbox server

• Messages sent/received per day: 20 sent/80 received

• Average message size: 50 KB

Tier 2: User Messaging Statistics

• Number of mailboxes: 75 percent of total on each Mailbox server

• Messages sent/received per day: 10 sent/40 received

• Average message size: 25 KB

Task 1: Review the A. Datum Corporation documentation

• Review the following information:

• Server Design Interviews

• Server Design Statistics




Task 2: Answer questions related to the documentation

Question: In the Server Design Interviews, what points are raised that impact your Mailbox server

deployment plan, and how do they impact it?

Question: In the Server Design Statistics, what information is relevant to determining serverdesign, and why?

Task 3: Perform high level planning for Mailbox server storage in London


A. Datum high level planning for mailbox servers in London


Document Author

Date

Jason Carlson

2nd April 2010


Create a high level plan for Mailbox server storage in London.

Additional Information

N/A

Question: Assuming that there are 12,000 users in London, how much disk space is required formailbox databases?

Question: Should the disk space for Mailbox servers be SAN or DAS?

Question: If DAS is used, will the disk space use RAID or JBOD?

Question: What size and speed of disk do you think is appropriate?

Question: Should transaction logs be stored on a separate LUN from database files?




Task 4: Use the Exchange 2010 Mailbox Server Role Requirements Calculator

spreadsheet to determine the configuration

1. On VAN-CL1, open the \\VAN-EX1\E$\Labfiles\LabResources\E2010Calc18.2.xlsm spreadsheet.

Click Enable Content and then click Yes.

2. Enter the following data on the Input tab:

• Exchange Environment Configuration

• Global Catalog Architecture: 64-bit

• Server Multi-Role Configuration: No

• Server Role Virtualization: No

• High Availability Deployment: YES

• Number of Mailbox Servers Hosting Active Mailboxes/DAG (Primary Datacenter): 2

• Number of Database Availability Groups: 1

• Mailbox Database Copy Configuration

• Total Number of HA Database Copy Instances (Includes Active Copy) within DAG: 3

• Total Number of Lagged Database Copy Instances within DAG: 0

• Number of HA Database Copy Instances Deployed in Secondary Datacenter: 1

• Exchange Data Configuration

• Data Overhead Factor: 20%

• Mailbox Moves / Week Percentage: 1%

• Dedicated Maintenance / Restore LUN: Yes

• LUN Free Space Percentage: 20%

• Exchange I/O Configuration

• I/O Overhead Factor: 20%

• Additional I/O Requirement / Server: 0

• Site Resilience Configuration

• Site Resilient Deployment: Yes

• Site Resilience User Distribution Model: Active/Passive

• Site Resilience Recovery Point Objective (Hours): 24

• Activation Block Secondary Datacenter Mailbox Servers: Yes

• Database Configuration

• Maximum Database Size Configuration: Default

• Automatically Calculate Number of Unique Databases / DAG: Yes

• Calculate Number of Unique Databases / DAG for Symmetrical Distribution: No




• Tier 1 User Mailbox Configuration

• Total Number of Tier 1 User Mailboxes: Use the data from Task 2

• Projected Mailbox Number Growth Percentage: Use the data from Task 2

• Total Send/Receive Capability / Mailbox / Day: Use the data from Task 2

•

Average Message Size (KB): Use the data from Task 2

• Mailbox Size Limit (MB): Use the data from Task 2

• Personal Archive Mailbox Size Limit (MB): Use the data from Task 2

• Deleted Item Recovery Window (Days): 14

• Single Item Recovery: Enabled

• Calendar Version Storage: Enabled

• IOPS Multiplication Factor: 1.00

• Megacycles Multiplication Factor: 1.00

•

Desktop Search Engines Enabled (for Online Mode Clients): No

• Predict IOPS Value: Yes


• Total Number of Tier 2 User Mailboxes: Use the data from Task 2

• Projected Mailbox Number Growth Percentage: Use the data from Task 2

• Total Send/Receive Capability / Mailbox / Day: Use the data from Task 2

• Average Message Size (KB): Use the data from Task 2

• Mailbox Size Limit (MB): Use the data from Task 2

•

Personal Archive Mailbox Size Limit (MB): Use the data from Task 2






• Desktop Search Engines Enabled (for Online Mode Clients): No


•

Backup Configuration

• Backup Methodology: Exchange Native Data Protection

• Database and Log Isolation Configured: No

• Backup/Truncation Failure Tolerance: 3

• Network Failure Tolerance (Days): 0




• Storage Options

• Consider Storage Designs Utilizing JBOD (if applicable): Yes

• Primary Datacenter Disk Configuration

• Database + Log: Use the data from Task 2

•

Restore LUN: Use the data from Task 2

• Secondary Datacenter Disk Configuration

• Database + Log: Use the data from Task 2

• Restore LUN: Use the data from Task 2”

• Server Configuration

• Primary Datacenter Mailbox Servers: Use the data from Task 2

• Primary Datacenter Mailbox Servers: Use the data from Task 2

• Log Replication Configuration

•

For Hours 1-5,20-24: 1% • For Hours: 6-7,18-19: 5%

• For Hours 8-17, 7%

• Network Configuration:

• Network Link Type: Fast Ethernet

• Network Link Latency: 50.00

3. Log off of VAN-CL1.

Task 5: Update the A. Datum Large Mailbox server design document


A. Datum Large Mailbox server design


Document Author

Date

Jason Carlson

2nd April 2010


Determine the hardware configuration for large Mailbox servers that use DAS.


N/A

Proposals

Question: What is the processor configuration for each server?

Question: What type of disks are being used?




(continued )


Question: How many databases are recommended?

Question: How many mailboxes are recommended for each database?

Question: What is the recommended RAM for this server?

Question: What is the expected CPU utilization for this server?

Question: What is the recommended number of LUNs on the server?

Question: How many databases are recommended per LUN?

Question: What is the total disk space required per server?

Question: What type of RAID is recommended?

Question: How many database disks are recommended for the primary datacenter servers?

Question: How many database disks are recommended for the secondary datacenter server?

Results: After this exercise, you should have determined the configuration for London mailbox servers.




Exercise 2: Designing Recipient Management

Scenario

In this exercise, you will determine the appropriate recipient management design based on the

information supplied in the A. Datum Exchange Server 2010 project documentation.


1. Review the A. Datum Corporation documentation.

2. Answer questions related to the documentation.

3.

Document the required configuration

Recipient Management Interviews

Conor Cunningham, Messaging Services Manager

We have two distinct business units right now. A. Datum is using the adatum.com domain, and Trey

Research is using the TreyResearch.net domain. All users in each business unit should be using their

assigned email address. However, sometimes, external users send messages to the wrong domain. All

incoming messages should correctly resolve for both domains.

I’ve been also been asked whether it is possible for Trey Research to have a separate GAL and other

address books from A. Datum. Since most communication is with a business unit we’d like to simplify the

address books for them.

Lori Penor, IT Client Services Manager

Client Services is the first point of contact when users in our organization have computer problems. They

also create and manage the user accounts. In our existing system, they are also responsible for creating

mailboxes. I’d like this to continue.

The Client Services staff at each location should be able to create and manage users and mailboxes only in

that physical location. The exceptions to that are Client Services team leaders in each location.

Occasionally, there is a need for Client Services staff to manage users in another location, but that shouldbe restricted to only the team leaders.

Sidney Higa, IT Client Services Team Lead in Toronto

We’re quite excited about the implementation of Exchange Server 2010. We have some ongoing concerns

that we’re hoping the new implementation can help us out with.

Our first concern is booking meeting rooms. The current system is working, but is difficult to configure.

We’d like to have an automated system where most bookings are automatically accepted and only

conflicts or other problems need to be manually approved.

Our second concern is group management. Right now, we are responsible for managing the membership

of distribution groups. If there is some way we can easily delegate that down to department

representatives, it would significantly reduce our workload.



• Recipient Management Interviews





Question: In the Recipient Management Interviews, what points are raised that impact your

Mailbox server deployment plan, and how do they impact it?

Task 3: Document the required configuration

•

Complete the following proposal document by answering the questions.

A. Datum recipient management configuration


Document Author

Date

Jason Carlson

2nd April 2010


Determine the configuration required to meet recipient management needs.


Proposals

Question: How will you ensure that recipients are assigned the correct email addresses?

Question: How will you enable the IT Client Services staff to perform recipient management?

Question: How will you meet the needs for meeting room bookings?

Question: How will you address the needs for distribution group management?

Question: How will you address the need for separating the address books for A. Datum and TreyResearch?

Results: After this exercise, you should have designed the appropriate configuration for recipient

management.




Exercise 3: Designing a Public Folder Deployment

Scenario

In this exercise, you will determine the appropriate recipient management design based on the

information supplied in the A. Datum Exchange Server 2010 project documentation.




3.

Document the required configuration

Public Folder Interviews


The executives have a wide variety of information that we’d like to share. We were thinking that a

discussion forum would be useful. I’ve been talking with Sabine and he has been recommending Windows

SharePoint Services for this type of collaboration. He’s told me that there are several SharePoint sites

being successfully used by other groups in the organization. However, we are very comfortable usingOutlook for this and don’t want to use learn yet another tool.

It is important that we can access this data quickly from any location. I also want to make sure that a

single server failure will not cause data to be lost.


There are a number of groups using SharePoint sites collaboratively and very successfully. We are actively

encouraging anyone that is looking to use public folders to consider SharePoint instead. SharePoint is

capable of a much wider variety of functionality that public folders just cannot do. It has features like

document libraries, shared calendars, blogs, and discussion groups.

That said, I don’t see eliminating public folders anytime soon. So many users are just comfortable with

them.

Lori Penor, IT Client Services Manager

We are looking for a way to share information within the IT Client Services team. I was thinking that a

public folder might be the best way to do this. That way we can have a shared calendar for department

events and discussions.



• Public Folder Interviews

• Server Design Interview


Question: In the Public Folder Interviews, what points are raised that impact your public folder


Question: In the Server Design Interview, what points are raised that impact your public folder







A. Datum public folder configuration


Document Author

Date

Jason Carlson

2nd April 2010


Determine the configuration required to meet public folder needs.

Proposals

Question: How will you address the executive’s desire for public folders?

Question: How will you address the IT Client Services request for a public folder?

Question: Other than the public folder for executives, which other public folders are required?

Results: After this exercise, you should have designed the appropriate configuration for public folders.




Exercise 4: Implementing Mailbox Services

Scenario


1. Replicate and configure the Executives public folder.

2.

Create and configure a resource mailbox.

3.

Test the delegation of a resource mailbox.

4. Configure a distribution group for delegated management and moderation.

5. Test moderation of a distribution group.

Task 1: Configure an address book policy for Trey Research.

1. On VAN-EX1, use the Active Directory Users and Computers administrative tool to create a new

organizational unit in the root of adatum.com.

• Name: Trey

2.

Open the Exchange Management Console and browse to the Mailbox node under Organization.

3.

Create a new address list for Trey Research users:

• Name: Trey Users

• Display Name: Trey Users

• Container: \

• Recipient container: Adatum.com/Trey

• Recipient types: Users with Exchange mailboxes

• Conditions: None

•

Schedule: Immediately

4. Create a new address list for Trey Research rooms:

• Name: Trey Rooms

• Display Name: Trey Rooms

• Container: \

• Recipient container: Adatum.com/Trey

• Recipient types: Resource mailboxes

• Conditions: None

•

Schedule: Immediately

5. Open the Exchange Management Shell.

6. Create a new GAL for Trey Research by using the following command:

New-GlobalAddressList TreyGAL –RecipientContainer “ou=Trey,dc=adatum,dc=com”




7. Create a new OAB for Trey Research by using the following command:

New-OfflineAddressBook TreyOAB –AddressLists TreyGAL

8.

In the Exchange Management Console, create a new address book policy with the following settings:

• Name: TreyABP

• Global address list: TreyGAL

• Offline address list: TreyOAB

• Room list: Trey Rooms

• Address lists: Trey Users

9.

In the Exchange Management Shell, assign TreyABP to all users in the Trey organizational unit by

using the following command:

Get-Mailbox –OrganizationalUnit Trey | Set-Mailbox –AddressBookPolicy TreyABP

10. On VAN-CL1, log on as Adatum\Wei with the password Pa$$w0rd.

11.

Open Outlook 2010, configure an Outlook profile as needed and then view the list of address books.

12. Verify that the Global Address List is empty because the OAB containing TreyGAL has not been

generated yet.

13.

Verify that Wei is the only user listed in the Trey Users address book.


Task 2: Create and configure a resource mailbox

1.

On VAN-EX1, open the Exchange Management Console and create a new resource mailbox with the

following options:

•

First name: Room 100

• User logon name: Room100

• Alias: Room100

2.

In the properties of Room 100, perform the following:

• Enable the Resource Booking Attendant.

• Specify Andreas Herbinger as a delegate.

• Allow Luca Dellamore to submit out-of-policy requests.

Task 3: Test the delegation of a resource mailbox

1.

On VAN-CL1, log on as Adatum\Luca using the password Pa$$w0rd.

2. Open Microsoft Outlook 2010.

3.

Create and send a new meeting request with the following settings:

• To: Luca; Conor

• Subject: Exchange Planning

• Start time: Tomorrow 1pm




• End Time: Tomorrow 2pm

• Room: Room 100

4.

Notice that an automatic response is received indicating that the booking was accepted by Room

100, because the request is in-policy. The response may take a minute or so to appear.

5.

Create and send a new meeting request with the following settings:• To: Luca; Conor

• Subject: Exchange Project Review

• Start time: 9 months from today at 1pm

• End Time: 9 months from today at 2pm

• Room: Room 100

6.

Open the Microsoft Internet Explorer® browser, and then connect to https://van-

ex1.adatum.com/owa.

7. Log on to Outlook Web App as Adatum\Andreas using the password Pa$$w0rd.

8.

Read and approve the meeting request from Luca.

9. In Outlook, verify that Room 100 has accepted the meeting request.

Task 4: Configure a distribution group for delegated management and moderation

1.

On VAN-EX1, use the Exchange Management Console to open the Properties of the Executives

distribution group.

2. On the Group Information tab, add Conor Cunningham as group manager.

3. On the Membership approval tab, verify that group membership is Closed.

4. On the Mailflow Settings tab:

•

Enable moderation.

• Add Luca Dellamore as the moderator.

• Add the Executives distribution group as a sender that does not require approval.

Task 5: Test moderation of a distribution group

1.

On VAN-CL1, send a message in Outlook Web App from Andreas with the following settings:

• To: Executives

• Subject: New Public Folder

• Body: The Executives public folder has been created for you.

2.

View the delivery report for the New Public Folder sent item.

3. In Office Outlook, approve the message for the Executives group.

4.

In Outlook Web App, view the delivery report for the New Public Folder sent item, and then verify its

delivery.

Results: After this exercise, you should have created and tested a public folder, a resource mailbox, and a

distribution group.





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

following steps:


2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.3. In the Revert Virtual Machine dialog box, click Revert.

4. Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-CL1. Close the virtual

machine connection windows


6. To connect to the virtual machine for the next module’s lab, click 10233B-VAN-DC1, and then in the

Actions pane, click Connect.

Important: Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully

started before starting the other virtual machines.

7.

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

8.

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





Review Questions

1. Why might you choose to use SATA drives instead of a SAN or SCSI drives for your Mailbox servers?

2. When deciding between editions of Exchange Server, you need to consider the number of databases

you require. How many databases does the Standard edition of Exchange Server 2010 support?

3. Which administrative tool should be used by a user that has been configured as a group manager?

4.

Which clients require the presence of public folders?

Best Practices Related to Designing Mailboxes


• Use Cached Exchange Mode to increase client performance over slow connections.

• Do not use Cached Exchange Mode to increase Mailbox server performance. In Exchange Server 2010,

the use of Cached Exchange Mode by clients does not affect Mailbox server performance.

• Use personal archives to reduce the size of the cached mailbox when using Cached Exchange Mode.

• Use personal archives instead of PST files.

• Use quotas to enforce size l imits on mailboxes.






4-1

Module 4

Planning and Deploying Client Access Services in Microsoft®Exchange Server 2010

Contents

Lesson 1: Overview of the Client Access Server Role 4-3

Lesson 2: Designing Client Access Server Deployment 4-14

Lesson 3: Designing Client Access 4-34Lesson 4: Designing Client Access Policies 4-48

Lab: Planning and Deploying Client Access Services in







Lesson 1

Overview of the Client Access Server Role

1

The Client Access server role provides access to Exchange Server 2010 mailboxes for all messaging clients.

Because all users connect to Client Access servers, you need to ensure that you design and deploy these

servers correctly. To do this, you must understand the services provided by the Client Access server role,

and how this role interacts with other Exchange Server 2010 server roles. This lesson provides a summary

of how the Client Access server role works in an Exchange Server 2010 deployment.


• Describe the client access business requirements that might impact your Client Access server design.

• Describe the services provided by the Client Access server role.

• Describe how the remote procedure call (RPC) Client Access service works.

• Describe how client access works with multiple sites.

• Describe the requirements for accessing Client Access servers from the Internet.



4-4 Planning and Deploying Client Access Services in Microsoft® Exchange Server 2010

Client Access Business Requirements

The Client Access server’s design can have a significant impact on how satisfied users are with the

messaging system. All clients — including Messaging Application Programming Interface (MAPI) clients

such as Microsoft Office Outlook® 2010 — connect to a Client Access server to access a mailbox on an

Exchange Server 2010 Mailbox server. Office Outlook 2010 or newer clients also connect to Client Access

servers to download offline address books (OABs), to access the Availability services, and to use the

Autodiscover feature. This means that substandard Client Access server performance directly affects users.

Information Required to Design Client Access Servers

When designing the Client Access server configuration, you will need to collect the following data:

• Total number and type of client connections. The total number of clients affects the Client Access

server design. Although the Client Access server can handle thousands of client connections

simultaneously, the number of connections is still an important consideration when you are planning

the server hardware and the number of servers to deploy. Additionally, the types of clients you deploy

are important, because each client access type may have unique requirements.

• Client usage profiles. Along with the total number of clients, you also need to consider how the

clients use the messaging system. This information should include a typical client profile that lists the

number of messages read and sent, and the average size of messages and attachments.

• Client locations. Consider the client locations when designing the Client Access server deployment.

Collect information that includes whether all clients are located on an internal network only, whether

clients are also connecting from the Internet, and whether clients will be connecting from branch

offices.

• Security requirements. All organizations should be using a Secure Sockets Layer (SSL) to secure client

connections to the Client Access servers. SSL encryption and decryption requires additional resources

on the Client Access server, so you may need to increase the server hardware resources if most clients

are connecting using Outlook Anywhere or Outlook Web App.




• Availability requirements. In addition to planning the Client Access server deployment from a capacity

perspective, also consider the availability requirements for the organization. If your organization

requires that all services continue to be available during a single-server failure, then you need to

deploy at least two Client Access servers in a Client Access server array.

• Performance requirements. Performance requirements may be harder to define objectively than some

of the other requirements, but most users will have minimum levels of performance expectationswhen they access their mailboxes. Understanding the performance expectations will help you to

design an appropriately sized Client Access server deployment.




Client Access Server Services

The Client Access server role in Exchange Server 2010 provides support for multiple types of messaging

clients, and provides several additional services for these clients. As you design your Client Access server

deployment, consider these clients and services.

Client Access Server Clients

Exchange Server 2010 supports the clients listed in the following table.

Client Description

Office Outlook (MAPI) Office Outlook 2003 SP1 and newer clients can connect to Exchange Server2010 mailboxes through the Client Access server role. MAPI clients requireRPC connectivity to the Client Access server.

Outlook Anywhere Outlook Anywhere enables Office Outlook 2003 or newer clients to accessuser mailboxes by using RPCs encapsulated in a Hypertext Transfer Protocol(HTTP) or Hypertext Transfer Protocol/Secure (HTTPS) packet. This enablessecure access to user mailboxes from clients located on the Internet.

Outlook Web App Outlook Web App in Exchange Server 2010 lets you access your email fromany web browser. Exchange Server 2010 provides a complete set of featuresfor the following browsers on a computer running Windows® XP, WindowsServer® 2003, Windows Vista®, or Linux:

•

Windows Internet Explorer® 7 and later versions.• Firefox 3.0.1 and later versions.

• Chrome and later versions.

On a computer running Max OS X, you can use:

• Safari 3.1 and later versions.

• Firefox 3.0.1 and later versions.




(continued )

Client Description

Microsoft ExchangeActiveSync®

Exchange ActiveSync lets you synchronize data between your mobile phoneand Exchange Server 2010. You can synchronize email, Contacts, Calendarinformation, and Tasks. Devices that run Windows Mobile® — including

Windows Mobile 5.0 and Windows Mobile 6 or newer —

are all supported.Devices running Windows Mobile 6.1 or newer support Autodiscover.Exchange ActiveSync is licensed to other mobile device manufacturers, and isavailable on a large variety of mobile devices.

POP3 and IMAP4 Besides supporting MAPI and HTTP clients, Exchange Server 2010 supportsPost Office Protocol version 3 (POP3) and Internet message access protocolversion 4 (IMAP4) clients. By default, POP3 and IMAP4 install at the same timeyou install the Client Access server role. However, the services needed tosupport POP3 and IMAP4 require a manual start. To use POP3 and IMAP4,you must first start the POP3 and IMAP4 services.

Entourage 2008, WebServices Edition

Entourage 2008, Web Services Edition, uses Exchange Web Services instead ofWeb Distributed Authoring and Versioning (WebDAV) to provide access to

the user mailboxes, which provides support for Autodiscover. You can useAutodiscover to automatically configure the client profile.

Note: Office Outlook 2011 for Mac also uses EWS to connect to

Exchange Server.

Note Previous versions of Entourage used WebDAV to connect to the Exchange

mailboxes. WebDAV is not available in Exchange 2010, so you must use the Web Services

edition of Entourage to connect to Exchange 2010 mailboxes.

Client Access Server Services

In Exchange Server 2010, the Client Access server role provides critical services for all messaging clients.The following table lists the services provided.

Service Description

RPC Client AccessService

Enables MAPI clients such as Office Outlook 2010 to connect to usermailboxes. The client connects to the Client Access server using a MAPIconnection.

Autodiscover The Autodiscover service configures client computers that are running OfficeOutlook 2007 or newer, or supported mobile devices. The Autodiscoverprocess configures the Office Outlook client profile, including the Mailboxserver, Availability service, and OAB download locations.

Availability The Availability service makes free/busy information available for OfficeOutlook 2007 and Outlook 2010 and Outlook Web App clients. TheAvailability service retrieves free/busy information from Mailbox servers orPublic folders, and presents the information to the clients.

Address Book The Client Access server makes OABs available through a web service. OnlyOffice Outlook 2007 or later clients are capable of retrieving OABs from a webservice.




(continued )

Service Description

Exchange WebServices

Exchange Web Services enables client applications to communicate with theExchange server. You can also access Exchange Web Servicesprogrammatically, and it provides access to much of the same data that is

available through Office Outlook. Exchange Web Services clients can integrateOffice Outlook data into line–of–business (LOB) applications.

MailTips The MailTips feature provides notifications for users regarding potential issueswith sending messages, before they send the messages.

Exchange ControlPanel

The Exchange Control Panel is a web–based management interface thatenables self–service for mailbox users, and enables users to perform specificmanagement tasks without having access to the entire ExchangeManagement interface.




How RPC Client Access Service Works

The introduction of the RPC Client Access service is one of the most significant architectural changes in

Exchange Server 2010. In previous Exchange Server versions, Office Outlook configured as a MAPI client

always connected to the Mailbox server directly, rather than connecting to a front-end or Client Access

server. In Exchange Server 2010, all clients connect to the Client Access server role, regardless of the client

protocol used.

How RPC Client Access Services Work

The architectural changes modify client communication with the Mailbox server in the following ways:• When a MAPI client starts, it connects to a Client Access server. The client protocol has not changed,

and it is still backwards-compatible with older Office Outlook versions.

• When the client connects to the Client Access server, the Client Access server uses a MAPI RPC

connection to communicate with the Mailbox server.

• When a client such as Office Outlook 2010 or Outlook Web App requests the global address list

(GAL), the Client Access server role provides a Name Service Provider Interface (NSPI) service, and it

queries the GAL on behalf of the client. This means that all client connections for address book

lookups are now sent to the Client Access server rather than a global catalog server.

RPC Client Access Service Benefits

RPC Client Access services provide a number of benefits:

• All clients now use the same mailbox access architecture.

• Organizations that deploy highly available Mailbox servers experience fewer client outages due to

mailbox databases that fail over to other servers. When a mailbox fails over to another server,

Exchange Server notifies the Client Access server, and redirects the client connections to a new server

within seconds. In a failover scenario, Exchange Server 2007 clients are disconnected for between 1

and 15 minutes. In Exchange Server 2010, if one Client Access server in a Client Access server array




fails, the client immediately reconnects to another Client Access server in the array. If a Mailbox server

fails, the client disconnects for 30 seconds.

• You can move mailboxes from one Mailbox server to another, even while the user is online and

connected to the mailbox.

• The new architecture supports more concurrent client connections to the Mailbox server. In Exchange

Server 2007, each Mailbox server handles up to 64,000 connections. In Exchange Server 2010, that

number increases to 250,000 connections.




How Client Access Service Works with Multiple Sites

In Exchange Server 2010, all messaging clients connect to a Client Access server when they access their

Exchange Server mailboxes. You must deploy a Client Access server in the same site as the Mailbox server

so users can access their mailboxes.

How Clients Access Mailboxes in a Single Site

The following steps describe what happens when a messaging client connects to the Client Access server:

1. If the client connects from the Internet using a non-MAPI connection, then the client connects to the

Client Access server using the client protocol. Only the client connection protocol ports must beavailable on the external firewall.

2. If the client connects from the internal network using Office Outlook configured as a MAPI client,

then the client connects to the Client Access server using MAPI RPC connections.

3. The Client Access server connects to an Active Directory® Domain Services (AD DS) domain controller

using Kerberos to authenticate the user. Internet Information Services (IIS) or the RPC Client Access

service on the Client Access server performs the authentication. The Client Access server also provides

a directory lookup service for all clients. When the client requests the GAL, or searches the GAL for a

specific recipient, the Client Access server performs the AD DS lookup for the client.

4.

The Client Access server connects to the Mailbox server using a MAPI RPC to submit messages to the

mailbox database, or to read messages.

How Client Access Works with Multiple AD DS Sites

Deploying Client Access servers in an environment with multiple AD DS sites adds complexity to

deployment planning, particularly when you consider the options for providing Internet access to those

Client Access servers.




How Client Access Works with Multiple Internet Access Points

If you have multiple AD DS sites, you can provide Internet access to each site’s Client Access servers. When

an Internet client connects to the Client Access server from the Internet, the Client Access server

authenticates the user, and then queries a global catalog server for the user mailbox location. At this

point, the Client Access server has two options:

•

If the user’s mailbox is located in the same site as the Client Access server, then the Client Accessserver connects to the Mailbox server to fulfill the client request.

• 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 the Client Access server uses an external URL, then the Client Access server redirects the

client request to the Client Access server in the site that contains the user mailbox by presenting the

user with a page that provides the correct URL for the Client Access server, so the user can connect to

the appropriate Client Access server within the home site.

Note With Exchange Server 2010 SP2, you can configure cross-site silent redirection to

enable this redirection process to happen without presenting the user with a webpage

containing the correct URL. When you enable this feature, a user with a mailbox in AD DSsite A who accesses the Outlook Web App URL in AD DS site B will be silently redirected to

the Outlook Web App URL for AD DS site A. To enable cross-site silent redirection, you mustuse the new CrossSiteRedirectType parameter from the Set-OWAVirtualDirectory cmdlet. The parameter has two possible settings, Silent and Manual. The default setting is

Manual.

If you do not configure an external URL for the Client Access server in the site that contains the user

mailbox, then the Client Access server receiving the request proxies the client request to the Client

Access server in the appropriate site.

Note Exchange Server 2010 can redirect only Outlook Web App and Outlook Anywhere

clients to another Client Access server in a different site. All other Client Access server client

requests are proxied to a Client Access server in the same site as the user mailbox. To

optimize access for non-Outlook Web App clients, you must configure the clients to

connect directly to a Client Access server in the user’s home site.

How Client Access Works with a Single Internet Access Point

The Client Access server in the site containing the user mailbox might not be accessible from the Internet,

or it might not have an external URL. In this case, when the user connects to a Client Access server in a site

that does not contain the user mailbox, the Client Access server proxies the client request to the Client

Access server in the site where the user’s mailbox is located. This proxy process uses the same protocol as

the client. In the destination site, the Client Access server then uses RPC to connect to the Mailbox server

managing the user mailbox.

For the Client Access server to proxy the client request, you must configure the Client Access servers that

are not accessible from the Internet to use Integrated Windows authentication. Exchange Server supports

proxying for clients that use Outlook Web App, Outlook Anywhere, Exchange ActiveSync, and Exchange

Web Services.




Requirements for Accessing the Client Access Server from the Internet

To enable access to the Client Access server from the Internet, complete the following steps:

1. Enable access from the Internet to the Client Access servers using the client access protocols. To

connect to the Client Access server, clients must be able to access the server using HTTPS, POP3 or

IMAP4. Configure the Internet firewalls or reverse proxy to enable this access.

2.

Configure the external URLs for each of the required client options. You can configure all of the Client

Access server web server-based features with an external URL. By default, the external URL is blank.

3.

Configure an external Domain Name System (DNS) name resolution. For each Client Access serverthat you expose to the Internet, verify that the server’s host name can be resolved on the Internet. To

do this, add a host record for the Client Access server to the DNS zone on the DNS server that is

hosting the Internet DNS zone for your organization. If you are using different host names for each

Client Access server, then configure a host record for each host. If you are using the same domain

name internally and externally, then configure the host records on both the internal and external DNS

servers.

4. Implement SSL certificates with multiple subject alternative names. If you are using multiple host

names for the Client Access services, or if you are publishing Autodiscover to the Internet, then ensure

that the SSL certificates that you deploy on each Client Access server have the required server names

listed in the subject alternative name extension.

5.

Configure Autodiscover for the Outlook Anywhere and Exchange ActiveSync clients. To enable access

to Autodiscover, you must enable access through the firewall to the Autodiscover virtual directory on

the Client Access server. Additionally, you must configure an external URL on the virtual directory,

and configure the required DNS records for clients to locate the Autodiscover service from the

Internet.

Note You have numerous design decisions to make when configuring Internet access to

the Client Access servers. Later lessons in this module address these design decisions in

depth.




Lesson 2

Designing Client Access Server Deployment

The first step in designing client access to Exchange Server mailboxes is designing the Client Access server

deployment and configuration. You must consider several factors when designing deployment, including

the hardware configuration, and how you will provide access to the services enabled on the Client Access

server. This lesson describes how to design Client Access server deployment.


•

Design the hardware requirements for the Client Access server.

• Design Client Access server security.

• Design SSL certificates for Client Access servers.

• Design the Autodiscover configuration.

• Design the configuration for the Availability service.

• Design the MailTips deployment.

• Design client throttling.

• Design Client Access server deployments for organizations with multiple namespaces.




Designing Client Access Server Hardware Requirements

The Client Access server in Exchange Server 2010 provides significantly more services than the front-end

server provides in Exchange Server 2003, or that the Client Access server provides in Exchange Server

2007. In particular, the RPC Client Access service requires significantly more resources on the Client Access

server than was required in previous versions of Exchange Server.

Designing Hardware Configurations for Client Access Servers

Consider the following guidelines when designing the Client Access server configuration:

•

There is currently no specific recommended processor configuration for Client Access servers.However, we recommend that you use a minimum of 2 processor cores, and a maximum of 12

processor cores.

• The recommended memory configuration is dependent on the number of client connections and the

transaction rate for a Client Access server. The recommended random access memory (RAM) for

Client Access servers is 2 gigabytes (GB) of RAM per processor core, with a minimum of 8 GB of RAM.

• The Client Access server is not a hard-disk intensive application. The following table describes Client

Access server role activities, and how each activity affects disk input/output (I/O).

Activity Descriptions and recommendations

Protocol logging Protocol logging is a sequential write process that, if enabled, causes a

performance issue and requires disk space to store the log files. On a serverthat handles a large number of messages, consider moving these log files to adedicated disk.




(continued )

Activity Descriptions and recommendations

Contentconversion

Content conversion for all Exchange Server 2010 protocols occurs on theClient Access server. Disk access can become an issue for Client Access serversif you have a large number of Internet clients that access mailbox data

through either POP3 or IMAP4. The POP3 and IMAP4 client requires that thecontent be converted into Multipurpose Internet Mail Extensions (MIMEs)before sending it to the client. This conversion occurs on the Client Accessserver, and if the message is larger than 64 kilobyte (KB), the conversionoccurs on disk. If a large percentage of the user base is using POP3 or IMAP4,the temporary folder where conversion occurs should be placed on adedicated fast disk.

Paging Continuous high rates of disk paging indicate a memory shortage.

• The Client Access server requires a fast network connection to Mailbox servers and global catalog

servers. If you have a large number of internal MAPI clients, the network connection may become a

bottleneck. To reduce the network bottleneck, configure the Client Access server with multiple 1

gigabits per second (Gbps) network cards.

• As a general guideline, you should deploy three Client Access server processor cores in an AD DS site

for every four Mailbox server processor cores. This is a significant change from previous Exchange

Server versions, primarily due to the increased processor load required for the RPC Client Access

service.




Client Access Server Security

In many organizations, the Client Access server is accessible from the Internet for Outlook Anywhere,

Outlook Web App, and Exchange ActiveSync clients. Therefore, always ensure that the Client Access server

that faces the Internet is as secure as possible.

Important In previous Exchange Server versions, we recommended that you run the

Security Configuration Wizard (SCW) to disable services and configure the Windows Firewall

settings on Client Access servers. To enable this option, you needed to register Exchange

Server-specific SCW configuration files before running the SCW. Exchange Server 2010,however, is designed to be secure by default, and during installation, only configures

required services and firewall settings. Exchange Server 2010 does not provide the SCW

configuration files. Running the SCW on an Exchange 2010 server is not recommended.

Securing Communications Between Clients and Client Access Servers

To encrypt the network traffic between messaging clients and the Client Access server, you must secure

the network traffic using SSL. To configure the Client Access server to use SSL, complete the following

steps:

1. Obtain and install a server certificate on the Client Access server. Ensure that the certificate name

matches exactly the server name that users will use to access the Client Access server. Additionally,

ensure that all the client computers and mobile devices that will access the server trust the certificateissued by a certification authority (CA).

2. Configure the Client Access server virtual directories in IIS to require SSL. Secure the following virtual

directories:

• Autodiscover

• ecp

• EWS




• Microsoft-Server-ActiveSync

• OAB

• owa

• RPC

•

RPCWithCert

Configuring Secure Authentication

Exchange Server 2010 provides several authentication options for clients communicating with the Client

Access server. If the server has multiple authentication options enabled, then it negotiates with the client

to determine the most secure authentication method that the options support.

Standard Authentication Options

The following standard authentication options are available on the Client Access server:

• Integrated Windows authentication. Integrated Windows authentication is the most secure standard

authentication option. When users log on with a domain account, they are not prompted for a user

name or password. Instead, the server negotiates with the Windows security packages installed on theclient computer to obtain the user name and password of the logged-on user. Unencrypted

authentication information is not transferred across the network.

Important When using a single Internet-accessible Client Access server for all sites, you

must enable Integrated Windows authentication on all of the Client Access servers that are

not Internet accessible. For example, the outward-facing Outlook Web App server can use

forms-based authentication, but the internal Client Access servers must be configured to

allow Integrated Windows authentication. This is changed from Exchange Server 2007.

• Digest authentication. Digest authentication secures the password by transmitting it as a hash value

over the network. To use Digest authentication, users must have an account stored in AD DS.

• Basic authentication. Basic authentication transmits passwords in clear text over the network.

Therefore, you should always secure basic authentication with SSL encryption. Basic authentication is

the authentication option that is most widely supported by clients. Single sign-on is not supported, so

workstation credentials are never automatically passed over basic authentication.

Forms-Based Authentication

Forms-based authentication is available only for Outlook Web App and Exchange Control Panel, and

when you use this option, it replaces the other authentication methods. This is the preferred

authentication option for Outlook Web App, because it provides enhanced security. With forms-based

authentication, Exchange Server uses cookies to encrypt the user logon credentials in the client

computer's web browser. Tracking the use of this cookie allows Exchange Server to time-out inactive

sessions.

The amount of time required before an inactive session times out varies depending on the computer type

selected during logon. If you choose a public or shared computer, the session times out after 15 minutes

of inactivity. If you choose a private computer, the session times out after 12 hours of inactivity.




Note You can configure the time-out values for public and private computers by

modifying the Client Access server registry. Use the Regedit utility, or the Set-ItemProperty

cmdlet. For more information about how to configure these settings, see the "Set the

Forms-Based Authentication Private Computer Cookie Time-Out Value" topic in Exchange

Server 2010 Help.

Forms-based authentication is enabled by default for Outlook Web App and Exchange Control Panel.

Note In Exchange Server 2010 SP2, if you have enabled cross-site silent redirection, and if

the authentication method for the Outlook Web App virtual directory on both the initial

and redirected Client Access servers is set to forms-based authentication, the user must

enter their credentials only once. However, if the authentication methods differ, the users

may be required to enter their credentials a second time.

Protecting the Client Access Server with an Application Layer Firewall

To provide an additional layer of security for network traffic and to protect the Client Access server,

deploy an application layer firewall or reverse proxy—such as Microsoft Forefront® Threat Management

Gateway or Forefront Unified Access Gateway—between the Internet and the Client Access server.Application layer firewalls provide the following benefits:

• You can configure the firewall as the endpoint for the client SSL connection. The firewall can decrypt

the client traffic, apply application layer filtering, and then re-encrypt the traffic before sending it to

the Client Access server.

• You can offload SSL decryption to the firewall. If you do not require all connections on your internal

network to be secure, you can configure the firewall to decrypt the SSL traffic, but not re-encrypt it

before sending the traffic to the Client Access server. This means that Client Access server resources

are not used to perform SSL decryption and encryption.

• If you use Forefront Threat Management Gateway or Forefront Unified Access Gateway as the

application layer firewall, you can configure the firewall to pre-authenticate all client connectionsusing forms-based authentication. This means that only authenticated connections are allowed into

the internal network.

Note If you are using certificate-based authentication for Exchange ActiveSync, you must

configure a server-publishing rule that forwards the client traffic to the Exchange Server

computer without decrypting the packets on the Microsoft Internet Security and

Acceleration (ISA) Server.




Designing Client Access Server Certificates

Because of the importance of using SSL secure network traffic between Client Access servers and

messaging clients, you must ensure that you deploy the appropriate certificates on the Client Access

servers. You can secure all client connections to the Client Access server using SSL.

Note By default, the Client Access server is configured with a self-signed certificate that is

not trusted by clients. You should remove this certificate and install a certificate from a

trusted CA. Exchange Server 2010 provides a certificate wizard that enables you to install

and manage certificates without having to use the Exchange Management Shell, as was thecase in Exchange Server 2007.

Choosing a Certification Authority

One of the most important considerations when planning to use certificates is identifying the certificate

source. Exchange Server 2010 supports self-signed certificates, certificates issued by a public CA, and

certificates issued by a private CA. Each certificate type has advantages and disadvantages, which are

identified in the following table.

Certificatetype Explanation

Public CA Advantages:

•

Client computers already trust the root CA, so you can chain certificates to theroot without further configuration.

• The public CA provides full certificate and certificate revocation managementservices.

Disadvantage:

• The certificates issued by public CAs are more expensive than self-signedcertificates, or certificates issued by internal CAs.




(continued )

Certificatetype Explanation

Internal CA Advantages:

• Revocation is managed internally, so you can centrally revoke certificates if a

private key is compromised.

• By managing your own CA, you have more flexibility in how you managecertificate distribution.

Disadvantages:

• Implementing an internal CA can be complicated, and the complexity may causesecurity problems if incorrectly managed.

• While the certificates issued by internal CAs are free, the cost of implementingand managing a CA implementation can be higher than buying certificates froma public CA.

• Client computers that are not members of an internal AD DS domain do notautomatically trust the root CA, so you must add certificates for the trusted root-to-client machines, where necessary.

Self-signedcertificates

Advantage:

• You can deploy self-signed certificates without a Public Key Infrastructure (PKI).When you install Exchange Server 2010, it automatically creates a self-signedcertificate for each computer.

Disadvantages:

• No centralized revocation lists. If the certificate’s private key is compromised,each associated party must be notified manually to change to a new certificateand stop relying on the existing one.

• Client computers do not automatically trust the self-signed certificate, so youmust add certificates for the trusted root-to-client machines where necessary.

You can use self-signed certificates for internal communication, such as for securing Simple Mail TransferProtocol (SMTP) connections between Hub Transport servers. You also can use them to secure client

connections to Client Access servers, but because none of the client computers trust these certificates, we

do not recommend this solution. Rather, you should consider obtaining a certificate from a public CA or

internal CA for all Client Access servers.

In most cases, you should deploy a certificate issued by a public CA if users access the Client Access server

from the Internet, to ensure that the clients trust the certificate, and that they have access to certificate

revocation lists from any location.

If only computers that are members of the internal domain access the Client Access server, consider using

an internal, or private CA. By deploying an enterprise CA, you can automate the process of distributing

and managing certificates and certificate revocation lists.

Federation Certificates

The Microsoft Federation Gateway is a free cloud-based service offered by Microsoft and acts as a trust

broker between your on-premises Exchange Server 2010 organization and other federated Exchange 2010

organizations.

If you want to configure federation in your Exchange organization, you must establish a one-time

federation trust with the Microsoft Federation Gateway, so that it can become a federation partner with

your organization.




With this trust in place, users authenticated by AD DS are issued Security Assertion Markup Language

(SAML) delegation tokens by the Microsoft Federation Gateway. These tokens enable users from one

federated organization to be trusted by another federated organization.

If you intend to implement a federation trust with the Microsoft Federation Gateway, with Exchange

Server 2010 SP1, you automatically use a self-signed certificate to create this trust. The self-signed

certificate for this purpose is created automatically and installed on Exchange servers in your organizationwhen you use the New Federation Trust wizard in the Exchange Management Console.

Identifying the Required Client Protocols

While planning the certificate deployment, determine the client protocols that are used to connect to the

Client Access server, and ensure that your certificate is configured for each certificate type.

Planning the Certificate Names

To prevent error messages during client connection to the Client Access server using SSL, the names on

the certificate must match the names that the clients use to connect to the server. For example, suppose

your users connect to the Outlook Web App site with https://mail.contoso.com, and they connect to the

IMAP4 server with IMAP.contoso.com. In this case, the certificates you use must support both

mail.contoso.com and IMAP.contoso.com. Additionally, if you enable Autodiscover access from theInternet, your certificate also must support a name such as Autodiscover.contoso.com.Use the following

options to implement this configuration:

• Obtain a separate certificate for each client protocol that requires a unique name. This may require

multiple certificates for all Client Access servers. This may also require multiple websites in IIS. This is

the most complicated option to configure.

• Configure all clients to use the same server name. For example, you could configure all clients to use

the server name mail.contoso.com, and obtain a certificate for just that one name.

• Obtain a certificate with multiple subject alternative names. Most public CAs support multiple names

in the certificate’s subject alternative name extension. When you use one of these certificates, clients

can connect to the Client Access server using any of the names listed in the subject alternative name.

• Use a certificate with a wildcard name. Most public CAs also support the use of wildcards in the

certificate request. For example, you could request a certificate using the subject of *.contoso.com,

and use that certificate for client connections.

Note Not all clients support wildcard certificates. Office Outlook, Internet Explorer, and

Windows Mobile 6 or newer clients support wildcard certificates, but you need to verify this

functionality for all messaging clients that are used in your organization before deploying

these certificates. Deploying wildcard certificates is also considered a security risk in many

organizations, because the certificate applies to any server name in the domain. If this

certificate is compromised, all host names for the organization are also compromised.




Designing Autodiscover

The Autodiscover service in Exchange Server 2010 simplifies configuration of Office Outlook 2007 or

newer clients and Windows Mobile. Autodiscover provides configuration information that Office Outlook

requires to create a profile for the client. Office Outlook clients use the Autodiscover service to repair

Exchange Server connection settings for corrupted profiles, and for user mailboxes that are moved to

different servers. The Autodiscover service uses email addresses and passwords to provide profile settings

to Office Outlook 2007 or newer clients, and supported mobile devices.

When creating a profile, Autodiscover provides information so that the client can locate various web

services, such as the Availability service, Unified Messaging settings, and OABs.

Consider Modifying the Internal URL

By default, the Autodiscover URL matches the server name where you installed the Client Access server

role — for example, https://cas1.adatum.com/autodiscover/autodiscover.xml.

The Client Access server deployment process registers this name in AD DS by creating a server connection

point that matches the fully qualified domain name (FQDN) of the server with the installed Client Access

server role. Domain-joined computers use this server connection point to locate the Autodiscover service.

Each deployed Client Access server in an organization has its own Autodiscover server connection point

record. The domain-joined Office Outlook 2010 client authenticates to the AD DS site, and searches for

the Autodiscover server connection point objects.

The Office Outlook client obtains and enumerates the Autodiscover service instances, and then connects

to the first Client Access server in the list, obtaining the required profile information — in the form of XML

data — that is needed to connect to the user's mailbox.

https://cas1.adatum.com/autodiscover/

https://cas1.adatum.com/autodiscover/




When you start Office Outlook 2010 on a client that is not connected to the domain, it tries to locate the

Autodiscover service by using DNS. Office Outlook determines the email address suffix of the user — for

example, adatum.com — and checks DNS for two predefined URLs. For example, if your SMTP domain is

adatum.com, Office Outlook attempts to connect to the Autodiscover service with the following two URLs:

• https://adatum.com/autodiscover/autodiscover.xml

•

https://autodiscover.adatum.com/autodiscover/autodiscover.xml

Because the behavior for internal and external clients differs, you may decide that you want to use a

single URL for both your internal and external clients.

To modify the internal Autodiscover URL, use the Exchange Management Shell. Type the following

command, and then press Enter:

Set-ClientAccessServer -Identity “ServerName” -AutodiscoverServiceInternalURI

https://mail.adatum.com/autodiscover/autodiscover.xml

Consider Site Affinity

If your organization has a large distributed wide area network (WAN) supporting AD DS sites that are

connected by slow network links, consider configuring site affinity for the Autodiscover service.

When you configure site affinity on the Client Access server, you enable clients using Office Outlook 2010

and Office Outlook 2010 to retrieve Autodiscover information from the closest AD DS site. This provides

Autodiscover information to the Office Outlook clients more quickly than if site affinity was not set.

To use site affinity, specify which AD DS sites the clients prefer to use to connect to particular

Autodiscover service instances.

To configure site affinity, use a cmdlet similar to the following example:

Set-ClientAccessServer -Identity "ServerName"

-AutodiscoverServiceInternalURI "https://VAN-EX1/autodiscover/autodiscover.xml"

AutodiscoverSiteScope "HeadOffice"

This cmdlet configures the Autodiscover service URL in the HeadOffice site to use the VAN-EX1 server.

Configure DNS

You must configure DNS with the correct information so that external clients can locate the appropriate

Client Access servers. When the Office Outlook client attempts to locate the Client Access server, it f irst

tries to locate the server connection point information in AD DS. If the client is outside the network, AD

DS is not available, so the client queries DNS for a server name based on the SMTP address that the user

provides. Office Outlook queries DNS for the following URLs:

• https://autodiscover.<emaildomain>/autodiscover/autodiscover.xml

• https://<emaildomain> /autodiscover/autodiscover.xml

To enable Autodiscover functionality for external clients, you must configure a DNS record on the DNS

server that the client uses to provide name resolution for that request. The DNS record should point to a

Client Access server that is accessible from the Internet.

https://adatum.com/autodiscover/autodiscover.xml


https://autodiscover/

https://autodiscover/


https://adatum.com/autodiscover/autodiscover.xml




Configure External Host Names

To initiate communications with the Exchange Server messaging system, Office Outlook 2010 requests

certain information from the Autodiscover service—including connection settings and URLs for the

required Exchange services. Exchange Server creates and stores these settings and URLs in AD DS during

setup, and updates them when you configure Exchange Server by using the Exchange Management Shell

or the Exchange Management Console.

Configure the necessary URLs for the Exchange services that you want to provide to external clients. These

services are:

• Outlook Anywhere

• Offline address book

• Unified Messaging

• Exchange Web Services

If you do not configure the external URL values, the Autodiscover service information that is provided to

the Office Outlook 2010 client may be incorrect for clients that are connecting from outside your network.

Note Users may be able to connect to their Exchange Server mailboxes; however, they will

be unable to use Exchange Server features such as Out of Office functionality, the

Availability service, Unified Messaging, and OAB downloads.

Additionally, certificates used to provide security when accessing these services must be correctly

configured with the appropriate hostnames. If multiple URLs are required, the certificate must support

multiple names.

Ensure Autodiscover Virtual Directory Is Accessible

After deploying and configuring Autodiscover, you must test the service. You can use the Test Email

AutoConfiguration feature in Office Outlook 2010 to test whether or not Autodiscover is working

correctly. To use this feature, complete the following steps:

1.

Open Office Outlook 2010 using a profile that can connect to a Mailbox server.

2. Press and hold the Ctrl key, click the Office Outlook icon in the notification area of the Windows task

bar, and then click Test E-mail AutoConfiguration.

3. Enter your email address and password in the respective text boxes.

4. Clear the Use Guessmart and Secure Guessmart Authentication check boxes. Guessmart automates

the process of configuring Outlook 2010 as an IMAP4 or POP3 client.

5. Click AutoConfigure, and then click the Log tab to view detailed information on how the client

attempts to complete the autoconfiguration.




Designing the Availability Service

The Availability service enables Outlook Web App and MAPI clients to access free/busy information. These

clients use Autodiscover to obtain the URL for the Availability service. By default, the Availability service

uses the URL http:// servername /EWS.

By default, the Availability service deploys on all Client Access servers, and you do not usually need to

configure it except in scenarios in which you are integrating the free/busy information from multiple

forests.

Design Considerations for the Availability ServiceConsider the following when designing the Availability service:

• Legacy clients. Office Outlook 2003 and earlier clients do not use the Availability service for accessing

free/busy information. These clients must use system public folders to determine availability.

Exchange Server 2003 uses a public folder called SCHEDULE+FREE BUSY to disseminate availability

information. If you have only Office Outlook 2007 or newer clients, then you do not need to use this

public folder-based mechanism for sharing and determining availability information.

• Cross-forest configurations. In Exchange Server 2003, sharing availability information between forests

is complex, and requires directory synchronization and additional tools such as the Inter-organization

Replication (IORepl) tool. Exchange Server 2010 supports cross-forest availability features without

these requirements.

You can select the granularity of free/busy information between forests when you configure cross-

forest availability. Choose between per-user and organization-wide granularity.

Per-user free/busy information is only supported in a trusted cross-forest topology. It enables the

Availability service to make cross-forest requests on behalf of a particular user, and it also enables

users in a remote forest to grant detailed free/busy information to other cross-forest users.

http://servername/EWS







With organization-wide free/busy data, the Availability service makes cross-forest requests only on

behalf of particular organizations. It returns users’ default free/busy information, and you cannot

control the level of free/busy information that it returns to users in other forests.

To ensure proper cross-forest availability, you must:

• Synchronize the GAL between forests. You can use the GAL Synchronization (GALSync) tool for

this requirement.

• Ensure that the Autodiscover service is working between forests. In cross-forest scenarios, the

Autodiscover service provides information to the Availability service by locating and providing

the external and internal URLs for the Office Outlook client and the Client Access server, for

cross-forest availability. Consequently, Client Access servers must be able to connect to the

Autodiscover service on the target forest to determine the target forest’s Availability URL.

When configuring your Autodiscover service to support cross-forest availability scenarios, select

from between two options:

• If the forests trust each other, then export the server connection point from the target to the

source forest.

•

Otherwise, use DNS to resolve the autodiscover.targetforest.com website address.

• Ensure that all Client Access servers can validate the certificate on the target forest. We recommend

that you use a third-party certificate from an authority that both parties trust.

Note Because the Availability service is the only method for sharing cross-forest

availability information, and because Office Outlook 2003 clients do not use the Availability

service, legacy clients cannot access free/busy information from a remote forest unless you

replicate the content of the SCHEDULE+FREE BUSY public folder between forests. Use

IORepl to synchronize free/busy data across multiple forests.




Designing MailTips

MailTips inform users about issues or limitations with their outgoing messages. Exchange Server 2010

analyzes the messages — including the list of recipients to which they are addressed — and if it detects

potential problems, notifies users with MailTips. Senders can use the MailTips feedback to adjust their

message, and thus avoid undesirable situations or non-delivery reports (NDRs).

How MailTips Work

MailTips is a web service provided by Exchange Server 2010. When a sender composes a message, the

client software performs an Exchange Web Services service call to the Exchange Server 2010 server withthe installed Client Access server role. The Exchange Server 2010 server responds with the list of MailTips

that apply to that message, and the client software displays the MailTips to the sender.

The Client Access server uses the following sources to compile MailTips for a specific message:

• AD DS

• Recipient mailboxes

• Local group metrics data

To ensure MailTips is optimized, you should understand how the Client Access server role interacts with

these services.

Group Metrics DataGroup metrics provide the following information:

• Number of members

• Number of members who are external to your organization




The Client Access server role uses group metrics data when deciding whether to display the following

MailTips:

• Large Audience. Displays when a sender adds a distribution group with a large membership count as

defined by your organization.

Note By default, any message addressed to more than 25 recipients is considered a largeaudience.

• External Recipients. Displays when a sender adds a distribution group that contains members who are

external to your organization.

Exchange Server evaluates MailTips each time senders add recipients to their messages, but it does not

calculate group metrics data as users compose their messages, because this could have an adverse impact

on performance. Instead, Exchange Server calculates group metrics data as a background process that you

can schedule to run during non-business hours.

Note By default, the Mailbox server that generates the OAB also generates the group

metrics data.

The Microsoft Exchange File Distribution Service distributes group metrics data. The service queries AD DS

for a list of Mailbox servers that are enabled for group metrics generation, and then copies the group

metrics data from the closest Mailbox server every eight hours.

AD DS and the Mailbox Server

When the mail client queries Client Access server, the Client Access server compiles the list of applicable

MailTips and returns all of them so the user can view them at the same time.

The Client Access server uses the following process to compile MailTips for a specific message:

1.

The mail client queries the web service on the Client Access server for MailTips that apply to therecipients in the message.

2. The Client Access server gathers MailTips data:

• The Client Access server queries AD DS, and reads group metrics data.

• The Client Access server queries the Mailbox server to gather the Recipient Out-of-Office and

Mailbox Full MailTips. If the recipient's mailbox is on another site, then the Client Access server

requests MailTips information from the Client Access server in the remote site.

3.

The Client Access server returns MailTips data back to the client.

For best performance, the Client Access server must have high-speed and reliable connectivity to both the

AD DS site and the Mailbox servers.

Note You can enable MailTips over an organization relationship between your Exchange

Server environment and Exchange Online, or another organization. With Exchange Server

2010 SP1, you have granular control over which MailTip types are returned over the

organization relationship in addition to just allowing or preventing returning MailTips.




Designing Client Throttling

Client throttling is a technology designed to ensure that users do not overload the Exchange Server

messaging system. It also helps to ensure that users connected to Exchange Server from a variety of

client-types, share system resources equitably.

Exchange Server provides a default client throttling policy that may be sufficient for most organizations.

However, you can create additional client throttling policies or modify the default policy as your

organizational needs dictate.

Client throttling tracks resource consumption on a per-user basis, which enables you to create —

ifnecessary — 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

• Exchange Web Services

• IMAP4

• POP3

• Outlook Web App

•

Windows PowerShell®

For each of these components, you can configure the following client throttling policy parameters:

• MaxConcurrency. Indicates how many concurrent connections a user can have against an Exchange

server. If a user tries to make more connections than allowed by the policy, the new connection

attempts fail. Use a value between 0 and 100. To unthrottle this component, specify the value $NULL.




• PercentTimeInCAS, PercentTimeInAD, PercentTimeInMailboxRPC. For each of these parameters,

define a percentile value. For example, if you use the value 100, then in each minute, a client can

consume 60 seconds of resource time. To unthrottle these components, specify the value $NULL.

Note PercentTimeInCAS is an overlapping superset of both PercentTimeInAD and

PercentTimeInMailboxRPC. This is because for the Exchange Server component to make anAD DS or RPC call, it must already be running Client Access server code. Additionally, the

expenditure in processing time for PercentTimeInCAS does not stop while Lightweight

Directory Access Protocol (LDAP) or RPC calls are being made. Consequently, you must set

the PercentTimeInCAS value higher than both the PercentTimeInAD and

PercentTimeInMailboxRPC values for a given component.

• PowerShellMaxConcurrency. Defines the maximum number of remote shell sessions that a user can

have open at one time.

• PowerShellMaxCmdlets. Defines the maximum number of cmdlets that a user can run over the time

period.

•

PowerShellMaxCmdletsTimePeriod. Defines the time period, in seconds, that the user can run themaximum number of cmdlets as defined by the PowerShellMaxCmdlets parameter.

• PowerShellMaxCmdletQueueDepth. Defines the number of operations that a user can run at the same

time.

Note The PowerShellMaxCmdletQueueDepth parameter directly affects the behavior of

the PowerShellMaxCmdlets and PowerShellMaxConcurrency parameters. For example, the

PowerShellMaxConcurrency parameter consumes at least two of the operations defined by

the PowerShellMaxCmdletQueueDepth parameter, but additional operations are also

counted against the throttling limit each time you run the cmdlet. The number of

operations that count toward the throttling limit depends on the cmdlets that you run.

Configure the PowerShellMaxCmdletQueueDepth parameter to at least three times larger

than the value of the PowerShellMaxConcurrency parameter.

You can use the performance monitor to examine how throttling governs the overall usage of system

resources.

Note Exchange Server 2010 SP1 introduced a number of client throttling behavioral

changes. For example, in Exchange Server 2010 SP1, all client throttling policies are enabled

by default. For further information about this and other client throttling changes introduced

by Exchange Server 2010 SP1, see the Microsoft TechNet website.




Designing Client Access Services with Multiple Namespaces

Before deploying Exchange Server 2010, you must consider how you will implement your external

namespaces. A namespace is a logical structure represented by a DNS domain name, such as adatum.com.

The decisions you make about your DNS namespace impact:

• DNS configurations

• Digital certificates

• Client configurations

Selecting a Namespace Model

Align your namespaces with your site configuration. In particular, consider implementing a separate

namespace for each site that contains an Internet-facing Client Access server. You can configure Exchange

Server 2010 according to one of the following organizational models:

• Centralized data center. All servers are located within one physical site with a single namespace, such

as mail.adatum.com. With this model, there are few DNS records to configure, fewer certificates to

manage, and only one URL for client computers. However, this model does not support multiple data

centers.

• Single namespace with proxy sites. Only one site contains an Internet-facing Client Access server.

Consequently, this model uses only one namespace. With this model, you must configure fewer DNS

records, manage fewer certificates, and client computers use only one external URL. However,because there are potentially many sites that do not contain an Internet-facing Client Access server,

many users will access their mailboxes using a proxy.

• Single namespace and multiple sites. Each site may have an Internet-facing Client Access server, or

there may be only one site that contains Internet-facing Client Access servers. In this model, the sites

use one namespace. Again, because there is a single namespace, DNS and certificates are easier to

manage, and client computers use a single external URL. However, this model also suffers from the

same disadvantages as those of the single namespace with proxy sites.




• Regional namespaces. This model consists of multiple physical sites and multiple namespaces. For

example, a site located in Seattle might have the namespace mail.usa.adatum.com, while a Vancouver

site might have the namespace mail.canada.adatum.com. This model reduces proxying, but there are

more DNS records and certificates to manage. Additionally, client computers must be configured with

the appropriate external URL.

•

Multiple forests. This model consists of multiple forests that have multiple namespaces. Anorganization that uses this model could be made up of two partner companies. Namespaces might

include mail.usa.adatum.com, and mail.europe.contoso.com.

Proxying and Redirection

Proxying occurs between two Client Access servers when you designate one Client Access server as an

Internet-facing server, in an organization with multiple sites. The Internet-facing Client Access server

proxies requests to Client Access servers in sites that have no Internet presence. For example, when a user

uses Outlook Web App to request mailbox access, the Internet-facing Client Access server proxies the

request to the Client Access server closest to the user's mailbox.

Exchange Server supports proxying for clients that use Outlook Web App, Exchange ActiveSync, Exchange

Web Services, POP3, and IMAP4 clients.

As an alternative to proxying, you can configure the Internet-facing Client Access server to redirect clients.

For example, when an Outlook Web App user connects to a Client Access server outside the AD DS site

that hosts the Mailbox server, the user sees a webpage that contains a link to the correct Client Access

server for the user’s mailbox.

Note To enable redirection, if your Client Access server is Internet-facing, configure the

ExternalURL property on the Outlook Web App virtual directories using the Exchange

Management Console or the Exchange Management Shell. You must also configure the

authentication method on these virtual directories to be Integrated Windows

authentication. If your organization has multiple Internet-facing AD DS sites and the

Internet connection to one of those sites is disabled, you can temporarily disable

redirection, and then configure Outlook Web App to use proxying instead. After theInternet connection in the site that has the problem is restored, you can reinstate

redirection. You can enable and disable redirection using the Set-OWAVirtualDirectory

cmdlet.

Only Outlook Web App clients support redirection.




Lesson 3

Designing Client Access

The type and version of client that you implement affects the deployment and configuration choices that

you make. This lesson explores the particular considerations for each client-type.


• Design MAPI client access.

•

Design Outlook Anywhere access.

• Design Outlook Web App and Exchange Control Panel.

• Design Exchange ActiveSync access.

• Design POP3 and IMAP4 access.

• Design firewalls and reverse proxies for client access.




Designing MAPI Client Access

The Client Access server role supports connections from RPC and MAPI clients such as Office Outlook

2007 and Office Outlook 2010; this was not the case with Exchange Server 2007, where MAPI clients

connected directly to the Mailbox server role. The MAPI client access change in Exchange Server 2010

provides consistency and improved failover scenarios for MAPI clients.

Benefits of MAPI Client Access

MAPI client access benefits your organization as follows:

•

Consistency. All clients now use the Client Access server to access their mailbox.

• Availability. If you deploy highly available Mailbox servers, clients can fail over more quickly to an

alternate Mailbox server. When the failover occurs, the Mailbox server notifies the Client Access

server, and the clients are redirected to the alternate Mailbox server within seconds.

• Performance. The new architecture supports more concurrent client connections.

• Convenience. You can move user mailboxes between Mailbox servers even when the client is online

and connected.

You do not need to change your configuration if your users run Office Outlook 2007 or Office Outlook

2010. However, if your users use Office Outlook 2003 SP1 or earlier, you must adjust the Office Outlook

client configuration changes to support MAPI client access. Specifically, you must enable RPC encryption

on the client by either changing the Exchange Server account settings in Office Outlook, or by using aGroup Policy object to deploy the configuration change.

Disabling MAPI Access

To disable all or some MAPI client types from connecting to Exchange Server, create the following registry

value on the Mailbox server:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\

ParametersSystem\Disable MAPI Clients




You can disable a specific MAPI client version by entering its version number. You can also specify a range

of version numbers.

• To disable a specific MAPI client version, type: 12.1234.01

• To disable a range of MAPI client versions, type: 11.1234.01-12.1234.01

Note To determine the MAPI client version for Office Outlook clients, view the file version

for the Emsmdb32.dll file. The Emsmdb32.dll file version is listed as X.Y.Z, and you must

enter this version value as X.Y.Z in the registry. For example, if the version is 12.0.4407.1004,

then enter 12.4407.1004 in the Disable MAPI Clients registry. Server-side Exchange Server

components also use MAPI to log on. Some components report their client version as an

Exchange build number; consequently, ensure that you do not restrict 6.x.x on an Exchange

server.

You can disable MAPI access for a specific user, mailbox, or for all mailboxes on a specific server. Use the

Exchange Management Console or the Exchange Management Shell to perform this task.




Designing Outlook Anywhere Access

You may decide to implement a single Office Outlook client within your organization so that users —

whether they are internal or external — use a single interface to access their email and related content.

Outlook Anywhere uses RPC over HTTPS to enable users connected to the Internet to access Exchange

Server with Office Outlook 2007 or Office Outlook 2010. To support Outlook Anywhere within your

organization, note the following:

• Configure Autodiscover. Autodiscover provides the necessary URLs for Outlook Anywhere clients. If

you do not configure Autodiscover settings correctly, Outlook Anywhere clients may fail to connectto users’ mailboxes, or else may connect but provide limited or reduced functionality.

• Remember that Client Access redirection is not supported. In a multi-site environment, you may need

to configure an Internet-facing Client Access server in each site that supports Outlook Anywhere

clients. Alternatively, configure Client Access proxying.

• Enable Outlook Anywhere on at least one Client Access server per site. Users connect to the Client

Access server that is in the site that also hosts the Mailbox server containing their mailboxes.

• Plan certificates carefully. You can use the same SSL server certificate that you use for both Outlook

Web App and Exchange ActiveSync to secure Outlook Anywhere. During installation, Exchange Server

2010 creates a default virtual directory named Rpc on the default IIS website on the Client Access

server. The Rpc virtual directory uses SSL to manage security for Outlook Anywhere and external

client access.

Note Bear in mind that if you use multiple Client Access servers—each in a different site

and each with different names—you should obtain a certificate that can support multiple

names. You may use a single certificate if you add all the possible DNS name values to the

certificate Subject Alternative Name property on the certificate request. Some CAs support

wildcard names for a particular domain suffix—for example, *.adatum.com.




• Configure firewall. Outlook Anywhere uses TCP port 443 for communication. To ensure proper

functionality, this port must be open on all firewalls through which Outlook Anywhere traffic passes.

This is the same Transmission Control Protocol (TCP) port used by Outlook Web App and many other

common web-based applications.




Designing Outlook Web App and Exchange Control Panel

Exchange Server 2010 uses Outlook Web App to provide users with web browser access to their

mailboxes. The Outlook Web App feature set is similar to those available in Office Outlook 2010.

Note Exchange Server 2010 SP2 provides a mini version of Outlook Web App. The mini

version of Outlook Web App is a l ightweight, browser-based client, similar to the Outlook

Mobile Access client in Exchange 2003. It is designed to be used on a mobile operating

system. The mini version of Outlook Web App provides users with basic messaging and

calendaring functionality.

Outlook Web App in Exchange Server 2010 includes features such as chat, text messaging, mobile phone

integration, and enhanced conversation view. You can access these features from an expanded set of web

browsers, including Internet Explorer® 6.0 or later, Firefox, Safari, and Chrome.

Outlook Web App provides many important benefits for an organization, including:

• Communication through HTTP. You can easily secure the connection using SSL. Additionally, you will

probably not need to reconfigure your firewalls, because HTTP is a widely implemented protocol.

• No need to deploy client software. All client computers—including computers that run Linux or

Macintosh—provide a web browser. Consequently, users can access their mailboxes from any client

that can access the Client Access server’s URL.• Direct access to unique features. You can access features such as the archive mailbox or conversation

view through Outlook Web App, without deploying Office Outlook 2010.

Outlook Web App cannot provide offline access to mailboxes. If the Exchange server hosting Outlook

Web App is offline, users cannot read or send messages. If offline access to files is required, you must

select another remote access method to the Exchange server. Outlook clients using Outlook Anywhere,

ActiveSync, POP3, and IMAP4 clients can cache messages to provide offline access.




The Exchange Control Panel is a web–based management interface that you can use to enable self–service

for mailbox users. Users can perform specific management tasks without having access to the entire

Exchange Management interface.

Design Considerations for Outlook Web App and Exchange Control Panel

When planning the deployment for Outlook Web App and Exchange Control Panel, consider the

following:

• Authentication. Select a suitable authentication method. The Outlook Web App and Exchange

Control Panel virtual directories support the following authentication methods:

• Integrated Windows authentication

• Digest authentication

• Basic authentication

• Forms-based authentication

• Virtual directory segmentation. Segmentation lets you enable and disable features that are available

to users in Outlook Web App. By default, all mail-enabled users in your Exchange organization can

access their mailboxes by using Outlook Web App. Depending on the needs of your organization, you

can use segmentation to configure the following restrictions for user access:

• Control access to certain Outlook Web App features for specific users.

• Disable an Outlook Web App feature completely.

• Advanced security options. Aside from the standard security measures that you must implement—

such as configuring SSL on both the Outlook Web App and Exchange Control Panel virtual

directories—also consider configuring Outlook Web App to support secure MIME (S/MIME).

S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who

have a digital identifier (ID) can read them. With S/MIME, users can digitally sign a message, which

allows recipients to verify both the sender’s identity, and that no one has tampered with the message.

S/MIME requires users to sign in to Outlook Web App using either Internet Explorer 7 or Internet

Explorer 8. Users must have a digital ID, and must install the S/MIME control for Outlook Web App

before they can send encrypted and digitally-signed messages through Outlook Web App. They must

also have both a digital ID and the S/MIME control to read encrypted messages in Outlook Web App.

The S/MIME control is necessary for signature verification on a digitally signed message. Use the

SMIME tab in the Options menu to install the S/MIME control for Outlook Web App on a user’s

computer.

• Outlook Web App virtual directory options. When deploying Outlook Web App and Exchange

Control Panel, consider the following virtual directory options:

• Simplify the Outlook Web App URL. You can use the IIS Manager to simplify the Outlook Web

App URL that users use to access their mailboxes.

• Configure the default website to redirect clients to the Outlook Web App virtual directory.

For example, when a user types https://servername/ , IIS redirects them to

https://servername/ owa.

• Alternatively, redirect users that use the form http:/servername/ to use SSL, and connect to

the Outlook Web App virtual directory. For example, when a user types http://servername/ ,

IIS redirects them to https://servername/owa.

https://servername/

https://servername/

http://servername/

https://servername/owa

https://servername/owa

http://servername/

https://servername/

https://servername/




• Redirect requests. If you have multiple AD DS sites that have Internet-facing Client Access servers,

use redirection to route users to the Client Access server that gives them the best Outlook Web

App experience. If you have multiple Client Access servers in different AD DS sites in an

organization, but only one Internet-facing server, use Client Access server-to-Client Access server

proxying to direct users to the Client Access server that will give them the best Outlook Web App

experience.

• Create new Outlook Web App virtual directories. For most organizations, the default Outlook

Web App virtual directory that Exchange Server creates during Client Access server role

installation is sufficient. Businesses that provide hosting services may choose to create new

Outlook Web App virtual directories.




Designing Exchange ActiveSync Access

Exchange Server 2010 supports mobile devices used as messaging clients. You can synchronize mailbox

content and perform most of the same tasks with mobile devices as you can with other messaging clients.

Note Exchange Server 2010 SP1 enables mobile device users to synchronize their text

messages with their Exchange Server mailbox. The Short Message Service (SMS) Sync

feature works with Windows Mobile 6.1 with the Outlook Mobile Update and with Windows

Mobile 6.5. When synchronizing text messages, users are able to send and receive text

messages from their Inbox; this feature is dependent on the user's mobile phones or devicessupporting this feature.

Consider the following factors when designing access to Exchange ActiveSync.

• Configure Autodiscover. Exchange ActiveSync clients use Autodiscover to retrieve configuration

information. It is important to properly configure Autodiscover to provide the correct information.

• Verify that SSL is enabled for mobile device connections. To ensure that the communication between

the mobile device and the Client Access server is secure, ensure that you configure the Microsoft-

Server-ActiveSync virtual directory to require SSL.

• Install certificates on mobile devices. Just like desktop computers, mobile devices are configured to

trust the root certificates for most public CAs. If you use an SSL certificate from a trusted commercialCA, you might not have to install the certificate on your device; most devices have certificates from

several trusted commercial CAs preinstalled in the device’s root store. However, if you choose to use

an internal CA to provide certificates for your Client Access servers, you must configure the mobile

devices to trust the root CAs by installing the root certificates on the device.




• Implement Exchange ActiveSync policies. Exchange ActiveSync policies provide one option for

securing mobile devices. When you apply the policy to a user, the mobile device automatically

downloads the policy the next time the device connects to the Client Access server. To ensure that

mobile devices are as secure as possible, configure Exchange ActiveSync policies that require device

passwords, and encrypt the data stored on the mobile device.

Note All users are initially assigned to the default ActiveSync policy.

• Configure your firewall to support Direct Push. Direct Push provides notification to the mobile phone

when new content is ready to be synchronized to the device. For Direct Push to work through your

firewall, you must open TCP port 443 between the Internet and the Client Access server. In addition to

opening ports on your firewall, for optimal Direct Push performance, increase the time-out value on

your firewall from the default to 15 to 30 minutes.

Note It is possible to disable Direct Push for users that are roaming.

•

Consider data plans when configuring client settings. Select an appropriate data plan for your mobiledevices that provides sufficient bandwidth for the desired services. Alternatively, tailor the services

that you provide to mobile device users based on the characteristics of their device data plan.




Designing POP3 and IMAP4 Access

Previous email solutions often used POP3, and later IMAP4, for email retrieval. Various Microsoft products,

including Office Outlook Express and Windows Mail, still support these mail retrieval protocols.

Be sure to consider whether support for these protocols is relevant for your organization. Exchange server

does support many client types, and perhaps these other client types might be more relevant to your

users.

By default, Exchange Server 2010 supports POP3 and IMAP4 client connections, but you must start the

services manually. To enable user access for these protocols, start the services, and then configure them tostart automatically.

Configuration Options

You can configure the following settings for POP3 and IMAP4.

Option Description

Bindings Configures the local server addresses that will be used for unencrypted TransportLayer Security (TLS) or SSL connections.

Authentication Configures the supported authentication options, such as basic authentication,Integrated Windows authentication, and secure logon requiring TLS. The defaultsetting is secure logon.

Connectionsettings

Configures server settings, such as time-out settings, connection limits, and thecommand relay or proxy target port (used for connections to an Exchange Server2003 back-end server).

Retrieval settings Configures the message formats used for the protocols, and configures how clientswill retrieve calendar requests.

User access Enables or disables access for the POP3 and IMAP4 protocols for each user account.By default, all users are access-enabled.




In addition to configuring the POP3 and IMAP4 services to automatically start, you must open the

required ports on your firewall. These ports are:

• POP3: 110 and 995 (SSL)

• IMAP4: 143 and 993 (SSL)

Consider using a reverse proxy to publish these protocols.Remember that although the clients retrieve messages by using either POP3 or IMAP4, they must send

messages using SMTP. You must provide a SMTP connector for POP3/IMAP4 client use, or else confirm

that users with these clients have access to a third-party SMTP relay, such as one provided by their

Internet service provider.

If you decide to provide SMTP within your organization, you may wish to use an Edge Transport server to

fulfill this role. However, you cannot configure the Edge Transport server to support authenticated

connections using internal AD DS accounts.

Consequently, you may choose to configure a Hub Transport server to provide this functionality. By

default, all Hub Transport servers implement a Client servername SMTP connector called Client

servername that supports authenticated connections over TCP port 587. You must open this port on your

firewall. Consider using a reverse proxy to publish this protocol.

Securing SMTP Connections

To secure the SMTP connections to the Hub Transport server, complete the following steps:

1.

Enable TLS for SMTP client connections. Configure the SMTP Receive connector on the Hub Transport

server to either require TLS security, or to enable basic authentication, but only after you initiate a TLS

session. If your SMTP service has a trusted certificate, you should enable these options, and then

configure all clients to use TLS.

2.

Use the Client Receive connector (port 587), and configure the Hub Transport servers with two

Receive connectors. The default Receive connector uses port 25, while the Client Receive connector

uses port 587. By default, both connectors require TLS security, and allow users to connect to the

connector. However, by using the Client Receive connector, you can avoid using the default SMTP

port for client connections. As described in RFC 2476, port 587 was proposed only for message

submission use from email clients that require message relay.

3.

Ensure that anonymous relay is disabled. Both of the default Receive connectors block anonymous

relays. Do not modify this option on any Receive connector that is accessible from the Internet. If you

enable anonymous relay, anyone can use your server to relay spam.

4. Enable POP3 and IMAP4 selectively. If only some users in your organization require POP3 and IMAP4

access, then disable this option on all other mailboxes.




Designing Firewalls and Reverse Proxies for Client Access

Most organizations have firewalls that protect their internal networks from unwanted Internet access. You

can configure these firewalls to enable users to connect to the required virtual directories and services on

the Client Access server, and to provide access to an SMTP server for IMAP4 and POP3 clients.

Implementing a firewall solution means that you need to configure the messaging clients to use a server

name that resolves to an external IP address on the firewall. Users that are connected to the Exchange

servers from both inside and outside the organization can complicate the messaging client configuration.

For example, users may connect to the Exchange servers from the internal network using the actual server

name, but may need to use a more generic name —

such as mail.contoso.com —

when connecting to theserver from the Internet. You may need to instruct users to use the two server names, or you may need to

configure the internal DNS zone to provide name resolution to the more generic name.

Configuring firewalls to provide access to the Exchange servers is fairly easy, but does raise potential

security issues. Standard firewalls filter network traffic based on source and destination IP addresses and

ports, but cannot analyze the contents of network packets. A standard firewall may use reverse Network

Address Translation (NAT), but still forward the packets directly to the Client Access server. This means

that the traffic that the firewall forwards to the internal Exchange servers may contain malicious code that

it did not detect.

As an alternative to the standard firewall, you can use a reverse proxy or an application layer firewall to

enable access to the internal Exchange servers. Reverse proxies provide an additional layer of security for

network traffic, and protect the Client Access servers. They terminate all client connections, and scan all

network packets for malicious code. The reverse proxy then initiates a new connection to the Client Access

server, and forwards the traffic to the internal network.

To use a reverse proxy, you must configure messaging clients to use a server name that resolves to an

external IP address on the firewall.




Reverse proxies—such as Microsoft Internet Security and Acceleration (ISA) Server 2006 or Forefront

Threat Management Gateway—provide the following benefits:

• You can configure the firewall as the endpoint for the client SSL connection. The firewall decrypts the

client traffic, applies application-layer filtering, and then re-encrypts the traffic before sending it to

the Client Access server.

•

You can offload SSL decryption to the firewall. If you do not require all connections on your internal

network to be secure, you can configure the firewall to decrypt the SSL traffic, but not re-encrypt it

before sending the traffic to the Client Access server. This means that the Client Access server

resources are not used to perform SSL decryption and encryption.

• You can use ISA Server or Forefront TMG forms-based authentication. If you use ISA Server 2006 or

Forefront TMG as the application layer firewall, you can configure the firewall to pre-authenticate all

client connections using forms-based authentication. This means that only authenticated connections

are allowed into the internal network.

Note If you use certificate-based authentication for Exchange ActiveSync, you must

configure a server-publishing rule that forwards the client traffic to the Exchange Server

computer without decrypting the packets on the ISA Server computer.

In addition to using ISA Server or Forefront TMG to configure forms-based authentication, you also can

use these tools to publish Outlook Web App servers by using mail-server publishing rules, and to control

email attachment availability to protect your organization’s resources when users access them through

Outlook Web App. Configuring authentication on the reverse proxy ensures that network traffic enters

your internal network only after user authentication.




Lesson 4

Designing Client Access Policies

Many organizations provide employees with the option to access their Exchange Server mailboxes with

mobile devices. However, this can raise security concerns, because mobile devices may contain a large

amount of confidential information, and they are easily lost or stolen. Therefore, it is essential to define

security policies for mobile device management.


•

Design Outlook Web App mailbox policies.

• Describe the options for managing mobile devices.

• Design security policies for mobile devices.

• Design policies for device management.




Designing Outlook Web App Mailbox Policies

After analyzing your organization’s business needs, modify the Outlook Web App virtual directory settings

to address most users’ requirements. These settings include:

• Authentication

• Segmentation

• Public computer file access

• Private computer file access

• Remote file servers

Once you have configured most users’ settings, consider modifying the properties of the default Outlook

Web App Mailbox policy. Outlook Web App mailbox policies enable you to configure the following

settings:

• Segmentation

• Public computer file access

• Private computer file access

Finally, after modifying the default Outlook Web App Mailbox policy, create additional policies to address

the needs of specific users or groups of users. You can assign the policy through the Exchange

Management Console using the Exchange Management Shell. For example, if you wish to configure users

in the Executives organizational unit (OU) with the Executive Policy Outlook Web App Mailbox Policy, use

the following command:

Get-Mailbox -OrganizationalUnit Executives | Set-CASMailbox -owamailboxpolicy "Executive

Policy"




Considerations for Designing Outlook Web App Mailbox Policies

Exchange Server 2010 provides several configuration options for managing access for Outlook Web App

users. These configuration options include:

• Configuring SSL for secure communication. By default, the Outlook Web App virtual directory

requires SSL for all connections. The default certificate installed on the Client Access server is a self-

signed certificate. Remove the default certificate and install a certificate from a trusted CA to ensurethat users can access the site without being prompted to accept the security certificate. When you

request the certificate from the CA, ensure that you use a FQDN for the certificate that matches the

FQDN that users will connect to when accessing Outlook Web App.

• Configuring authentication. The Client Access server supports several types of authentication for

Outlook Web App. The most secure option is forms-based authentication, which uses a cookie-based

authentication system. This cookie is configured to time out after a specified period of client

inactivity, so that the user credentials do not remain valid on the client computer. The user can log

out of Outlook Web App at any point, which removes the cookie from the computer memory.

• Configuring access to attachments. You can configure the types of attachments that users can

download with Outlook Web App. You also can block access to attachments based on file extension

or MIME type. If you allow users to download and view attachments, be aware that the attachmentswill be stored on the local computer.

As an alternative to allowing users to download attachments, consider configuring WebReady

Document Viewing as a requirement. This feature converts attachments with supported file

extensions or MIME types to HTML, and displays them so that users can read them but not download

or edit them. If your organization requires a high level of security for message attachments, consider

implementing WebReady Document Viewing.

Note To prevent users from directly accessing files, in addition to enabling the Force

WebReady Document Viewing option, you also must clear the Enable direct file access

option.




Options for Managing Mobile Devices

One of the most common ways users access their mailboxes is with mobile devices, such as cell phones

and personal digital assistants (PDAs). However, these mobile devices present a serious security risk.

Exchange Server 2010 provides several options for managing these devices.

Requirements for Mobile Device Policies

Mobile clients—such as Exchange ActiveSync clients—have unique security requirements. Mobile clients

are susceptible to loss and theft, because the devices are small and portable. Additionally, these devices

may contain highly confidential information, because company executives often carry them. The storagecards that fit into mobile device expansion slots store increasingly large amounts of data. While this data-

storage capacity is important to the mobile device user, it also heightens the concern that unauthorized

users may be able to access the data.

Using Exchange ActiveSync Policies to Manage Mobile Devices

Exchange Server 2010 provides Exchange ActiveSync policies as one option for securing mobile devices.

You can set security restrictions on devices by configuring the applicable policies, and applying them to

user mailboxes. These security restrictions include configuring requirements for password length and

complexity, and permissions for downloading attachments to devices.

When you apply the policy to a mailbox, the Exchange ActiveSync policy downloads automatically to the

mobile device the next time it connects to the Client Access server.




Managing Mobile Devices

You also can manage mobile devices with either the Exchange Management Console or the Exchange

Management Shell. You generally use these tools when users report lost or stolen devices. The console

and the shell enable you to:

• View a list of all mobile devices for each user.

• Send a remote wipe command to the mobile device, which removes all data on the mobile device

and sets the device back to the factory default settings.

• Delete an old or unused partnership between devices and users.

You also can manage other settings to ensure that the connections are secure from the mobile device to

the Client Access server. At a minimum, you should configure a server certificate from a trusted CA on the

Client Access server, and configure ActiveSync to require SSL for all connections. Additionally, you can

configure the virtual directory to require client certificates for authentication. When you enable this

option, only clients with approved certificates can connect to the Client Access server using Exchange

ActiveSync.

You can manage which device types can connect to the Client Access server. To support features such as

Exchange ActiveSync mailbox policies, the mobile client must be running Windows Mobile 5.0 with theMessaging and Security Feature Pack, or a newer version of Windows Mobile. To ensure that the policies

apply to all mobile clients, you can prevent connections from all devices that do not meet this minimum

requirement.

You also can manage Exchange ActiveSync access for individual user accounts. By default, all users are

enabled for Exchange ActiveSync, but you can disable this setting on each user mailbox.

Note From Exchange Server 2010 SP1, you can manage Exchange ActiveSync devices

using the Exchange Control Panel (ECP).




Designing Exchange ActiveSync Policies

Exchange ActiveSync policies are one of the most important ways to implement mobile device security in

Exchange Server 2010. You can configure password policies for mobile devices by configuring Exchange

ActiveSync policies.

Exchange ActiveSync Policy Options

Exchange ActiveSync policies include settings such as:

• Password complexity requirements, password length, password expiration, and the time-out value

before users must re-enter their password.

• Restrictions on downloading attachments to mobile devices.

• Requirements for data encryption on mobile devices.

• The number of times users can enter the wrong passwords before their devices are locked or wiped.

• Storage of the device’s recovery password on an Exchange server. If you select this option, you can

view the password from either Outlook Web App or the Exchange Management Console.

Considerations for Configuring Exchange ActiveSync Policies

Balance usability with security when configuring Exchange ActiveSync policies. For example, you can

configure a policy that requires a high security level by requiring long, complex passwords that users need

to change frequently. Also, you can configure a low lockout value for incorrect passwords. However, asyou increase the security level required by a policy, users are more likely to experience usability issues.

Higher password security tend to increase device lockout incidences, and Exchange administrators are

likely to spend more time recovering or resetting passwords, causing increased user dissatisfaction. Lower

security levels tend to increase user satisfaction, but also increase the chances of serious security breaches.

As part of the design process, you need to negotiate a security level that is acceptable to the organization.




Consider configuring different policies for different users. For example, consider configuring a policy with

higher security settings for user groups that carry highly confidential information on their mobile devices,

or have access to highly confidential email. Create as many policies as required, and use the Exchange

Management Shell to assign the policies to multiple users simultaneously.

Also consider enabling remote file access through Exchange ActiveSync, rather than allowing users to

download attachments. Users with compatible mobile devices can view files from an internal file sharerather than downloading the files to their mobile devices.

In addition to setting Exchange ActiveSync policies, you also may need to define other policies regarding

the data that users can store on mobile devices. For example, you can block users from receiving email

attachments, but allow them to transfer data to the devices through a cradle or a USB connection. As part

of managing mobile devices, you should define corporate policies that determine the data that users can

store on their devices.






• Develop policies for allowing users to wipe their own devices. Exchange Server 2010 also allows users

to wipe their own devices, or to remove the partnership between a device and their Exchange

mailbox. This option is available on the Outlook Web App Options page. Allowing users to wipe

their own devices can decrease the time required for administrators to manage mobile devices,

because users can remove associations with devices they no longer use. If your organization

implements a policy that prevents users from managing their own devices, remove this option in the

Outlook Web App segmentation settings.




Lab: Planning and Deploying Client Access Services inExchange Server 2010

Lab Setup

For this lab, you will use the available virtual machine environment. Before you begin the lab, you must:


2. Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, and 10233B-VAN-EX2 virtual machines are

running.



Lab Scenario


multiple locations. A. Datum Corporation is an international corporation involved in technology research

and investment, and is planning to upgrade from Exchange Server 2003 to Exchange Server 2010.

You have been tasked with reviewing the current messaging infrastructure and network topology, and

planning the deployment and configuration of Client Access servers. You are required to make proposals

about how best to address the needs of the various stakeholders in the organization.

Finally, you are required to implement part of your proposed Client Access design.

Note Your instructor may choose to perform parts of this lab as a group discussion, rather

than an individual activity.




Server Design Interview Notes.doc

Marcel Truempy, CIO

For me, high availability is the most important part of your server design. You need to ensure that if a

single server fails, or if a single component on a server fails, the failure affects as few people as possible.

Ideally, a server failure should affect no one. I know that is a bit unrealistic in some cases, but it is a goal

toward which we can aim.

We also need to ensure that your design can be scaled easily to a larger size. I think it is realistic that all of

our office locations will grow by 30 percent over the next three years. We will be buying more companies,

so prepare for that, as well.


We have deployed a very good storage area network (SAN) at London, Tokyo, and Vancouver. This SAN

has fully redundant systems, and provides a very high level of availability. For the Mailbox servers we are

deploying in these offices, the SAN needs to store the data. As far as I am concerned, the SAN provides

enough availability so that we do not have to do anything additional for these servers. We plan to install

one of these SANs at the new London office, as well.

For the Mailbox servers in the other offices, we are going to need to provide redundancy for the mailbox

databases. These servers all use Directly Attached Storage. Like I said before, I am worried about the

budget, so do whatever you can to provide high availability without deploying too many additional

servers.

Many of our organization’s users are using Microsoft Office Outlook 2003, but we have started a project

to deploy the Windows 7 operating system with the 2007 Microsoft Office system; however, it will take at

least 18 months to complete. Additionally, we will be deploying new client computers in our future

London and Chennai offices.


I understand that Carole wants to use the SAN for mailbox storage, but I think she is underestimating the

amount of storage space we require for Exchange servers. The SANs that we have in place right now haveonly about 10 terabytes of free disk. Unless we keep our mailboxes very small, that simply will not be

sufficient.

Her plan to use the SAN will also not result in high availability for Mailbox servers. The server itself will be

a single point of failure. Exchange Server 2010 does not support the use of single copy clusters like

Exchange Server 2007. A DAG will be required for high availability, and each server in the DAG maintains

a copy of the database. It would be incredibly inefficient to store multiple copies of the same data on the

same SAN.

We currently have a mailbox size limit of 50 megabyte (MB) for all users. However, this limit is too small

and many people have been able to convince their managers to approve a size increase. Almost half of

the people in the company currently have an exception on their mailbox limits, with the limit at 200 MB

or more. During a meeting last week, the CIO mentioned that when we get to Exchange Server 2010, we

would set up a mailbox size limit of 250 MB for all users, with a 500 MB limit for executives or other

exceptional cases. About 25 percent of the users will fall into the exceptional category. In addition, we

want to create archive mailboxes for the users that are double the size of the mailbox to eliminate the use

of .pst files.




I have some concerns with increasing the mailbox size to this limit. The back-up system in all of our offices

does not have as much capacity as we would like. In some offices, we are still backing up to tape. Some of

the tape backup systems can restore at only 50 GB per hour. According to the service level agreement

that we have in place, we are supposed to restore any failed database within an hour of failure.

Requirements Interview Notes.doc

Madeleine Kelly, CEO

The Board of Directors has just initiated a three-year plan that will result in A. Datum doubling in size.

Some of this growth is going to come from internal growth by expanding our current businesses, but the

plan also calls for a very aggressive acquisitions strategy. Much of my time for the next three years will be

spent identifying potential acquisitions anywhere in the world, and negotiating partnerships or takeovers.

Whatever messaging solution you create has to be very flexible and easily expanded.

Karen Toh, Vice President – Europe

My biggest complaint with the current email system is that it is technically obsolete. One of the groups I

manage is our International Sales Team. There are only 50 people on the team, but they are constantly

traveling throughout the world researching business opportunities. This team makes more money for this

company than any other group of people. They are also very knowledgeable about technology, and they

tell me that our current system is archaic compared to what other companies are using. This team wants

the latest and greatest in technology. This team needs to be able to access their email from anywhere in

the world at any time.

Marcel Truempy, CIO

In the last five years since I became CIO, our email system has changed from being a useful tool for

business to being a critical part of our business processes, and everybody notices when email is not

available. To give you an example, a couple of months ago all of the email servers in London were

unavailable for six hours due to a virus outbreak. A couple of months before, one of the servers in

Vancouver failed, and we could not send email to and from Vancouver for eight hours while the hardware

vendors came in to fix the hardware. This happened right in the middle of some critical businessnegotiations where we had to be able to exchange documents rapidly. In both cases, the CEO and every

other member of the executive staff called me on my cell phone while I was at home. The most important

requirement I have for this email system is availability. This system must always be available.


Our Security and Compliance Department is based in Vancouver, so it reports to me. The head of that

department tells me that the rules for how we do business and, especially, how we handle confidential or

private information are changing all the time. Just about every country has laws regulating what we can

do with private customer information, but the rules are often not the same. This gets very complicated for

an international organization like ours where some of that information is crossing country borders. We

need a messaging solution that we can use to enforce some of the compliance requirements.

Gareth Chan, Vice President - Asia

A. Datum is establishing an important partner relationship with Contoso, Ltd. Contoso, Ltd is a high-tech

research organization, and we are working on some confidential projects with them. We need to ensure

that all of the email that we are sending between our company and Contoso, Ltd cannot be viewed by

anyone else on the Internet.





My biggest concern with this project is the budget. This company has a history of setting high

expectations for a project, and then not providing the budget to do the job right. So whatever design you

come up with, we are going to have to be conscious of the budget.


The Network Operations department is responsible for managing all of the WAN links, the local area

networks (LANs), and the firewalls. One of the restrictions that the Security department placed on us

recently is that we cannot allow any unencrypted traffic through our internal firewalls. We can accept

unencrypted traffic into our perimeter network, but not to the internal network.


I can provide you with a Microsoft Office Visio® diagram that has all of our WAN connections and our

connections to the Internet. Our network right now is quiet reliable, but we do not have much available

bandwidth between company locations.


The company just finished upgrading all of the AD DS domain controllers to Windows Server 2008,Service Pack 1 (SP1). As part of the upgrade, we did a thorough review of our whole AD DS design. We do

not anticipate making any more changes to the AD DS configuration for a while.

Conor Cunnigham, Messaging Services Manager

One of our biggest problems right now is all of the mobile users that we have to support. We have quite a

few users using Outlook Web Access, and that seems to be working pretty well, although I do have some

security concerns with using Outlook Web App. Many of our users work at home, and most of them use

POP3 clients. I also have security concerns with these clients, but a bigger problem for them is

functionality. Users complain that they cannot easily access their calendar information or send meeting

requests. And we have more and more people asking for access to their email through cell phone devices.


We currently have a mailbox size limit of 50 MB for all users. However, this limit is much too small, and a

lot of people have convinced their managers to approve size increases for their mailboxes. At this point,

almost half of the people in the company have an exception on their mailbox limits, most of these limits

are at 100 MB.

Luca Dellamore, Messaging Specialist

We currently have four administrative groups in our Exchange Server organization. We have an

administrative group for North America, one for Europe, and one for Asia (LondonAG, VancouverAG, and

TokyoAG). The extra administrative group contains all of the routing groups (RoutingGroupAG). In each

location, we have a group of Exchange Server administrators that have full administrative permissions for

their administrative group, but do not have any permission in the other administrative groups

(LondonExAdmins, VancouverExAdmins, and TokyoExAdmins). In London, we have a group of seniormessaging specialists who have full control over all administrative groups (EnterpriseExAdmins). This

group is also the only group that has administrative permissions over the routing administrative group.

We also have a routing group for each of the big company locations. The routing group in Vancouver is

called VancouverRG, and then we have LondonRG and TokyoRG. I can send you the Office Visio with all of

the Exchange servers in each location. We have a routing group connector between VancouverRG and

LondonRG, and between LondonRG and TokyoRG.

We use two SMTP namespaces: adatum.com, and TreyResearch.net.




AD DS and Routing Interview Notes.doc


The company just finished upgrading all of the AD DS domain controllers to Windows Server 2008 SP1.

The company has indicated that there is no budget for any further AD DS changes, so any modifications

we make as part of this project must have no budget implications.

One change that we have been considering is removing the Chennai domain controller. The office

currently does not have a secure server room. There was a project in place to build the server room, but

that project’s budget is in jeopardy. Any input you could provide to this decision would be appreciated

greatly.


We currently have some messaging problems at the London location. Quite often, when I look at the

server queues on the Exchange servers, I see that there are many messages in the categorizer queue. Users

also complain that when they try to view the global address list, it can take more than 10 seconds for it to

appear. All of the other network locations seem to be fine.

We have had some past problems with the bridgehead servers in London, Vancouver, and Tokyo. The

problems appear when there is a network outage to one of the other offices. If the outage lasts for more

than a few minutes, it seems like we get hundreds of messages in the bridgehead server queues, and then

it can take a long time for the server to deliver the messages once we restore the network connection.

Compounding this problem in London is the fact that this is the only location where we accept inbound

SMTP email for Trey Research. We need to ensure that messages get sent out of these sites even if the

final destination site is not available.

As you have already heard, we have many employees using Outlook Web Access. We would really like to

make sure that the experience for the Outlook Web App users is as positive as possible.


We have been monitoring network traffic by protocol for the last year, and have noticed a significant

increase in the network bandwidth that SMTP traffic uses. In your design, you need to ensure that emailmessages always are sent to the network connections with the highest bandwidth. Also, make sure that

you take advantage of any other way that you can save bandwidth that email uses.

We are just taking over managing the network in San Diego, so we are not sure what network changes we

will need to make there. From what I understand, we may need to wait on some firewall changes until

after we get rid of the current messaging system.


Our department is responsible for the company’s firewall configurations. With every company location

having its own Internet connection, this can be a real challenge. Right now, we are allowing HTTPS access

to some Exchange servers in London, Vancouver, and Tokyo. This configuration is working okay, but we

do not want to open up any more messaging ports in any location. Additionally, we currently are allowingincoming and outgoing SMTP traffic through our firewalls only in London, because that is the only

location where we have a spam-filtering solution in place. We would be open to changing this, but would

need to know that the email messages are being scanned for viruses and spam in all locations where we

allow SMTP traffic.




Adatum_CurrentPerimeterDesign.vsd




Adatum_CurrentADSiteDesign.vsd




Policy Requirements.doc

As part of the Exchange Server 2010 design process, the analysts assigned to the project have identified

the following policy requirements.

Mailbox and Message Policies

• The available network bandwidth between company locations is limited. The largest message sent by

most users in the organization is 5 MB.

• The graphics department regularly sent messages with 10 MB attachments. The graphics personnel

are located in London, Vancouver, and Tokyo. These messages must be delivered within the

organization.

• The current limit for sending and receiving email to the Internet is 2 MB. Many users in the

organization have concerns about this limit, and would like to at least double this limit. With the

changes made to the delivery of messages to and from the Internet, the organization has agreed to

meet this expectation.

• As a general rule, the design should allow for 20 percent buffer when designing message size policies.

•

All users must have a maximum mailbox size of 250 MB. Executives and managers must have amaximum mailbox size of 500 MB. Each user will also have an archive mailbox that is twice the size of

the mailbox.

• All users should receive a warning when their mailbox reaches 80 percent of the maximum mailbox

size, and should be prevented from sending email when their mailbox reaches 90 percent of the

maximum size.

• Users should be able to recover items in their mailboxes for 7 days after the message has been

deleted from the deleted items folders. Executives should be able to recover these types of messages

for 21 days.

• All users in the entire organization should be able to book meetings using any resource mailboxes,

such as meeting rooms and equipment mailboxes. When users book a meeting, they should get an

email back saying that the meeting has been accepted. No duplicate meetings should be accepted by

a meeting room. The only exceptions to this policy are two meeting rooms in London that are used

for video conferences. Any member of the Sales team in the entire organization should be able to

book the meeting room, but the meeting requests much be accepted by a member of the Sales

Support team in London.

Mobile Messaging Requirements

• All executives and many managers would like to use mobile devices to access the Exchange

mailboxes. Up to this point, users have not been able to access their email using mobile devices.

There is a very strong demand to make this feature available. Many executives see this as the primary

benefit of implementing the new email system.

•

As access to email from mobile devices becomes available, the business departments are expectingmany users will want to have the same level of access. Providing this access is a high priority for most

business departments.




• The security officer is concerned about making mobile device access available for all users. He has

specified the following security requirements:

• All users who will be accessing email on the Exchange server must be required to have an

alphanumeric password that is at least 6 characters long.

• Users who want to download attachments to the device must have encryption enabled on the

device, and the device must be configured to lock after five failed logon attempts.

• Exchange administrators must be able to remotely wipe any mobile devices.

• All executives and managers must be able to download attachments to their mobile devices.

Other users do not require this functionality.

• The Exchange administrators do not want to be involved every time a user gets a new mobile

device, but they also do not want users to have many mobile devices associated with their

mailbox.

Compliance Requirements

• The corporation reviews its sales and marketing approach every six months. All members of the Sales

and Marketing teams are involved in the reviews. During the review process, a significant amount ofemail is sent between team members. Retaining this email for historical data is important, but these

emails should not be retained in user mailboxes for more than nine months. When the messages are

removed from the user mailboxes, they should easily be accessible to all members of the Sales and

Marketing teams, but should not be accessible to other users in the organization.

• All messages sent to and from the Legal team must be retained in a secure location.

• In order to decrease the size of user mailboxes, all messages in user mailboxes that are more than 12

months old should be deleted and placed in the deleted items folder. All messages more than six

months old in the Deleted Items folder and Sent Items folder should be deleted. This policy should

apply to all users.

• Members of the Executive group should have the option of saving messages in their mailbox

indefinitely.




A. Datum User Distribution Summary.doc


London

Corporate

Headquarters

12,000 currently

10,000 after the new

London office is ready



•

800 Office Outlook users connecting through a virtualprivate network (VPN)

London (newoffice)

4,000 (anticipated) • 200 Outlook Web Access users


San Diego

Former headoffice ofTrey Research







Chennai (newoffice)

800 (anticipated) • 200 Outlook Web Access users


A. Datum has deployed a single AD DS forest with a dedicated root domain named Adatum.com, and

three child domains in the same tree. These domains are:

• EU.Adatum.com

•

NA.Adatum.com

• AS.Adatum.com






Exercise 1: Designing the Client Access Server Deployment

Scenario

In this exercise, you will examine the current topology and messaging infrastructure. You will determine

the appropriate Client Access server deployment based on the information supplied in the A. Datum

Exchange Server 2010 project documentation.


1. Review the A. Datum documentation.

2.

Answer questions related to the documentation.

3. Update the A. Datum Client Access server deployment plan document.

Task 1: Review the A. Datum documentation


• Server Design Interview Notes.doc

• Requirements Interview Notes.doc

• AD DS and Routing Interview Notes.doc

• Adatum_CurrentPerimeterDesign.vsd

• Adatum_CurrentADSiteDesign.vsd


Question: In the Server Design Interview Notes document, what points are raised that impact

your Client Access server deployment plan, and why do they impact the plan?

Question: In the Requirements Interview Notes document, what points are raised that impact

your Client Access server deployment plan, and why do they impact the plan?

Question: In the AD DS and Routing Interview Notes document, what points are raised that

impact your Client Access server deployment plan, and why do they impact the plan?

Question: Is there anything in the Adatum_CurrentPerimeterDesign.vsd diagram that raises

Client Access server deployment issues? If so, what?

Question: Is there anything in the Adatum_CurrentADSiteDesign.vsd diagram that raises Client

Access server deployment issues? If so, what?




Task 3: Update the A. Datum Client Access server deployment plan document


A. Datum Client Access Server Deployment Plan


Document Author

Date

Jason Carlson

4th April 2010


Determine the number and placement of Client Access servers within the existing networkinfrastructure.


Identify infrastructure changes that may be required due to the proposed deployment.

Proposals

Question: With reference to the Adatum_CurrentADSiteDesign diagram, how many Client Accessservers do you propose to deploy in each site?

Question: Do you have sufficient information from the documents reviewed so far, to determinewhether some sites require additional Client Access servers?

Question: Based on the documentation you have reviewed, what client types must you support?

Question: Is it clear from the documentation that you have reviewed which sites support whichclient types?

Question: While maintaining compliance with the requirements mentioned in the documentation,can you propose changes to the client types that will simplify the configuration?

Question: Which Client Access servers do you propose to make Internet-facing?

Question: How will you configure Autodiscover to support your Client Access server model?


Results: After this exercise, you should have completed the A. Datum Client Access server deployment

plan document.




Exercise 2: Designing Client Access

Scenario

In this exercise, you will determine which Client Access server features and services are required, and you

will plan how to configure them to support the defined requirements.




3.

Update the A. Datum Client Access server configuration document.


• Review the contents of the following documents:

• Policy Requirements.doc

• A. Datum User Distribution Summary.doc


Question: In the Policy Requirements document, what points are raised that impact your Client

Access server deployment plan, and why?

Question: In the A. Datum User Distribution Summary document, what points are raised that

impact your Client Access server deployment plan and why?

Task 3: Update the A. Datum Client Access server configuration document


A. Datum Client Access Server Configuration


Document Author

Date

Jason Carlson

4th April 2010


Determine the feature configuration for Client Access servers in the A. Datum Exchange Server 2010upgrade.

Proposals

Question: Based on the information in the A. Datum User Distribution Summary document, do youenvisage deploying additional Client Access servers in any sites?

Question: Which features must you enable on the Client Access servers to support the currentclient-types?

Question: Which client protocols must you enable through the firewalls?





Question: What would you do to address the security concerns raised regarding mobile clients?

Question: To support the other client types, what other configuration changes must you make?



Results: After this exercise, you should have completed the A. Datum Client Access server configuration

document.




Exercise 3: Implementing Client Access

Scenario

In this exercise, you will implement Exchange ActiveSync according to your proposals.


1.

Verify the Exchange ActiveSync virtual directory configuration.

2.

Create a new Exchange ActiveSync mailbox policy.

3. Configure Exchange ActiveSync settings from the ECP.

Task 1: Verify the Exchange ActiveSync virtual directory configuration

• In the Exchange Management Console, review the configuration for the Microsoft-Server-ActiveSync

virtual directory. The virtual directory configuration can be viewed for each Client Access server in the

Client Access node.

Task 2: Create a new Exchange ActiveSync mailbox policy

1.

On VAN-EX2, in the Exchange Management Console, create a new Exchange ActiveSync Mailboxpolicy with the following configuration:

• Name: Executive Policy

• Enable non-provisionable devices

• Enable attachments to be downloaded to the device

• Require passwords

• Disable simple passwords

• Enable password recovery

• Minimum password length: 6

• Require encryption on device

Note You must create and then modify the policy to configure the following two settings.

• Configure the number of failed logon attempts at 5

• Require encryption on storage card

2.

Review the other Exchange ActiveSync Mailbox policy settings.

3. Apply the Exchange ActiveSync Mailbox policy to users in the Executives OU. Open Exchange

Management Shell, and then execute the following command:

Get-Mailbox -OrganizationalUnit Executives | Set-CASMailbox

-activesyncmailboxpolicy "Executive Policy"

Task 3: Configure Exchange ActiveSync settings from the ECP

1.

Open Internet Explorer and navigate to https://van-ex2.adatum.com/ecp.

2. Logon as adatum\administrator using the password of Pa$$w0rd.

https://van-ex2.adatum.com/ecp

https://van-ex2.adatum.com/ecp




3. From Phone & Voice, from within the ActiveSync Device Policy, review the Executive Policy.

Notice that text messages can be synchronized by default.

4. From within ActiveSync Access, create a New Device Access Rule:

• All families

•

Quarantine – Let me decide to block or allow later.• You will not be able to save the settings as there are no devices currently in use within the

Adatum organization. Cancel the policy creation and close all open windows.

Results: After this exercise, you should have deployed and configured Exchange ActiveSync for members

of the Executives group.


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

steps:

1.

On the host computer, start Hyper-V Manager.

2.

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


4. Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2. Close the virtual machine connection

windows.


6.

To connect to the virtual machine for the next module’s lab, click 10233B-VAN-DC1, and then in the


Important Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully


7.

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

machine.

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

9.

Wait for 10233B-VAN-EX2 to start, and then start 10223A-VAN-EDG. Connect to the virtual

machine.





Review Questions

1. When a user attempts to connect to an Internet-facing client access server, the petitioned server

determines that the user’s mailbox is located in another site. The Client Access server in the other site

is not configured with an external URL. What happens next?

2. You have deployed a single Internet-facing Client Access server to support all sites in your

organization. Which authentication method must you configure on all other Client Access servers?

3. Your users seem to be experiencing problems when trying to access their mailboxes using Outlook

Web App. You realize they are typing the incorrect URL, and are forgetting the https prefix. What can

you do to assist?

Best Practices


• Never deploy a Client Access server in your perimeter network.

• As a general guideline, deploy three Client Access server processor cores in an AD DS site for every

four Mailbox server processor cores.




• Do not run the Security Configuration Wizard on servers that support Exchange Server 2010 server

roles.

• If your organization has deployed Exchange servers in multiple AD DS sites, consider configuring site

affinity for the Autodiscover service.

• If you have multiple Client Access servers—each in a different site and with different names—be sure

to obtain a certificate that can support multiple names.



5-1

Module 5

Planning and Deploying Message Transport in Microsoft®Exchange Server 2010

Contents

Lesson 1: Designing Message Routing for Exchange Server 2010 5-3

Lesson 2: Designing Hub Transport Servers 5-13

Lesson 3: Designing the Message Routing Perimeter 5-29Lab: Planning and Deploying Message Transport in Exchange Server 2010 5-44



5-2 Planning and Deploying Message Transport in Microsoft® Exchange Server 2010

Module Overview

After you have defined the business requirements of your organization and have a good understanding of

the current network environment, the next step is to design message routing—both within the

organization, and between your organization and other organizations that are connected to the Internet.

Objectives


•

Design message routing for Microsoft® Exchange Server 2010.

• Design Hub Transport servers.

• Design the message routing perimeter.




Lesson 1

Designing Message Routing for Exchange Server 2010

One of the Exchange Server 2010 infrastructure’s most important design components is the message

routing topology for messages sent within the organization, and those sent to and from the Internet. In

Exchange Server 2010, the routing topology integrates tightly with the Active Directory® Domain Services

(AD DS) site configuration.

Objectives


• Describe the message transport components in Exchange Server 2010.

• Describe the default message routing configuration in Exchange Server 2010.

• Explain how to modify the default message routing topology.

• Explain how to design message routing to mitigate the effects of message routing failure.




Overview of Message Transport Components in Exchange Server 2010

The message transport pipeline in Exchange Server 2010 consists of several components that work

together to route messages. Messages from outside the organization enter this pipeline through a Simple

Mail Transfer Protocol (SMTP) Receive connector on an Edge Transport server, a Hub Transport server, or

another non-Exchange SMTP server. Messages inside the organization enter the transport pipeline

through the SMTP connector on a Hub Transport server, through agent submission, from the Pickup or

Replay directory, or by direct placement by the store driver in the Submission queue.

Submission Queue

When the Microsoft Exchange Transport service starts, the categorizer creates one Submission queue on

each Edge Transport server and Hub Transport server. The Submission queue stores all messages on a disk

until the categorizer processes them for further delivery. No message can be categorized without being

submitted to the Submission queue. While the categorizer processes a message, it remains in the

Submission queue. After the categorizer categorizes a message successfully, it removes it from the

Submission queue.

Messages can enter the Submission queue in several ways:

• Messages received by an SMTP Receive connector. Use this for messages inbound from the Internet

or from a client using Post Office Protocol version 3 (POP3) or Internet Message Access Protocol

(IMAP).

•

Messages placed in the Pickup directory. Use this method for troubleshooting and for legacy

applications.

• Messages submitted by the store driver. Use this method to retrieve messages from a sender’s

Outbox.

• Messages resubmitted after failed delivery. The categorizer resubmits messages that were not

delivered on the first attempt. You also can resubmit messages manually.




Store Driver

Messages sent by mailbox users enter the message-transport pipeline from the sender’s Outbox. The store

driver on the Hub Transport server retrieves messages from the sender’s Outbox, and submits them to a

Submission queue.

The store driver can place messages into the Submission queue on any Hub Transport server that is on the

same AD DS site as the Mailbox server from which it retrieves the message. After the store driver adds themessage 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 MAPI format, and the store driver must convert them to Summary

Transport Neutral Encoding Format (STNEF) before placing them in the Submission queue. If the store

driver is unable to convert the content, it generates a non-delivery report (NDR).

Microsoft Exchange Mail Submission Service

The Microsoft Exchange Mail Submission service is a notification service running on Mailbox servers. It

notifies a Hub Transport server role in the local AD DS site when a message is available for retrieval from a

sender’s Outbox. The store driver on the notified Hub Transport server role then picks up the message

from the sender’s Outbox.If there are multiple Hub Transport servers in the AD DS site, the Microsoft Exchange Mail Submission

service attempts to distribute notifications evenly between the Hub Transport servers.

Categorizer

The categorizer retrieves one message at a time from the Submission queue, and always picks the oldest

message first. On an Edge Transport server, categorization of an inbound message is a short process in

which the categorizer verifies the recipient SMTP address, and places the message directly into the

delivery queue. From the delivery queue, it routes the message to a Hub Transport server.

On a Hub Transport server, the categorizer performs the following tasks:

• Identifies and verifies recipients. All messages must have a valid SMTP address.

• Bifurcates messages that have multiple recipients. The expansion of distribution lists enables

identification of individual recipients who belong to the distribution list. Additionally, the categorizer

processes the return path for distribution-list delivery status notifications (DSNs), and it determines

whether Out-of-Office messages or automatically generated replies are sent to the original message’s

sender.

• Determines routing paths. As part of determining the routing path, the categorizer identifies the

destination. The destination must be a user’s mailbox, a public folder, or an expansion server for

distribution groups. If it cannot determine a valid destination, an NDR is generated.

• Converts content format. Various recipients require messages in different formats. The categorizer

converts the message to an appropriate format for the recipient. Inside the Exchange Server

organization, the recipient format is stored in AD DS. Messages routed to the Internet are sent in theMultipurpose Internet Mail Extensions (MIME) or Secure/Multipurpose Internet Mail Extensions

(S/MIME) format.

• Applies organizational message policies. You can use organizational policies to control messaging

aspects such as size, permission to send messages to specific users, the number of message recipients,

and other characteristics.




Pickup Directory

Most messages enter the message transport pipeline through SMTP Receive connectors, or by submission

through the store driver. However, messages also can enter the message transport pipeline by being

placed in the Pickup directory on either a Hub Transport server or an Edge Transport server.

The store driver submits messages that the categorizer places in the Pickup directory to the Submission

queue. The store driver deletes messages from the Pickup directory after it submits them to thecategorizer from the Submission queue. Messages that the categorizer places in the Pickup directory must

be in the appropriate format and have read/write permissions configured.

The Pickup directory allows you to take a properly formatted text file, and have the Hub Transport server

process and deliver it. This can be useful for validating mail flow in an organization, replaying specific

messages, or returning recovered email to the message transport pipeline. Additionally, some legacy

applications may place messages in the Pickup directory for delivery, rather than communicate directly

with Exchange Server SMTP Receive connectors.




Default Message Routing Configuration in Exchange Server 2010

Many organizations create AD DS sites to control AD DS replication and client authentication network

traffic. Exchange Server 2010 uses AD DS sites and AD DS site links to define an organization’s internal

and external message routing.

How Exchange Server 2010 Uses Sites for Message Routing

A Hub Transport server is responsible for message routing within and between sites. Between sites, the

Hub Transport server determines the best route to the destination site for the message recipient, and

delivers the message to a Hub Transport server in the destination site.When a message is addressed to a recipient in the same Exchange Server organization, and is sent

between AD DS sites, the following steps occur:

1. The Mailbox server uses AD DS site membership information to determine which Hub Transport

servers are in the same AD DS site as the Mailbox server. The Mailbox server submits the message to

the Hub Transport server. If more than one Hub Transport server exists in the site, the Mailbox server

uses the Hub Transport servers by using the round-robin algorithm.

2. The Hub Transport server performs recipient resolution, and queries AD DS to match the recipient

email address to a recipient account. The recipient account information includes the fully qualified

domain name (FQDN) of the user’s Mailbox server. The FQDN determines the AD DS site of the user’s

Mailbox server.

3.

The Hub Transport server uses AD DS site link information to determine the lowest cost route to the

destination AD DS site. In a default configuration, the Hub Transport server opens an SMTP

connection to the Hub Transport server in the destination site, and delivers the message.

4. After a Hub Transport server in the destination AD DS site receives a message, the Hub Transport

server forwards the message to the appropriate Mailbox server in the destination AD DS site.




5. If the message has multiple recipients whose mailboxes are in different AD DS sites, Exchange Server

uses delayed fan-out (or bifurcation) to optimize message delivery. If the recipients share part of, or

the entire path, Exchange Server sends a single copy of the message with these recipients until the

bifurcation point. When the mail reaches the bifurcation point, the message is bifurcated and a

separate copy is sent to each recipient. For example, if the least-cost route from Site 1 to Site 3 and

Site 4 both pass through Site 2, then a single copy of a message intended for recipients in Site 3 and

Site 4 is sent to a Hub Transport server in Site 2. The Hub Transport server in Site 2 then sends two

copies of the message, one each to a Hub Transport server in Site 3 and Site 4.

Note If you deploy Exchange Server 2010 in an existing legacy Exchange Server

environment, the organization’s message routing will vary if the messages are routed to, or

from, previous Exchange Server versions. For example, in Exchange Server 2003, you can use

routing groups to group Exchange Servers into location contexts. These routing groups

may, or may not, match up with the AD DS site configuration. All Exchange Server 2010

servers are grouped into a single routing group for backwards compatibility with Exchange

Server 2003.

How Exchange Server 2010 Selects a Message RouteIn some cases, there may be more than one route available for delivering messages between AD DS sites.

If a recipient is in the remote AD DS site, and multiple paths exist to get to that site, the Exchange Server’s

routing service uses the following criteria to choose a path on which to send the message:

• The path with the lowest cost from source to destination site. The lowest-cost route is calculated by

aggregating all AD DS IP site link costs, or the Exchange Server cost assigned to the site links between

the source and destination sites.

• The path with the least number of segments. If the aggregated costs for the site links are the same for

more multiple paths, then Exchange Server chooses the path with the fewest site links between the

source and destination sites.

Note Exchange Servers do not use the underlying network topology to make message

routing decisions. A single site link may actually cross multiple network segments, but the

Exchange Server evaluates only the site link. Therefore, it is important that the site links

logically reflect the underlying network topology.

• Alphanumerically lower preceding AD DS site name. If the previous criteria do not result in a single

path, the Exchange Server selects the route that passes through the intervening site with the lowest

alphanumeric name. The Exchange Server uses the site closest to the destination site to make the

selection. If the paths pass through the same site before reaching the destination site, the Exchange

Server backs along the routing path until a unique site name is available.

Note Each Exchange transport server calculates a set of routing tables that determine howto route messages to recipients. Whenever the Exchange server calculates the routing table,

it logs the result. By default, these logs are located in the %Program

Files%\Microsoft\Exchange Server\V14\Transport\Logs\Routing folder. The Exchange

Transport server recalculates the routing tables when the transport services begin, or when

changes to the routing topology are made.






Considerations for Modifying the Default Routing Topology

Most organizations do not need to modify the default Exchange Server 2010 routing topology. However,

consider the following factors if you modify the default topology:

• Use hub sites when the network topology does not support direct connections between Hub

Transport servers in different sites. For example, use hub sites when firewalls that exist between AD DS

sites prevent direct SMTP communications.

Note Configuring hub sites does not decrease the network traffic, as Exchange Server

2010 uses delayed fan out, regardless of whether you configure hub sites or not.

• Consider configuring an Exchange Server-specific cost to an IP site l ink if the cost does not result in

an optimal Exchange Server message routing topology, and if you cannot modify the AD DS

parameter.

• Consider site link costs when configuring hub sites. Hub sites are used only if the hub site is along the

least-cost routing path between two Hub Transport servers. The Hub Transport server first calculates

the least-cost route between two sites, then checks to see if that route has any hub sites.

• Consider using expansion servers for very large distribution lists. Expanding large distribution groups

is a resource-intensive process for the Hub Transport server and a global catalog server. If your

organization has a central location with more powerful Hub Transport servers or more global catalog

server capacity, you may want to configure one of the Hub Transport servers in the site as the

expansion server for large distribution lists. Ensure that this server is highly available, because it is not

possible to assign more than one expansion server to a distribution list.

Note If you nest groups — that is, some of your groups contain groups as members —

consider configuring the second-tier groups with expansion servers. This is especially

relevant if these groups are representative of users distributed regionally. For example, if A.

Datum Corporation had a worldwide sales team, a regional sales team for each continent,

and a sales team in each country within each continent, you might consider configuring thetop-level World-Wide Sales group with no expansion server. However, it might prove

efficient to configure the Americas-Sales, Asia-Sales, and Europe-Sales groups with

expansion servers in the relevant region. For example, Europe-Sales might be configured

with an expansion server in Paris, France. You might decide to continue this approach with

the next group level. For example, the London-Sales group has an expansion server that is

located in Canary Wharf, the head offices for A. Datum Corporation in London.




Designing Message Routing to Mitigate the Effects of Message RoutingFailure

When designing the message routing topology, you also should consider how Exchange Server 2010 deals

with situations where message routing between sites fails.

How Exchange Server 2010 Deals with Message Delivery Failure

If a Hub Transport server cannot deliver a message to another Hub Transport server in the destination site

or a hub site, then the Hub Transport server delivers the messages through the least-cost routing path to

a Hub Transport server as close as possible to the destination site.The source Hub Transport server attempts to deliver the message to a Hub Transport server in the last site

before the destination site, along the least-cost routing path. The Hub Transport server continues its

attempts to connect to a Hub Transport server as close as possible to the target Hub Transport server. The

messages are queued in that AD DS site, and the queue is in a retry state. If no Hub Transport servers are

available in any site along the least-cost route, the message is queued on the local Hub Transport server.

This feature is called queue at point of failure.

Important Exchange Server 2010 uses deterministic algorithms to choose available paths

between AD DS sites. The algorithms are deterministic because they always choose one

path provided contributing factors do not change. Exchange Server 2010 does not load-

balance message delivery across multiple connectors with the same cost, and it does not fail

over to an alternate path if a Hub Transport server in a site does not respond.




Guidelines for Dealing with Message Routing Failure

You should consider how Exchange Server 2010 deals with message routing failure when designing the

message routing topology. Consider the following guidelines:

• For each of your organization’s possible routing paths, consider where you will queue messages that

cannot be delivered to a destination hub site.

• Deploy multiple Hub Transport servers in the AD DS sites where messages will be queued for multiple

destination sites. For example, if your organization uses a hub and spoke topology for the AD DS site

links, messages are queued in the hub AD DS site. Ensure that you have multiple Hub Transport

servers in the site to ensure availability and performance scalability.

• To reduce the chance of message-routing failure, deploy multiple Hub Transport servers in each AD

DS site. If one of the Hub Transport servers is not available in a site, the source Hub Transport server

attempts to connect to the site’s other Hub Transport servers before queuing to the failure point.

Note Deploying multiple Hub Transport servers in a site also provides load balancing. If

there are multiple Hub Transport servers available in the destination site, message delivery

is distributed across all available servers. For example, when more than one Hub Transport

server exists in a remote AD DS site, round-robin load balancing determines the routing

path. Fault tolerance is achieved by connecting to the next available server in a prioritized

list of servers when the selected server is unavailable.






Hardware Requirements for Hub Transport Servers

Optimizing a messaging system is a question of optimizing all the elements within the system. In

Exchange Server 2010, by ensuring that your Hub Transport servers meet the recommended hardware

requirements, you can ensure an optimal routing infrastructure.

Note The hardware requirements of an Edge Transport server do not differ greatly from

that of a Hub Transport server.

Processor Requirements

Exchange Server 2010 is a 64-bit application, and must therefore run on a 64-bit processor. You can select

processors from Intel that support Intel Extended Memory 64 Technology, or processors from AMD that

support AMD64.

Note For more information about these processor options, see the Intel 64 Architecture

website at http://www.intel.com/technology/intel64/, or the AMD Opteron Processor

Family website at http://www.amd.com/us/products/server/ processors/Pages

/server-processors.aspx.

After you have selected a 64-bit processor-based server computer, you should configure your Hub

Transport server role with an appropriate number of processor cores. You will need more cores for

organizations where you deploy Hub Transport servers with several Mailbox servers and thousands of

mailboxes.

You can efficiently use eight processor core Hub Transport servers when you also configure the Hub

Transport to use antivirus and anti-spam. Consider either one or two core processors configurations if

your organization does not support many mailboxes, or you have insufficient message traffic to warrant

using more processor cores. A maximum of 12 processor cores is recommended.

http://www.amd.com/us/products/server

http://www.amd.com/us/products/server




Note Processor utilization is based on several factors, such as message rate, average

message size, number of enabled transport agents, antivirus configuration, and third-party

applications.

Memory Requirements

When planning memory for your Hub Transport server, consider:• Memory speed. To support greater amounts of installed memory, some servers require slower

memory. For example, using PC3200 memory may enable you to scale your server to only 16

gigabytes (GB) of memory, while using PC2700 memory enables support for 32 GB of memory.

• Module size. Ensure that the maximum memory module size enables you to meet your target

memory.

• Number of memory slots. Linked to the module size, the number of slots determines the maximum

installable memory.

• Total memory. The Hub Transport server role does not require substantial quantities of memory to

perform well in typical conditions. Generally, 1 gigabyte (GB) of random access memory (RAM) per

processor core, with a minimum of 4 GB per server, is sufficient to handle all but the most demandingloads.

Disk Configuration

The performance of disk resources is also important in the Hub Transport server role as it processes email

from memory into the queue database. For optimal performance, consider placing the mail queue

database on a different disk spindle than that which hosts the related transaction logs. Additionally, you

must ensure that sufficient free-space is available to avoid back pressure—a system resource monitoring

feature of the Microsoft Exchange Server 2010 transport service.

Network Configuration

Much of the network interface subsystem is tuned automatically. Server-based network adapters are

capable of detecting the type and level of traffic passing through the network interface, and they self-tune to reflect this information. You should have operational practices in place to ensure that the latest

device drivers are maintained on the server for installed network interface cards (NICs).

Server Ratios

You should plan to deploy seven mailbox servers to each Hub Transport server, if the Hub Transport

server does not provide antivirus scanning. If your Hub Transport servers perform antivirus scanning, then

the Mailbox server to Hub Transport server ratio should be 5:1.




Default Hub Transport Server Configuration

The fundamental building block of Exchange Server 2010’s transport architecture is the Hub Transport

server. This role is responsible for all internal message routing, relaying of messages to and from the

perimeter network, and optionally, routing of messages to and from the Internet, depending upon

configuration. To design an optimal routing infrastructure, you might need to consider reconfiguring your

Hub Transport servers. It is therefore important to understand the default configuration.

Accepted Domains

Accepted domains configured at the organization level define the SMTP namespaces for which yourorganization receives email. By default, your Exchange Server organization accepts email for the AD DS

forest root domain.

Remote Domains

Remote Domains enable you to configure message settings between your organization and other external

organizations. For example, you can configure out-of-office messages, and message format settings. By

default, the remote domain * is configured. This wildcard setting affects all messages sent to all other

domains.

Receive Connectors

Receive connectors handle inbound email—that is, inbound to a specific Hub Transport server. Each Hub

Transport server hosts two SMTP receive connectors:• The Default <server name> connector is configured to accept inbound connections from any IP

address over all locally configured IP addresses using Transmission Control Protocol (TCP) port 25.

This connector is used to support connections from other Hub Transport servers. By default, the

following authentication mechanisms are enabled: Transport Layer Security (TLS) Basic authentication

(offer Basic authentication only after starting TLS), Exchange Server authentication, and Integrated

Windows authentication. Exchange Server users, Exchange servers, and legacy Exchange servers are

permitted to use the connector by default.




• The Client <server name> connector is provided to support inbound connections from SMTP clients.

It supports inbound connections on all connected NICs, and from any IP address over TCP port 587.

By default, the following authentication mechanisms are enabled: TLS, Basic authentication (offer

Basic authentication only after starting TLS), and Integrated Windows authentication. Only Exchange

Server users are permitted to use the connector by default.

There are no default Send connectors configured on each Hub Transport server.

Transport Agents

Transport agents process email messages that pass through the transport pipeline on a Hub Transport

server or Edge Transport server. Custom transport agents provide additional functionality to Exchange

Server 2010, such as anti-spam or antivirus programs, or any transport function that your organization

may require.

Exchange Server 2010 includes several default transport agents that enable it to provide features such as

transport rules and journaling. By default, the following transport agents are installed on Hub Transport

servers.

• Transport Rule agent . The Transport Rule agent processes transport rules on Hub Transport servers. It

fires on the OnRoutedMessage transport event. Transport rules configured on Hub Transport serversare stored in AD DS, making them accessible to all Hub Transport servers in the Exchange

organization. This allows Exchange Server to apply consistently a single set of rules across the entire

organization.

• Journaling agent . The Journaling agent is a compliance-focused transport agent that processes

messages on Hub Transport servers. It fires on the OnSubmittedMessage and OnRoutedMessage

transport events. When you enable standard journaling on a Mailbox database, this information is

saved in AD DS, and is read by the Journaling agent.

• Active Directory Rights Management Services Prelicensing agent . You can use the Active Directory

Rights Management Services (AD RMS) Prelicensing agent to certify the Microsoft Office Outlook®

recipient's authenticity, so that the recipient can open messages without receiving a credential

prompt on every attempt. It fires on the OnRoutedMessage transport event.

Note Transport agents have full access to all messages that they process; Exchange puts

no restrictions on a transport agent's behavior. Consequently, transport agents that are

unstable or contain security flaws may affect the stability and security of Exchange Server

2010.




Planning SMTP Send and Receive Connectors

An SMTP connector is an Exchange Server component that supports one-way SMTP connections, which

route mail between Hub Transport and Edge Transport servers, or between the transport servers and the

Internet. Exchange Server 2010 provides two types of SMTP connectors: SMTP Receive connectors, and

SMTP Send connectors.

Note Exchange Server 2010 automatically creates the Send and Receive connectors that

are required by intra-organization mail flow. These are implicit connectors that are not

visible in the Exchange Server management tools, and you cannot modify them.

An SMTP Receive connector is required for an Exchange Server 2010 computer to accept any SMTP email.

An SMTP Receive connector enables an Exchange Hub Transport or Edge Transport server to receive mail

from any other SMTP sources, including: SMTP mail programs such as Office Outlook Express, and SMTP

servers on the Internet, Edge Transport servers, or other Exchange Server SMTP servers.

Two default SMTP Receive connectors are created on each server running the Hub Transport server role.

An Exchange Server 2010 computer requires an SMTP Send connector to send any SMTP email.

Additionally, SMTP Send connectors are required to send email to any SMTP server on the Internet, or to

any SMTP servers in the same Exchange Server organization.

Note By default, no SMTP Send connectors are configured on Hub Transport servers,

except for the implicit SMTP Send connectors that are created dynamically to communicate

with Hub Transport servers in other sites.




When to Consider Additional SMTP Connectors

You must configure additional SMTP connectors if you want to connect your Exchange Server

organization to the Internet. You have a number of options that you can consider to support this

connectivity:

• Configure an Edge Subscription. Perhaps the easiest option is to deploy an Edge Server in your

perimeter network, and then create an Edge subscription between your internal Exchangeorganization and the Edge Server in the perimeter network. This option results in the automatic

creation of the required Send and Receive connectors—between the organization and the perimeter,

and at the perimeter, to and from the Internet.

• Configure Internet connectivity to and from the Hub Transport servers. If you do not deploy an Edge

Transport server, you must configure the Hub Transport server to enable inbound and outbound mail

flow. To enable inbound mail flow, you must configure an SMTP Receive connector to accept

anonymous connections on port 25 using a network interface that is accessible from the Internet. To

enable outbound email flow, you must configure an SMTP Send connector with an address space of

“*”that uses Domain Name System (DNS) to send messages to the Internet.

Note If you use the Hub Transport server to send and receive email from the Internet, youshould configure antivirus and anti-spam agents on the Hub Transport server.

• Configure external SMTP relay. Smaller organizations often configure an SMTP relay agent, perhaps

hosted by an Internet Service Provider (ISP), to handle their Internet mail flow. To support this

configuration, you must configure your Hub Transport server. To enable inbound mail flow, you must

configure an SMTP Receive connector to accept anonymous connections on port 25 using a network

interface that is accessible from the Internet. To enable outbound email flow, you must configure an

SMTP Send connector with an address space of “*”that can use a smart host to send messages to the

Internet. You must ensure that the authentication configuration of this connector matches the details

provided by your ISP.

•

Configure internal SMTP relay. If your Exchange organization is responsible for handling email foranother AD DS forest, you will need to configure internal SMTP relaying. This option is discussed in

more detail in the following topic.

• Configure mail flow through Exchange Online or a third-party gateway. To establish Internet mail

flow through Exchange Online (or an external SMTP gateway), you must create a Send connector and

a Receive connector between the Hub Transport servers in your Exchange Server organization and the

external SMTP servers that process and route Internet email. The precise details of the configuration

of these connectors vary.

Note You can configure multiple SMTP Receive connectors with different parameters on a

single Exchange server. However, you must configure each SMTP Receive connector with

the following: a port on which the connector can receive connections; local IP addressesthat can be used for incoming connections; and a remote IP subnet that can send mail to

this SMTP Receive connector. The combination of these three properties must be unique

across every SMTP Receive connector in the organization. In large organizations, there can

be multiple SMTP Receive connectors on a single server, or on multiple servers. In small to

medium-sized organizations, as few as two connectors (a Send and a Receive connector)

could serve the entire organization.




SMTP Connector Improvements in Exchange Server 2010 SP1

Exchange Server 2010 SP1 introduces a number of improvements in the transport architecture. These

include changes in the behavior of SMTP connectors.

• SMTP failover and load balancing improvements. Exchange Server 2010 SP1 improves the way

Transport servers detect unhealthy servers and use enhanced DNS.

When all servers are healthy, enhanced DNS helps to distribute the load evenly, but when one or

more servers have become unavailable, the load distribution among the remaining healthy servers

may not be evenly balanced.

To help to address this, all Exchange Server 2010 SP1 Transport servers maintain a list of unavailable

servers. When routing a message, servers use this list to filter out the unavailable servers from the set

of target servers. Consequently, Exchange Server 2010 SP1 Transport servers always distribute the

load evenly between healthy servers and avoid any servers that are unavailable for any reason.

• Send connectors over reliable connections improvements. Exchange Server 2010 SP1 provides the

ability to downgrade connection failures in Send connectors.

Within your Exchange organization, you may implement dedicated Send connectors that are used for

routing messages over well-defined, reliable communication channels, for example, a send connectordedicated to sending messages to Exchange Online.

Because these communication channels are expected to be reliable, you might not expect to see so

many of the typical errors that occur on ordinary destinations over the Internet; consequently, you

might want to treat any such communication errors as transient instead of immediately resulting in

the generation of a non-delivery report (NDR).

With Exchange Server 2010 SP1, you can configure a send connector to downgrade authentication

and name resolution errors that normally result in an NDR, to transient errors. In these instances,

Exchange Server attempts delivery again, instead of immediately issuing an NDR.




Planning for Internal SMTP Relay

Internal SMTP relay occurs when you configure your Exchange Server organization to route email that is

addressed to recipients that do not exist within your AD DS forest, to another SMTP host. A possible

scenario might arise if your organization has two AD DS forests—perhaps following a merger or

acquisition. Each forest has its own Exchange Server organization, and you decide to configure one

organization to handle all inbound message routing for both organizations.

To demonstrate this point, consider two AD DS forests: A. Datum, and Contoso. A. Datum Corporation

recently acquired Contoso, Ltd. Both organizations have implemented Exchange Server 2010 in their AD

DS forests; however, following the acquisition, it is decided that the Exchange Server organization A.Datum will route all inbound email for both organizations. To facilitate this, you must complete the

following steps:

1. Configure external DNS records for both organizations to point to the A. Datum Edge Transport

servers.

2.

Configure the A. Datum organization with two accepted domains:

• Adatum.com is configured automatically as an authoritative accepted domain, as it is the forest

root domain for the A. Datum forest.

• Contoso.com must be configured as an accepted domain for internal relay.

3.

Create a Send connector at A. Datum to route messages to the Contoso organization.4.

Create a Send connector at Contoso to route messages to the A. Datum organization.

5.

Configure the reciprocal Receive connectors with settings that match the Send connectors in terms of

authentication and IP configuration.

6.

Configure a mechanism to synchronize the address lists between the two organizations. For example,

consider deploying Identity Integration Feature Pack (IIFP) or Microsoft Identity Integration Server

(MIIS) to propagate the mailbox users from Contoso to A. Datum as contacts.




Designing Accepted Domains and Remote Domains

As part of the Hub Transport server configuration process, you should configure the domains for which

the Hub Transport server will accept email, and configure users with alternate email addresses.

Accepted Domains

When you create a new accepted domain, you have three options for the domain type you want to

create:

• Authoritative Domain. Select this option if the recipients using this domain name have mailboxes in

the Exchange Server organization.

• Internal Relay Domain. Select this option if the Hub Transport or Edge Transport server should

accept the email, but relay it to another messaging organization in another AD DS forest. The

recipients in internal relay domain do not have mailboxes in this Exchange organization, but do have

contacts in the global address list (GAL). When messages are sent to the contacts, the Hub Transport

server or Edge Transport server forwards them to another SMTP server.

• External Relay Domain. Select this option if the Hub Transport or Edge Transport server should

accept the email, but relay it to an alternate SMTP server. In this scenario, the transport server

receives the messages for recipients in the external relay domain, and then routes the messages to

the email system for the external relay domain. This requires a Send connector from the transport

server to the external relay domain.




By default, only the forest root domain is established as an accepted domain. There are a number of

situations in which you may consider adding additional accepted domains. These include:

• Additional namespaces. If you have additional domains within your forest, or more particularly,

additional trees—which represent different namespaces—you may consider adding authoritative

domains for them. If you add an authoritative domain for an additional tree or domain within your

AD DS forest, you must also create an email address policy to support the domain.

• Mergers and acquisitions. When your organization acquires another organization, you may decide to

configure an accepted domain to facilitate internal relay to the acquired organization.

• External relay. You must configure an accepted domain to support external SMTP relay. Unlike

internal relay, where your Exchange Server organization routes messages to a Hub Transport server in

another AD DS forest, an external relay is to any SMTP host outside your organization. An ISP might

configure external relay for a customer.

Remote Domains

Remote domains define SMTP domains that are external to your Exchange Server organization. You can

create remote domain entries to define the settings for message transfer between the Exchange Server

2010 organization and domains outside your AD DS forest. When you create a remote domain entry, youcontrol 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.

You can create remote domain entries to define the mail transfer settings between the Exchange Server

2010 organization and a domain that is outside your AD DS forest. When you create a domain entry, you

provide a name to help the administrator identify the entry’s purpose when they view configuration

settings.

The domain name is limited to 64 characters. You also provide the domain name to which this entry and

the associated settings will apply. You can use a wildcard character in the domain name to include all sub-

domains. The wildcard character must appear at the start of the domain name entry. The SMTP domainname is limited to 256 characters.

The default settings may be suitable for most situations, but when you work with a partner organization,

you may choose to create a remote domain for their SMTP namespace, and configure specific settings

accordingly.




Designing Message Throttling, Back Pressure, and Size Limits

Under certain situations, it might be beneficial to configure a number of Exchange Server features that

enable you to more accurately control message flow within your organization. These features are:

• Message throttling. Message throttling is a group of limits that you can impose on the number of

messages and connections that a Hub Transport server or Edge Transport server can process. This

helps to prevent the accidental inundation of the system resources on the transport server.

• Back pressure. Back pressure is a system resource monitoring feature of the transport service that

exists on Hub Transport and Edge Transport servers. Transport servers detect when vital resources—such as available disk space—are under pressure, and take configured action to help to avoid service

unavailability.

• Message size limits. Message size limits enable you to restrict the total size of a message, or the size of

the individual components of a message—such as the message header or message attachments—and

the number of recipients. You can apply limits globally for the whole Exchange Server 2010

organization, or specifically for a particular connector or user object.

Message Throttling

Message throttling involves a variety of limits on message processing rates, SMTP connection rates, and

SMTP session time-outs. These limits combine to prevent the Hub Transport server or Edge Transport

server from being overwhelmed by accepting and delivering messages. Although a large backlog of

messages and connections may be waiting to be processed, the message throttling limits enable the

transport server to process the messages and connections in an orderly manner.

You can set the message throttling options on:

• The transport server. Configuring message throttling options on the transport server affects only

those messages transiting that particular transport server.

• A Send connector. This enables you to control message throttling for a specific Send connector—for

example, to control message throttling to an internal relay domain.




• A Receive connector. This enables you to control message throttling for a specific Receive

connector—for example, to control message flow from a partner organization.

Note In Exchange Server 2010 SP1, a running average delivery cost of messages sent by

specific users is maintained by transport servers. The delivery cost of a message is

determined by factors including to how many recipients it is addressed, and whether it has

large attachments. If a user often sends costly messages, Transport servers can give priority

to other messages with lower costs before processing messages from that user.

Transport servers also track the Remote Procedure Call (RPC) utilization of mailbox servers.

RPC sessions are established with mailbox servers when transport servers deliver messages

and when interactive client sessions occur. Excessive RPC utilization can result in a

downgraded client experience. If a Hub Transport server determines that a mailbox server is

under RPC resource pressure, it can reduce the RPC sessions that it opens to that mailbox

server. This can help to improve interactive client sessions on the mailbox server.

Back Pressure

In Exchange Server 2010, when a transport server is in back pressure, incoming connections are accepted;however, the incoming messages over those connections are either accepted at a slower rate, or are

rejected. This differs from Exchange Server 2007. When an Exchange Server 2007 Hub or Edge Transport

server is under resource pressure, it rejects incoming connections.

For each monitored system resource on a Hub Transport server or Edge Transport server, the following

three levels of resource utilization are applied:

• Normal. The resource is not being overused.

• Medium. The resource is slightly overused, and back pressure is applied to the server in a limited

manner. Mail from senders in the authoritative domain can flow. However, depending on the specific

resource under pressure, the server uses tar-pitting to delay server response, or rejects incoming MAIL

FROM commands from other sources.

• High. The resource is severely overused, and full back-pressure is applied. All message flow stops, and

the server rejects all new incoming MAIL FROM commands.

Back pressure monitors the following resources:

• Free space on the message queue database hard disk drive. The high level of hard disk space

utilization is calculated by using the following formula:

100 * (hard disk size – fixed constant) / hard disk size

In this formula, the fixed constant defaults to 500 megabytes (MB).

• Free space on the message queue database transaction logs hard disk drive. By default, the high level

of hard disk utilization is calculated by using the following formula:

100 * (hard disk size - Max(5 GB, 3*DatabaseCheckPointDepthMax) / hard disk size

In this formula, DatabaseCheckPointDepthMax defaults to 512 MB.

• The number of uncommitted message queue database transactions.




• The memory that is used by the EdgeTransport.exe process. By default, the high level of memory

utilization by the EdgeTransport.exe process is calculated by using the following formula:

75 percent of the total physical memory or 1 terabyte, whichever is less

• The memory that is used by all processes. By default, the high level of memory utilization by all

processes is 94 percent of total physical memory.

Message Size Limits

You can configure the scope of message size limits as follows:

• Organizational limits. These limits apply to all Exchange Server 2010 and Exchange Server 2007

servers that exist in your organization.

• Global limits. These limits apply to all Exchange Server 2010, Exchange Server 2007, and Exchange

Server 2003 servers that exist in your organization.

• Connector limits. These limits apply to any messages that use the specified Send, Receive, or Foreign

connector for message delivery.

• AD DS site links. Any messages that exceed the maximum message size limit on any AD DS site link

included in the least cost routing path are not delivered, and generate a delivery status notification

(DSN) that has the value 5.3.4.

• Routing group connectors. Any messages that exceed the maximum message size limit on any routing

group connector in the least cost routing path will not be delivered; they will generate a DSN that has

the value 5.3.4.

• Server limits. These limits apply to a specific Hub Transport server or Edge Transport server.

• User limits. These limits apply to a specific user object, such as a mailbox, contact, distribution group,

or public folder.




Troubleshooting Internal Message Delivery

Exchange Server 2010 provides several tools for troubleshooting SMTP message delivery.

Using the Exchange Server Best Practices Analyzer

The Exchange Server Best Practices Analyzer is a tool that you can use to check the Exchange server

configuration and health of your Exchange server topology. This tool automatically examines an Exchange

server deployment, and determines whether the configuration is in line with Microsoft best practices. You

should run the Best Practices Analyzer after you install a new Exchange server, upgrade an existing

Exchange server, or make configuration changes.

Using the Exchange Mail Flow Troubleshooter

The Exchange Mail Flow Troubleshooter tool assists Exchange Server administrators in troubleshooting

common mail-flow problems.

When you launch the Mail Flow Troubleshooter, you are prompted to select from the symptoms that

describe the message-flow issue. Based on the symptoms, the tool suggests a troubleshooting path. The

tool also shows an analysis of possible root causes, and provides suggestions for corrective actions.

Using the Queue Viewer

Like previous Exchange Server versions, messages waiting to be processed or delivered reside in message

queues on the Hub Transport servers. However, unlike Exchange Server versions before 2007, all message

queues reside in a local Exchange Server database on the server.The message queues provide a very usefuldiagnostic tool to locate and identify messages that have not been delivered.

Exchange Server 2010 provides simplified queues. Hub Transport servers maintain five queues:

• Submission queue. This queue contains messages that the Categorizer is processing.

• Remote delivery queue. There is one queue for each outbound SMTP domain to which mail is routed.

• Poison message queue. This queue contains messages that might have caused the server to crash.




• Mailbox delivery queue. There is one queue for each Mailbox server to which the Hub Transport server

can deliver messages.

• Unreachable queue. This queue contains messages that cannot be routed to their destinations.

Using Message Tracking

You also can use message tracking to troubleshoot message flow. By default, message tracking is enabledon Hub Transport servers, and all message-tracking logs are stored in the C:\Program

Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking folder. The message-tracking

logs are retained for 30 days, with a maximum size for all log files of 250 MB.

Exchange Server 2010 SP1 introduced a number of message tracking improvements:

• Improved error messages for delivery reports. If a user attempts to access delivery reports for a

message immediately after sending it, it is possible that the tracking information for that message has

not yet been inserted into the logs with the result that the user cannot view the report. In this type of

situation, Exchange Server 2010 SP1 improves the message displayed to the user, providing specific

explanations as to why the requested information is not available.

• Message tracking, monitoring, and troubleshooting. Exchange Server 2010 SP1 adds several new

monitoring capabilities for message tracking, including new event log entries, alerts, and performance

monitor counters.

• Message tracking trace levels. You can now request complete logs of every operation that was

executed by a Client Access server processing a delivery report request. The additional logging detail

may be beneficial when troubleshooting message flow.

Using the Routing Log Viewer

You can use the routing log viewer to open a routing log file that contains information about how the

routing topology appears to the Exchange server. You can use this information when you troubleshoot

message routing within the organization or to the Internet. To use the Routing Log Viewer, start the

viewer from the Tools folder in Exchange Management Console, and then open the routing log files on a

specific server. You can open the current log file or previous ones.

Using Protocol Logging

You also can configure protocol logging to provide detailed information for troubleshooting message

flow. Protocol logging is enabled on the SMTP Send connector or SMTP Receive connector properties,

and the log files are stored in the C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs

\ProtocolLog folder.

Using Telnet

You can use Telnet to check if the SMTP port responds, or to directly send an SMTP mail to a connector to

see if the connector accepts it. Telnet is a Windows Server® 2008 feature, and you use it from the

command line using the following syntax: telnet <servername> SMTP or Port #.




Lesson 3

Designing the Message Routing Perimeter

Another important component in designing an Exchange Server 2010 organization’s message routing is to

plan how messages pass through the network perimeter. The network perimeter requires special

consideration because of issues related to connecting an internal network to the Internet. As you plan the

message routing perimeter, you must consider all possible ways that messages may be sent outside the

Exchange Server organization.

ObjectivesAfter completing this lesson, you will be able to:

• Describe the default Edge Transport server configuration.

• Design Edge Subscriptions.

• Design outbound message flow to the Internet.

• Design inbound message flow from the Internet.

• Design message routing from the internal network to the network perimeter.

• Plan address rewriting.




Default Edge Transport Server Configuration

It is important that you are familiar with the default configuration of Edge Transport servers. This enables

you to make an informed choice about whether you must reconfigure the Edge Transport server to

support the needs of your organization.

Transport Agents

The Edge Transport server supports the following transport agents:

• Connection Filtering agent . This is an anti-spam agent that is enabled on Edge Transport servers.

• Address Rewriting Inbound agent . This agent rewrites inbound email addresses.

• Edge Rule agent . This agent provides compliance at the Edge Transport server.

• Content Filter agent . This agent evaluates inbound email messages, and assesses the probability that

an inbound message is legitimate or spam.

• Sender ID agent . This is an anti-spam agent that is enabled on Edge Transport servers. Sender ID helps

to combat the impersonation of a sender and a domain, a practice that is known as spoofing; a

spoofed mail is an email message that has a sending address that is modified to appear as if it

originates from a sender other than the actual sender of the message.

• Sender Filter agent . This is an anti-spam agent that is enabled on Edge Transport servers. The Sender

Filter agent acts on messages from specific senders outside the organization. You can maintain a listof senders that are blocked from sending messages to your organization. You can block single

senders ([email protected]), whole domains (*@.adatum.com), or domains and all subdomains

*@*.adatum.com).

• Recipient Filter agent . This is an anti-spam agent that is enabled on Edge Transport servers. The

Recipient Filter agent blocks messages according to the characteristics of the intended recipient in the

organization.


mailto:(*@.adatum.com

mailto:(*@*.adatum.com

mailto:(*@*.adatum.com

mailto:(*@.adatum.com





• Protocol Analysis agent . Protocol logging records the SMTP conversations that occur between email

servers as part of message delivery.

• Attachment Filtering agent . This agent lets you apply fi lters at the Edge Transport server to control the

attachments that users receive.

• Address Rewriting Outbound agent . This agent rewrites addresses for outbound email.

Connectors

By default, until you establish an Edge subscription, there are no Send or Receive connectors on the Edge

Transport server. If you decide to create an Edge subscription, the necessary Send and Receive connectors

are created. This is discussed in more detail in the following topic.

Accepted Domains

There are no accepted domains configured by default. After you have established an Edge subscription,

you must configure accepted domains for your organization. These settings are synchronized with the

Edge Transport servers through the Edge subscription process. This is discussed in more detail in the

following topic.




Designing Edge Subscriptions

You can subscribe an Edge Transport server to an AD DS site. This associates the Edge Transport server

with the Exchange Server organization. A subscribed Edge Transport server is stamped with an AD DS site

attribute, which means that you can configure the Edge subscription as a source server for Send

connectors that you create in the Exchange Server organization.

When you configure an Edge subscription, the configuration between the Exchange Server organization

and the Edge Transport server occurs automatically, and enables Internet message flow. After you

configure the Edge Subscription, the Edge synchronization process replicates the following data from AD

DS to Active Directory Lightweight Directory Service (AD LDS):

• Accepted and remote domains

• Recipients (Hashed)

• Safe senders (Hashed)

• Send connectors

• Hub Transport server list (for dynamic connector generation)

Note A one-way hash is used on the recipient’s and safe sender’s information so that a

malicious user cannot retrieve it from the Edge Transport server.




Considerations for Designing Edge Subscriptions

When designing Edge subscription, consider the following factors:

• You can subscribe an Edge Transport server only to a single AD DS site. If you have multiple AD DS

sites through which you want to route Internet email, you must configure a separate Edge

subscription for each site.

• An Edge subscription is specific to each Edge Transport server. If you deploy multiple Edge Transport

servers in a perimeter network, you must configure an Edge subscription for each Edge Transport

server. After you deploy each server’s Edge subscription, Edge synchronization configures many of the

Edge Transport server settings. You also can use Edge cloning to duplicate other configuration

settings, such as the anti-spam filters.

• When you configure the Edge subscription, it sets up secure message transfer between the Edge

Transport server and all Hub Transport servers in the subscribed AD DS site. If you deploy new Hub

Transport servers in the site after you configure the Edge subscription, you must remove the existing

Edge subscription, and then add a new one so that the new Hub Transport servers will use the Edge

Transport server for message routing.

•

Deploy multiple Edge Transport servers to enable high availability and load balancing. If you aredeploying multiple Edge Transport servers, then configure a mail exchanger (MX) resource record for

each Edge Transport server in the DNS zone that is accessible from the Internet. Internet SMTP hosts

use DNS round-robin to distribute the load for incoming email. Additionally, the internal Hub

Transport servers distribute message flow between all available Edge Transport servers to load-

balance outbound message delivery. If one of the Edge Transport servers is not available, both

inbound and outbound email is sent through the available servers.




Designing Outbound Message Flow

To enable message flow to the Internet, you must configure the Exchange organization with at least one

SMTP Send connector that has an SMTP address space that includes Internet SMTP domains. Depending

on your organization’s requirements, you can deploy multiple Edge Transport servers with multiple SMTP

Send connectors to send Internet email.

Considerations for Designing Outbound Message Flow

When designing outbound message flow, consider the following issues:

•

Using a single location for routing all messages to the Internet, or enabling message routing throughmultiple locations. If your organization has more than one location with an Internet connection, you

can enable message routing through each. To do this, you can choose one of the following options:

• Install an Edge Transport server in each location, and configure Edge subscriptions between the

Edge Transport servers and the local AD DS sites.

• Manually configure Send connectors on the Hub Transport or Edge Transport servers.

Load balancing and availability are the primary advantages of using multiple connections.

Note Exchange Server 2010 does not fail over automatically to use an alternate connector

if one connector is unavailable. Each server running Exchange Server 2010 chooses a single

route for delivering messages to a specified recipient. If a connector is unavailable for anextended period of time, and you need to force the Exchange Servers to use an alternate

connection, remove the connector from the Exchange Server organization, wait for AD DS

replication to update all organizational domain controllers, and restart the Microsoft

Exchange Transport service to force the Hub Transport servers to recalculate routing.




• Configuring the SMTP Send connectors. To enable outbound message flow, you must configure at

least one SMTP Send connector to send email to the Internet. You can use the following options to

configure SMTP Send connectors:

• Use Edge synchronization to configure the SMTP Send connectors. When you configure an Edge

subscription, Edge synchronization automatically configures a Send connector for the AD DS site

to enable message delivery between the local Hub Transport servers and the Edge Transportserver. Additionally, Edge synchronization configures a Send connector to enable message

delivery from the Edge Transport server to the Internet.

• Create additional SMTP Send connectors. You might have additional requirements for Send

connectors. For example, you might need to configure unique message routing or message

security for a partner organization. You can configure an additional Send connector using the

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.

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




Designing Inbound Message Flow

To enable message flow from the Internet, you must configure the Exchange Server organization with at

least one SMTP Receive connector that will accept anonymous SMTP connections from Internet SMTP

servers. Depending on your organization’s requirements, you can deploy multiple Edge Transport servers

with multiple SMTP Receive connectors to receive Internet email.

Considerations for Designing Inbound Message Flow

When designing inbound message flow, consider the following issues:

•

Will you use a single location for inbound routing from the Internet, or will you enable messagerouting through multiple locations? If your organization has more than one location with an Internet

connection, you can enable inbound message routing through each location. To do this, you can

either install an Edge Transport server in each location, and then configure Edge subscriptions

between the Edge Transport servers and the local AD DS sites, or you can configure receive

connectors manually on the Hub Transport or Edge Transport servers. Load balancing and availability

are the primary advantages of using multiple connections.

• If you are going to implement multiple inbound routing points, how do you plan to design the MX

records? If you configure MX records for each inbound SMTP server with equal priorities, the inbound

messages are load-balanced between the two servers. If you configure MX records with different

priorities, the SMTP servers with the lowest priority MX record references are used for all inbound

message flow, and those that the higher priority MX record references are used only when the firstSMTP servers are not available.

• How will you configure SMTP Receive connectors? By default, an Edge Transport server is configured

with an SMTP Receive connector that accepts anonymous connections from all IP addresses. You can

use this Receive connector to accept incoming email. All Hub Transport servers also are configured

with a Receive connector. However, this connector only accepts authentication connections.




• If you configure Edge subscription, this creates a Send connector on the Edge Transport server to

send messages to the internal Hub Transport servers. The Edge subscription also configures an

account that authenticates the connection to the Hub Transport server and provides an encryption

key that can encrypt messages sent between the two servers.

• You can create additional SMTP Receive connectors to address specific business requirements. For

example, you may want to configure a Receive connector that requires authentication or TLSencryption 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.




Designing Message Routing to the Perimeter

In addition to planning a message routing topology inside the Exchange Server organization, you also

need to plan a message routing topology for messages sent to recipients outside the Exchange Server

organization. To do this, you must understand how Exchange Server 2010 selects a route for outbound

messages, and how to optimize this configuration.

How Exchange Server 2010 Routes Messages to the Network Perimeter

For Exchange Server 2010 to route messages outside the organization, you must configure at least one

SMTP Send connector with an address space that includes external SMTP domains. By default, when youdeploy a Hub Transport server and an Edge Transport server, no Send connectors are configured. When

you configure an Edge subscription between an AD DS site and an Edge Transport server, a Send

connector is configured with an address space of * that uses the subscribed Edge Transport server as the

connector source server. This Send connector enables the Hub Transport servers in the subscribed AD DS

site to route messages to the Edge Transport server, which then routes the message outside the

organization.

Note You also can configure a Send connector on one or more Hub Transport servers to

enable message flow outside the organization.

If you configure more than one Send connector with a namespace that meets the routing requirements

for an external recipient, Exchange Server 2010 routing will select a single connector through which to

route the message using the following algorithm:

• Select the connectors that do not have restrictions that prevent message delivery. If you configure a

Send connector with a 3 MB size limit, it will not be considered for sending a message with a 4 MB

attachment. A disabled connector is not selected for sending messages.




• From the remaining connectors, select the connectors with the most specific address space match. For

example, if you configure one Send connector with the address space *.contoso.com, and a second

connector with the address space *, a message that is addressed to a recipient with an SMTP address

@contoso.com is routed through the first connector.

• From the remaining connectors, select the connector with the lowest aggregate cost. The connector’s

cost is determined by adding the cost of the IP site links between the source site and the AD DS sitethat contains the source servers for the Send connector, and the cost assigned to the connector.

• From the remaining connectors, select the connector with the closest proximity. The local server is

chosen over another Hub Transport server in the same AD DS site, while a server in the local AD DS

site is chosen over a source server in a remote AD DS site.

• From the remaining connectors, select the connector with the lowest alphanumeric connector name.

Note After selecting the SMTP Send connector to use to send the message outside the

organization, the Hub Transport server in the source site routes the message to a Hub

Transport server in the site where you have configured the Send connector. Exchange Server

2010 uses deterministic routing for messages sent outside the organization. Exchange

Server 2010 chooses a single route through which to send messages outside theorganization, and it will not use an alternate route unless you change the underlying

routing configuration.

Configuring the Connector Scope to Manage Message Routing to the Perimeter

The address space for a Send connector can be scoped to an AD DS site. When a scope is applied to a

Send connector, it is visible to only the Hub Transport servers in the AD DS site to which the connector is

scoped. Only servers that have site membership can consider that connector for routing to external

recipients.

Note Assign limited scope to a connector by adding the Local: prefix to the address

space. Do this with the Set-SendConnector cmdlet. For example, to limit a Sendconnector’s scope to an AD DS site, you run the following command: Set-SendConnector -identity Connectorname -AddressSpaces local:*.

Considerations for Designing Message Routing to the Network Perimeter

For all organizations—including those with a single AD DS site—if you are planning message routing to

the network perimeter, it is important to consider:

• Whether to use an Edge Transport server to route messages to and from the Internet.

• Whether to configure Edge subscriptions between the Edge Transport server and the AD DS site.

Both of these options are highly recommended to provide maximum security and administrative ease.

If your organization has multiple AD DS sites, you also should consider the following factors:

• Consider whether you want to implement a single path for routing messages to the Internet, or

whether you want to implement multiple paths. The greatest advantage of a single route is security.

You need to be concerned only with a single connection, from the internal network to the Internet.

Redundancy and load balancing are the greatest advantages of multiple routes.

mailto:@contoso.com

mailto:@contoso.com




• If you implement multiple paths to the Internet, you also must plan the internal message routing for

messages being sent to the Internet. By default, each Exchange Server 2010 server considers all SMTP

Send connectors with the correct external address space, when choosing a route over which to

send messages to the Internet. When you plan message routing to the AD DS site that can route

messages to the Internet, use the same considerations that you used for planning internal message

routing between AD DS sites.

• Use the connector scope to control whether messages sent to recipients outside the organization are

sent between AD DS sites. For example, if you have two company locations that have Internet

connections, but are connected by a wide area network (WAN) link with limited available bandwidth,

you can define the Send connector scope in both locations as local, so that messages bound for the

Internet are never routed across the WAN link.




Planning Address Rewriting

Address rewriting enables you to modify the addresses of originators or recipients in your Exchange

Server organization. Generally, you use address rewriting to present a consistent interface to

correspondents that are external to your organization.

There are a number of specific reasons why you might consider address rewriting.

• Group consolidation. If your organization segments its internal business into separate domains—for

technical or business reasons—this would typically cause email to appear to originate from separate

organizations. For example, in the domains Asia.Adatum.com, Europe.Adatum.com, andAmericas.Adatum.com, address rewriting could be used to ensure that email appears to come from a

single domain—Adatum.com.

• Mergers and acquisitions. If you recently acquired a new company, it will have a different namespace

from your current organization. If you want email that originates in the acquired organization to

appear to come from your own organization, you could implement address rewriting.

• Partners. If you use partner organizations to provide services or to manage projects, you can use

address rewriting. For example, if you outsource the launch of a new product to a marketing

company, it may be useful to implement address rewriting so that messages originating in the partner

organization have addresses from your own organization.

Considerations for Address Rewriting

It is important to note that there are a number of considerations for address rewriting.

• Outbound-only address rewriting. When an email message is outbound from your Exchange

organization, outbound-only address rewriting involves modification of only the sender SMTP

address. You can configure the Address Rewriting agent only on the Send connector on the Edge

Transport server. The following list shows the conditions that are required to configure an outbound-

only Address Rewriting agent:




• The resulting addresses must be unique across the organization. For example, if you include the

unique email addresses [email protected] [email protected] in a rule to rewrite all

addresses to adatum.com, the Address Rewriting agent rewrites both addresses to

[email protected], and causes a conflict. When such a conflict occurs, you must change the email

address of one of the recipient mailboxes to an address that does not conflict with the email

address in any other subdomain.

• You must configure a proxy address on each mailbox that matches the rewritten email address.

This enables those mailboxes to receive replies to email messages in which headers are rewritten.

• When you use wildcard characters, there must be a period between the wildcard character and

the domain name.

• You can use wildcard characters only in the internal domain.

• No characters can be in front of the wildcard character.

• Outbound-only address rewriting cannot affect the part of the address with the user name or

display name.

• Only literal strings are supported.

• Bidirectional address rewriting. Bidirectional address rewriting modifies both the sender SMTP address

on email messages that leave your Exchange Server organization, and the recipient SMTP address on

email messages that enter your Exchange Server organization. To do this, you configure the Address

Rewriting agent on both the Send connector and Receive connector on the Edge Transport server.

The following list shows the conditions that are required when you create a bidirectional Address

Rewriting agent:

• You cannot use wildcard characters.

• You must use full SMTP addresses when you configure a bidirectional address rewriting rule. For

example, the internal address is [email protected], and the external address is

[email protected].

•

Only literal strings are supported.

• The address must be unique across the organization. For example, if an

email address such as [email protected] already exists, mapping [email protected] to

[email protected] will cause replies to messages from [email protected] to be delivered to the

wrong person.

• Priority of address rewriting entries. The rule that best matches the internal and external domain pair is

applied. The following prioritization is the exact order of address rewriting entries from highest

priority to lowest priority:

• Individual email addresses. For example, mapping [email protected] to [email protected].

• Specific domain or sub-domain mapping. For example, mapping Adatum.com to Contoso.com or

Sales.Adatum.com to Adatum.com.

• Domain flattening. For example, flattening *.adatum.com into Adatum.com.

mailto:'[email protected]





















mailto:'[email protected]




• Digitally signed, encrypted, or rights-protected email . Address rewriting should not affect most signed,

encrypted, or rights-protected messages. If address rewriting were to invalidate a signature, make an

encrypted or rights-protected message unreadable, or otherwise change the security status of such

messages in any way, address rewriting is not applied. Addresses and information in the following

message sections can be rewritten, because information in these sections is not part of message

signing, encryption, or rights protection:

• SMTP envelope fields

• Top-level message body headers

Addresses and information in the following message sections is not rewritten, because information in

these sections is part of message signing, encryption, or rights protection:

• Headers located inside MIME body parts that may be signed

• The boundary string parameter of the MIME content type




Lab: Planning and Deploying Message Transport inExchange Server 2010

Lab Setup



2. Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, 10233B-VAN-EX2, and the 10233B-VAN-EDG

virtual machines are running.



4.

Log on to 10233B-VAN-EDG as Administrator using the password Pa$$w0rd

Lab Scenario


locations.

You have been tasked with designing the new routing infrastructure for your organization. You must

examine the documentation that details the existing infrastructure, and then make proposals regarding

any changes you might need to make to address the organization’s needs. You must also document your

proposals.

Finally, use various Exchange Server management tools to investigate the current routing topology, and

make some changes.






AD DS and Routing Interview Notes.doc


The company just finished upgrading all of the AD DS domain controllers to Windows Server 2008,

Service Pack 1 (SP1). The company has indicated that there is not enough budget for any further AD DS

changes, so any modifications we make as part of this project must have no budget implications.

One change that we have been considering is removing the Chennai domain controller. The office

currently does not have a secure server room. There was a project in place to build the server room, but

that project’s budget is in jeopardy. Any input you could provide to this decision would be appreciated

greatly.


We currently are having some messaging problems at the London location. Quite often, when I look at

the server queues on the Exchange Servers, I see that there are many messages in the categorizer queue.

Users also complain that when they try to view the global address list (GAL), it can take more than 10

seconds for it to appear. All of the other network locations seem to be fine.

We have had some past problems with the bridgehead servers in London, Vancouver, and Tokyo. The

problem shows up when there is a network outage to one of the other offices. If the outage lasts for more

than a few minutes, it seems like we get hundreds of messages in the bridgehead server queues, and then

it can take a long time for the server to deliver the messages once we restore the network connection.

Compounding this problem in London is the fact that this is the only location where we are accepting

inbound SMTP email for Trey Research. We need to make sure that messages get sent out of these sites

even if the final destination site is not available.

As you have already heard, we have many employees using Office Outlook Web Access. We would really

like to make sure that the experience for the Outlook Web App users is as positive as possible.


We have been monitoring network traffic by protocol for the last year, and have noticed a very big

increase in the network bandwidth that SMTP traffic uses. In your design, you need to make sure thatemail messages always are sent through the network connections that have the highest bandwidth. Also,

make sure that you take advantage of any other way that you can save bandwidth that email uses.

We are just taking over managing the network in San Diego, so we are not sure what network changes we

will need to make there. From what I understand, we may need to wait on some firewall changes until

after we get rid of the current messaging system.


Our department is responsible for the company’s firewall configurations. With every company location

having its own Internet connection, this can be a real challenge. Right now, we are allowing Hypertext

Transfer Protocol Secure (HTTPS) access to some Exchange Servers in London, Vancouver, and Tokyo. This

configuration is working okay, but we do not want to open up any more messaging ports in any location.Additionally, we are currently allowing incoming and outgoing SMTP traffic through our firewalls only in

London, because that is the only location where we have a spam-filtering solution in place. We would be

open to changing this, but we would need to know that the email messages are being scanned for viruses

and spam in all locations where we allow SMTP traffic.




Adatum_Info.vsd (WAN Links)









Exercise 1: Designing a Message Routing Topology

Scenario

In this exercise, you will design a message routing topology for the A. Datum Exchange organization.

To complete this exercise, review the existing A. Datum Corporation documentation:

•

Interview notes from meetings with various A. Datum Corporation personnel.

• Microsoft Office Visio® diagrams describing the A. Datum Corporation site topology.



2.

Modify the A. Datum Current AD DS Site Design diagram with proposed changes to the site design.


• Review the contents of the following files:


•


• Adatum_Info.vsd

Task 2: Modify the A. Datum current AD DS site design diagram with proposed

changes to the site design

1. Use callouts in the following diagram to document proposed changes to the site design. For each

proposed change, provide:

• The proposed change.

• A rationale for the proposed change.

2.

Indicate which server roles need to be deployed in each AD DS site.3. Document message flow within the organization. Document the changes that you will need to make

to the AD DS configuration to enable optimal message flow.


Results: After this exercise, you should have successfully modified the A. Datum AD DS site design.




Exercise 2: Designing a Messaging Perimeter

Scenario

In this exercise, you will design a message perimeter for the A. Datum Exchange organization.

To complete this exercise, review the following A. Datum Corporation documentation:

•

Interview notes from meetings with various A. Datum personnel

• Office Visio diagrams describing the A. Datum network perimeter configuration



2.

Modify the A. Datum Current Perimeter Design diagram with proposed changes to the site design.




•


• Adatum_Info.vsd

Task 2: Modify the A. Datum current perimeter design diagram with proposed


1. Use callouts in the following diagram to document proposed changes to the perimeter design. For

each proposed change, provide:



2.

Indicate whether you need to deploy any additional server roles in each AD DS site.3. Indicate the required firewall changes to meet your design requirements.

4. Indicate any other infrastructure changes that you must implement to meet your design

requirements.

5. For each company location, document how messages are delivered to the Internet, and how inbound

messages are delivered to internal recipients.


Results: After this exercise, you should have successfully designed the A. Datum messaging perimeter.




Exercise 3: Discussion: Improving an AD DS and Message Routing Design

Scenario

In this exercise, you will present your design decisions from the previous two exercises, and discuss your

recommendations.

Task: Discuss as a class, and then answer the following questions

Question: What changes did you make to the AD DS site configuration and the

organization’s message routing?

Question: If your recommended changes are implemented, how will messages flow between

the AD DS sites? Where will messages be queued in the event of a server or network

connection failure?

Question: How did you design message routing to the Internet?

Question: What conflicting requirements were presented in the scenario? How did you

resolve conflicting requirements?

Question: What additional information should you consider when designing message

routing in this scenario?

Results: After this exercise, you should have successfully improved the A. Datum AD DS and message

routing design.




Exercise 4: Modifying the Routing Topology

Scenario

A. Datum Corporation has a partner organization, Contoso, Ltd based in New York. You must make some

configuration changes to the routing infrastructure to support messaging to the partner organization. In

this exercise, you will investigate the current routing topology, and then make some configurationchanges.


1.

Determine the current organizational settings.

2. Examine the current routing topology.

3.

Add a new accepted domain.

4.

Configure a send connector to support the new accepted domain.

5. Update the default site configuration with Exchange Server-specific values.

6. Add an Edge Subscription.

7.

Review the updated topology.

Task 1: Determine the current organizational settings

1. On VAN-EX1, open the Exchange Management Console.

2.

Browse to the Organization Configuration, and view the Send Connectors tab in the Hub

Transport node.

Question: Have any connectors been configured?

Question: Has an Edge Subscription been defined?

Task 2: Examine the current routing topology

1. From the Toolbox, open Routing Log Viewer.

2. Use the File menu to open the most recent routing table file.

3.

Use the various tabs to answer the following questions:

Question: Is Default-First-Site-Name a hub site?

Question: What is the AD DS cost of the link to VAN-EX1.Adatum.com?

Question: What Send Connectors are listed?

Question: What Address Spaces are listed?

4.

Close Routing Log Viewer.




Task 3: Add a new accepted domain

• From Organization Configuration, in the Hub Transport node, create a new Accepted Domain with

the following properties:

• Name: Contoso

•

Domain name: Contoso.com • Type: External Relay Domain

Task 4: Configure a Send connector to support the new accepted domain

• From Organization Configuration, in the Hub Transport node, create a new Send Connector with the

following properties:

• Name: Contoso Connector

• Intended use: Partner

• Address: Contoso.com

• Include all subdomains: Yes

• Cost: 10

• All other settings: default values

Task 5: Update the default site configuration with Exchange Server-specific values

1.

Open the Exchange Management Shell.

2.

At the Shell, type the following command, and then press Enter.

set-AdSite – id “Default-First-Site-Name” –HubSiteEnabled $true

3. At the Shell, type the following command, and then press Enter.

set-AdSiteLink –id “DEFAULTIPSITELINK” –ExchangeCost 25

4.

Close the shell.

Task 6: Add an Edge subscription

1. Switch to VAN-EDG.

2.


3. At the Exchange Management Shell, type the following command, and then press Enter

new-edgesubscription –filename C:\EdgeSubscriptionExport.xml.

4.

When prompted, type Y, and then press Enter.

5.

At the Exchange Management Shell, type the following command, and then press Enter.

copy c:\EdgeSubscriptionExport.xml \\VAN-EX1\c$

6.

Switch to VAN-EX1.




7. Create a new Edge Subscription with the following properties:

• Site: Default-First-Site-Name

• Subscription file: C:\EdgeSubscriptionExport.xml

• Other settings: default values

Note You may receive a warning. This is expected.

Task 7: Review the updated topology

1. Open Routing Log Viewer from the Toolbox.

2.

Use the File menu to open the most recent routing table file.

3. Use the various tabs to answer the following questions:


Question: What SMTP Send Connectors are listed?

Question: What SMTP Address Spaces are listed?

Question: What is the connector cost for the Contoso Connector?

4. Close the Routing Log Viewer.

Results: After this exercise, you should have modified the message routing topology.



following steps:


2.


3.

In the Revert Virtual Machine dialog box, click Revert.

4. Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EDG. Close the virtual

machine connection windows.

5.

In the Virtual Machines pane, click 10233B-VAN-DC1, and then in the Actions pane, click Start.









8.

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





Review Questions

1. In which folder are the routing table logs stored?

2.

When would you consider implementing Exchange Server-specific routing costs?

3.

When you add an accepted domain for other than your forest root domain, what else must you

configure in order for recipients within your organization to receive email using the new accepted

domain?






6-1

Module 6

Planning and Deploying Messaging Security

Contents

Lesson 1: Designing Message Security 6-3

Lesson 2: Designing Antivirus and Anti-Spam Solutions 6-16

Lab: Planning and Deploying Messaging Security 6-32



6-2 Planning and Deploying Messaging Security

Module Overview

A critical consideration when designing a Microsoft® Exchange Server 2010 messaging solution is

ensuring that the messaging system is as secure as possible. This includes planning for message security,

which ensures that messages sent within the organization, and to and from the Internet, meet the

organization’s compliance and security requirements. A second consideration for planning the security is

implementing an antivirus and anti-spam solution that prevents malicious emails from entering the

Exchange Server organization.

ObjectivesAfter completing this module, you will be able to:

• Design message security.

• Design antivirus and anti-spam solutions.




Lesson 1

Designing Message Security

Designing message security is an essential part of designing security for your Exchange Server 2010

organization. Exchange Server 2010 provides several features, such as transport rules, Simple Mail Transfer

Protocol (SMTP) connector security, and Domain Security to provide message-level security.

Objectives


• Define message security requirements.

• Design restrictions to message flow.

• Design SMTP connector security.

• Design secure message routing between partner organizations.

• Design client-based messaging security.




Defining Message Security Requirements

In most organizations, email is a primary tool for exchanging business information, and many business

processes depend upon it. However, SMTP email is not secure because SMTP message contents are not

encrypted or validated. This means that your confidential information potentially may be exposed

through email.

To plan for your organization’s messaging security, you first need to understand what types of data your

organization is sending through email, and how you are currently securing those messages.

Analyze Email Message ContentsTo collect information about email message contents, you should ask the following questions:

• Is confidential business information sent via email? This information may include confidential

corporate documentation such as sales projections, salary information, trade secrets, or intellectual

property.

• Is private customer information sent by email? If your organization uses email to exchange

information with customers, you need to analyze the type of information that you are exchanging.

Some information—such as customer queries or orders—may be confidential. If this information

becomes public, the organization’s reputation may suffer. Additionally, if the customer information

includes private information such as social security numbers or transactional information, your

organization may be legally liable.

Note It might also be important that recipients of messages can ensure that messages

were not tampered with during transit.




Analyze Message Recipients and Senders

To collect information about message recipients and senders, you should ask the following questions:

• Are both recipients and senders internal to the organization, or is the email sent externally? In most

cases, confidential corporate information is sent to other internal users. However, those users may be

forwarding the information to external email addresses. In some organizations where users do not

have external email access, they may send email to an external email address—such as to personalaccount—to enable them to work outside the office. Customer information is almost always sent

outside the organization.

• Are confidential emails sent primarily to a limited number of external organizations, or to a variety of

recipients? If confidential emails are sent to external recipients, you need to understand where those

messages are going. In some cases, confidential email may be sent primarily to one or two partner

organizations. For example, a law firm may exchange confidential emails with large corporate clients.

In other cases, the confidential emails may be sent to thousands of recipients in many different

locations.

Analyze Current Security Mechanisms

Most organizations have some level of Internet email security. In some cases, organizations use corporatepolicies to try to restrict what messages are sent to the Internet. For example, an organization might

implement a policy that prohibits email that is sent to customers, from including the customer’s social

security number, credit card number, or other personal information. Some organizations incorporate

technical solutions to enable email security—such as Secure/Multipurpose Internet Mail Extensions

(S/MIME), Pretty Good Privacy (PGP), or secure network connections.

Organizations that secure email by using policies or technical solutions should analyze the effectiveness

and satisfaction with their current solution by asking the following questions:

• Are users complying with email usage policies?

• If the organization policy requires that all customer emails with confidential information be secured

using Secure/Multipurpose Internet Mail Extensions (S/MIME), are all users complying with the policy?

If the current security efforts are not effective, then investigate why they are not meeting the

organization’s needs.




Designing Restrictions to Message Flow

One of the options for providing message security is to implement restrictions on what messages users

can receive and send out of the organization. Exchange Server 2010 provides transport rules that you can

use to restrict message flow, or to modify messages in transit by attaching disclaimers or headers to them.

Restricting Message Flow with Transport Rules

You can implement transport rules to restrict message flow in many different ways, including:

• Implementing Hub Transport rules. The Transport Rules agent on the Hub Transport server applies

Hub Transport rules, which Active Directory® Domain Services (AD DS) stores, and which are appliedon all Hub Transport servers in the Exchange Server organization. You can use Hub Transport rules to

enforce message flow restrictions, such as:

• Preventing inappropriate content from entering or leaving the organization through the

messaging system.

• Filtering the organization’s confidential information that exists within the messaging system.

• Tracking or archiving messages that specific individuals send or receive.

• Redirecting inbound and outbound messages for inspection before delivery.

• Applying disclaimers to messages as they pass through the messaging system.

When designing the Hub Transport rule implementation, you must define precisely the messages to whichthe policies need to apply. In some cases, this may be easy, such as when you want to apply a transport

rule to all messages that a particular user or group sends.

In other cases, you might be required to use multiple criteria. You can use many different criteria when

selecting conditions and exceptions. For example, to filter messages for confidential customer information,

you can define the criteria that the transport rule should use to evaluate whether the message contains

customer information. As a best practice, begin your Hub Transport rule deployment by implementing a

few rules at a time, and testing them thoroughly.




• Implementing Edge Transport rules. Edge Transport rules are similar to Hub Transport rules except

that the Edge Rules agent—which runs on the Edge Transport server—enforces them. Because Edge

Transport rules are applied at the network perimeter, you can use them to restrict messages from

entering your organization, or to apply policies to messages as they leave your organization.

Active Directory Lightweight Directory Services (AD LDS) stores all Edge Transport rules so they do

not replicate automatically to all Edge Transport servers in your organization. You can use the clonedconfiguration feature to duplicate the Edge Transport rule configuration between servers.

Implementing Message Classifications with Transport Rules

One way to restrict message flow is to implement transport rules that act based on message

classifications. Message classifications are a feature that enables users to set a classification on a message.

Message classifications can be found in Exchange Server 2010, Microsoft Office Outlook® 2007, Microsoft

Office Outlook 2010, and Outlook Web App. The message classification contains specific metadata that

describes the message’s intended use or audience. You can configure a Hub Transport rule that will use

the classification information to implement message flow restrictions.

A message classification includes the following information:

•

Display name. This field appears in Office Outlook 2007, Office Outlook 2010, and Outlook WebApp. Users can use the field to select the appropriate message classification before they send a

message.

• Sender description. This field explains to the sender what the message classification intends to

achieve.

• Recipient description. This field explains to the recipient what the message classification intends to

achieve.

• Locale. This field specifies a culture code to create a locale-specific version of the message

classification.

One of the message classification options is the Attorney-Client Privileged (A/C Privileged) message

classification. The A/C Privileged message classification is one of two default message classifications thatExchange Server 2010 includes. By default, when a user assigns the A/C Privileged classification to a

message, the classification displays for all organizational recipients, but no transport rule is applied to the

message.

However, you can create a Hub Transport rule that enforces the A/C Privileged classification. For example,

if your organization groups all of its attorneys into an organizational unit called “Legal,” you can configure

a transport rule that returns messages classified as A/C Privileged to the sender if the sender or at least

one recipient on the To or CC line is not in the Legal group.

You can use message classifications in two ways:

• The message sender can add a message classification manually. A Hub Transport rule can then apply

an action based on this classification.• A transport rule can add a message classification. For example, if you want to filter messages that

contain customer information, you can configure the transport rule to scan the message for this

information, and then have the transport rule apply the classification.




Exchange Server 2010 includes two default message classifications, but you can configure additional ones.

Before Office Outlook users can set and view message classifications, you must deploy the message

classification configuration files and create an Office Outlook registry key on the end users’ computers.

The Office Outlook message classification templates are XML files that you must generate after you create

and configure the message classifications.




Designing SMTP Connector Security

Another option for securing email messages is to modify the default configuration for SMTP Send and

Receive connectors, or create new connectors with more secure configurations. By default, the SMTP

connectors that you use to send Internet email accept anonymous connections, and do not require

message encryption.

Options for Providing SMTP Connector Security

To provide additional security for SMTP email, you can use the following options:

•

Configure authentication for SMTP receive connectors. If you enable authentication for Receiveconnectors, you can restrict the users or other SMTP servers that can establish an SMTP connection to

the Receive connectors for sending email.

Note Bear in-mind that enabling authentication on a receive connector could disrupt

normal SMTP email communications if that connector is used to accept email from the

Internet.

• Configure authentication for SMTP send connectors. When you configure authentication on a Send

connector, you configure your SMTP server to use authentication when sending messages to another

server. If the authentication fails, the message is not delivered.

When configuring SMTP Send connectors that use a smart host, you must configure authentication to

match the method used by the smart host. You can select between the following authentication

mechanisms:

• None. Select this option if you want an anonymous connection. This is quite common for

connectors used to support mail flow to and from the Internet.




• Basic Authentication. Basic authentication requires that you provide a user name and password.

We strongly recommend that you use an encrypted connection if you use basic authentication,

because the user name and password are sent in clear text. Select the Basic Authentication over

TLS check box to enable encryption on the connection.

• Exchange Server Authentication. Select this option to authenticate by using an Exchange

Server authentication mechanism, such as Transport Layer Security (TLS) direct trust orTLS\Kerberos.

• Externally Secured. Select this option if the connection is secured by external means, such as

being physically secured over a private network, or secured using Internet Protocol security

(IPsec).

When configuring SMTP Receive connectors, you can select between the following authentication

mechanisms:

• TLS. When you select this option, the STARTTLS keyword is advertised in the EHLO response to

connecting SMTP servers, and TLS authentication is accepted.

• Domain Security. There are additional configuration steps required before you can enable

mutual TLS, which is required for Domain Security.

• Basic Authentication. When you select Basic Authentication, the AUTH keyword is advertised in

the EHLO response to connecting SMTP servers, and Basic authentication is accepted. Because

the user name and password are sent in clear text when Basic authentication is used, you should

not use Basic authentication without encryption.

• Offer Basic Authentication only after starting TLS. When you select this option, the connector

starts TLS first, and then after TLS encryption completes, the connector offers Basic

authentication.

• Exchange Server authentication. Select this option to authenticate by using an Exchange Server

authentication mechanism, such as TLS direct trust or Kerberos through TLS.

•

Integrated Windows authentication. Select this option to use Integrated Windowsauthentication, which represents NTLM, Kerberos, and Negotiate authentication mechanisms.

• Externally Secured. Use this option if the incoming connections to this Receive connector are

secured by external means. When you select this option, you make an assertion of external

security that cannot be programmatically verified by Exchange Server. Before you select this

authentication method, you must first select the Exchange Server permissions group on the

Permission Groups tab.

Use the Permission Groups tab to select the permission groups assigned to the Receive connector. A

permission group is a predefined set of permissions granted to well-known groups of users,

computers, or security groups. Members of the selected permission groups on this tab are allowed to

submit messages to this Receive connector.

The following options are available on the Permission Groups tab:

• Anonymous users

• Exchange users

• Exchange

• Legacy Exchange servers

• Partners




Guidelines for Securing SMTP Connectors

As you design SMTP connector security, consider the following:

• If you configure authentication on a receive connector, you ensure that only authenticated users or

servers can send email to the connector. This option is useful for scenarios in which you want to

configure a connector to accept connections only from a particular partner organization. You can

configure the Receive connector to accept connections only from the IP address of the partnerorganization’s SMTP server, and require authentication. If you use basic or Integrated Windows

authentication, you must provide the sending organization with the user credentials that the SMTP

server will accept. As a best practice, you should combine authentication with TLS to ensure that the

user credentials are authenticated, and that data is encrypted.

• You might need to configure authentication on a Send connector to meet another organization’s

security requirements. If the other organization requires authentication, configure the Send connector

to use the other organization’s SMTP server as a smart host, and then use the user credentials

provided by the other organization or TLS to authenticate the SMTP session.

• TLS encryption ensures that authentication credentials and email messages cannot be read while in

transit. Use this option to provide a level of security beyond authentication. Before you configure TLS

security for SMTP Receive connectors, you must configure the SMTP service with an X.509 certificatetrusted by the SMTP server that sends email to your organization. Normally, this requires that you

obtain a server certificate from a public certification authority (CA). When configuring an SMTP Send

connector to use TLS, your SMTP server must trust the certificate issued to the destination SMTP

server.

• For both SMTP Send and Receive connectors, you can select the Externally Secured authentication

option if you are certain that there is a trusted network connection between the servers. For example,

you could use a virtual private network (VPN) or a dedicated network connection between two

companies, or you could use IPsec to secure the message transfer. This option treats all email

messages sent through this connection as authenticated, rather than anonymous.

• In most cases, you need to configure new SMTP connectors to support authentication and encryption.

To send and receive email in most organizations, you must configure the default SMTP connectors to

use anonymous and unencrypted connections. This is the default configuration for connectors on an

Edge Transport server when you enable Edge synchronization. Create a new connector if you are

going to require authentication and encryption for messages from a partner organization.

• Before you enable either authentication or TLS encryption, you must communicate with the

organizations that will be sending email over the secure connection to ensure that they configure

their SMTP servers to comply with your policies.

• If you deploy an Edge Transport server and implement Edge subscriptions, you should not need to

modify the Receive connectors on Hub Transport servers. By default, when you install the Hub

Transport server role, two receive connectors exist: one which will accept only authenticated

connections on TCP port 25, and the other that will accept only authentication connections on TCP

port 587. If you enable Edge subscriptions, the connection between the Edge Transport server and

the Hub Transport server are authenticated, and all messages are encrypted.




Designing Secure Message Routing Between Partner Organizations

In addition to configuring the SMTP connectors to enhance message security between partner

organizations, you can use the Domain Security feature in Exchange Server 2010 to provide extra security

and functionality.

How Domain Security Works

You can use Domain Security to manage secured message paths over the Internet for use with business

partners. After you configure these secured message paths, messages sent over the paths from an

authenticated sender display to users in the Office Outlook and Outlook Web App interfaces as “DomainSecured”.

Domain Security uses TLS with mutual authentication to provide session-based authentication and

encryption. This functionality enables authentication of all connections between the partner organizations,

and encrypts all messages while they are in transit on the Internet.

TLS with mutual authentication differs from the usual TLS implementation. Typically, when you implement

TLS, the client verifies a secure connection to the intended server by validating the server’s certificate,

which is received during TLS negotiation. With mutual TLS, each server verifies the connection with the

other by validating a certificate that the other server provides.

Configuring Domain Security

To set up Domain Security, perform the following steps:1.

On the Edge Transport server, generate a TLS certificates request. You can request the certificate from

an internal, private CA that your organization owns and manages, or from a commercial CA.

Regardless of the CA you choose, the SMTP servers in the partner organization that you exchange

messages with must trust the certificate. When you request the certificate, ensure that the certificate

request includes the domain name for all internal SMTP domains in your organization.




Note When an SMTP server establishes a TLS session with an Edge Transport server, the

SMTP server validates the Domain Name System (DNS) name in the server certificate on the

Edge Transport server against the DNS name of the email recipient domain. When you

generate the request for the Edge Transport server certificate, ensure that you include all

possible domain names that clients can use to connect to the server. For example, if you

host multiple SMTP domains that need to be accessible through this connector, you must

include all of the hosted domain names in the certificate request. The Subject AlternativeNames value on the certificate stores the domain name information. You can create acertificate that contains multiple Subject Alternative Names by using the DomainName

parameter of the New-ExchangeCertificate cmdlet.

2. Import and enable the certificate on the Edge Transport server. After you request the certificate, you

must import the certificate on the Edge Transport server, and enable the certificate for use by the

SMTP connectors that send and receive domain-secured email.

3.

Configure outbound Domain Security. To configure outbound Domain Security, use Exchange

Management Shell commands to specify the domains to which you send domain-secured email, and

then configure the SMTP Send connector to use domain-secured email.

4.

Configure inbound Domain Security. To configure inbound Domain Security, use ExchangeManagement Shell commands to specify the domains from which you receive domain-secured email,

and then configure the SMTP Receive connector to use domain-secured email.

5.

Test domain-secured mail flow. After you configure domain-secured email, you can test the

connection by reviewing the performance and protocol logs. The Domain Security feature includes

the following performance counters under MSExchange Secure Mail Transport:

• Domain Secure Messages Received

• Domain Secure Messages Sent

• Domain Secure Outbound Session Failures

You can create a new counter log file that contains these performance counters to monitor themessages sent and received, and the failed mutual TLS sessions.




Designing Client-Based Messaging Security

Exchange Server 2010 supports client-based solutions for providing messaging security. Exchange Server

2010 supports both S/MIME and Rights Management Service (RMS).

Using S/MIME to Secure Email Messages

One of the client-based solutions for providing message security is S/MIME. S/MIME uses digital

signatures and message encryption to provide message-level authentication, non-repudiation, data

integrity, and message encryption.

Although S/MIME provides a very high level of security for SMTP messages, there are several issues thatcan complicate an S/MIME implementation:

• You must install a certificate on each client computer to enable email security. You need to plan for

certificates due to the following factors:

• Certificate distribution. Because each client computer that sends or receives email by using

S/MIME must have a certificate, you must develop a plan for distributing certificates.

• Certificate trust. You typically use S/MIME to secure email that is sent to external recipients. The

recipients must trust the certificates that you assign to each computer.

• Public key distribution. To send an encrypted message, the message sender must have a copy of

the recipient’s public key. This means that the message recipient must have a digital certificate,

and must provide the certificate with the sender’s public key. One method of distributing thepublic key is to send a digitally signed email. This manual process of distributing public keys

makes the entire process cumbersome.

Note Consider that it is possible to use AD DS for distributing public keys.




• Certificate and private key backups. If a user ever loses the private key associated with their

computer’s certificate, the user will not be able to decrypt messages that were encrypted with the

public key that is associated with the certificate. The local computer stores the private key, which

means it could be lost due to hard-disk failure or profile corruption. Thus, you must export the

private key from each client computer, and save it in safe place.

•

You can address many of these certificate issues by implementing a private CA on a computerrunning Windows Server® 2008, and integrating the CA with AD DS. This solution enables

automation of many certification management tasks for internal users. However, unless you configure

the private CA as a subordinate CA to a trusted public root CA, external clients will not trust the

certificates that your CA issues.

• Another issue with using S/MIME to provide message-level security is that it is a user-based security

model. When sending a message, the user must sign or encrypt the message manually. However,

there is no guarantee that users will do this, even if the message contains confidential information.

• A final issue with using S/MIME to secure messages is that because the messages entering or leaving

the organization are encrypted, and the messages remain encrypted in the user mailbox, it is not

possible to scan the messages for policy compliance, viruses, or spam.

Despite the limitations, S/MIME is the best option for securing email messages sent from one individual to

recipients in other organizations. Most organizations will not want to set up server-level security for one

or two users, so you may need to use S/MIME for these situations.

Using AD RMS to Secure Email

Active Directory Rights Management Services (AD RMS) for Windows Server 2008 is a technology that

works with RMS-aware applications such as Office Outlook to protect documents and email from

unauthorized use. With RMS, you can set limitations on what message recipients can do with the

messages that they receive. For example, you can place restrictions on the messages so that the recipient

cannot forward or print the message, or so that the message expires after a specific time.

To implement an RMS solution, you must install and configure the AD RMS role on a server computer

running Windows Server 2008. All RMS clients must use RMS-aware applications, such as Office Outlook2003 or a newer version.

RMS is a useful solution for implementing message security for internal users who use Office Outlook

2003 or a newer version to read email. However, implementing RMS for external users and customers is

more difficult, because the client computers must be able to connect to the AD RMS server to obtain

a certificate that enables reading RMS-protected content. Therefore, Outlook Anywhere users will not be

able to access RMS-protected email while offline, and Outlook Web App and external users will be able to

access these messages only if you make an RMS server Internet-accessible.




Lesson 2

Designing Antivirus and Anti-Spam Solutions

Viruses and spam can inflict significant damage on an organization. Therefore, the spam and virus filtering

solution you design is a critical component to consider when you are designing message security for an

Exchange organization.

Objectives


• Describe the requirements for an antivirus and anti-spam solution.

• Identify the options for implementing antivirus and anti-spam solutions in Exchange Server 2010.

• Design an anti-spam solution.

• Describe the recommendations for monitoring an anti-spam solution.

• Design antivirus solutions.

• Manage antivirus solutions.




Overview of Antivirus and Anti-Spam Solution Requirements

One of the most important issues for any Exchange Server administrator is managing virus and spam

filtering solutions. As an Exchange Server administrator, you must be constantly aware of attempts to have

malicious email enter your organization. To design an effective anti-spam and antivirus solution, you

should be familiar with the new techniques that spammers and malicious virus writers use.

Requirements for Spam and Virus Filtering Solutions

Many organizations have standard requirements for spam and virus filtering solutions. When evaluating

these solutions, you should consider the following critical factors:• How often are the antivirus and anti-spam filters updated, and are the processes automated? When a

new virus is released on the Internet, it is critical that you update your antivirus software before the

virus enters your organization. If you discover a new phishing scheme, it is important that you update

your anti-spam filters to block the phishing emails.

• When evaluating an antivirus or anti-spam solution, monitor the speed with which the vendor

provides updates, and ensure that their automated process for distributing updates works effectively.

As a best practice, consider implementing an antivirus solution that can use multiple scan engines

from multiple vendors to maximize your chances of obtaining updates as quickly as possible.

• How does the anti-spam solution provide a balance between false positives and reducing as much

spam as possible? A false positive is a legitimate email message that the spam-filtering solution

incorrectly identifies as spam. One of the most critical issues in managing an anti-spam solution is the

ability to eliminate false positives while still blocking as much spam as possible. Many anti-spam

solutions provide features such as safe-senders lists or other lists that allow users to define senders

whose messages should not be blocked.




• What options does the solution provide for quarantining potentially malicious messages? This is

particularly important for anti-spam solutions, because this is the primary method of detecting false

positives. At a minimum, the anti-spam solution should provide a quarantine location that the

administrator can monitor for messages that do not appear to be spam. Some solutions also provide

quarantine locations that users can access to review all messages that were intended for their

mailboxes, but which the spam solution filtered instead. Exchange Server 2010 provides a quarantine

mailbox for messages filtered by the content filter, and enables administrators to resubmit messages

from the quarantine mailbox.

• What management and monitoring tools does the solution provide? Antivirus or anti-spam solutions

often include components that run on different computers. The management tools should provide an

efficient means to manage all of these systems. The solution also should provide an effective

monitoring system that can provide real-time statistics for the messaging administrators, and it

should provide alerts when it detects outbreaks or attacks.

• How well does the solution integrate with your current system? The obvious requirement is that the

anti-spam and antivirus solution work with your messaging system, but you also should consider

additional integration factors. For example, does the solution provide user-level integration so that

you can configure filtering rules based on your organization’s individual recipients without

necessitating management of two separate directories? Does the solution integrate with your

administrative model so that you can assign permissions easily using existing administrative groups to

manage and monitor the system?

You also should document any unique requirements that your organization may have. For example, if

users are using S/MIME frequently to send encrypted email that spam or virus filters cannot scan, you may

need to explore other options for scanning this content. Other organizations may want to ensure that

spam filters scan all messages from a partner organization for viruses, but do not block them.




Options for Implementing Antivirus and Anti-Spam Solutions inExchange Server 2010

Malicious senders or spammers may use a variety of methods to attempt to send malicious email or spam

into your organization. Therefore, no single tool or process can eliminate all malicious email or spam.

Exchange Server 2010 includes a variety of anti-spam and antivirus features that are designed to work

cumulatively to reduce the spam that enters your organization.

You can reduce the number of virus outbreaks and attacks by malicious software in your organization if

you are able to prevent—or at least reduce the quantity of—spam messages entering your organization.

By implementing antivirus and anti-spam tools at the perimeter network on the server configured with

the Edge Transport role, you can ensure a healthy message stream from the Internet.

Exchange Server 2010’s transport architecture provides a number of antivirus and anti-spam solutions that

are implemented as a series of layers. The anti-spam and antivirus filters are applied in the following

order:

• Connection filtering. The Connection filter inspects the IP address of the remote server that is trying

to send the message, to determine what action to take on an inbound message. Connection filtering

uses a variety of IP Block lists, IP Allow lists, and IP Block Providers services or IP Allow Provider

services to determine whether the connection from the specific IP should be blocked or allowed in

the organization.

•

Sender filtering. The Sender filter compares the sender on the MAIL FROM: SMTP command to anadministrator-defined list of senders or sender domains that are prohibited from sending messages to

the organization, to determine what action to take on an inbound message.

• Recipient filtering. The Recipient filter compares the message recipients on the RCPT TO: SMTP

command to an administrator-defined Recipient Block list. If a match is found, the message is

not permitted to enter the organization. The recipient filter also compares recipients on inbound

messages to the local recipient directory to determine whether the message is addressed to valid




recipients. When a message is not addressed to valid recipients, the message can be rejected at the

organization's network perimeter.

• Sender ID. Sender ID is intended to combat the impersonation of a sender and a domain, a practice

that's frequently called spoofing. A spoofed mail is an email message with a sending address that was

modified to appear as if it originates from a sender other than the actual sender of the message.

Spoofed mails typically contain a From: address that appears to be from a certain organization. In thepast, it was relatively easy to spoof the From: address, in both the SMTP session, such as the MAIL

FROM: header, and in the RFC 822 message data, such as From: "Jo Berry" [email protected], because

the headers were not validated.

In Exchange Server 2010, Sender ID makes spoofing more difficult. When you enable Sender ID, each

message contains a Sender ID status in the metadata of the message. When an email message is

received, the Edge Transport server queries the sender's DNS server to verify that the IP address from

which the message was received is authorized to send messages for the domain that is specified in

the message headers. The IP address of the authorized sending server is referred to as the purported

responsible address (PRA).

Domain administrators publish sender policy framework (SPF) records on their DNS servers. SPF

records identify authorized outbound email servers. If an SPF record is configured on the sender'sDNS server, the Edge Transport server parses the SPF record and determines whether the IP address

from which the message was received is authorized to send email on behalf of the domain that is

specified in the message.

The Edge Transport server updates the message metadata with the Sender ID status based on the SPF

record. After the Edge Transport server updates the message metadata, the Edge Transport server

delivers the message as it ordinarily would. PRA is calculated based on the following message

headers:

• Resent-Sender:

• Resent-From:

•

Sender:

• From:

• Content filtering. The Content filter uses Microsoft SmartScreen® technology to assess the contents

of a message. Based on the characteristics of millions of messages, Intelligent Message Filter—the

underlying technology in content filtering—recognizes indicators of both legitimate messages and

spam messages. Intelligent Message Filter can accurately assess the probability that an inbound email

message is either a legitimate message or spam.

Note Content filtering also acts on the safelist aggregation feature. Safelist aggregation

collects data from the anti-spam safe lists that Office Outlook and Outlook Web App users

configure, and makes this data available to the Content Filter agent on the computer that

has the Exchange Server 2010 Edge Transport server role installed. When an Exchange

Server 2010 administrator enables and correctly configures safelist aggregation, the Content

Filter agent passes safe email messages to the enterprise mailbox without additional

processing. Email messages that Office Outlook users receive from contacts, or contacts

added to their Outlook Safe Senders List, or have trusted, are identified by the Content

Filter agent as safe. The result is that messages that are identified as safe are not classified as

spam and unintentionally filtered out of the messaging system.




• Sender reputation. The Sender Reputation filter relies on persisted data about the IP address of the

sending server to determine what action—if any—to take on an inbound message. The Protocol

Analysis agent is the underlying agent that implements the sender reputation functionality. A sender

reputation level (SRL) is calculated from several sender characteristics that are derived from message

analysis and external tests. Senders whose SRL exceeds a configurable threshold are temporarily

blocked, and all their future connections are rejected for up to 48 hours.

In addition to the locally calculated IP reputation, Exchange Server 2010 also takes advantage of the

IP Reputation Service anti-spam updates, which are available through Microsoft Update. These

updates provide sender reputation information about IP addresses that are known to send spam.

• Attachment filtering. The Attachment filter filters messages based on the attachment file name, file

name extension, or file Multipurpose Internet Mail Extension (MIME) content type. You can configure

attachment filtering to block a message and its attachment, to strip the attachment and allow the

message to pass through, or to delete the message and its attachment without notifying the

recipient.

• Forefront Protection 2010 for Exchange Server. Microsoft Forefront® Protection for Exchange Server

is an antivirus software package that is tightly integrated with Exchange Server 2010, and offers

antivirus protection for the Exchange Server environment.

• Outlook Junk Email filtering. The Outlook Junk Email filter uses state-of-the-art technology to

evaluate whether a message should be treated as a junk email message based on several factors.

These factors include: time that the message was sent; content and structure of the message; and

metadata collected by the Exchange Server anti-spam filters. Messages caught by the filter are moved

to a special Junk Email folder where the recipient can access them later.

The messages that can reach a user’s Outlook Junk Email folder is determined by the spam

confidence level (SCL) threshold configured at the Exchange organizational level. By adjusting the SCL

threshold configuration, you can minimize:

• Number of legitimate email messages that reach the Microsoft Outlook user's Junk Email folder.

•

Number of offensive spam email messages that reach the Outlook user's Inbox or Junk Emailfolder.

• Number of spam email messages that reach the Outlook user's Inbox.

You can escalate the content filtering action taken on messages that have a greater risk of being

spam. To understand this functionality, it is important to understand the different SCL threshold

actions, and how you can configure them:

• SCL delete threshold. When the SCL value for a specific message is equal to or higher than the

SCL delete threshold, the Content Filter agent deletes the message. If the SCL value for a message

is lower than the SCL delete threshold value, instead of deleting the message, the Content Filter

agent compares the SCL value to the SCL reject threshold.

•

SCL reject threshold. When the SCL value for a specific message is equal to or higher than the SCLreject threshold, the Content Filter agent deletes the message. If the SCL value for a message is

lower than the SCL delete and SCL reject threshold values, instead of deleting or rejecting the

message, the Content Filter agent compares the SCL value to the SCL quarantine threshold.




• SCL quarantine threshold. When the SCL value for a specific message is equal to or higher than

the SCL quarantine threshold, the Content Filter agent sends the message to a quarantine

mailbox. You must periodically review the quarantine mailbox. If the SCL value for a message is

lower than the SCL delete, reject, and quarantine threshold values, the Content Filter agent sends

the message to the appropriate Mailbox server, where the per-recipient SCL Junk Email folder

threshold value of the message is evaluated.

• SCL Junk Email folder threshold. If the SCL value for a specific message exceeds the SCL Junk

Email folder threshold, the Mailbox server puts the message in the Outlook user's Junk Email

folder. If the SCL value for a message is lower than the SCL delete, reject, quarantine, and Junk

Email folder threshold values, the Mailbox server puts the message in the user's Inbox.

For example, if you set the SCL delete threshold to 8, the SCL reject threshold to 7, the SCL quarantine

threshold to 6, and the SCL Junk Email folder threshold to 5, all email with an SCL of 5 or lower will be

delivered to the user's Inbox.




Designing Anti-Spam Solutions

Designing an anti-spam solution is difficult because if you set all anti-spam feature filters to their most

aggressive levels and configure all anti-spam features to reject all suspicious messages, you are more likely

to reject legitimate messages that are not spam. On the other hand, if you do not set the anti-spam filters

at a sufficiently aggressive level, and do not set the SCL threshold appropriately for your organization, you

probably will not notice a reduction in spam.

Design Considerations for an Anti-Spam Solution

When designing your anti-spam solution, consider the following recommendations.• Scan for spam at the messaging gateway. To minimize the spam that enters the internal network, you

should try to filter most of it at the SMTP gateway server. By scanning messages at that server and

rejecting suspected spam messages, you can decrease costs by not delivering and storing suspected

spam on internal servers. The goal is to process and transport as little spam as possible through the

network.

• Scan for spam on the hub transport server. In addition to scanning at the edge where messages enter

the organization, to help reduce the propagation of spam, also scan at the hub transport servers.

• Scan messages for spam before scanning for viruses. Because anti-spam scanning blocks a high

percentage of incoming Internet messages, it makes sense to scan for spam before viruses. It is not

cost-effective to run a virus scan on messages that filters might later identify as spam, because filters

will block those messages eventually anyway. Moreover, spam filtering is less resource-intensive for

messaging servers compared to virus filtering.




• Configure the connection filter agent, recipient filter agent, and sender filter agent to reject

messages. This approach is better than quarantining filtered messages or assigning metadata—such

as anti-spam stamps—to the messages. The connection filter agent and recipient filter agent

automatically block messages that the respective filters identify. You can configure the action that the

Sender Filter agent takes on inbound email messages. You also should reject messages filtered by

real-time block list (RBL) services and recipient filtering, although the underlying confidence is not as

high as the IP Block list.

• Consider implementing Edge Transport servers as SMTP gateway servers. There are many third-party,

anti-spam solutions available, but Edge Transport servers provide additional integration with the

internal Exchange Server organization when you enable Edge synchronization. For example, if you

enable Edge synchronization, the recipients and safelist aggregation lists from inside the organization

are replicated to AD LDS on the Edge Transport server, which then uses the information to filter spam.

• Implement safelist aggregation. Safelist aggregation enables the Edge Transport server to make

spam-filtering decisions by using the data from the Safe Recipients Lists or Safe Senders Lists, and

contact data that Office Outlook users configure. Safelist aggregation can reduce the instances of

false-positives in anti-spam filtering. When an Exchange Server administrator enables and configures

safelist aggregation, the Content Filter agent passes email messages from the Safe Senders, Safe

Recipients, or Contacts Lists to the user mailbox without additional processing.

Note Safelist aggregation data contains both the user’s Safe Senders List and the user’s

Safe Recipients List. When you use the Update-Safelist cmdlet, you can specify whether to

update the Safe Senders List or the Safe Recipients List, or both. However, the safelist

aggregation feature only uses Safe Senders List data, and does not act on Safe Recipients

List data. Therefore, to reduce Active Directory storage and replication issues, you shouldnot run the Update-Safelist cmdlet with the Type parameter set to the SafeRecipients or

Both values. The default value for the Type parameter is SafeSenders.

• Implement automatic anti-spam updates. Exchange Server 2010 includes many anti-spam features

that depend on downloaded data to determine whether a message is, or is not, spam. You mustcontinually update this data, which includes content filter updates, Microsoft IP Reputation Service

data, and spam signature data, to ensure that the anti-spam features function optimally.

To enable updates, you must access the Microsoft Update website to download and install the

content filter updates. The content filter update data is updated and available for download every

two weeks. Automatic updates are available if you have an Exchange Enterprise client access license

(CAL) for each user mailbox, or a Forefront Security for Exchange Server license. Manual updates from

Microsoft Update do not include the Microsoft IP Reputation Service or spam signature data. The

Microsoft IP Reputation Service and spam signature data is only available with Automatic Updates.

• Increase the filtering level over time. When you first implement the anti-spam solution, you should

plan a fairly non-aggressive configuration of the anti-spam features. This approach lets you minimize

the number of false positives. As you monitor and adjust the anti-spam features, you can becomemore aggressive about the type of spam and spam attacks that your organization experiences.




Recommendations for Monitoring the Anti-Spam Solution

It is almost impossible to configure an anti-spam solution so that as soon as it is placed into production, it

functions optimally. When you first implement the solution, you are likely to either have too many false

positives, or too many spam messages getting through your defenses. Even if you optimize the

configuration, spammers are constantly trying new techniques to slip messages past your spam filters.

Defining the Monitoring Requirements

The first step in designing the anti-spam monitoring process is to gather monitoring requirements. As part

of the monitoring process, you should:• Monitor for false positives. This is probably the most important monitoring task, because messages

that you filter falsely as spam can disrupt business processes. Depending on how you configure your

anti-spam filters, users may not be aware that legitimate emails are being deleted.

• Monitor for filtering effectiveness. You also should monitor anti-spam filters to determine whether

they are blocking most of the spam messages.

• Monitor the quarantine mailbox. If you configure content filtering to send messages with a specific

SCL to a quarantine mailbox, you must monitor the quarantine mailbox on a regular basis. This is

particularly important when you first implement content filtering.

• Collect user feedback on the spam filter’s effectiveness. Spam filters most directly affect users, and

they often can provide the most valuable feedback. To collect this feedback, ensure that the HelpDesk personnel track all calls pertaining to spam filtering, and distribute a user survey on a regular

basis. One option for collecting user feedback is to request that they forward all spam messages to a

spam collection alias.




Designing the Monitoring Process

After you establish the monitoring requirements, you need to design a monitoring process. As part of the

monitoring process design, you should:

• Identify the administrators who are responsible for monitoring the spam solution, and provide them

with tools for monitoring it. Exchange Server 2010 provides several scripts in the

%programfiles%\Microsoft\Exchange Server\Scripts folder that enable collecting agent loginformation. These scripts provide information such as the IP addresses or domain names with the

most blocked spam messages, or the recipients who receive the most spam messages.

• Establish guidelines for how frequently administrators should monitor the system. Some anti-spam

solutions provide real-time monitoring, while others provide tools for verifying the solution status at

various points in time. You should ensure that administrators monitor the system frequently enough

to rapidly identify any issues.

• Establish a change-control process for modifying spam filters. If the monitoring shows that the filters

are identifying too many messages as false positives, or if a new type of spam message is bypassing

your filters, you should have a change-control process in place to modify the spam filters. In some

scenarios, this may require immediate action. In other scenarios, you may have additional time to

implement a solution. You should include both scenarios in your change-control process.

Working with Anti-Spam Stamps

Exchange Server 2010 supports anti-spam stamps to help you diagnose spam-related problems by

applying diagnostic metadata to messages as they pass through the anti-spam filters. When the Edge

Transport server scans a message, it assigns an anti-spam stamp to it, which you can view to determine

why a message was, or was not, filtered.

The anti-spam stamp includes various data, including:

• Sender ID evaluation

• Phishing confidence level

•

Spam confidence level

• Custom weight level that assigns a value based on whether the message contains words on the

approved or unapproved content filter list

• Time stamps that indicate a significant delay between when the message was sent and received

• Stamps based on other spam-filtering features

You can view a message’s anti-spam stamp by opening the message in Office Outlook, and viewing the

Internet headers section in the Message Options page.

Question: Will you be deploying anti-spam filtering using an Edge Transport server in

Exchange Server 2010? What is the reasoning behind your decision?




Designing Antivirus Solutions

One of the most common ways in which viruses spread from one organization to another is through

email. Thus, one of the primary means of protecting your Exchange Server organization is to ensure that

you stop all messages containing viruses at the messaging environment’s perimeter.

Guidelines for Designing an Antivirus Solution

When designing your organization’s antivirus solution, consider the following guidelines:

• Implement a defense-in-depth approach for dealing with viruses. Applying the defense-in-depth

model means that you implement defenses against viruses at multiple organizational levels, including:

• Client computer-based solutions. Install and maintain client-side antivirus software on all client

computers that connect to your network, including remote clients. Additionally, you should

enable the anti-spam and anti-phishing features available in messaging clients such as Office

Outlook 2010, Outlook 2007, and Office Outlook 2003, and the anti-phishing features in

Windows® Internet Explorer® 7.

• Exchange Server-based solutions. Install server-side antivirus software on every Hub Transport

server in your organization to scan all messages as they pass through. Many organizations also

deploy antivirus software on Mailbox servers to scan the mailbox databases. Antivirus software on

the Mailbox servers uses the Microsoft Virus Scanning application programming interface (VSAPI)

to scan mailbox databases. However, it is generally preferable to install antivirus software at the

entry point to your messaging infrastructure. Deploying antivirus components to the Edge and/or

Hub Transport servers enables you to reduce the risk of infection of a mailbox database.

• Internet edge-based solutions. You also should deploy antivirus and anti-spam software on the

SMTP server, or the Edge Transport server that is accessible directly from the Internet. This

software scans files as they enter the organization, thereby stopping the viruses and spam before

they get into, or out of, the network.




• Delete, rather than clean infected messages. Although it is possible for some antivirus solutions to

remove a detected virus from a message and preserve its contents, such attempts may not be

completely effective. Therefore, sending these messages through the system presents a potential

liability. For this reason, you should delete infected messages.

• Strip attachments of certain file types. By stripping all attachments that contain executable content,

you can help protect an environment from unknown or recently released malicious software thatemail attachments transmit, and for which signature files are not yet available or deployed. A best

practice is to implement attachment stripping at the email gateway layer, and to match the gateway-

layer attachment stripping policy with the attachment blocking policy that the client enforces.

• Scan both incoming and outgoing email for viruses. Although scanning incoming email is the primary

method for keeping a messaging environment free of viruses, you must also ensure that internal users

do not send viruses in outgoing email.

• Implement an antivirus solution that can take advantage of specific transport-related Exchange Server

2010 features, including those that antivirus vendors can use to optimize antivirus solutions:

• Transport agents for antivirus scanning. In an Exchange Server 2010 environment, all messages

must pass through a Hub Transport server, and inbound and outbound messages pass through

an Edge Transport server—if you deploy one. On the transport servers, you can use transport

agents to scan messages and apply policies to them. This also applies to antivirus scanning.

Antivirus vendors can create transport agents that specifically scan for viruses.

• Antivirus stamping. Antivirus stamping helps reduce the number of times a message is scanned as

it is sent through an organization. This feature works by stamping messages that an antivirus

solution scans with the name and version of the antivirus engine that performed the scan and the

scan’s results. The antivirus stamp travels with the message as it proceeds through the

organization, and other Exchange servers use it to determine if virus scanning is necessary for a

message. By reducing the number of times a virus needs scanning, you can reduce the use of

server resources that scanning requires.

Forefront Protection 2010 for Exchange ServerForefront Protection 2010 for Exchange Server is a Microsoft antivirus and anti-spam solution that

integrates with Exchange Server 2010. It provides advanced protection, optimized performance,

centralized management, and other features, including:

• Support for multiple antivirus engines. Forefront Protection 2010 for Exchange Server includes

industry-leading, antivirus engines from global security firms such as Kaspersky Labs, CA, and Sophos.

You can use as many as five scanning engines, at once, and in different combinations, across the

server system. Forefront Protection 2010 for Exchange Server automatically downloads the latest

signatures, and selects the optimal combination of engines that ensure a high protection level and

reduce exposure to any given threat.

• Layered protection. Forefront Protection 2010 for Exchange Server provides protection at multiple

checkpoints in the messaging infrastructure, including Exchange Server 2010 Edge Transport servers,

Hub Transport servers, and Mailbox servers.




• Forefront Protection 2010 for Exchange Server utilizes the Exchange Server 2010 transport agents and

Microsoft VSAPI technologies.

• Centralized management of remote installation, engine, and signature updating, reporting, and alerts

through the Microsoft Forefront Server Security Management Console.

Question: How will you modify your antivirus solution when you deploy Exchange Server

2010?




Managing Antivirus Solutions

Managing an antivirus solution is a priority for messaging administrators. Virus writers are constantly

developing new viruses that exploit new vulnerabilities, or that use new techniques to bypass antivirus

solutions. Therefore, it is critical that you conduct daily monitoring and management of your antivirus

solution.

Guidelines for Managing Antivirus Solutions

To manage your organization’s antivirus solutions, you should:

•

Develop clearly defined policies and processes for managing antivirus solutions. These policies andprocesses should identify which administrators are responsible for daily monitoring tasks, and how

frequently they should perform these tasks. The policies and processes also should define the action

to take if a virus outbreak occurs.

• Automate as many processes as possible. For example, one of the critical components in managing an

antivirus system is ensuring that antivirus software is up-to-date and running on all servers at all

times. Develop an automated process that verifies the version of the antivirus signature files and

scanning engines that you have deployed on the servers, and that updates the servers if the files are

not current. Ensure that the automated processes also include a means by which you can alert

messaging administrators if the processes fail. You should configure all antivirus systems to update

daily, and configure all critical systems—such as the Internet Edge SMTP servers—to update several

times daily.

• Regularly monitor antivirus software sites for information on new viruses and virus outbreaks.

• Monitor daily statistics for the volume of processed email, and the number of detected viruses. A

sharp increase in the number of infected messages may indicate that a new virus has been released,

which may require extra vigilance.




• Develop a user education process. Most viruses require user action to initiate an attack. Therefore,

your antivirus management strategy should include a user education plan that will teach users about

viruses, and how to deal with suspicious email. Educating users includes making them aware of

current threats, as well as the importance of keeping their computer systems up-to-date with the

latest signature files and security updates. If you educate users, they can help prevent a virus from

spreading if it infects their system.

• Consider using a solution such as Exchange Online, which offers anti-spam and antivirus solution

management from outside your organization. In most organizations, messaging administrators are

busy, and it is easy to delay the daily task of monitoring the antivirus system, especially if they have

identified no new viruses for some time.




Lab: Planning and Deploying Messaging Security

Lab Setup


1.

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

Manager.

2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, and the 10233B-VAN-CL1 virtual machines are

running.



Lab Scenario


multiple locations. You have been tasked with undertaking an analysis of the organization’s message

security requirements. After you complete the analysis, you must update the necessary documentation.

After you have completed the message security analysis, you will investigate the organization’s antivirus

and anti-spam requirements, and update the necessary documentation with your planned changes.

Finally, you will implement some of your proposals.






Security Requirements.doc

Message Security Requirements

• Before any message is sent to a recipient on the Internet, a disclaimer that has been approved by the

Legal department must be added to the message.

•

Messages sent to Internet recipients from members of the Sales team must have a different disclaimeradded to the message.

• Messages with a Company Internal classification must be blocked from being sent to the Internet. If a

user tries to send a message with this classification to the Internet, they should receive a response

indicating that they are not allowed to send messages with this classification to the Internet.

• A small group of senior executives and a few board members make up a Strategic Acquisitions team.

These users should be able to send each other messages that are clearly marked as Acquisitions

Confidential, and the messages should not ever be sent to users who are not on this team.

• A. Datum has formed a strategic partnership with Contoso, Ltd. The central office for Contoso, Ltd is

located in New York. Because much of the email send between A. Datum and Contoso contains

confidential email, all messages sent between the organizations must be as secure as possible. When

viewing an email sent between the companies, users should be able to determine that the message

has been secured while in transit.

• A. Datum uses a law firm based in Brussels to deal with international regulations related to their

business. All network traffic between the two firms is sent through a VPN. A. Datum needs to ensure

that all messages sent to the law firm in Brussels are sent through the VPN, and that all messages

coming from the law firm through the VPN are accepted without spam filtering.

• All users in the A. Datum organization should have the option of sending secure email to any

recipients on the Internet. However, the network administrators at A. Datum do not want to manually

deploy the certificates required to enable and manage secure email. At the same time, it is important

that the users can implement and use secure email with as few problems as possible.

Virus and Spam Filtering Requirements

• All messages that are sent to A. Datum must be scanned for viruses and filtered for spam before the

messages enter the network.

• The messaging administrators at A. Datum have identified two third-party organizations on the

Internet that provide lists of SMTP servers on the Internet that are known to send spam messages.

The messaging administrators have also identified one organization that provides a list of SMTP

servers that are known not to be spammers. The messaging administrators would like to use the lists

provided by these organizations when configuring their anti-spam filters.

• Messages sent from partner organizations such as Contoso, Ltd and the law firm in Brussels should

never be identified as spam.

•

The messaging administrators are planning on using content filters to block spam messages, but areconcerned that too many false positives will be filtered if they enable content filtering.

• A. Datum has several distribution lists that include over 200 recipients. Users from the Internet should

not be able to send email to any of these distribution lists.

• The messaging administrators at A. Datum are concerned about the number of messages coming into

the organization with spoofed SMTP domain names. They want to reduce the quantity of these sorts

of messages.




• Many users are using the Safe Senders list in Office Outlook to ensure that messages from the users

on the Safe Senders list are not identified as spam. The Exchange Servers should be able to use this

information to ensure that messages from these users are not blocked before they get to the user

mailboxes.

• All messages sent between users in the Exchange organization or sent to the Internet should be

scanned for viruses when the message is sent. Messages should be scanned only once for virusesinside the organization.

• All messages being sent to the Internet should be scanned for viruses as the message leaves the

organization.

• If users receive a virus from an external messaging system or by downloading the virus from a

website, the virus should be detected as soon as possible in order to avoid infecting other systems.

• At a minimum, antivirus files on all systems should be updated daily, and the antivirus files on all

systems that receive email directly from the Internet should be updated four times per day. If the

antivirus files on any messaging server are more than two update cycles out of date, the messaging

administrators should receive an alert.




Exercise 1: Designing Message Security

Scenario

In this exercise, you will design a messaging security implementation for the A. Datum Corporation.


•




2. Modify the A. Datum Proposed Security Policies document with a proposed message security plan.

3.

Answer questions relating to the documentation.



• Message Security Requirements section in the Security Requirements.doc

Task 2: Modify the A. Datum Proposed Security Policies document with a proposed

message security plan

• Complete the relevant sections of the following document. In the document, provide:

• The type of component you will need to configure.

• The configuration details for each component.

A. Datum Proposed Security Policies


Document AuthorDate

Jason Carlson12th March 2010

Message Security Components

Componenttype

Configuration details




(continued )


Componenttype

Configuration details

Additional notes



Note Your instructor may perform this task as a discussion.

Question: How did you address the need to exchange secure email between the A. Datum

Corporation and Contoso, Ltd?

Question: Does your organization have a requirement for the Domain Security solution?

What barriers will there be to adopting this solution?

Results: After this exercise, you should have successfully designed message security for A Datum.




Exercise 2: Designing Antivirus and Anti-Spam Solutions

Scenario

In this exercise, you will design an antivirus and anti-spam implementation for A. Datum Corporation.


•




2. Modify the A Datum security Proposed Policies Document with a proposed antivirus and anti-spam

solution.




•

Virus and Spam Filtering Requirements in the Security Requirements.doc


antivirus and anti-spam solution

• Complete both the Anti-Spam and Antivirus Solution Components sections of the following

document. In the document, provide:





Document Author

Date

Jason Carlson

12th March 2010

Anti-Spam Solution Components

Component type Configuration details

Anti-spamsoftware

IP Allow Listprovider

IP Block Listprovider

SMTP connectors

Content filter andquarantinemailbox




(continued )


Anti-Spam Solution Components


Sender IDfiltering

Safelistaggregation

Blocked recipientlists

Antivirus Solution Components


Antivirus software

Antivirus software

Antivirusstamping

Antivirus update

Additional notes




Question: How did you design the antivirus and anti-spam solution for A. Datum

Corporation? How does this compare to the solution you would implement for your

organization?

Results: After this exercise, you should have successfully designed an antivirus and anti-spam strategy for

A Datum.




Exercise 3: Implementing Message Security

Scenario

In this exercise, you will implement some of your proposed changes. You must implement S/MIME within

the A. Datum Corporation organization.


1. Create a new certificate template.

2. Import the certificate template.

3.

Configure user certificate auto-enrollment.

4. Update the group policy on VAN-CL1.

5. Verify the presence of the certificate for Scott.

6.

Configure Outlook for Scott.

7. Verify the presence of the certificate for Marcel.

8.

Configure Outlook for Marcel.9. Send a signed and sealed message to Scott.

10. Verify receipt of the secured message.

Task 1: Create a new certificate template

1. On VAN-DC1, open a new MMC, and add the Certificate Templates snap-in.

2.

Duplicate the User template.

3. Configure the following properties for the duplicate template, and then close the Exchange

Management Console:

a. Template display name: S/MIME Certificate

b. Domain Users granted the allow Enroll and Autoenroll permissions.

Task 2: Import the certificate template

1.

Open Certification Authority.

2. Import the S/MIME certificate.

3. Close Certification Authority.

Task 3: Configure user certificate auto-enrollment

1. Open the Group Policy Management console.

2.

Locate and open the Default Domain Policy for editing.3.

In Group Policy Management Editor, expand User Configuration, expand Policies, expand Windows

Settings, expand Security Settings, and then click Public Key Policies.

4. Configure the Certificate Services Client – Auto-Enrollment with the following options:

a.

Configuration Model: Enabled

b. Renew expired certificates, update pending certificates, and remove revoked certificates:

Selected




c. Update certificates that use certificate templates: Selected

5.

Close the Group Policy Management Editor, and then close the Group Policy Management console.

Task 4: Update the group policy on VAN-CL1

1. Switch to VAN-CL1.

2.

Open a command prompt, and at the command prompt, type gpupdate /force, and then press

Enter.

3. Log off VAN-CL1.

Task 5: Verify the presence of the certificate for Scott

1.

Log on to VAN-CL1 using the following credentials:

• User name: Scott


• Domain: Adatum

2.

Open a new MMC, and add the Certificates snap-in.

3. Verify the presence of a certificate based on the S/MIME Certificate template in the Current

User\Personal certificate store.

4. Close Console1 without saving changes.

Task 6: Configure Outlook for Scott

1.

Open Microsoft Outlook 2010.

2. Accept all defaults—EXCEPT in the Welcome to the Microsoft Office 2010 wizard, click Don’t make

changes and then click OK .

3. Close Microsoft Outlook and log off.

Task 7: Verify the presence of the certificate for Marcel

1.


• User name: Marcel


• Domain: Adatum

2. Open a new MMC and add the Certificates snap-in.

3. Verify the presence of a certificate based on the S/MIME Certificate template in the Current

User\Personal certificate store.

4.

Close Console1 without saving changes.

Task 8: Configure Outlook for Marcel

1.

Open Office Outlook 2010.

2.

Accept all defaults—EXCEPT in the Welcome to the Microsoft Office 2010 wizard, click Don’t make

changes and then click OK .




Task 9: Send a signed and sealed message to Scott

1.

Create a new message entitled S/MIME Test.

2.

Click the Options tab.

3. On the Office Outlook ribbon, expand More Options.

4.

In the Properties dialog box, click Security Settings.

5. In the Security Properties dialog box, select the following check boxes, and then click OK :

• Encrypt message contents and attachments

• Add a digital signature to this message

• Request S/MIME receipt for this message

6. In the Properties dialog box, click Close, and then click Send.

7.

Close Microsoft Outlook, and log off.

Task 10: Verify receipt of the secured message

1.




• Domain: Adatum

2. Open Microsoft Outlook 2010.

3.

Open the new message entitled S/MIME Test.

4.

In the message, click the padlock symbol. Read the information, and then click Close.

5. In the message, click the symbol next to the padlock symbol. Read the information, and then click

Close.

Results: After this exercise, you should have successfully implemented some aspects of the messaging

security design for A Datum.



following steps:

1.


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


4.

Repeat these steps for 10233B-VAN-EX1 and 10233B-VAN-CL1. Close the virtual machine connection

windows.

5.







Note Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully started

before starting the other virtual machines.






Review Questions

1. On the Edge Transport server, which service holds the Edge Transport rules?

2.

You have established the required Edge Transport rules on one of the Edge Transport servers in your

perimeter network. Now you wish to duplicate the configuration. What is one way to easily duplicate

the Edge Transport rules?

3.

When selecting Basic authentication on a receive connector, what additional option should you

select?

4.

What is the purpose of the permissions groups on a Receive connector?




Best Practices


• Always consider implementing TLS when configuring Basic authentication on Send or Receive

connectors.

• Deploy an Edge Server in your perimeter network to more easily secure your organization against the

threats posed by viruses and malicious software contained in email messages.

• Consider implementing an antivirus solution that can use multiple scan engines from multiple

vendors to maximize your changes of obtaining updates as quickly as possible.

• Implement attachment stripping at the email gateway layer, and match the gateway-layer attachment

stripping policy with the attachment blocking policy that the client enforces.



7-1

Module 7

Planning and Deploying Messaging Compliance

Contents:

Lesson 1: Designing Transport Compliance 7-3

Lesson 2: Designing AD RMS Integration with Exchange Server 2010 7-12

Lesson 3: Designing Message Journaling and Archiving 7-20

Lesson 4: Designing Messaging Records Management 7-30Lab: Planning and Deploying Messaging Compliance 7-37






Lesson 1

Designing Transport Compliance

Transport compliance allows you to control messages as they are transported through the Exchange

Server organization. To implement transport compliance, you can use transport rules, message

classifications, and message moderation. These features can be used to control which users can send

messages, which users receive messages, and whether messages are modified.


•

Identify the requirements and options for implementing transport compliance.

• Design transport rules.

• Design message classifications.

• Design message moderation.



7-4 Planning and Deploying Messaging Compliance

Identifying Transport Compliance Requirements and Options

Key Points

Many organizations enforce transport compliance by controlling the senders and recipients of messages.

Exchange Server 2010 contains features that you can use to implement transport compliance, including:

• Transport rules. Transport rules help you manage messages while messages are in transport. Each Hub

Transport server is responsible for applying transport rules to the messages that pass through it, and

each transport rule defines conditions that must be met for a transport rule to apply. If the conditions

are met, then the Hub Transport server performs the actions specified in the rule, such as modifying

the message, adding or removing recipients, and even deleting the message.

• Moderated recipients. Moderated recipients control which recipients receive messages from other

recipients. When you send a message to a moderated recipient, a designated moderator must

approve that message before the message is delivered. In most cases, the moderated recipient is a

distribution group.

• Message classifications. Message classifications add metadata to a message. Metadata typically

describes how the message should be used, and who should have access to the message. After you

classify a message, you can use transport rules to manage it in a specific way.

• AD RMS integration. AD RMS integration controls what recipients can do with email messages. For

example, you can prevent users from printing or forwarding messages, and prevent unauthorized

users from reading messages.

Common transport compliance requirements include:

• Add disclaimers to messages. Many organizations may require Exchange Server to add specific, pre-

written text to all messages sent from the organizations to external recipients. Instead of relying on

individual users to add the disclaimer, you can centrally implement and enforce the use of disclaimers

by using transport rules.




• Restrict users from sending messages to other recipients. Use transport rules and moderated

recipients to control which users can send messages to other recipients. For example, a transport rule

could prevent a user from sending messages outside the organization. Or, you can restrict the

messages sent to a distribution group by implementing moderated recipients.

• Block or retain messages with specific content. Use transport rules to block or retain messages with

specific content. For example, you can create a transport rule that deletes all messages with the textstring “guaranteed return.” Or, you could forward all messages with the text string “guaranteed

return” to a mailbox so that they can be reviewed.

• Restrict what recipients can do with a message. Use AD RMS to limit what recipients can do with a

message. For example, you could create a message intended for the company lawyer, and prevent

that message from being forwarded to other recipients.

• Block messages to a specific email domain. Use transport rules to block messages addressed to a

specific email domain. For example, you could use a transport rule to delete all messages addressed

to the contoso.com domain. Or, if there are multiple recipients, you could remove all recipients in the

contoso.com domain.




Planning Transport Rules

Key Points

Transport rules provide you with an almost limitless ability to control messaging in your Exchange Server

organization. Always carefully plan your transport rules to ensure that they behave as intended.

Otherwise, you could accidentally delete messages, or deliver messages to unintended recipients.

When planning transport rules, do the following:

• Plan conditions and exceptions carefully. Transport rule conditions and exceptions define which

messages are affected by the transport rule. If you implement the rules incorrectly, you mayunintentionally modify or delete messages.

• Use regular expressions to check message contents. Use regular expressions to simplify the l ist of

terms when you are including a text string in a condition. You can use one regular expression, rather

than a list of variations on the same word. For example, when searching for a phone-number pattern,

you can use the expression “\d\d\d(-|.)\d\d\d\d”, which denotes a pattern of 3 digits, then a dot or

dash, and then four digits.

• Test application of transport rules. Test new transport rules to ensure they behave as intended. This is

important because a new transport rule could conflict with existing transport rules.

• Plan for transport rule limitations on encrypted and digitally signed messages. AD RMS integration

with Exchange Server 2010 enables you to implement transport rules and messaging policies when

you are using AD RMS Information Rights Management encryption to protect messages. Encryption

through other mechanisms may prevent the application of transport rules or records management.

For example, Exchange Server may not be able to scan encrypted messages for the text string

specified in a transport rule. Additionally, antivirus scanners cannot scan messages with encrypted

attachments.




• Use transport rules on Edge Transport servers to apply outbound message policies for delivery to

external recipients. Hub Transport servers apply transport rules, which results in unnecessary

processing for outbound messages. You can offload this processing to Edge Transport servers instead.

Additionally, in some cases, messages from external organizations may be relayed through Edge

Transport servers directly to another messaging organization, and not be processed by Hub Transport

servers at all.

• Consider transport rule recovery. Deleted transport rules are not easily recoverable. Transport rules

are stored in Active Directory Domain Services (AD DS), and restoring rules from AD DS is a complex

process. Alternatively, documented transport rules are easy to recreate, and you can export transport

rules to backup files by using the Export-TransportRuleCollection cmdlet. However, when you

import transport rules onto a Hub Transport server, the server replaces all of the existing transport

rules for the organization.




Planning Message Classifications

Key Points

Message classifications organize messages and provide additional information about those messages.

They also can trigger transport rules. Both users and transport rules can apply message classifications.

Message classifications are visible in Microsoft Office Outlook® 2007 or later, and Outlook Web App.

These tools display classification information when users view classified messages.

The default message classifications are:

•

Attachment Removed

• Originator Requested Alternate Recipient

• Partner Mail

Note Exchange Server 2010 retains message classifications when upgraded from


When planning message classifications, do the following:

• Develop custom message classifications. In most cases, you need to create your own custom message

classifications to meet organizational needs. To do this, determine which classifications are required

to meet organizational needs, and define the sender and recipient descriptions that appear when themessage is classified.

• Plan for localized versions of message classifications. Each message classification can include alternate

sender and recipient descriptions associated with different locales. For multilingual organizations,

create localized versions of message classification descriptions so that recipients can read the

message classification in their preferred languages.




• Configure client file distribution for Office Outlook 2007 and Office Outlook 2010. These clients do

not use message classifications by default, and must be configured to do so. To configure Office

Outlook 2007 and Office Outlook 2010, distribute an XML file that contains the message

classifications. This XML file needs to be redistributed each time you modify message classifications.

You also need to configure registry entries. Outlook Web App supports message classifications by

default.

• Configure transport rules. You can use transport rules to control how Exchange Server transports

classified messages based on company polices. For example, you can create a transport rule that

prevents messages with the Company Internal classification from being delivered outside the

organization. Additionally, you can use transport rules to apply message classifications based on

message content, senders, or recipients. For example, you can automatically assign the Legal

classification to any message that arrives from an external lawyer.




Planning Message Moderation

Key Points

Use message moderation to control which messages are delivered to specific recipients. In previous

Exchange Server versions, you could prevent recipients from sending messages to specific recipients, but

could not approve individual messages.

When planning message moderation, do the following:

• Consider using moderation for large or confidential distribution groups. Many users within an

organization use large distribution groups for unauthorized messages of a personal nature, such asfundraising activities. Enabling moderation allows you to control which messages are delivered to

groups that can include an entire physical location or organization.

• Select an appropriate moderator. Ideally, a moderator is someone with authority to determine which

messages to allow, and which messages to block. In general, Exchange Server administrators should

not be moderators, because they are not closely linked to business decisions related to moderating

messages. For example, the moderator for a departmental distribution group also should be a

messaging user within that department. Remember that a busy group may generate many message-

approval requests. The moderator must have sufficient time to evaluate the moderated messages.

• Configure appropriate moderation exceptions for groups. To reduce the load on a group moderator,

configure moderation exceptions. These exceptions should include senders that can be trusted to

determine appropriate content for the group.

• Consider the role of group owners. A group owner can modify the membership list of a distribution

group, or approve membership requests. However, a group owner is not a moderator, and cannot

automatically approve messages sent to a moderated group. If the group owner also needs to

approve messages sent to a moderated group, then you must configure the owner as moderator of

the group.




• Plan for message moderation during upgrades. Previous Exchange Server versions do not support

message moderation. This can lead to unexpected results for message moderation. To ensure proper

moderation, you must route messages that are moderated by transport rules through an Exchange

Server 2010 Hub Transport server. Additionally, you must expand distribution groups with an

Exchange Server 2010 Hub Transport server to ensure that Exchange Server moderates messages

addressed to the groups.

• Consider using moderated groups and transport rules. In addition to moderated groups, you also can

use transport rules to moderate message transport. This allows you to moderate messages based on

senders, recipients, text patterns, and many other useful scenarios. For example, you could moderate

all messages sent to the email domain of a competitor.




Lesson 2

Designing AD RMS Integration with Exchange Server 2010

You can integrate Exchange Server 2010 with AD RMS to provide additional protection for messages. As

part of planning AD RMS integration, consider how to best protect messages, and how external recipients

can access AD RMS to decrypt and view messages.


• Describe the options for integrating AD RMS with Exchange Server 2010.

• Design AD RMS integration.

• Design AD RMS integration with other organizations.

• Implement and manage AD RMS integration.




Options for Integrating AD RMS and Exchange Server 2010

Key Points

AD RMS is a role of the Windows Server® 2008 operating system that allows integrated applications to

secure document content. By using AD RMS with Exchange Server 2010, you can limit the recipients who

can read certain messages, prevent messages from being forwarded, and even prevent messages from

being printed. For integration to work, the client application must support AD RMS. Office Outlook 2007

and Office Outlook 2010 both support AD RMS for message protection. Mobile clients running the

Windows® Mobile 6 operating system also support AD RMS for message protection. However, extra

configuration is required to support mobile devices—both in AD RMS, and on the mobile device.

The options for integrating AD RMS and Exchange Server 2010 are:

• Transport protection rules. A transport protection rule is a transport rule that applies an AD RMS

template. The AD RMS template defines the restrictions that Exchange Server places on messages. Use

the conditions in the transport rule to determine which messages are protected.

• Outlook protection rules. An Outlook protection rule is similar in structure to a transport protection

rule, except it is applied at the Outlook-client level. The only conditions you can base this rule on are

FromDepartment, SentTo, and SentToScope. Within the Outlook client, users receive notification

when Outlook protection rules are applied. You can allow users to override the rules, which can be

useful when there may be exceptions to the normal rule that applies AD RMS templates. Only

Outlook 2010 supports Outlook protection rules.

• Transport decryption. The first Exchange Server 2010 Hub Transport server within an organization

that handles a protected message decrypts the message for inspection. This allows the Hub Transport

server to apply transport rules based on message content, and to perform anti-spam and antivirus

scanning. The message is encrypted again before delivery to the next Hub Transport server. You can

configure Exchange Server 2010 to reject messages that it cannot decrypt, decrypt messages

whenever possible, or disable transport decryption.




• Journal report decryption. To ensure that journaled content is accessible for compliance purposes,

you must enable journal report decryption. When enabled, Exchange Server decrypts the message

before attaching it to the journal report. Journal report decryption is enabled by default.




Planning AD RMS Integration

Key Points

AD RMS server implementation is the most basic requirement for AD RMS integration. The AD RMS server

generates the certificates that protect message content and specify restrictions.

After you have configured AD RMS, do the following:

• Train users to use AD RMS functionality. Users have the option to apply AD RMS templates to

messages. However, they will most likely not use this functionality unless you train them on how to

use the templates.

• Consider adding additional templates. Exchange Server 2010 comes with one template, the Do Not

Forward template. This template is useful, but you may need additional templates that prevent

message modification, printing, saving, and copying.

• Define the boundaries for AD RMS-protected messages. To decrypt and view protected messages,

clients must be able to access the AD RMS server. Within your organization, it is easy to provide

clients with access to the AD RMS server. However, if you allow AD RMS-protected messages outside

of the organization, you also need to provide external users with access to your AD RMS server.

• Use transport protection rules to protect messages regardless of the client. Depending on the client

software, users may not be able to apply AD RMS templates. For example, Outlook protection rules

are only applicable to Outlook 2010 clients. To ensure that messages are protected regardless of the

client software, implement transport protection rules that protect messages at the Hub Transport

server level.




Planning AD RMS Integration with External Organizations

Key Points

AD RMS integration with external organizations is more complex than simply restricting AD RMS

deployment to your own organization. Before selecting the option for AD RMS integration with external

organizations, consider the following:

• Can you create external user accounts in your Active Directory forest?

• Have the external organizations deployed AD RMS?

•

Do you need to enable AD RMS integration for all users in the external organizations?

• Have the external organizations deployed Active Directory Federation Services (AD FS)?

The options for integrating AD RMS with external organizations are:

• Deploy an AD RMS server that is accessible from the Internet. If your AD RMS server is accessible from

the Internet, then external users can communicate with the AD RMS server to obtain the necessary

license certificates. This does not require the external organization to implement AD RMS, but it does

require you to create external user accounts in your Active Directory forest, or create a separate forest

with an AD RMS trust.

• Configure trusted user or publishing domains. You can use both trusted user and trusted publishing

domains when the external organization has enabled AD RMS. These two integration methods allow

users in one organization to access content protected by AD RMS in the other organization.

• Configure AD RMS integration with the Windows Live® ID network of Internet services. Configure a

trust with Windows Live ID to allow protected content to be sent to any user with a Windows Live ID.

However, this option is suitable only for a small number of users, and does not allow the external user

to create protected content.




• Configure a federated trust by using AD FS. With this option, external clients contact the AD RMS

server in your organization, but AD FS performs authentication. Configuring this option means that

you do not need to create external user accounts in your Active Directory forest.




Considerations for Implementing and Managing AD RMS Integration

Key Points

Consider the following when implementing AD RMS integration:

• Provide Outlook Web App for external users. Outlook Web App allows external users to use a web

browser to view protected messages. You still need to create user accounts for the external users, but

you do not need to provide external access to your AD RMS server. The Client Access server hosting

Outlook Web App communicates with the AD RMS server instead. By contrast, Outlook Anywhere

requires the client to communicate directly with the AD RMS server.

• Support for clients running Windows Mobile is not enabled by default. Mobile clients running

Windows Mobile 6 support AD RMS for message protection. You must enable AD RMS on the

Windows Mobile device by connecting it to a computer that has the AD RMS client and either the

Microsoft Exchange ActiveSync® technology or Windows Mobile Device Center installed. Also, you

must configure security on the AD RMS server to allow mobile devices.

• Develop a plan for distributing AD RMS templates. AD RMS templates must be distributed to the

clients so that the clients can use them. You can use the Windows Vista® operating system with

Service Pack 1 (SP1) or later, and Windows Server 2008 to automate template distribution to clients.

By default, these tools distribute templates every 30 days. You can also copy AD RMS templates to

clients as part of a Group Policy Object (GPO).

•

Ensure that only trusted users have access to the journal mailbox. Exchange Server stores all journaledcontent in an unencrypted format, when journal report decryption is disabled. This means that

anyone with access to the journal mailbox can read the messages. If encrypted messages contain

confidential information, then increase security on the journal mailbox.

• Develop a communication plan for users. AD RMS is a powerful tool for managing message usage.

However, you must teach users how to use AD RMS.




• Monitor the performance impact of encryption on Hub Transport servers. Transport protection rules,

transport decryption, and journal report decryption require a Hub Transport server to encrypt or

decrypt messages. Encryption and decryption are processor-intensive tasks that may cause

performance issues on the Hub Transport server. This is particularly true when the server processes

many messages.




Lesson 3

Designing Message Journaling and Archiving

Exchange Server 2010 includes many features that can help you design message journaling and archiving.

Message journaling stores copies of specified messages in dedicated mailboxes. Personal archives provide

users with a more convenient alternative to using personal folders (PST) files. A litigation hold prevents

message deletion until a time specified by an administrator. Multi-Mailbox Search can search the entire

Exchange Server organization for relevant messages.


• Identify the requirements and options for message journaling and archiving.

• Describe the message journaling options.

• Design message journaling.

• Describe the mailbox archival process.

• Design a personal archives deployment.

• Design a litigation hold strategy.

• Design a Multi-Mailbox Search implementation.




Identifying Message Journaling and Archiving Requirements and Options

Key Points

Exchange Server 2010 includes new and enhanced features to improve message journaling and archiving.

These features are:

• Message journaling. When you implement message journaling, Exchange Server copies specified

messages to a dedicated mailbox where they are retained until an administrator reviews them.

• Litigation hold. When you implement a litigation hold for a mailbox, Exchange Server never purges

the mailbox’s deleted messages, so they remain searchable with Multi-Mailbox Search.

• Multi-Mailbox Search. When implemented, Multi-Mailbox Search enables authorized users to search

all mailboxes in the organization. This includes content in litigation hold and single-item recovery.

• Personal archives. When implemented, personal archives provide users with an alternative to using

PST files to store historical data. Exchange Server creates personal archives as additional mailboxes

that are linked to the original user mailbox. The personal archive can be in the same mailbox

database as the original user mailbox or in a different mailbox database.

Requirements for using these features include:

• Messages sent to or by members of a distribution group must be retained. You can create a transport

rule that journals messages sent to the distribution group or sent by members of the distribution

group.

• Messages sent or received by specific users must be retained. You can enable a litigation hold on any

user mailbox, in order to retain all messages sent or received by that user indefinitely.

• Messages must be searchable for specific types of content. You can use Multi-Mailbox Search to

search any mailbox in the Exchange Server organization.




• Users must store all messages in an Exchange Server database. You can enable personal archives,

import PST contents into the archives, and then disable the ability to use PST files.

• Messages sent by users in a specific mailbox database must be retained. You can enable message

journaling on a mailbox database to capture all of the messages sent or received by mailboxes in that

mailbox database.




Options for Implementing Message Journaling

Key Points

You can implement message journaling at multiple levels to collect only the specific messages you

require. You can then copy these messages to a local mailbox or to any other valid Simple Mail Transfer

Protocol (SMTP) address.

You can configure message journaling as follows:

• On a specific mailbox database. Exchange Server journals all messages that are sent to or from

mailboxes in the mailbox database. This is the only type of journaling that does not require aMicrosoft Enterprise client access license (CAL) for Exchange Server.

• On a specific recipient. Exchange Server journals all messages that are sent to or from a specific

recipient, by using a journal rule.

• As part of managed folder policies. You can use managed folder polices to journal messages before

they are removed from user mailboxes. However, managed folder policies cannot be combined with

retention policies. So, this option for journaling is not appropriate for many organizations. Retention

policies move expired messages to a personal archive instead of journaling them.




Planning Message Journaling

Key Points

When planning message journaling, do the following:

• Identify which messages you should journal. Journal only the specific messages that are required. This

limits the storage space used by the journal mailbox.

• Identify the type of message journaling to implement. After determining which messages to journal,

identify the journaling method required to journal those messages.

•

Identify the journal mailbox. Journal mailboxes receive all of an organization’s journaled messages. In

most cases, the journal mailbox is located in a separate mailbox database or Mailbox server from the

source of the journaled messages. This prevents journaled content from affecting user mailbox

performance. You can also host a journal mailbox in a separate email system for security purposes.

• Plan for multiple sites in large organizations. Large organizations can generate high levels of message

traffic. You can increase wide area network (WAN)-link utilization if you locate journal mailboxes

across a WAN-link from where the journaled messages are generated.

• Consider a litigation hold as an alternative to journaling. A litigation hold retains messages and makes

them searchable without requiring message copies to be stored in another mailbox.




Considerations for Managing the Journal Mailbox

Key Points

The journal mailbox contains journaled messages. Securing the journal mailbox and managing its size are

very important. Consider the following for the journal mailbox:

• Plan for the maximum size of the journal mailbox. Allocate an appropriate amount of space for the

journal mailbox. Base the allocated space on the expected number of journaled messages and their

expected size. Use quotas to identify when the journal mailbox grows too large.

•

Define a process for addressing over-quota journal mailboxes. Determine how to address a journalmailbox that grows past its quota. In some cases, you may have sufficient disk space to increase the

quota. In other cases, you may decide to remove content from the journal mailbox.

• Use MRM to automate message removal. You can remove messages from the journal mailbox after

backing them up and ensuring they are recoverable from offsite storage. To simplify the process, use

MRM to automatically remove journaled messages after a specific time determined by your backup

schedule.

• Place the journal mailbox in a separate database to provide backup flexibility. Exchange Server 2010

backups are performed at the database level. If you place the journal mailbox in a separate database,

you can back up the journal mailbox on a different schedule than user mailboxes.

• Control who can access journal mailboxes. Most likely, your journal mailboxes contain confidential

information that should not be available to most users. Ensure that only authorized users can access

the contents of the journal mailboxes.

• Ensure legal compliance. To ensure that your plan meets legal requirements, obtain approval from

legal representatives.




Planning Personal Archiving

Key Points

You can enable personal archives for individual mailboxes that are hosted on an Exchange Server 2010

Mailbox server. Personal archives are additional mailboxes that are linked to a user’s primary mailbox.

These mailboxes appear and are accessible when users open Outlook 2007, Outlook 2010, or Outlook

Web App.

When planning personal archiving, do the following:

•

Consider the impact of personal archives on Mailbox server storage. Personal archives reduce usermailbox size. However, they do not reduce the total storage utilization because the archived

messages are still stored in a mailbox database, Importing PST files into the archive results in higher

storage utilization. To reduce the impact on storage utilization, you can implement cloud-based

personal archives.

• Consider which mailbox database to use for storing personal archives. If you keep personal archives in

the same mailbox database as the user’s primary mailbox, you reduce overall I/O because fewer

mailboxes are kept on a single disk. However, if you place personal archives in a different mailbox

database than the user’s primary mailbox, you can specify a different backup schedule for personal

archives.

• Selectively enable personal archives. Not all users require them. Enable personal archives only for

users who need additional space for archiving messages, as determined by your organizationalpolicies.

• Consider disabling access to PST files. PST files are difficult to manage because users create them,

sometimes in locations that are not backed up. If you provide personal archives, consider disabling

access to PST files to simplify management and to help ensure that all message data is backed up.




• Ensure that you have the correct versions of Outlook to support viewing personal archive contents.

Not all versions of Outlook support personal archives. The version of Outlook that is included in the

following editions of Microsoft Office do not provide access to personal archives:

• Microsoft Office Home and Business 2010 (retail)

• Microsoft Office Professional 2010 (retail)

• Microsoft Office 2010 Standard (volume license)

• Microsoft Office 2007 (volume license)

• Develop policies for managing personal archive contents and quotas. The personal archive is not

considered part of a user mailbox when quotas are calculated. However, you can define quotas that

are specific to the personal archive. As with primary mailboxes, the organization should establish

consistent company policies regarding what content should be stored in personal archives and

regarding personal archive quotas.




Planning a Litigation Hold

Key Points

Use a litigation hold to help ensure that messages are not purged from specified mailboxes. You typically

use this feature to ensure that all messages can be found in the case of potential or ongoing legal actions.

To enable a litigation hold, use the Set-Mailbox mailboxname –LitigationHoldEnabled $true cmdlet.

When enabled, the litigation hold retains all versions of messages that have been modified.

Consider the following when implementing a litigation hold:

•

Enable a litigation hold only if required. If you implement a litigation hold for a large number ofmailboxes, the mailbox database size can grow quickly because messages cannot be deleted.

• Messages in recoverable items (removed from Deleted Items) do not count toward the mailbox

quota. You do not need to do any special planning for user quotas when a litigation hold is enabled

for a mailbox.

• There are quotas for recoverable items that can be set on a per-mailbox basis. The

RecoverableItemsWarningQuota is set to 20 GB by default, and an event is generated in the

Application log of the Mailbox server when the quota is reached. The RecoverableItemsQuota is set to

30 GB by default, and users cannot delete items when the quota is reached.

Note The RecoverableItemsQuota default configuration is derived from a setting on the

mailbox database that holds the mailbox.

• Use the Legal Hold role to delegate management of litigation holds. In many cases, the manager

responsible for designating which users are subject to a l itigation hold may not want to share that

information with Exchange Server administrators. You can delegate the ability to enable a litigation

hold by using the Legal Hold role.




Planning Multi-Mailbox Search

Key Points

In previous Exchange Server versions, you cannot easily search an organization to find messages with

specified content. Multi-Mailbox Search in Exchange Server 2010 provides efficient search capabilities

across entire Exchange Server organizations, because it uses the indexes already created for the feature,

Exchange Search. You can access items that are recoverable with single-item recovery, or with a litigation

hold, by using Multi-Mailbox Search.

Multi-mailbox searches are often referred to as discovery searches. Discovery search results are stored in a

discovery mailbox. By default, there is one discovery mailbox named Discovery Search Mailbox. You

should create additional discovery mailboxes for distinct users or groups that perform discovery searches.

This helps ensure that access to the results of the searches are limited to only those authorized to perform

the searches. For example, the team performing searches for legal purposes may have access to different

mailboxes than the help desk staff recovering deleted messages from mailboxes.

Members of the Discovery Management role group can perform discovery searches across the entire

Exchange Server organization. In many cases, you will want to limit the scope of discovery searches. You

can use the Mailbox Search role to configure limited scopes for users performing discovery searches.

Auditors are likely candidates for assignment to the Discovery Management role group or the Mailbox

Search role.

You can use the Advanced Query Syntax format to generate search queries that are more specific than the

options provided in the basic user interface. If you have users who perform many discovery searches,

provide them with information about Advanced Query Syntax to make their searching more efficient.

You can use mailbox audit logging to track the use of Multi-Mailbox Search. Mailbox audit logging was

introduced in SP1 for Exchange Server 2010, but it is not enabled by default. You must enable mailbox

audit logging on each mailbox.




Lesson 4

Designing Messaging Records Management

Use messaging records management (MRM) to control the lifetime of messages in an Exchange Server

organization. With MRM, you can define when to archive or delete messages in compliance with your

organization’s messaging policies.


• Identify the requirements and options for implementing MRM.

• Design a retention policy deployment.

• Design a managed folder deployment.

• Design migration from managed folder policies to retention policies.

• Describe communication plans for messaging compliance.




Identifying Messaging Records Management Requirements and Options

Key Points

MRM automates messaging management. You can apply policies centrally at the server level, or users can

apply policies directly to messages and folders.

Exchange Server 2010 MRM options are:

• Retention policies. You can combine multiple retention policy tags, multiple personal tags, and the

default policy tag into one retention policy. MRM applies the retention policy to mailboxes. The

retention tags in a retention policy can specify that messages are archived or deleted.

• Retention policy tag. A method for applying retention settings to a specific folder and its

subfolders.

• Personal tag. A method in which users manually apply retention settings to a folder or item. A

personal tag overrides a retention policy tag.

• Default policy tag. The policy tag with retention settings that applies to any item that is not

tagged explicitly by the user and is not in a folder subject to a retention policy tag.

• Managed folder policies. A managed folder policy combines the settings for both managed default

folders and managed custom folders into a single unit that MRM applies to user mailboxes. A

managed folder can contain content settings that move, delete, or journal messages in a specific

folder. Managed folders are provided primarily for compatibility with Exchange Server 2007.Retention policies are the preferred method for implementing MRM.

MRM requirements can include:

• Deleting messages in specified mailbox folders after a specified time. Apply retention settings to

managed default folders or to managed custom folders, if messages should be deleted from only a

few folders. Use a default policy tag if messages should be deleted from all folders without applying

another retention policy.




• Allowing users to mark specific messages for retention. Use personal tags to allow users to manage

retention of their own folders and items.

• Automatically moving messages to the personal archive at specified times. Use a retention policy with

the necessary retention tags to archive messages at the appropriate times.

• Retaining messages related to specific projects. Configure managed content settings for custom

folders into which users move messages. Users can apply personal tags to manage messages that are

not stored in a custom folder.

• Journaling messages when they are automatically deleted from user mailboxes. Use managed content

settings for the entire mailbox-managed default folder to journal messages if they are automatically

deleted. This can be overridden by managed content settings applied to a specific folder.




Planning a Retention Policy Deployment

Key Points

You can apply only one retention policy to a mailbox. This means that you need to carefully plan the

retention tags for that policy. You may create several retention policies with different combinations of

retention tags to meet the needs of different user categories.

Even after you create and apply retention policies, users still have control over the retention process. Users

can control the process by moving messages into a folder with appropriate retention settings, or by

assigning personal tags to individual messages or folders.

When planning retention policy deployment, do the following:

• Plan retention policy tags for default folders such as Inbox. To manage default-folder content, create

retention policy tags, and then use them in retention policies that you apply to mailboxes.

• Plan a default policy tag. To manage content in folders that are not assigned a retention policy tag,

create a default retention policy tag, and include it in the retention policy.

• Minimize the number of personal tags. Limiting the number of personal tags simplifies the retention

system for users. Users are more likely to use a simple system and to make fewer mistakes in applying

personal tags.

• Base retention policies on compliance requirements. To create retention policies that meet the needs

of the organization, understand the business and regulatory requirements for messaging compliance.

• Provide training on how to use retention policies. In particular, show users how AutoTagging

simplifies message retention by learning from past tagging performed by the user. A minimum of 500

tagged messages are required to enable AutoTagging. AutoTagging is an Outlook 2010 feature.

• Use a retention hold for users who are out of the office for extended periods of time. Retention holds

prevent retention policies from being applied to a mailbox. If a user is away for an extended period of

time, this prevents messages from being archived until the user returns and can read the messages.




Planning a Managed Folder Deployment

Key Points

Managed folders provide interoperability with Exchange Server 2007, and are supported by Exchange

Server 2010. If you are implementing MRM and have completely upgraded to Exchange Server 2010, then

use retention policies rather than managed folders. If you have a mixed Exchange Server 2007 and

Exchange Server 2010 organization, you may want to use managed folders to provide a consistent way to

manage mailbox content.

When planning a managed folder deployment, do the following:

• Plan managed folder policies based on departments or project groups. Create managed folder

policies for groups that have similar needs. In most cases, departments or project groups have similar

needs and use the same managed folder policy.

• Use managed custom folders and journaling to assist with message retention. The managed content

settings that you apply to managed folders do not have an option for archiving messages. Instead,

you can journal messages when they expire.

• Implement a default managed folder policy for all users, and also custom managed folder policies as

needed. You can create a managed folder policy that meets the needs of most users in your

organization, and apply that policy to all mailboxes as the default. Then, you can create custom

managed folder policies for groups with special needs.

•

Provide user training for default folders and custom folders. Train your users so that they understand

the actions that are performed on messages as they move them to different folders. This prevents

confusion when messages are automatically deleted from specific folders.




Planning Migration from Managed Folder Policies to Retention Policies

Key Points

After you implement Exchange Server 2010 in your organization, you should migrate from using

managed folder policies to using retention policies. This way, you can take advantage of the new features

in retention policies, such as archiving messages to a personal archive.

Do the following when planning migration from managed folder policies to retention policies

• Create retention policies based on the settings in your managed folder policies. If your organizational

needs remain the same for MRM, identify how you can get a similar effect from retention policies asyou did from managed folder policies. In some cases, you cannot replicate the same functionality. For

example, you cannot journal messages by using a retention policy.

• Be aware that when you apply a retention policy to a mailbox, the managed folder policy is removed.

This ensures that there is no conflict between retention policies and managed folder policies.

• Apply retention policies to mailboxes as you deploy Outlook 2010. Only users with Outlook 2010 or

Outlook Web App can apply personal tags to messages and folders. The mailboxes of users with

previous versions of Outlook are still affected by retention policy tags and default policy tags based

on folders.

• Train users in the differences between retention policies and managed folder policies. Retention

policies do not require users to move messages to specific folders. Unlike managed folder policies,

retention policies do not require users to move messages to specific folders for the retention settings

to apply. Users can manually apply personal tags to individual messages or can use AutoTagging.




Discussion: Designing a User Communication Plan for MessagingCompliance

Key Points

Communicating with your users is an essential part of implementing messaging compliance. Users need to

understand which tasks Exchange Server 2010 performs automatically, and how they can customize the

process to meet their needs.

Question: How do you communicate IT environment changes to users?

Question: What information would you include in a communication plan?

Question: How do you pilot and implement significant changes to your environment?

Question: How will you ensure that users follow messaging policies?




Lab: Planning and Deploying Messaging Compliance

Lab Setup

For this lab, you will use the available virtual machine environment. Before you begin the lab, you must do

the following:


2. Ensure that the 10233B-VAN-DC1 and 10233B-VAN-EX1 virtual machines are running.

3.

If required, connect to the virtual machines. Log on to the virtual machines asAdatum\Administrator using the password Pa$$w0rd.

Lab Scenario


locations. A. Datum is an international corporation involved in technology research and investment, and it

is planning to upgrade from Exchange Server 2003 to Exchange Server 2010.

You are aware of the new messaging compliance features in Exchange Server 2010, and need to

determine how you will implement them to meet the needs of your organization.




Exercise 1: Planning a Message Transport Implementation

Scenario

As part of the project planning for the Exchange Server 2010 implementation, the business units have

been interviewed to find any requirements that may impact the planning process. You think that the

security requirements document is most likely to have content that relates to message transport.

After reviewing the security requirements document, you find the following points that relate to the

configuration of message transport:

• Before Exchange Server 2010 sends messages to recipients on the Internet, it must add a disclaimer

that was approved by the Legal department.

• Messages sent to Internet recipients from members of the Sales team must include a different

disclaimer with the messages.

• Messages with a Company Internal classification must be blocked from being sent to the Internet.

When users try to send messages with this classification to the Internet, they should receive a

response stating that they are not allowed to send messages with this classification to the Internet.

•

A small group of senior executives and a few board members make up a Strategic Acquisitions team.These users should be able to send each other messages that are clearly marked as Acquisitions

Confidential, and the messages should never be sent to users who are not on this team.


1.

Review the A. Datum documentation.

2. Document the required configuration for message transport.


• Review the points related to message transport in the Exercise 1 scenario.




Task 2: Document the required configuration for message transport


A. Datum Message Transport Plan


Document Author

Date

Jason Carlson

15th Apr 2010


Determine how you will manage message transport.

Proposals

Question: Are transport rules required? If so, how should you configure them?

Question: Is message moderation required? If so, how should you configure it?

Question: Are message classifications required? If so, how should you configure them?

Note Be prepared to discuss your proposed plan with the class.

Results: After this exercise, you should have created a message transport plan.




Exercise 2: Planning a Message Journaling and Archiving Solution

Scenario

The next stage in implementation planning is creating a plan for message journaling and archiving. As you

search through the A. Datum documentation for the project, you find the Message Compliance Interviews

document, with content that looks relevant for this plan.

You need to determine the configuration for message journaling and archiving.

Message Compliance Interview


As part of our Mailbox server planning, we decided that users would be assigned personal archives as a

replacement for PST files. The PST files were simply too difficult to manage. We can use the personal

archives as part of our retention strategy.

As we move mailboxes to Exchange Server 2010, I’d like to implement our new archiving scheme. What I’d

like to do is this:

•

Archive all messages after 1 year.• Remove deleted items after 30 days.

• Allow users to mark individual items not to be archived.

I have also been speaking with our auditors. They need to be able to monitor and track some

communication in the organization. One item is that all messages sent to the Executives group need to be

monitored. Auditors will review these messages from time to time. In addition, auditors need to be able to

monitor communication for specific users when legal proceedings are initiated. The auditors need the

ability to initiate this process and review all messages. It is important that no messages are deleted for the

specified users.


1.



3. Document the required configuration for journaling and archiving.



• Message Compliance Interview



Question: In the Message Compliance Interview, what points are raised that impact your

journaling and archiving plan?




Task 3: Document the required configuration for journaling and archiving


A. Datum Journaling and Archiving Plan


Document Author

Date

Jason Carlson

15th Apr 2010


Determine how you will configure journaling and archiving.

Proposals

Question: Are personal archives required?

Question: Should you remove PST files?

Question: How can users access personal archives? Does this affect which users will receivepersonal archives usage?

Question: Is journaling required? If so, how should you configure it?

Question: How can you prevent users from deleting messages?

Question: Can auditors prevent users from deleting messages?


Results: After this exercise, you should have created a journaling and archiving plan.




Exercise 3: Planning a Messaging Records Management Implementation

Scenario

Finally, you need to determine what type of MRM you need to implement. You are familiar with both

managed folder policies and retention policies. You need to determine if either is required to meet your

business objectives.



2.


3. Document the required MRM configuration.






Question: In the Message Compliance Interview, what points are raised that impact your MRM

plan?

Task 3: Document the required MRM configuration


A. Datum Messaging Records Management Plan


Document Author

Date

Jason Carlson

15th Apr 2010


Determine how you will implement MRM.

Proposals

Question: Will you use managed folder policies for MRM? If so, how should you configure them?

Question: Will you use retention policies for MRM? If so, how should you configure them?


Results: After this exercise, you should have created an MRM plan.




Exercise 4: Implementing a Message Compliance Plan

Scenario

In this exercise, you will implement a message compliance plan. These steps are part of the configuration

that you planned in the previous exercises.


1. Prevent ‘Company Internal’ classification messages from being sent to the Internet.

2. Test the classification rules.

3.

Enable personal archives for all mailboxes in Mailbox Database 1.

4. Review the default policy tags and retention policies.

5. Create the Standard Mailbox Retention Policy.

6.

Apply the retention policy to the mailboxes in Mailbox Database 1.

Task 1: Prevent ‘Company Internal’ classification messages from being sent to the

Internet1.

On VAN-EX1, open the Exchange Management Shell.

2.

At the shell, type the following command, and then press ENTER:

New-MessageClassification -name “Company Internal” –Displayname “Company Internal”

-DisplayPrecedence Highest -RetainClassificationEnabled $true

-senderdescription “This message is for internal distribution only; it will not be

forwarded on to the Internet”

3.

At the shell, type the following command, and then press ENTER:

new-systemmessage –dsncode 5.7.999 –text “Internal recipients only”

–Internal $True –language En

4. In the Exchange Management Console, on the Hub Transport node under Organization

Configuration, create a new transport rule with the following properties:

• Name: Company Internal Rule

• Condition 1: sent to users that are inside or outside the organization, or partners = Outside

the organization

• Condition 2: marked with classification = Company Internal

• Action: send rejection message to sender with enhanced status code

• Bounce message: Messages classified as Company Internal cannot be sent to the

Internet

• enhanced status code: 5.7.999

• Exceptions: None

Task 2: Test the classification rules

1. On VAN-EX1, open the Microsoft Internet Explorer® browser, and then navigate to

https://van-ex1.adatum.com/owa.

2. Click This is a private computer.

3. In the Domain\user name box, type adatum\paul.




4. In the Password box, type Pa$$w0rd, and then click Sign in.

5. On the Language page, click OK .

6.

Send a new message with the following properties:

• To: [email protected]

•

Subject: Company financial results

• Permission: Company Internal

7. Wait a moment, and then open the returned message.

Question: Was the delivery successful?

Question: What error do you see?

Task 3: Enable personal archives for all mailboxes in Mailbox Database 1

1.

On VAN-EX1, in the Exchange Management Console, filter the Mailboxes view to list only those in

Mailbox Database 1.

2.

Select all of the mailboxes, and then enable archives in Mailbox Database 1.

Task 4: Review the default policy tags and retention policies

1. On VAN-EX1, in the Exchange Management Console, under Organization Configuration, on the

Retention Policy Tags tab, read the list of retention policy tags.

2. On the Retention Policy tab, view the properties of the Default Archive and Retention Policy.

Task 5: Create the Standard Mailbox Retention Policy

1. On VAN-EX1, in the Exchange Management Console, create a new retention policy tag with the

following settings:

• Tag Name: Default 1 year archive

• Tag Type: All other folders in the mailbox

• Age Limit for retention (days): 365

• Action to take when the age limit is reached: Move To Archive

• Comment: Archive messages after 1 year

2. Create another retention policy tag with the following settings:

• Tag Name: Deleted Items 30 day removal

• Tag Type: Deleted Items


• Action to take when the age limit is reached: Delete and Allow Recovery

• Comment: Remove deleted items after 30 days








3. Create a new retention policy with the following settings:

• Name: Standard Mailbox Retention Policy

• Retention policy tags: Default 1 year archive, Deleted Items 30 day removal

• Mailboxes: none

Task 6: Apply the retention policy to the mailboxes in Mailbox Database 1

1.

On VAN-EX1, in the Exchange Management Console, browse to the Mailbox node.

2. Add a the following expression to the existing filter that prevents the Discovery Mailbox from being

displayed:

• Recipient Details Does Not Equal Discovery Mailbox

3. After applying the filter, select all of the mailboxes, and then open Properties.

4.

On the Mailbox Settings tab, apply the Standard Mailbox Retention Policy to all of the mailboxes.

5.

Verify that the Standard Mailbox Retention Policy is applied to Paul West by viewing the Messaging

Records Management properties for his mailbox.

Results: After this exercise, you should have prevented messages classified as Company Internal from

being sent to the Internet, created a retention policy, and applied it to all of the mailboxes in Mailbox

Database 1.


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

1. On the host computer, start the Microsoft Hyper-V® Manager.

2.



4. Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3. Close the virtual


5. In the Virtual Machines pane, click 10233B-VAN-DC1, and then, in the Actions pane, click Start.

6. To connect to the virtual machine for the next module’s lab, click 10233B-VAN-DC1, and then, in the





8.







Review Questions

1. What is the relationship between retention policy tags and retention policies?

2.

Does a personal archive decrease the size of a mailbox database?

3.

Can you apply message moderation to recipients other than distribution groups?

4. Can Exchange Server 2010 prevent messages that meet specific criteria from being forwarded to

other users?

Best Practices Related to Messaging Records Management


• Replace managed folder policies with retention policies as you migrate mailboxes to Exchange Server

2010 and Outlook 2010.

• Implement Outlook 2010 to allow users to apply personal tags.

• Provide users with training on how to apply personal tags and use AutoTagging.

• Minimize the number of personal tags to simplify the user experience.

• Base retention policies on business needs.



8-1

Module 8

Planning and Deploying High Availability

Contents:

Lesson 1: Introduction to High Availability Planning in Exchange Server 2010 8-3

Lesson 2: Designing High Availability for Mailbox Databases 8-14

Lesson 3: Designing High Availability for Other Server Roles 8-25

Lesson 4: Designing Site Resilience 8-32Lab: Planning and Deploying High Availability 8-45






Lesson 1

Introduction to High Availability in Exchange Server 2010

Before you can begin planning a highly available Exchange Server 2010 organization, you need to

understand the options for providing high availability for each server role. Then, you can select the

options that are most appropriate for your organization. In this lesson, you will learn what high availability

is, and how you can implement high availability for Exchange Server 2010 roles.


•

Describe high availability.

• Describe the components that must be highly available to help ensure Exchange Server availability.

• Describe how database availability groups (DAGs) work.

• Describe the options for implementing database copies.

• Describe how shadow redundancy works.

• Describe how high availability works for Client Access servers.



8-4 Planning and Deploying High Availability

What Is High Availability?

Key Points

Availability refers to a level of service that applications, services, or systems provide, and is expressed as

the percentage of time that a service or system is available. Highly available systems have minimal

downtime—whether planned or unplanned—and are available more than 99 percent of the time,

depending on the needs and the budget of the organization. For example, a system that is unavailable for

8.75 hours per year would have a 99.9 percent availability rating.

To improve availability, you must implement fault-tolerance mechanisms that mask or minimize how

failures of the service’s components and dependencies impact the system. You can achieve fault tolerance

by implementing redundancy for single points of failure.

Defining Availability Requirements

Service availability is a complex issue that spans many disciplines. You can take many different approaches

to deliver the required availability levels, and each approach has its own cost implications.

Availability requirements must be expressed so that there are no misunderstandings about the

implications. Miscommunication concerning service level expectations between the customer and the IT

organization can result in inappropriate business results, such as unsuitable investment levels and

customer dissatisfaction.

Different Availability RequirementsOne organization’s requirement for 99.5 percent availability can be different from another organization’s

requirement for 99.5 percent availability. One requirement may state the availability of the hardware

platform alone, while another may state the availability of complete end-to-end service. Even the

definition of complete end-to-end service availability can vary. It is important to understand how you

must measure each availability requirement. Consider the following scenarios:

• If all hardware and software on the primary server are functioning correctly, and the application is

ready to accept all user connections, then does the solution provide 100 percent availability?




• If there are 100 users, but 25 percent cannot connect because of a local network failure, does the

solution still provide 100 percent availability? In this situation, the solution meets the 100 percent

availability expectations of 75 percent of the users, but for the rest of the users, it does not. How do

we consider this as part of the availability, because not all of the users are affected?

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

•

If all 100 users can connect, but the service is degraded with only two out of three customer

transactions being available, or performance is poor, how does this affect availability measurements?

• The availability measurement period also can have a significant effect on the definition of availability.

For example, a requirement for 99.9 percent availability over a one-year period allows 8.75 hours of

downtime, whereas a requirement for 99.9 percent availability over a rolling four-week window allows

only 40 minutes of downtime per period.

Outages

It also is necessary to identify and negotiate downtime periods for planned maintenance activities, service

pack updates, and software updates. These are scheduled outages, and typically not included as

downtime when calculating the system’s availability. You typically calculate availability based on

unplanned outages, such as a system crash. However, you have to negotiate exactly which outages youconsider to be downtime.

Question: How does your organization define high availability for services?




Components of High Availability

Key Points

When an application requires high availability, you need to consider more than just the application

components. All of the infrastructure and services that the application relies on also must be highly

available. This also applies to Exchange Server 2010.

Some of the additional components that you must consider include the following:

• Data center infrastructure. The room that stores the server must have sufficient power and cooling

capacity, which must also be highly available. You can make power highly available by ensuring thatan alternate power source—such as a battery or a generator—is available when the electrical utility

experiences outages. You can make cooling capacity highly available by using multiple cooling units

with sufficient capacity to keep the data center cool when one unit fails. In cases of a catastrophic

failure, you can use an alternate data center location.

• Server hardware. To make server hardware highly available, there must be redundant components in

the server. Redundant components can include power supplies, network adapters, processors, and

memory. Error-correction code (ECC) memory helps to resolve minor errors in memory.

• Storage. To make storage highly available on a single server, you can use a version of Redundant

Array of Independent Disks (RAID). RAID uses parity information to ensure that a server can survive

the loss of at least one hard drive without losing any data. If multiple servers are available, you can

replicate data between servers. This allows the data to survive the loss of an entire server, rather than just a hard drive.




• Network infrastructure. To make a local area network (LAN) highly available, you must introduce

redundant components. Within a LAN, this typically means redundant switches. Even moderately

priced switches include redundant configurations. To make the network connectivity for any

individual computer fault-tolerant, you must configure redundant network interface cards on the

computer. This is a standard feature in most mid-level and higher servers. High availability for a wide

area network (WAN) is typically the responsibility of the WAN service provider. However, if you are

using private links for your WAN, you can create redundant paths through the WAN.

• Internet connectivity. For highly available Internet access, you must have redundant Internet

connectivity. Ideally, you would use two different Internet service providers (ISPs), and two different

physical connectivity methods. For example, one ISP could be land-based, and the other wireless. If

you use these methods, it is unlikely that a problem affecting one ISP would affect the other. Many

firewalls and routers are capable of using one connection for Internet connectivity and failing over to

another if the primary service fails. For incoming email, you must use multiple mail exchange (MX)

resource records, with one record pointing at the IP address allocated by each ISP.

• Network services. Active Directory® Domain Services (AD DS) and Domain Name System (DNS) are

the two services that must be highly available to support highly available Exchange Server 2010

organizations. To make AD DS highly available, you should have multiple domain controllers and

global catalog servers. Depending on the size of a location, there may be multiple domain controllers

and global catalog servers in a single location. To make internal DNS highly available, you must have

multiple DNS servers with DNS information synchronized between them. By default, the DNS zones

for AD DS are Active Directory–integrated, and replicated between all DNS servers in the forest.

Question: Which infrastructure is highly available in your organization?




How DAGs Work

Key Points

A Database Availability Group (DAG) is a logical grouping of servers that you can use to provide high

availability for mailbox databases. A DAG can contain up to 16 servers. A mailbox database has a single

active copy on one of the servers in the DAG. Client requests are serviced by the active database copy.

Each mailbox database in a DAG can have one or more passive copies. Continuous replication copies

transaction log data from the active database to the passive copies. The logs are played on passive copies

of the database to update them with the same information as the active copy of the database. Continuous

replication – file mode, which copies full transaction log files, is used initially. When all transaction log files

are copied and up to date, continuous replication – block mode is used. Continuous replication – block

mode replicates each file write to the active transaction log. Continuous replication – block mode reduces

synchronization latency between the active and passive copies of a database. It also removes the current

log file as a single point of failure during failover.

If passive database copies are using continuous replication – file mode and a failover occurs, any missing

transaction logs are copied to a passive copy before activation. If the missing transaction logs cannot be

copied, nonreplicated messages are recovered from the transport dumpster on Hub Transport servers. The

transport dumpster keeps a copy of messages until they are replicated.

DAGs require the clustering feature in the Windows Server® 2008 operating system. However, the Active

Manager component is responsible for directing Client Access servers to the active copy of the database.

The Active Manager runs on all Mailbox servers that are DAG members, and runs as either the primary

active manager or a standby active manager.

The primary active manager is the Active Manager in a DAG that decides which copies are active and

passive. It is also responsible for processing topology change notifications and for reacting to server

failures.




The standby active manager provides information to other components of Exchange Server about which

server hosts the active copy of a mailbox database. For example, the RPC Client Access service on a Client

Access server communicates with the Active Manager to determine the location of a mailbox for a user.

The standby active manager also detects local database and local information store failures. It reacts to

failures by sending a request to the primary active manager to initiate a failover (if the database is

replicated).

Note As an administrator, you do not manage which servers are primary active manager

or passive active manager. The process is completely automatic.

A DAG protects against corruption of individual database pages. The most common type of database

corruption is caused by small physical errors on disks. This type of error can cause individual database

pages to be corrupted. When a request is made to an active database for a corrupted page in the

database, the corrupted page is retrieved from a passive database copy and the active database is

repaired.




Options for Implementing Database Copies

Key Points

After you add a Mailbox server to a DAG, the mailbox database is not automatically replicated to other

nodes in the DAG. You control which servers in a DAG have a copy of a specific database. Not all

databases need to have the same number of copies. In a 16-node DAG, one database can have 16 copies,

while another database is not redundant and contains only the one active copy.

When you implement a database copy, you must configure the activation settings. The activation

preference number controls the order in which passive database copies are activated when all passive

copies are up to date. If not all database copies are up to date, an up-to-date database copy is preferred

regardless of the activation preference number.

You can disable activation for a specific database copy. If you are performing maintenance, you may want

to disable activation to prevent a database from failing over to an alternate server. You may also want to

disable activation for a database copy in a remote site that is used only for disaster recovery.

For each passive copy of a database, you have the option to set a replay lag. The replay lag controls how

far behind the transaction logs are in replaying compared to the original source. For example, the active

mailbox database plays the transaction logs immediately, to place the data into the database. The replay

of logs on a passive database copy is delayed by the time period that you specify. In cases where the

transaction logs contain data that causes a logical corruption of the database, you can prevent the bad

data from being replayed on the passive copy because of the replay lag.




Truncation lag controls how long transaction logs are retained before they are deleted. In a DAG, with at

least three database copies, it is common to configure circular logging on the database because a

database restore will never be performed. If circular logging is enabled, the transaction logs are deleted

shortly after they are played into the database. If you configure a truncation lag on a database copy,

transaction logs are kept for recovery in case there are problems with the transaction logs on the active

database copy. If circular logging is not enabled, a transaction log file is not eligible for truncation until it

is backed up. A transaction log file is also not eligible for truncation until it is replicated to all database

copies and played on all database copies that are not lagged.

Question: Do you anticipate using replay lag in your organization?




How Shadow Redundancy Works

Key Points

Exchange Server 2010 includes the shadow redundancy feature, which provides redundancy for messages

for the entire time they are in transit. This is in addition to the transport dumpster. With shadow

redundancy, the message deletion from the transport databases is delayed until the transport server

verifies that the next hop for that message has completed delivery. If the next hop fails before reporting

back successful delivery, the message is resubmitted for delivery to that next hop.

When messages are delivered externally, many SMTP servers on the Internet do not support discard

status. If discard status is not supported, the final transport server in the Exchange 2010 organization

marks the message as delivered after delivery to the external SMTP server. Shadow redundancy is not

used if the next hop does not support it.

Incoming messages from the Internet do use shadow redundancy. The first transport server in the

Exchange 2010 organization delays the acknowledgement of message receipt for up to 30 seconds while

it delivers the message to the next transport server. If the first transport server fails at this point, the SMTP

server on the Internet resends the message. If the first transport server cannot send the message to the

next transport server within 30 seconds, the acknowledgement is sent to the Internet SMTP server to

indicate successful message delivery, and the message remains queued for delivery on the first transport

server.

Shadow redundancy provides the following benefits:

• Eliminates reliance on the state of any specific Hub Transport or Edge Transport server. As long as

redundant message paths exist in your routing topology, any transport server becomes disposable.

• If a transport server fails, you can simply remove it from production without worrying about emptying

its queues or losing messages.

• If you want to upgrade a Hub Transport or Edge Transport server, you can bring that server offline at

any time without the risk of losing messages.








Lesson 2

Designing High Availability for Mailbox Databases

You can implement high availability for mailbox databases by using a DAG. When you implement a DAG,

there are unique considerations that you must take into account. Proper design for a DAG ensures

sufficient performance and redundancy. A poorly designed DAG may not provide any redundancy for

mailbox databases, or may experience performance issues when one or more Mailbox servers fail.


•

Describe the requirements for implementing DAGs.

• Design the network components for a DAG deployment.

• Design the storage components for a DAG deployment.

• Design database copies and continuous replication.

• Design a plan for monitoring and managing DAGs.




Requirements for DAGs

Key Points

When you implement a DAG, you must ensure that you meet a number of very specific requirements. You

need to consider the requirements related to general configuration, operating system version, network

configuration, and DAG configuration.

General Configuration

The general requirements for implementing a DAG are:

•

DNS must be implemented with a host record for each Exchange server. Dynamic updates for DNS

are preferred.

• Each Mailbox server must be a member of the same domain. It is not possible to have Mailbox servers

in different Active Directory domains as members of the same DAG.

• The Mailbox servers that are members of a DAG cannot also be domain controllers. This configuration

is not supported.

• The computer name for the Mailbox server must be unique, and must be 15 characters or less.

Operating System Version

All members of a DAG must be running the same operating system version. All DAG members must be

running Windows Server 2008, or all DAG members must be running Windows Server 2008 R2. It is notpossible to mix the two operating system versions within the same DAG.

A DAG is based on the use of Failover Clustering in Windows Server 2008. Only the Enterprise or

Datacenter versions of Windows Server 2008 and Windows Server 2008 R2 include Failover Clustering.

Therefore, only these operating system versions can be used for DAG members.





The network configuration requirements include the following:

• One network adapter is supported, but two network adapters are recommended. This allows you to

configure a MAPI network, and a separate replication network.

• Latency between DAG members must be less than 250 milliseconds (ms). This is important when you

configure a DAG with members in multiple physical locations.

• You can use Internet Protocol version 6 (IPv6) only if Internet Protocol version 4 (IPv4) is also

configured. IPv4 cannot be disabled.

• Automatic Private Internet Protocol Addressing (APIPA) is not supported for DAG members.

DAG Configuration

In addition to the physical network and IP addressing requirements for the member servers of the DAG,

the DAG itself has certain other requirements:

• The DAG must have at least one IP address on the MAPI network. This address can be static or

dynamic, although a static IP address is typically used in most environments.

• If the DAG is expanded across multiple subnets, then the DAG must have an IP address on each

subnet.

• The name of the DAG—like the name of each member of the DAG—must be 15 characters or less,

and must be unique.

Witness Server

Failover Clustering in Windows Server 2008 uses the concept of a quorum for decision making in the

cluster. In clusters with a shared disk, connectivity to the shared disk can be used to define which nodes

should potentially be active in the cluster. In a DAG, there is no central disk.

A DAG requires the use of a witness server for a node and file share majority quorum. The witness server

functions as an additional member of the DAG for determining the quorum, but is only used when thereis an even number of members in the DAG. The witness server is a file share located on a server that is not

a member of the DAG.

The quorum for a DAG is used to determine which members participate in replications, and which can

mount databases. For example, if one computer in a DAG loses network communication, it is not part of

the quorum, and cannot mount databases.

It is recommended that you configure the witness server on a Hub Transport server in the Exchange

Server organization. The additional load on the server is minimal, and it is already under the control of the

Exchange Server management group. The witness server does not need to run the same version of

Windows Server as the members of the DAG.

If the DAG witness server is not an Exchange server, then you need to add the Exchange Trusted

Subsystem group as a member of the local Administrators group on the witness server.

Note It is possible for a DAG member to host additional server roles.

Question: Can your organization meet all of the requirements for a DAG?




Designing Network Components for a DAG

Key Points

The MAPI network is the network that other Exchange servers use to communicate with DAG members.

Additionally, you can configure replication networks that are used exclusively for log shipping between

the DAG members. If only a single network is available, it is used for all communication, including log

shipping. Although this is supported, it is not recommended. If you use only a single network, then you

should use gigabit Ethernet to ensure you have sufficient network capacity on the members.

By adding a replication network, you provide redundancy for log shipping. If the MAPI network fails for a

member with active databases, those databases fail over to another member. If the replication network

fails for a member, replication is performed over the MAPI network.

Each DAG member must have the same number of networks. If you determine that the DAG will have two

replication networks in addition to the MAPI network, all members in the DAG must have three network

adapters.

DAG networks cannot share the same subnet, or be routable between them. The MAPI network must be

separate from replication networks. Replication networks must be separate from each other.

A DAG network can span multiple subnets. This is typically used when a DAG spans multiple data centers

for geographic redundancy. When you use multiple subnets for a DAG network, you must configure

routing between the subnets. For example, the subnet used for the MAPI network in one location must be

routable from the MAPI network for another location.

Note If a DAG member hosts additional Mailbox server roles, those roles communicate by

using the MAPI network.




MAPI Network Configuration

The network adapter used for the MAPI network should have the following configuration:

• Client for Microsoft Networks – Enabled

• QoS Packet Scheduler – Optional

•

File and Printer Sharing for Microsoft Networks – Enabled

• Link-Layer Topology Discovery Mapper I/O Driver – Enabled

• Link-Layer Discovery Responder – Enabled

• Register this connections address with DNS

Replication Network Configuration

The network adapter used for the replication network should have the following configuration:

• Client for Microsoft Networks – Disabled

• QoS Packet Scheduler – Optional

•

File and Printer Sharing for Microsoft Networks – Disabled

• Link-Layer Topology Discovery Mapper I/O Driver – Enabled

• Link-Layer Discovery Responder – Enabled

• Do not register this connections address with DNS

Because a computer with a Windows® operating system supports only a single default gateway, you

should not configure the replication network adapter with a default gateway. Instead, you should

configure static routes if routing is required on a replication network.




Designing the Storage Components for a DAG

Key Points

The storage performance requirements for a DAG member vary depending on your organization. In

general, the storage for a DAG member must be sufficient to support all active databases and all passive

databases placed on the DAG member. Both active and passive databases generate disk activity. However,

passive databases generate less disk activity because they are not affected by users reading messages.

Failover Considerations

When designing the storage components for a DAG, you need to consider the results of DAG memberfailure. When one DAG member fails, the active databases on that DAG member fail over to other DAG

members. If all of the active databases on a DAG member fail over to only one other DAG member, it

could potentially overload the target of the failover. You can design your DAG as follows:

• Active/active. An active/active DAG has active mailbox databases on all nodes. When a node fails in

an active/active DAG, the active mailbox databases from the failed node should fan out to unaffected

members. This spreads the input/output (I/O) among several servers, and it prevents remaining

servers from performing poorly.

• Active/passive. An active/passive DAG has at least one node dedicated to passive mailbox database

copies. By maintaining a passive server with sufficient capacity to become active, other active servers

are not affected by a failover.

Control the failover of mailbox databases by using the activation preference number. However, be aware

that the activation preference number is used to control failover only if all database copies are up to date.

Storage Selection

A DAG provides redundancy. As part of your design, you might select storage that is not redundant in

your servers. When you create three or more database copies, you should use just a bunch of disks (JBOD)

rather than RAID. This allows you to reduce your storage costs.

Question: Are you willing to consider using JBOD instead of RAID for database copies?




Designing Database Copies and Continuous Replication

Key Points

When designing database copies, you need to consider how many database copies are required. There

are no specific rules for the number of databases you should have. More databases increase redundancy,

but they also increase the processing and storage load on the DAG members. If you are concerned about

network failure, you should design your database copies with at least one copy on a second network.

Replay Lag

You can configure a replay lag from passive copies of a database. This prevents shipped transaction logsfrom being replayed on passive database copies for a specific timeframe.

The main purpose of configuring a replay lag is to avoid logical corruption of the passive database, based

on the transaction log data that has corrupted the active database. You need to consider how long this

replay lag should be. It needs to be long enough for you to identify the error and prevent the bad data

from being replayed on the passive copy. The replay lag is set for each database copy.

Using three database copies can provide fast recovery from database failure, and it prevents logical

corruption of the database by using transaction log replay. One copy is active, and a second copy is

passive with no replay lag. In case of a disk failure or server failure, the second copy can be configured to

activate automatically. The third copy is passive with a replay lag, and it is used to prevent logical

corruption based on transaction log data. If logical corruption occurs, the first two copies are corrupted,

but the third copy is not corrupted due to the replay lag. Then, during recovery, you can specify whichtransaction logs should be replayed on the third copy.

The logical corruption that replay lag helps to recover from is quite rare. It is different from most common

database corruption that is caused by disk errors. The data in the transaction logs is based on valid MAPI

commands. Therefore, the logical corruption is more accurately described as unexpected data

manipulation than corruption. This can be caused by third-party applications that interact with Exchange

Server, such as archiving software.




Log Truncation

Typically, database logs are truncated when you perform a backup. Alternatively, when circular logging is

enabled, transaction logs are truncated after they are placed into the database. In a DAG, transaction logs

are never truncated until they are replicated to all passive database copies and played into the passive

databases. If a passive database is a lagged copy, transactions logs must be replicated to it, but the logs

do not need to be played before other database copies truncate the logs.

You can extend the time that transaction logs are retained by setting the log truncation time on a

database copy. The retained transaction logs can be used for recovery operations if there is a problem

with transaction logs on the active copy.

Site Resilience

A DAG can include members on multiple subnets and in multiple physical locations. This makes it possible

to provide site resiliency by placing DAG members in two separate data centers in two separate locations.

Note Site resiliency is discussed in Lesson 4: Designing Site Resilience.




Designing Monitoring and Management for a DAG

Key Points

In larger organizations, the management of DAGs is likely to be restricted to a relatively small group of

administrators. This group understands all of the design parameters that need to be taken into account

when creating and managing DAGs and database copies. You can delegate these permissions using Role

Based Access Control (RBAC).

To create and manage DAGs, you must be part of the Organization Management role group or Database

Availability Groups role group. To create and manage database copies, you must be part of the

Organization Management role group or Database Copies role group.

Monitoring

One of the unique challenges when managing DAGs is that, in a well-designed system, you may not

notice the failover of a database from one DAG member to another. One way you can monitor DAG

members is by using the Exchange Server 2010 monitoring management pack for System Center

Operations Manager 2007. The Exchange Server 2010 monitoring management pack proactively monitors

servers, and it can notify administrators when errors and events occur.

Exchange Server 2010 has some options for monitoring DAG status:

• Get-MailboxDatabaseCopyStatus. Use this cmdlet to view status information about a specific

mailbox database copy, all mailbox database copies of a database, or all mailbox database copies on

a server.

• Test-ReplicationHealth. Use this cmdlet to perform a variety of tests, and to report back status for

various replication components.

• Event logs. In addition to events in logs for the Windows® operating system, there are also event logs

that are specific to Exchange Server. These logs are located in the Applications and Services node. The

two specific logs that are of interest for high availability are the High Availability and

MailboxDatabaseFailureItems logs.




• CollectOverMetrics.ps1. This script collects statistics and information about switchovers and failovers.

The data reported is based on past events.

• CollectReplicationMetrics.ps1. This script collects real-time statistics about replication while it is

running.

• CheckDatabaseRedundancy.ps1. This script is scheduled to run on Mailbox servers as a scheduled task

named Database One Copy Alert. The task runs every 60 minutes. Running this task places events in

the Application event log if only a single copy of a mailbox database is healthy in a DAG. You can also

use this script interactively to generate summary reports and to show error details.

Note For examples on how to use the monitoring tools included in Exchange Server 2010,

see “Monitoring High Availability and Site Resilience”

(http://go.microsoft.com/fwlink/?LinkID=185448).

Question: Which users in your organization do you want to have permission to manage

DAGs?




Lesson 3

Designing High Availability for Other Server Roles

High availability for non-Mailbox servers varies depending on the server role. Each server role has a

unique method for providing high availability. Hub Transport servers require no configuration other than

the addition of a second Hub Transport server. Client Access servers require a client access array to be

created. Edge Transport servers require the proper configuration of MX records in DNS.


•

Design a highly available Hub Transport server deployment.

• Design a highly available Client Access server deployment.

• Design a highly available Edge Transport server deployment.

• Design a highly available deployment using multiple server roles per server.




Designing High Availability for Hub Transport Servers

Key Points

Each Active Directory site with an Exchange Server 2010 Mailbox server requires at least one Hub

Transport server to process the delivery of messages. If there is no Hub Transport server available in an

Active Directory site, Exchange Server users with mailboxes in that site will not be able to send or receive

messages.

High availability for message transport is particularly important for Hub sites. When a Hub site exists on a

routing path, all messages are forced to go through a Hub Transport server in that site. If no Hub

Transport servers are available in a Hub site, then messages cannot be delivered on that routing path.

To implement high availability for message transport in a site, you need to install multiple Hub Transport

servers in the site. No additional configuration is required. If one Hub Transport server in a site is

unavailable, Exchange services will automatically use the other Hub Transport server for message

transport.

Applications that use a Hub Transport server for message relaying will not automatically fail over to

another Hub Transport server unless the application can be configured with multiple destinations. To

provide high availability for applications, you must configure a load-balancing cluster for the Hub

Transport servers.

When a Hub Transport server fails, it may have messages in a queue waiting to be delivered. These

messages would be lost, but shadow redundancy ensures that messages are not lost. With shadowredundancy, messages remain in the transport dumpster of other Hub Transport servers until they are

notified that the message has been delivered.




You need to determine how many Hub Transport servers are justified for high availability. In branch

offices with a single server performing multiple roles, high availability for message transport may not be

important. For a main site with a large data center hosting mailboxes for thousands of users, you might

decide that three Hub Transport servers are necessary to provide the necessary level of redundancy. The

Hub Transport server role is commonly combined with the Client Access server role.

Question: Is high availability for Hub Transport more important for some sites than others?




Designing High Availability for Client Access Servers

Key Points

All clients use Client Access servers to access mailboxes. Even MAPI clients use a Client Access server to

access mailbox contents. If a Client Access server is not available in an Active Directory site, users cannot

access their mailbox contents.

Depending on the design of Internet access to Client Access servers, the failure of a Client Access server in

an Active Directory site can prevent users from multiple sites from accessing mailbox contents. If users on

the Internet connect to Client Access servers in a single main Active Directory site, and those requests are

proxied to other Active Directory sites, the failure of Client Access servers in the main sites prevents access

to those proxied sites. Consequently, high availability becomes critical for the main site that proxies the

requests.

To implement high availability for a Client Access server, you use load balancing between the Client

Access server and a client access array. You can use hardware-based load balancing or software-based

load balancing. Windows Server 2008 includes the NLB feature. Your organization can select the type of

load balancing that you are most comfortable with.

Load balancing spreads client requests between the Client Access servers. If one Client Access server

becomes unavailable, then requests are handled by the remaining Client Access servers. The client access

array directs clients to the host name used by the load-balanced cluster.

All Client Access servers in the array must be configured with the same Secure Sockets Layer (SSL)certificate. This is because all Client Access servers use the name specified in the client access array.

Internet Users

For Internet users, you need to consider redundant Internet connections as part of your design. You can

have two separate ISPs, and allow access through both to the Client Access servers in your organization. If

one ISP experiences a failure, users can access their mailbox content by using the alternate ISP at a

different domain name.




Alternatively, if you configure each Active Directory site to be available directly from the Internet, the

failure of a single Internet connection affects connectivity only to one Active Directory site. This mitigates

the damage caused by failure, but does not provide complete redundancy.

Question: Is high availability for Client Access servers more important for some sites than

others?




Designing High Availability for Edge Transport Servers

Key Points

The failure of an Edge Transport server can prevent an organization from receiving new Internet

messages. It can also prevent Exchange Server 2010 users from sending messages to Internet recipients. In

many cases, an interruption in Internet mail is considered a critical business event.

To make the Edge Transport server role highly available, you can install a second Edge Transport server.

For external message delivery, no additional configuration is required. For message reception, you must

configure an additional MX record for the second Edge Transport server. If both MX records have the

same priority, then incoming messages are load-balanced between the two Edge Transport servers.

To provide network redundancy for message delivery to the Internet, you can use two ISPs. Many firewalls

are capable of failing over to a second Internet connection when the primary connection fails. To receive

messages on the second Internet connection, you must create additional MX records.

If your Exchange Server organization has multiple points of contact with the Internet and multiple

locations with Edge Transport servers, this does not provide redundancy for outgoing messages. Messages

are delivered only on the lowest cost path. If the Edge Transport servers on the lowest cost path are

unavailable, the messages are queued on a Hub Transport server for delivery to the Edge Transport server.

Routing paths are not recalculated based on availability.

Question: Is high availability for Edge Transport servers important for your organization?




Designing High Availability for Servers with Multiple Roles

Key Points

Exchange Server 2010 allows you to combine multiple server roles on a single Exchange server. For

example, a branch office may have only a single Exchange server that performs the Mailbox, Client Access,

and Hub Transport server roles. Even in larger organizations, it is common to combine all three core server

roles on each Exchange server to simplify the overall design.

When combined on a single server, there is no conflict between the high availability methods used for the

different server roles. An Exchange server with multiple server roles can be a member of a DAG or of a

client access array. If you are using a DAG, the server that is a DAG member cannot also be a member of

an NLB cluster. However, you can use hardware-based load balancing instead.

Transport Modification

Message transport is modified when the Hub Transport and Mailbox server roles are installed on the same

server. The transport path is modified to force messages to be delivered through a second server. This

ensures that the message is in the transport dumpster and shadow queues of an alternate server in case of

a server failure.

When the Mailbox Submission Service contacts a Hub Transport server role, it gives preference to a Hub

Transport server role on a separate server. For example, VAN-EX1 and VAN-EX2 both have the Hub

Transport and Mailbox server roles installed. When a user with a mailbox on VAN-EX1 sends a message,

the Mailbox Submission Service on VAN-EX1 prefers to notify VAN-EX2 to pick up the message from theoutbox.

When a Hub Transport server role has a message for delivery to a mailbox on the same server, the

message is first delivered to a Hub Transport server role on another server for delivery back to the

mailbox. For example, VAN-EX1 and VAN-EX2 both have the Hub Transport and Mailbox server roles

installed. When the Hub Transport server role on VAN-EX2 has a message for delivery to a mailbox on

VAN-EX2, it delivers the message to the Hub Transport server role on VAN-EX1 for delivery to the mailbox

on VAN-EX2.




Capacity Planning

When you are planning capacity and optimizing performance, you need to consider not only the roles

that are running on the server now, but the additional load that will be placed on the server if another

server fails. For example, a single server that is a member of a DAG and in a client access array experiences

a load increase if another server in the DAG or another server in the client access array fails. This makes

performance planning more complex.




Lesson 4

Designing Site Resilience

Site resilience allows messaging services to survive the failure of a physical location. Exchange Server 2010

supports site resilience for mailbox databases protected in a DAG. However, you should be aware of the

several considerations that are specific to the design of site resilience.


• Describe the options for providing site resilience in Exchange Server 2010.

• Describe how site resilience works.

• Design DAGs for site resilience.

• Design other server roles for site resilience.

• Design site failover and failback.




What Is Site Resilience?

Key Points

Site resilience is the ability of the messaging system to survive a site failure, and to continue functioning

through the use of an alternate data center. In some cases, the alternate data center is a site that is

dedicated only to disaster recovery. In other cases, the alternate data center could be another company

site that is in use, but has sufficient capacity to handle services for the failed location.

A DAG is capable of existing across multiple subnets. This means that a DAG can exist across multiple

Active Directory sites. This is a major improvement over previous versions of Exchange Server that require

you to extend a subnet across a WAN link.

Site resilience exists only for Mailbox servers. Any other server roles that are required must already exist in

the site; they do not fail over. For example, Hub Transport servers and Client Access servers should already

exist in the alternate data center. Other services — such as DNS, domain controllers, and global catalog

servers — must also be available in the alternate data center.

Question: Does your organization plan for site resilience as part of its disaster recovery

planning?




How Site Resilience Works

Key Points

At the simplest level, site resilience allows for a database in a DAG to fail over to an alternate data center.

Clients can continue to access their mailbox contents and send messages. It is important to understand

how clients behave during this process, so that you can make appropriate design decisions.

When the primary data center fails, the database is activated in the alternate data center. Client

computers locate an appropriate Client Access server or array for a database by using the

RPCClientAccessServer property of the database. Unless a specific action is taken, the client computers

still use the client access array in the primary site. Clients continue to have access to mailboxes by using

the client access array in the primary site, if it is available. The client access array in the primary data

center communicates with the Mailbox server in the alternate data center.

It is more efficient from a network perspective to have clients access a client access array in the alternate

data center. In particular, when the WAN link has high latency, there is improved performance. The

simplest way to redirect clients to the client access array in the alternate datacenter is to modify the DNS

record of the local client access array to resolve as the IP address of the client access array in the alternate

datacenter. You may need to clear the DNS cache on client computers for the DNS change to take effect.

You also have the option to update the RPCClientAccessServer property of the database to direct clients

to a client access array in the alternate data center. The behavior of clients varies depending on the

version of the Microsoft Office Outlook® messaging client. In all cases, clients first attempt to connect to

the client access array in the primary data center.

Note To update the RpcClientAccessServer property of a database, use the Set-MailboxDatabase cmdlet.




Each Outlook client behaves as follows:

• Outlook 2010 clients perform an Autodiscover to get the updated Client Access server property,

update the local profile, and then begin communicating with the client access array in the alternate

data center. After a restart, Outlook 2010 clients can connect directly to the client access array in the

alternate data center. This behavior is the same whether the Client Access server in the primary data

center is available or not.

• Outlook 2007 clients perform an Autodiscover to get the updated Client Access server property, and

then begin communicating with the client access array in the alternate data center. If the Client

Access server in the primary data center is available, the profile is not updated automatically, and the

client continues to connect to the client access array in the primary site before being redirected to the

alternate data center. If the Client Access server in the primary data center is not available, the profile

is updated, and the client must restart.

• Outlook 2003 clients are never redirected to the new client access array. You must manually update

the profile to use the new client access array.

Question: Which version of Outlook does your organization use?




Designing DAGs for Site Resilience

Key Points

To configure a DAG for site resilience, the DAG must have at least one member in an alternate data

center. Then databases can be replicated to the member in the alternate data center. No other specific

configuration is required on the Mailbox servers, or for databases.

A DAG supports having multiple subnets on the MAPI network, and multiple subnets on a replication

network. Therefore, subnets do not need to span a WAN link. However, there can be no routing between

the MAPI network and the replication network. The WAN link must support both networks.

In addition to the Mailbox server in the alternate data center, you also need to install a Client Access

server and a Hub Transport server. To reduce hardware requirements in the alternate data center, you can

place the Client Access server and Hub Transport server roles on the same computer as the Mailbox server

role. However, you should do so only if the computer has sufficient capacity.

An alternate witness server must be configured in the alternate data center. The alternate witness server is

used when recovery to the alternate data center begins. Until recovery to the alternate data center is

performed, the alternate witness server is not used.

Use Datacenter Activation Coordination (DAC) mode for DAGs with members that span two locations.

Previous versions of Exchange Server recommend the use of a third physical location for geographically

distributed clusters to prevent the split-brain syndrome. The split-brain syndrome occurs when more than

one DAG member mounts a database. This is a problem because there is no way to reconcile the differentcontent in the two mounted databases. In Exchange Server 2010, the DAG includes DAC to prevent the

split-brain syndrome.

Question: Why is the DAC mode important?




How DAC Mode Works

A DAG that does not use DAC mode relies only on a quorum to determine which members of the DAG

can activate a database. A quorum is achieved when a majority of members can communicate. A witness

server is considered to be one of the members for the purposes of calculating the quorum. For example, if

there is a three-member DAG, and one member loses connectivity, the two remaining members achieve a

quorum and are able to activate databases. The single node is not part of the quorum, and cannot

activate databases.

The default configuration of a DAG creates problems in creating a DAG with site resiliency. A three-

member DAG with two members in the primary site and one member in an alternate data center canexperience split-brain syndrome when the servers cannot determine which servers should be active. If the

primary data center fails and you activate the alternate data center, split-brain syndrome arises when you

restart the primary data center without connectivity to the alternate data center. The two servers in the

primary data center have a quorum when they restart and activate their databases. The databases are

active in both the primary site and the alternate data center, with no method to resolve the data changes

between them.

You can use the DAC mode to avoid split-brain syndrome in a DAG that spans multiple locations. When

you activate the DAC mode, each DAG member stores a Datacenter Activation Coordination Protocol

(DACP) bit in memory that indicates whether that member is allowed to mount databases. Each time a

DAG member starts, the DACP bit is set to 0, which indicates that mounting is not allowed. The DAG

member communicates with other DAG members to find out their status. When the DAG member findsanother DAG member with the DACP bit set to 1, it sets its own DACP bit to 1, and can now mount

databases.

Note: To enable DAC mode for a DAG, use the command Set-DatabaseAvailabilityGroupdagname –DatacenterActivationMode DagOnly in the Exchange Management Shell.




Two node DAGs

Exchange Server 2010 with SP2 adds support for using DAC mode with two-node DAGs with two

locations. In versions before Exchange Server 2010 with SP2, a DAG needs three or more nodes to use

DAC mode. To support DAC mode with two-node DAGs, the evaluation of whether a node can mount

databases also includes the boot time of the alternate witness server in the alternate data center.

The remaining single node in a two node DAG and the alternate witness server should never be rebootedat the same time, or else DAC mode may prevent the single remaining node from starting databases. At

this point, you would be forced to reset the DACP bit in the DAG by using the Restore-

DatabaseAvailabilityGroup cmdlet.




Designing Other Roles for Site Resilience

Key Points

For Mailbox servers, you can use a DAG across multiple physical locations to provide site resilience. For

other server roles, there is no special configuration to provide site resilience; those server roles must

already exist in the alternate data center.

Hub Transport

Message transport is performed based on Active Directory sites. Each Active Directory site with a Mailbox

server must have a Hub Transport server as well. When a database is activated in the alternate data center,it uses the Hub Transport server in the alternate data center. No specific configuration is required for

message transport.

If you have applications that are configured to use a specific Hub Transport server for relaying messages,

you need to direct those applications to a new Hub Transport server. If the application is configured to

use the IP address of the Hub Transport server, you must reconfigure the application to use the IP address

of a Hub Transport server in the alternate data center. If the application is configured to use the hostname

of the Hub Transport server, you can modify the host record for the Hub Transport server to use the IP

address of the Hub Transport server in the alternate data center.

You should ensure that the Hub Transport servers in the alternate data center have sufficient capacity to

handle the volume of message processing that is expected when the alternate data center is used.

Client Access

It is not possible to span a client access array over multiple subnets. So, similar to a Hub Transport server,

you need to include a Client Access server in the Active Directory site in the alternate data center.




If the client access array in the original site is still available, it can continue to provide services for clients,

and access the active database in the alternate data center. This is a good solution if the alternate data

center is going to be used for a short term. If the alternate data center is going to be used for a long term,

you should update the RPCClientAccessServer property on the database. This allows the redirection of

Outlook 2007 and Outlook 2010 clients to the Client Access server in the alternate data center.

If the client access array in the original site is not available, you should update theRPCClientAccessServer property on the database. This allows Outlook 2007 and Outlook 2010 clients to

use Autodiscover to find the Client Access server in the alternate data center. You can also change the

DNS record for the original client access array to point to the IP address for the client access array in the

alternate data center.

Clients running Outlook Anywhere and the Microsoft Exchange ActiveSync® technology locate a Client

Access server that is accessible on the Internet by using DNS records. If the original client access array is

unavailable, you need to change the host record for the external client access to point to the Client Access

server in the alternate data center.

A potential concern is the caching of DNS records. If the client computer caches the hostname of the

Client Access server, you can clear the cache on the client computer by using ipconfig /flushdns or by

restarting the client. However, many Internet DNS servers cache resolved hostnames for 24 hours. Toensure that clients can access the Client Access servers in the alternate data center quickly, you must

provide clients with an alternate hostname to access services.

Edge Transport

To provide site resilience for Edge Transport servers, you must have a second Internet connection at the

alternate data center. The simplest way to configure site resiliency is by having the Edge Transport servers

already active and able to receive messages.

Incoming messages are directed to an Edge Transport based on MX records in DNS. The MX records are a

pointer to the hostname of the Edge Transport server. To have messages automatically redirected to the

alternate data center when the primary location is unavailable, you can configure multiple MX records.

The priority number for MX records determines the order in which they are used. An MX record with alower priority number is contacted first. The MX record for the alternate data center has a higher priority

number than the MX record for the primary data center. With this configuration, mail servers attempt

delivery to the primary data center first, and if the primary data center is unavailable, the messages are

delivered to the alternate data center.

Messages transported through the alternate data center automatically use the Edge Transport server in

the alternate data center for message delivery, because it is the closest Edge Transport server.




Designing Failover and Failback Between Sites

Key Points

Failover and failback for databases within a site can be automatic, and clients may not even notice them.

But failover and failback between sites is disruptive and can impact service. Consequently, failover and

failback between sites is considered a disaster recovery event, and must be performed manually.

Failover Considerations

When you design the failover process for a DAG, you should fail over to servers in the primary data center

before failing over to the alternate data center. The failover process to an alternate data center can bedisruptive. For example, a three-member DAG with two servers in the primary data center should only

activate a database in the alternate data center if both the servers in the primary data center are

unavailable.

When the primary data center fails, you should consider whether repair is possible before failing over to

the alternate data center. If the primary data center is going to be offline temporarily, it may cause a

greater interruption to fail over to the alternate data center, than to wait for the primary data center to

become available again. This decision is influenced by the Service Level Agreement (SLA) associated with

the mailbox databases.

Failback

Just as the failover process to an alternate data center is manual, so is the failback process. Before failing

back any databases to the primary data center, you should ensure that all necessary services—such as

DNS, domain controllers, and global catalog servers—are functioning properly. Hub Transport and Client

Access servers in the primary data center also need to be functional.

When the DAG members in the primary data center and all necessary services are functioning again, you

can replicate the databases back to the primary data center. When replication is complete, you can

activate the databases in the original site. The activation of databases in the primary site does not need to

be done during off-hours.




Discussion: Failure Scenarios

It is important to understand how a DAG with site resilience responds when a node fails. You can create

an appropriate recovery plan only if you understand the failover process.

In scenario 1, Site A has two Mailbox servers and a witness server. Site B has a single Mailbox server and

an alternate witness server. All active mailbox databases are on the Mailbox servers in Site A. Each Mailbox

server has database copies of all mailbox databases.

Question: If the WAN link between Site A and Site B fails, what impact does it have on the

active databases in Site A?

Question: How can you ensure that mailbox databases fail over between the Mailbox servers

in Site A rather than failing over to the Mailbox server in Site B?

In scenario 2, Site A has one Mailbox server and a witness server. Site B has a single Mailbox server and an

alternate witness server. All active mailbox databases are on the Mailbox server in Site A. A passive copy of

each mailbox database is on the Mailbox server in Site B.

Question: If the WAN link between Site A and Site B fails, what impact does it have on the

active databases in Site A?

Question: If there were active mailbox databases in Site B when the WAN link failed, how

would they be affected?

Question: If the Mailbox server in Site A fails, does the Mailbox server in Site B automatically

mount the databases?




Question: If all of the data center infrastructure in Site A fails, does the Mailbox server in

Site B automatically mount the databases?

Question: If you want two locations to have highly available mailbox databases, how many

DAGs should you have?




Lab: Planning and Deploying High Availability

Lab Setup


1.

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

2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3 virtual

machines are running.

3.

If required, connect to the virtual machines. Log on to the virtual machines asAdatum\Administrator using the password Pa$$w0rd.

Lab Scenario




Concerns have been raised about the availability of Exchange Server 2010. Messaging has been

designated as a critical service in the organization. The existing Exchange Server 2003 organization

experienced several outages, and you want to avoid these outages in the future. You need to create a

high availability design for Exchange Server 2010.

Finally, you are required to implement part of your proposed high availability design.

Note Your instructor may choose to do this lab as a group discussion rather than an





Exercise 1: Designing High Availability for Exchange Servers

Scenario

In this exercise, you will examine the current topology and messaging infrastructure. You will determine

the appropriate high availability deployment based on the information supplied in the A. Datum

Exchange Server 2010 project documentation.

High Availability Interviews

Marcel Truempy, CIO

In the last five years since I became CIO, our email system has changed from being a useful tool for

business to being a critical part of our business processes, and everybody notices when email is not

available. To give you an example, a couple of months ago, all of the email servers in London were

unavailable for six hours due to a virus outbreak. A couple of months before that, one of the servers in

Vancouver failed, and we couldn’t send any email to and from Vancouver for eight hours while the

hardware vendors came in to fix the hardware. This happened right in the middle of some critical business

negotiations where we had to be able to exchange documents rapidly. In both cases, the CEO and every

other member of the executive staff called me on my cell phone while I was at home. The most important

requirement I have for this email system is availability—this system has to be available always.


I can provide you with a Microsoft Office Visio® diagram that has all of our WAN connections, and our

connections to the Internet. Our network right now is quite reliable, but we don’t have much available

bandwidth between company locations.


If you want to replicate a lot of messaging information over the WAN, then we need to consider the cost

of the links to these locations. Within a given continent, WAN links are relatively cheap when compared to

those that cross oceans. I guess that it costs a lot of money to run fiber optic cable on the bottom of the

ocean. Did you know that some WAN links between continents even use satellites? No wonder it costs so

much.

So, ultimately, if possible, from a cost perspective, we’re better off keeping traffic within a continent.


We’ve gone through a negotiation process for new SLAs that coincides with our Exchange Server 2010

implementation. Any site that has more than 3,000 users must have off-site disaster recovery of

messaging. We don’t need to fail over within minutes, but within four hours. That gives us time to decide

whether we can recover a data center, or need to activate the disaster recovery site.

I still haven’t decided whether we need dedicated disaster recovery sites, or whether we should use some

of our own data centers as disaster recovery sites for each other. The initial setup cost for using our own

data centers is much less, and they have the capacity. I guess it comes down to the cost of network

connectivity with the disaster recovery sites, which would be an ongoing cost that could add up over time.

Smaller sites with less than 3,000 users must be highly available, but we don’t need off-site disaster

recovery.


The larger sites with more than 3,000 users have servers dedicated to specific server roles. The Vancouver

site has two Mailbox servers, a Hub transport server, and a Client Access server in the current plan.




The smaller sites combine all server roles on a single physical server. The San Diego site has just one

Exchange server with all server roles in the current plan.

One other issue I’m concerned about is logical corruption of database copies in a DAG. I know that this is

a very rare occurrence, but I think it makes sense to protect ourselves against the possibility. As I

understand it, we can configure a delay on a database copy so that a logical corruption in the transaction

logs won’t be passed on to the database copy for a period of time. I think a delay of six hours would besufficient.

User Distribution Summary


London

Corporate Headquarters

12,000 currently

10,000 after thenew Londonoffice is ready



• 800 Outlook users connecting through a virtualprivate network (VPN)

London (new office) 4,000(anticipated)

• 200 Outlook Web Access users


San Diego

Former head officeof Trey Research Corporation






• 200 Outlook users connecting through a VPN

Chennai (new office) 800 (anticipated) • 200 Outlook Web Access users

•

50 Outlook users connecting through a VPN









1.

Review the A. Datum Corporation documentation.

2.


3. Document the required configuration for the San Diego site.

4.

Document the required configuration for the Vancouver site.



• High Availability Interviews

• User Distribution Summary

• Network Configuration



Question: In the High Availability Interviews, what points are raised that impact your high

availability design, and how do they impact it?

Question: Is there anything in the User Distribution Summary that raises high availability issues?

If so, what is it?

Question: Is there anything in the Network Configuration that raises high availability issues? If so,

what is it?




Task 3: Document the required configuration for the San Diego site


A. Datum High Availability Design for San Diego


Document Author

Date

Jason Carlson

24th April 2010


Determine how high availability will be provided for all server roles in San Diego.



Proposals

Question: Will this site have offsite disaster recovery? If so, where should that site be located?

Question: How do you provide high availability for databases?

Question: How do you provide high availability for Client Access servers?

Question: How do you provide high availability for message transport?

Question: Is high availability required for the Edge Transport server role?

Question: How many Exchange servers will be located in this site? Which roles will they host?

Question: How will databases be configured on the DAG members?

Question: How will load balancing be performed for the Client Access server role?

Question: Is any additional configuration required for the Hub Transport server role




Task 4: Document the required configuration for the Vancouver site


A. Datum High Availability Design for Vancouver


Document Author

Date

Jason Carlson

24th April 2010


Determine how high availability will be provided for all server roles in Vancouver.



Proposals









Results: After this exercise, you should have created a high availability design for the San Diego and

Vancouver sites.




Exercise 2: Implementing High Availability for Exchange Servers

Scenario

In this exercise, you will implement part of the high availability plan for the Vancouver site. VAN-EX1 and

VAN-EX2 are the Mailbox servers located in Vancouver. VAN-EX3 is the Mailbox server located San Diego,

which will have a lagged copy of the database.

Note Due to restrictions in the virtualized environment, VAN-EX3 is not located in a

separate Active Directory site.


1.

Prepare VAN-DC1 to be a DAG witness server.

2.

Create a three-member DAG.

3. Configure replication for Mailbox Database 1.

4.

Simulate the failure of VAN-EX1.

5.

Recover VAN-EX1.

Task 1: Prepare VAN-DC1 to be a DAG witness server

1.

On VAN-DC1, open Active Directory Users and Computers.

2.

Add Exchange Trusted Subsystem as a member of the Builtin\Administrators group.

Note This task configures the security to use a Domain Controller without Exchange

Server 2010 installed as the witness server. If a member server is used instead of a domain

controller, Exchange Trusted Subsystem should be added as a member of the local

Administrators group on the member server.

Task 2: Create a three-member DAG

1.

On VAN-EX3, open the Exchange Management Console.

2. Under Organization Configuration, on the Mailbox node, select the Database Availability Groups

tab and create a new DAG with the following settings:

• Database availability group name: VancouverDAG

• Witness Server: VAN-DC1

• Witness Directory: C:\VanDAGWitness

Note Step 2 generates a warning, because the witness server is not an Exchange server.

This does not indicate a problem. The necessary permissions were configured in Task 1.

3.

Open the properties of VancouverDAG, and then add 10.10.0.200 as an IP address for the DAG.

Note Step 3 generates a warning, because the witness server is not an Exchange Server.





4. Use the context menu of VancouverDAG to add VAN-EX1, VAN-EX2, and VAN-EX3 as DAG

members.

Task 3: Configure replication for Mailbox Database 1

1. On VAN-EX3, in the Exchange Management Console, on the Database Management tab, add a copy

of Mailbox Database 1 to VAN-EX2.

2. Add a copy of Mailbox Database 1 to VAN-EX3.

3. In the Exchange Management Shell, use the following command to configure a replay lag time of six

hours for Mailbox Database 1 copy on VAN-EX3:

Set-MailboxDatabaseCopy –Identity “Mailbox Database 1\VAN-EX3” –ReplayLagTime 0.6:0:0

4. Use the following command to verify that the replay lag is configured correctly:

Get-MailboxDatabase “Mailbox Database 1” | Format-List ReplayLagTimes

5.

Use the following command to view the status of the Mailbox Database 1 copy on VAN-EX3:

Get-MailboxDatabaseCopyStatus –Identity “Mailbox Database 1\VAN-EX3”

Task 4: Simulate the failure of VAN-EX1

1. On the host computer, in the 10233B-VAN-EX1 window, turn off VAN-EX1.

2.

On VAN-EX3, refresh the Exchange Management Console to view the status of the Mailbox

Database 1 copies.

3.

If any database copy has a status of Disconnected, refresh the view again.

Question: What is the status for Mailbox Database 1 on each server?

Question: Why is the server where the database is mounted selected?

Task 5: Recover VAN-EX1

1. On the host computer, in the 10233B-VAN-EX1 window, start VAN-EX1.

2.

On VAN-EX3, refresh the Exchange Management Console to view the status of the Mailbox

Database 1 copies.


3. If the status of Mailbox Database 1 on VAN-EX1 is initializing, wait a few minutes, and then click

Refresh again. You may need to select Mailbox Database 1 on VAN-EX1 to refresh its status.

Results: After this exercise, you should have implemented high availability for Mailbox Database 1 in

Vancouver.






following steps:


2.









7.


8.

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





Review Questions

1. To make a highly available Exchange Server organization, which components must be highly

available?

2.

Which Exchange Server 2010 feature provides fault tolerance for message delivery?

3. How many networks should be used for a DAG?

4.

What are the requirements for using the DAC mode?

Best Practices Related to High Availability for Client Access Servers


• Use a client access array and load balancing to make client access highly available.

•

If a Client Access server is also a member of a DAG, then use hardware-based load balancing.• Ensure that Internet-accessible sites that proxy Client Access for multiple sites are highly available,

because their outage will affect many users.

• When a DAG fails over to an alternate site for a short period of time, allow the clients to continue

using the client access array in the original site.

• When a DAG fails over to an alternate site for an extended period of time, reconfigure the

RPCClientAccessServer property of the databases to direct clients to a client access array in the

alternate site.






9-1

Module 9

Planning a Disaster Recovery Solution

Contents:

Lesson 1: Planning for Disaster Mitigation 9-3

Lesson 2: Planning Exchange Server Backup 9-17

Lesson 3: Planning Exchange Server Recovery 9-27

Lab: Planning a Disaster Recovery Solution 9-41



9-2 Planning a Disaster Recovery Solution

Module Overview

Disaster recovery planning is an essential requirement for fulfilling service level agreements (SLAs). These

agreements define when a service needs to be available, and how quickly it must be recovered if it fails.

To ensure that you meet SLA requirements, you need to plan how Microsoft® Exchange Server 2010 will

be backed up and restored.


• Plan for disaster mitigation.

• Plan Exchange Server 2010 backup.

• Plan Exchange Server 2010 recovery.




Lesson 1

Planning for Disaster Mitigation

Disaster mitigation avoids the need for disaster recovery, and it allows you to recover data much faster

than with a full restore. Exchange Server 2010 has improved the disaster mitigation methods that are

available to administrators, with features such as database availability groups (DAGs).


•

Identify potential disasters or data loss scenarios.

• List the Exchange Server 2010 features that can alleviate the impact of disaster or data loss scenarios.

• Design Exchange Server 2010 for disaster mitigation.

•

Identify the relationship between high availability and disaster mitigation.

• Design an Exchange Server 2010 high availability solution for disaster mitigation.

• Describe backup-less Exchange Server.

•

Describe recovery time objective (RTO) and recovery point objective (RPO).

• Identify scenarios that may require backup and restore.




Identifying Data Loss Scenarios

Key Points

To understand which type of disaster mitigation method is appropriate, first consider the potential data

loss scenarios. Each scenario requires different disaster mitigation methods.

Lost Item

A lost item from a mailbox often occurs because a user deleted that item. The item could be deleted by

accident, or the item could be deleted on purpose and the user may only realize later that the item was

required.

One lost mailbox item typically consists of a small amount of data. However, that small amount of data

can be very important. A lost item could be a mail message or a calendar item, and may include

attachments.

Lost Mailbox

A lost mailbox results in the entire contents of that mailbox being lost. A lost mailbox is typically the result

of deletion by an administrator. While this could occur accidentally, deletion is more commonly done

when a user leaves the organization. After the user account is deleted, a manager or former colleague

may need access to the mailbox to review what the user was working on.

Lost Database

A lost database results in a loss of all mailboxes in that database. Additionally, while the database is

missing, users with mailboxes in that database can no longer send or receive messages.

A lost database typically occurs because of a system malfunction, which can include disk failure or

database corruption. Lost database recovery is critical, because many users are affected by the outage.




Lost Server

A lost server results in a loss of all databases on that server. A lost server typically occurs because of a

system or infrastructure failure. For example, the server’s power supply could fail, or there could be a fire

in the server room. Lost server recovery is critical, because many users are affected.

Question: Can you think of any other ways that Exchange Server data can be lost?




Data Loss Mitigation Features

Key Points

Exchange Server 2010 includes a number of features that you can use to mitigate data loss. These are

important, because when you mitigate data loss, you do not need to perform recovery from backup. It is

typically much faster to use these data loss mitigation methods than to recover from backup.

Deleted Item Recovery

In earlier Exchange Server versions, user-deleted items were still recoverable until the items were purged

from the dumpster. A hard delete (SHIFT+DELETE) permanently removed messages. This is also thedefault configuration in Exchange Server 2010. If the default times are not modified, then Exchange Server

purges mail messages after 14 days, and calendar items after 120 days.

Single-item recovery allows you to recover a message after a user deletes an item. The message is

recoverable even if the user performed a hard deletion. Also, the dumpster stores multiple versions of

edited items. If the default times are not modified, then Exchange Server purges mail messages after 14

days, and calendar items after 120 days.

If you enable a litigation hold, then items are never purged from the dumpster. This helps you to ensure

that no messages are lost.

Note For more information about single-item recovery, see Single Item Recovery in

Exchange Server 2010 on The Microsoft Exchange Team Blog(http://go.microsoft.com/fwlink/?LinkID=185406).

Other Data Loss Mitigation Features

Other data loss mitigation features include:

• Deleted mailbox retention. Use deleted mailbox retention to recover deleted mailboxes and their

contents. By default, Exchange Server retains deleted mailboxes in the mailbox database for 30 days.




• DAG. Use a DAG in most scenarios to recover from a lost server or a lost database. When a server or

database fails, Exchange Server mounts a replicated copy of that database onto another member of

the DAG. This process is much faster than restoring a database from backup.

• Shadow redundancy. Shadow redundancy is automatically enabled for all Exchange Server 2010 Hub

Transport and Edge Transport servers. Transport servers keep a copy of the message they are sending

until it is delivered to the next Hub Transport or Mailbox server. This ensures that messages are notlost in transport due to a server failure.

Question: Which of these data loss mitigation features do you think you will use most often?




Designing a Disaster Mitigation Strategy

Key Points

The default Exchange Server configuration is sufficient for many organizations. However, consider the

following when planning your disaster mitigation strategy:

• Increase deleted item retention so that the items are recoverable for a longer time period. However,

the default 14 days is normally a sufficient time period, and lowering this value has a minimal impact

on database size.

•

Increase the deleted item retention time period for specific users. By increasing the deleted itemretention time period for critical users or users most likely to require item recovery, you limit the

increase in database size, and meet the needs of users.

• Enable single-item recovery to ensure that all items are recoverable. Single-item recovery prevents

users from hard-deleting items and purging them from the dumpster. The items are invisible to the

user, but they are recoverable by an administrator.

• Increase deleted mailbox retention so that mailboxes are recoverable for a longer period of time. The

default 30 days is normally a long-enough time period, and lowering the value has a minimal impact

on database size.

•

Use DAGs to provide server-level redundancy and avoid data loss. You must have the Enterprise

version of the Windows Server® 2008 operating system. However, unlike with previous Exchange

Server versions, the Enterprise version of Exchange Server is not required.

• Use replay lag time to prevent database corruption. Database corruption can occur when a

transaction is placed in the transaction logs. In such cases, replay lag times may prevent corruption of

the passive copy, because you can prevent the offending transaction from being replayed on the

passive copy.




What Is the Relationship Between Disaster Recovery and High Availability?

Key Points

High availability provides fault tolerance for various parts of a system. Fault tolerance is typically provided

through redundant components. In servers, Redundant Array of Independent Disks (RAID) arrays provide

fault tolerance for hard drives. On a network, redundant routing paths provide fault tolerance. Exchange

Server 2010 enables you to make each server role highly available.

Disaster recovery is required when high availability fails. For example, a RAID 5 array can survive a single-

disk failure. However, if multiple disks fail, then data loss occurs and you must perform disaster recovery

to retrieve the data.

You also need disaster recovery when high availability does not provide the required functionality. For

example, high availability does not provide for long-term data archiving. To recover historical data, you

must perform a restore from an archive. You typically use high availability to maintain the current state of

a system.




Designing a High Availability Solution for Disaster Mitigation

Key Points

Exchange Server 2010 provides methods to make each server role highly available. When properly

implemented, the need for disaster recovery is small.

Exchange Server 2010 supports the following high availability methods:

• DAGs for mailbox databases. In a DAG mailbox, databases are replicated to multiple servers. If one

server or database fails, Exchange Server mounts a replica on another server and continues servicing

client requests. This avoids the need to recover a failed Mailbox server or corrupted mailbox database.

• Replication for public folders. A public folder database cannot be replicated in a DAG. However, to

provide high availability, you can replicate individual public folders and their contents between public

folder databases on different servers, and between sites. This avoids the need to recover a failed

Mailbox server or corrupted public folder database.

•

Multiple Hub Transport servers for message transport. Message transport is automatically made

highly available when you have multiple Hub Transport servers in a site. If one Hub Transport server

fails, then the remaining Hub Transport servers service all requests. This avoids the need to recover a

failed Hub Transport server.

•

Client access arrays for client access. When you implement a client access array and configure load

balancing between Client Access servers, you make client access highly available. If one Client Access

server fails, then the remaining Client Access servers handle the client requests. This avoids the need

to recover a failed Client Access server.

•

Multiple Edge Transport servers for edge transport. To make edge transport highly available, you

need two Edge Transport servers in the perimeter network. Outgoing messages are automatically

load-balanced between the two Edge Transport servers, and if one fails, the other continues

delivering all messages. For inbound messages, you must either initiate load balancing, or configure

one mail exchanger (MX) resource record for each Edge Transport server. This avoids the need to

recover a failed Edge Transport server.




When high availability is used for a server role, you are not required to recover a failed server. However, in

most cases you will replace the failed server with a new server that provides the same functionality. This is

required to continue providing the same level of high availability. For example, when a member if a DAG

fails, the databases will mount on other DAG members, and you will then add a new DAG member to

replace the functionality of the lost DAG member.

Question: Which of these high availability methods do you think your organization willimplement?




Exchange Native Data Protection

Key Points

Exchange native data protection is the combination of disaster mitigation technologies found in Exchange

Server 2010. When properly configured, you can use Exchange native data protection as an alternative to

traditional backups. To use Exchange native data protection as an alternative to traditional backups, at a

minimum you need a DAG and single-item recovery. You should also consider the use of personal

archives and litigation holds.

Database CopiesExchange native data protection requires at least three database copies for each mailbox database. The

chance of all three database copies being lost is very small, and thus there is no need to perform a backup

for disaster recovery. If a Mailbox server fails, a database copy on another server is activated.

To mitigate the risk of a lost site due to a disaster such as a fire, you should have at least one database

copy in a remote site. This is the equivalent to having a backup tape stored offsite.

When using a traditional backup solution, the transaction logs for a mailbox database are truncated

during a full backup. Backups are not performed with Exchange native data protection, and transaction

logs are not truncated. You should enable circular logging on databases to prevent log files from taking

up unnecessary disk space. The DAG ensures that all log files are replicated before they are removed.

Lagged Database CopiesTo mitigate the risk of logical corruption affecting all database copies, you should configure a lagged

database copy. A lagged database copy delays replay of logs for up to 14 days. When you activate the

lagged database copy, you can select the point in time to which it recovers. You can also specify a

truncation delay on the lagged database copy to keep transaction logs for up to 14 days after they are

replayed in the database.




Single-Item Recovery

To ensure that you can recover individual items after users have deleted them, you enable single-item

recovery on each Mailbox. Single-item recovery keeps copies of deleted items even when they were

deleted by the user. The administrator can then use Multi-Mailbox Search to find and recover the items.

Single-item recovery is not enabled on mailboxes by default.

You need to determine an appropriate length of time in which you can recover items. The default timethat items are available for recovery is 14 days. You may want to extend this time when using Exchange

native data protection because deleted item recovery is the only option for recovering deleted items;

there is no backup to restore. However, as you extend the retention period, additional disk space is

consumed by the mailbox databases. If required, you can vary the retention time for individual users.

Archiving

The biggest concern many organizations have when considering Exchange native data protection is the

lack of long-term archiving. When deleted items are no longer available through single-item recovery,

they are not recoverable. Carefully consider the policies your organization has in place for Exchange

Server data retention. Most organizations rarely need to recover archived Exchange Server data.

The storage improvements in Exchange Server 2010 allow you to consider using larger and less expensivestorage. This in turn allows you to increase the time the items are retained by single-item recovery.

One alternative to consider is occasional backups for archival purposes. If specific data needs to be

archived, you should implement messaging records management (MRM). It may be possible to locate all

mailboxes that need to be archived in a single mailbox database that is backed up.

Reduced Costs

Exchange native data protection reduces costs in the following ways:

• Simplified management. After the initial configuration, Exchange native data protection is much

easier to manage than backups. There is no ongoing need to manage backup media.

• No backup software or hardware. The cost to purchase backup software and hardware can be

significant. This is no longer required.

•

No RAID. When three or more database copies are implemented, the recommended disk

configuration is just a bunch of disks (JBOD). This disk configuration is less expensive to implement

than RAID.

Note Remember that to implement a DAG, you need to use the Enterprise version of

Windows Server and multiple servers. In smaller organizations, this may increase costs.




Discussion: When Is Exchange Native Data Protection Appropriate?

Exchange native data protection offers a number of advantages over traditional backups. Your

organization may have specific needs for implementing Exchange native data protection.

Question: When compared to traditional backups, how does Exchange native protection

affect recovery time?

Question: How does using Exchange native data protection affect the backup window?

Question: Does Exchange native data protection meet the archiving needs of your

organization?




What Are the Timelines for Disaster Recovery

Key Points

The timelines for disaster recovery are determined by the SLA. Each SLA should have an RTO and an RPO

that you use to determine how to perform backups and disaster recovery.

The RTO for a service defines how quickly you should recover the service. For example, after a Mailbox

server fails, the RTO for the Mailbox server might indicate that you need to recover the mailboxes stored

on that server within two hours.

In some cases, there may be an RTO for partial functionality. For example, after a Mailbox server fails, theRTO for sending and receiving messages might be one hour, but the RTO for historical data in mailboxes

might be 12 hours.

The RPO for a service defines at what point in time you must recover the service. The RPO may indicate

that data from a specific timeframe can be lost, or that recovery must equal a certain point in time. For

example, the RPO for a Mailbox server may indicate that up to 12 hours of data may be lost, or that a

Mailbox server must be recovered to the backup at 02:00 the previous night.

Based on your RTO and RPO for Mailbox servers, you may choose to:

• Keep databases small to shorten recovery times.

• Keep transaction logs on separate drives from the databases to ensure that you can replay them after

a database restore.

• Perform a backup every few hours to ensure minimal data loss.

Note If you are using a DAG with at least three database copies for high availability, then

backups will be less frequent, and it is not necessary to separate transaction logs and

databases on separate disks.

Question: Does your organization have formally defined RTOs and RPOs for messaging?




Scenarios Requiring Backup and Restore

Key Points

After implementing data loss mitigation and high availability for Mailbox servers, you will still encounter

scenarios that require backup and restore. Scenarios requiring backup and restore include:

• Recovering a hard-deleted message when single-item recovery is not enabled. If single-item recovery

is not enabled on a Mailbox server and a user hard deletes an item, Exchange Server removes the

item from the database without placing it in the dumpster.

•

Recovering a message after the item retention period has passed. Even when you enable single-itemrecovery, Exchange Server only retains deleted items for the specified time period. By default, this is

14 days for mail messages.

• Recovering a public folder item after the item retention period has passed. Exchange Server only

retains a deleted item in a public folder for the specified time period. By default, this is 14 days.

•

Recovering a database when you are not using a DAG. You must recover failed mailbox databases

from backup when they are not replicated in a DAG. Alternatively, you can use database repair tools,

but it is typically faster to restore from backup than to repair a database.

• Recovering from a server failure when you are not using a DAG. When a Mailbox server fails, all

mailbox databases on that server are lost if they are not replicated as part of a DAG. You must recover

the server from backup.

With a DAG in place, you may consider not backing up Mailbox servers regularly. With multiple database

copies and a replay lag time used to mitigate data corruption, you can avoid restoring a database.

Additionally, you can guarantee deleted-item recovery for a period of time by using single-item recovery.

You can extend the time period for single-item recovery to meet your organizational requirements.

Question: When did you last restore an Exchange server? Why did you need to restore it?




Lesson 2

Planning Exchange Server Backup

When planning Exchange Server backup, consider which data you need to restore. You only need to back

up the data that needs restoring. Limiting the backup data size decreases the time it takes to perform the

backup, and allows you more flexibility in your backup schedule.

The software you use to perform backups can also influence your backup process. There are many third-

party solutions for backing up Exchange Server 2010. You can also use Windows Server Backup in the

Windows® operating system and Microsoft System Center Data Protection Manager.


• Identify backup requirements for Mailbox servers and data.

•

Identify backup requirements for non-Mailbox servers.

• Choose Exchange Server Backup software.

• Choose Exchange Server backup media.

• Design an Exchange Server backup schedule.

•

Design an Exchange Server backup management process.




Identifying Backup Requirements for Mailbox Servers

Key Points

To support disaster recovery for database and Mailbox server failures, maintain backups for the following:

•

Mailbox databases. To recover the contents of the mailboxes in a mailbox database, you must

maintain a mailbox database backup. You can restore this database to the same server or to another

Mailbox server.

• Public folder databases: To recover the contents of the public folders in a public folder database, you

must maintain a public folder database backup. You can restore this database to the same server, orto another Mailbox server.

• Transaction logs. Transaction logs are an important part of an Exchange Server 2010 backup. After

restoring a database, Exchange Server 2010 replays the transaction logs to bring the database up to

the current state and make it consistent with the previous version of the database. If you perform an

incremental backup, then only transaction logs are backed up.

You do not have to back up Mailbox server configuration data. All configuration data for a Mailbox server

is stored in the configuration partition of Active Directory® Domain Services (AD DS). You can retrieve

any necessary configuration data required for a server restore from AD DS.




Identifying Backup Requirements for Non-Mailbox Servers

Key Points

Non-Mailbox servers contain little data that you need to back up. As with Mailbox servers, the AD DS

configuration partition stores all non-Mailbox server configuration data. You can retrieve any necessary

configuration data required for a server restore from AD DS. However, a server restore is seldom

necessary, because you can replace the functionality with a new server instead of restoring a failed server.

The following table lists the data you may want to back up for specific server roles.

Server role Data to back up

Client Access • Customized website pages and configuration settings. You do not need asystem state backup to back up configuration settings in Internet InformationServices (IIS) 7.0, just a backup of the configuration directory. If you do nothave this data backed up, you can reconfigure it.

• Secure Sockets Layer (SSL) certificate with private key. However, if you do notback up the SSL certificate, you can always purchase another one.

Hub Transport • Message transport logs. Backing up these logs may be useful for latertroubleshooting. However, no backups are required to restore functionality.

Edge Transport • Server configuration. This is stored locally rather than in AD DS. You shouldclone the configuration to back up the server configuration.

Unified Messaging • Customized audio prompts. If not backed up, the prompts are lost when theUnified Messaging servers fail.

Question: Do you customize Microsoft Office Outlook® Web App or Outlook Web Access

pages in your organization?




Choosing Exchange Server Backup Software

You can back up by using the built-in Windows Backup software, System Center Data Protection Manager

(DPM), or third-party software. Choose the software based on the features that you require. At a

minimum, use backup software that the vendor indicates works properly with Exchange Server 2010.

The backup software that you choose must support Volume Shadow Copy Service (VSS) backups. A VSS

backup takes a snapshot of the database rather than streaming the data from Exchange Server. On the

Exchange server, the VSS writer is responsible for triggering the snapshot and for making the Exchange

Server databases consistent before the snapshot is taken.

Windows Server Backup

You can use Windows Server Backup that is included with Windows Server 2008 to back up Exchange

Server 2010 databases and other data. When Exchange Server 2010 is installed, the version of Windows

Server Backup is updated to support Exchange Server 2010 backups. However, Windows Server Backup

has the following critical limitations:

• It must run locally on the server that has the Exchange Server data.

•

It must back up to a local disk or network share, not to tape.

• It restores only full databases.

• It cannot back up passive DAG copies.

Data Protection Manager

DPM is a backup solution for servers running Windows Server. It can back up basic file and print servers

and application servers. DPM performs disk-based backups first, and then you can use it to archive to

tape.




DPM improves on Windows Server Backup in the following ways:

• Unlike Windows Backup, DPM requires only an agent to be installed on the computer running

Exchange Server 2010. So you can use DPM to centralize the backups of multiple servers.

• You can restore databases or mailboxes. Recovering a mailbox is easier than restoring a database to a

recovery database and then extracting the mailbox contents.

• You can back up passive database copies. This means that you can back up databases from a server

without determining whether the server has an active or passive database copy.

Third-Party Backup Software

Most third-party backup software is similar to DPM. However, some third-party backup software has the

following additional features:

• Individual item restore. Some third-party backup software can restore individual mail messages

directly from backup to a user’s mailbox. This is less complex than first recovering to a recovery

database and then extracting the required message.

• Brick-level backup. Brick-level backups are backups of mailbox contents. To perform a brick-level

backup, the backup software creates a Messaging Application Programming Interface (MAPI)connection to each mailbox that it is backing up. This can be useful for backing up specific mailboxes

more frequently. If you have implemented personal archives, you can use brick-level backups to back

up only the main mailboxes in a mailbox databases, and not the archive data.




Choosing Exchange Server Backup Media

Key Points

Tape backup is still a popular method of performing backups. Tapes are easy to transport, and very

durable. Tape capacity and speed have steadily grown as manufacturers bring out new products. If you

need to expand backup capacity beyond a single tape, you can use a tape changer that automatically

rotates several tapes in a single unit. In high-capacity environments, you can use a tape library. A tape

library is a cabinet with one or more tape backup units, and a robot arm that moves tapes in and out of

the tape backup units.

To increase backup performance, many organizations use disk-based backups instead of tapes. Disk

storage is often cheaper than tape storage when you use large capacity disks rather than faster

performing Small Computer System Interface (SCSI) disks.

The first backup to disk is a complete copy of the server. The second snapshot captures only changes and

writes them to disk. Multiple backup versions exist on the disk, but the tool uses only as much disk space

as the first backup plus changes. This is similar to VSS in that you can use it to store multiple versions of

files.

However, disk-based backups are not as well suited as tape-based backups for off-site storage. Disks tend

to be sensitive to physical movement, and become unreliable if you transport them regularly. Therefore,

many organizations use disks as a first backup tier, and then transfer backups to tape for off-site storage.

If your Exchange Server databases are located on a storage area network (SAN), then you can use SAN-based snapshots to lessen backup traffic on the main network, and keep backup traffic on the SAN. The

backup is taken from the SAN snapshot rather than through the Exchange Server. To implement SAN-

based snapshots for Exchange Server backup, your backup application must support your specific SAN

hardware.




Designing an Exchange Server Backup Schedule

Key Points

When determining an Exchange Server 2010 backup schedule, you must consider many factors, including

backup frequency, requirements for various server roles, the available backup window, and recovery

requirements.

Mailbox Servers

You must back up Mailbox servers more often than other Exchange Server roles. Mailbox servers contain

the messages that users receive each day, and therefore you must back them up regularly to ensure thatmailboxes and message are recoverable. One way to determine the backup frequency for Mailbox servers

is to determine the acceptable data loss if both the database and transaction logs are lost. If only 12 hours

of data loss is acceptable, you must back up every 12 hours, and then store the tapes off-site.

When you use tapes for backup, you typically keep enough tapes to maintain a recent data archive. For

example, you could have your daily backup tapes, but then also retain each Friday backup tape for one

month, and possibly each month’s last-Friday tape for a year. This is sometimes referred to as a

grandfather, father, son scheme.

When you use disks for backup, you can archive to tape at any time. In a similar way, you could create a

weekly tape each Friday, and then retain one weekly tape per month for a year.

Non-Mailbox ServersOther server roles do not maintain user data, and you can back them up less often. Configuration data is

the main concern when backing up non-Mailbox servers. You may institute a policy in which you back up

non-Mailbox servers weekly, or only when you change your configuration.




Backup Window

You time window for performing backups may influence your backup schedule. For example, an

organization that operates 16 hours per day, five days per week, may not be able to perform a full backup

to tape each night. In this case, you can perform a weekly full backup on weekends, and incremental or

differential backups during the week. Incremental or differential backups to tape are much faster than full

backups. However, be aware that when you use differential backups, the transaction logs are not

truncated. On a busy Mailbox server, this can lead to large volumes of transaction logs.

The backup window is less of an issue when you back up to disk. VSS backups to disk capture only

changes since the last backup. Thus, VSS backups to disk effectively function like incremental backups,

because you are not backing up redundant data that was already backed up. You may choose to perform

VSS backups to disk frequently, because the backup sizes are small. In some cases, organizations perform

VSS backups multiple times a day.

You also can use passive database copies in a DAG to perform backups during normal production hours,

without affecting the Mailbox server’s performance. By doing this, you can extend your backup window

beyond what is normally available. The ability to back up passive database copies is important when

selecting backup software.

Note Windows Backup cannot back up a passive database copy in a DAG.

Recovery Requirements

Your SLA recovery requirements also influence how you perform backups. If recovery speed is the primary

concern, then you must perform full backups daily, because they are the fastest to restore. When you use

differential or incremental backups, you must replay many transaction logs after you restore the backup.

Depending on the amount of transaction logs, replaying the transaction logs can take a long time.

If you are doing frequent disk-based backups, each backup behaves as a full backup. This means that

recovery is fast. It is also generally faster to restore from disk backup than from tape.




Designing an Exchange Server Backup Management Solution

Key Points

Backup management solutions define how the organization manages and monitors backups, and

manages the backup media that it uses. These solutions may include how the organization performs

backups, backup frequency, backup media, and various other details related to the backup schedule and

process.

Planning and Configuration

Assign a team or administrator to take primary responsibility for managing backups. Assigningresponsibility for managing backups ensures that backup management occurs. It also provides a single

contact for backup requests. When you centralize responsibility, there is a lower likelihood of conflicting

changes being made to the backup system.

Monitoring

Ensure that daily backup monitoring occurs, and address backup failures immediately. Failed backups

increase the risk to data. For example, if you fail to back up three days in a row and the hard disks fail, you

could lose three days of data. In most cases, configure backup software to automatically send you the

backup completion status.

Media

Backup media must be stored off-site daily. This can prevent data loss, even if you lose an entire physicallocation. When transporting data offsite, you should secure the backups. Using a trusted courier service is

one way to secure offsite backups. Also, ensure that you are using a secure offsite location. Many third-

party vendors provide secure storage facilities.

Finally, consider encrypting your backup contents. This ensures that no one can access the contents if the

tapes are lost or stolen.




Media Rotation

Most organizations reuse tapes after a mandated time defined by the organization’s data storage

requirements. For example, some organizations rotate tapes on a weekly basis so that each Friday a

backup tape is transported offsite and remains archived for six months or longer. In this scenario, the

organization reuses the daily backup tapes from Monday through Thursday, from one week to the next.

Be sure to keep track of the average failure time for backup media, and remove tapes from the rotationbefore failure occurs. For example, some types of backup tapes only guarantee a year’s life expectancy

when used weekly. The average failure time varies depending on the media type and the media’s storage

conditions—such as humidity and temperature.

When using disk-based backup, closely monitor disk status in the backup server. If a disk in a RAID array

fails, replace it quickly. Ideally, you always have a spare disk available in the server.

Test Restore Functionality

It is important to test the restore functionality in your backup and restore solution on a regular basis. This

ensures that you backup media actually contains a functional backup that can be used for recovery.

Testing restore functionality also ensures that your restore procedures are valid.




Lesson 3

Planning Exchange Server Recovery

To restore lost servers and data in the most efficient manner, you need to understand the options

available for recovering Exchange Server functionality and data. The recovery process varies depending on

the specific server roles. To ensure that everyone in your organization understands the recovery process,

you should create and maintain a disaster recovery plan.


•

Describe the options for recovering Exchange Server functionality.

•

Describe the options for recovering mailbox data and databases.

• Plan Mailbox server recovery.

• Plan non-Mailbox server recovery.

•

Plan Edge Transport server recovery.

• Create a disaster recovery plan.

• Maintain the disaster recovery plan.




Options to Recover Exchange Server Functionality

Key Points

You have two options when recovering Exchange Server functionality: replace the lost server roles or

restore the lost server. Both options allow you to recover full functionality.

Replace the Lost Server Roles

It is typically faster to replace a lost server role than to restore a lost server. Replacing a lost server role

means that you do not need to restore from backup any server roles other than the Mailbox server, which

must be restored from backup by using a DAG. If you are using a DAG, you can add a new server to theDAG and create a new database copy on the server. Other server roles may have customizations that you

need to configure.

Restore the Lost Server

When a server fails, you can restore the lost server to recover the functionality provided by that server.

Restoring the server requires you to build a new server, and to join that server to the domain using the

same computer account name. You can restore the computer’s system state to recover the computer

name and recover some configuration information, such as the IP address and certificates.

After joining the domain, install Exchange Server 2010 using the Recovery mode. The Recovery mode

reads the Exchange Server configuration information from AD DS and automatically installs the

appropriate server roles that are linked to the computer account. After installation, the Exchange Server

configuration information stored in AD DS is used for that computer.

Never delete the computer account for a failed Exchange Server. If you do so, you cannot recover the

Exchange Server functionality for that server.




When to Restore a Lost Server

Even though it is faster and easier to replace a lost server role than to recover a lost server, in the

following cases, you should recover the server:

• To avoid reconfiguring Outlook 2003 clients. Outlook 2003 clients do not support the Autodiscovery

feature. Therefore, these clients cannot reconfigure a profile and find the location of a new mailbox.

Recovering the server with same name means that you do not need to reconfigure the Outlook 2003clients.

• To avoid reconfiguring firewalls. Internet-accessible servers such as Outlook Web App and the

Microsoft Exchange ActiveSync® technology are protected by firewalls and proxy servers. Recreating

the original configuration means that you do not need to reconfigure firewalls to direct traffic to a

new server. If the Client Access server is part of a client access array, firewall reconfiguration is not a

concern because the replacement server will be a new node in the existing client access array.

•

To recover poorly documented customizations. If a lost server’s customizations are poorly

documented, you may not be able to replicate the configuration. Restoring from backup may be the

only option to recover the configuration.

•

To avoid reconfiguring applications configured to use a specific server. Some applications areconfigured to use a specific server. For example, an application may be using a specific Hub Transport

server as a mail relay. Recovering the server means that you do not need to reconfigure a new Hub

Transport server with an appropriate Simple Mail Transfer Protocol (SMTP) receive connector.




Options to Recover Mailbox Data and Databases

Key Points

If a database is intact, you can use single-item recovery to restore individual messages. If a database is lost

due to corruption or server failure, you need to recover the data that was stored in the lost database.

There are many options that you can use when performing a recovery. Each option is appropriate in

different circumstances. The available options are described in the following table.

Option Description

Database restore Recover a database lost due to corruption or disk failure by restoring thedatabase. After restoration, replay the transaction logs to bring the database upto the current state just before it was lost.

Recovery database Use a recovery database if you need to recover data from inside a database,instead of recovering the entire database. A recovery database is a databasethat is mounted on a Mailbox server, but is not directly accessible to users. Afterrestoring a database in the recovery database, extract the messages ormailboxes that you want to restore.

Database portability You do not need to restore databases on the same servers that backed them up.You can restore and mount databases on any Exchange Server 2010 Mailboxserver in the organization. This is useful when one of several Mailbox serversfails, and you want to recover the database to a functional Mailbox server. You

can also restore to a recovery database located on a different server.After restoring a database to an alternate server, you must use the Set-Mailbox cmdlet with the –Database parameter to link the mailboxes with the newlocation.




(continued )

Option Description

Dial-tone recovery When a mailbox database fails, users with mailboxes in that database can nolonger send and receive messages. You can create a dial-tone database bycreating and mounting an empty database for the mailboxes contained in the

failed database. This quickly allows users to send and receive messages again.After the dial-tone database is functional, restore historical data to a recoverydatabase, and then merge the data into the dial-tone database.

If the dial-tone database is located on a different server than the faileddatabase, use the Set-Mailbox cmdlet with the –Database parameter to linkthe mailboxes with the new location.

DAG recovery Performing a DAG recovery means that you do not need to perform a databaserestore. Assuming you have multiple database copies in a DAG, then when onedatabase copy fails, Exchange Server automatically mounts and redirects usersto another database copy. To restore redundancy, create another database copyon a different server.

Note When a user with a cached mailbox connects to a dial-tone recovery database for

the first time, Exchange Server deletes the contents of the cache.

Question: Which recovery method is preferable?




Planning the Recovery of Mailbox Data and Databases

Key Points

When planning Mailbox server recovery, consider the following:

•

Using a DAG means you do not have to perform a recovery; Exchange Server uses a replica database

instead. This is much faster and easier than using other recovery methods, and improves the recovery

experience for users and administrators.

• Place transaction logs and databases on physically separate disks if you do not use a DAG and if you

may need to restore from backup. This ensures that transaction logs will be available for replay if thedisks containing the database are lost.

• Recover basic functionality as soon as possible if you do not use a DAG, and a Mailbox server or

database fails. Use a dial-tone recovery database to allow users to send and receive messages as

quickly as possible. This is much faster than waiting for a database to restore.

•

Ensure that you have enough free disk space to hold a restored database. Allocate enough free disk

space to hold any database from which you might need to recover data. You can allocate disk space

on each Mailbox server, or allocate one server to use for database recoveries.

Question: Will you allocate space for database recovery on each Mailbox server?




Planning the Recovery of Non-Mailbox Servers

Key Points

Non-Mailbox servers provide various functions, and do not contain significant amounts of user or

configuration data. You can recover the basic functions of non-Mailbox servers without backing up

existing servers. Backups are required only if you are restoring additional configuration options that you

may have set after installation.

Adding a Server Role

One way you can replace a failed non-Mailbox server is to add the server role to an existing Exchangeserver in the same site. This way, you can recover functionality quickly. In most cases, this is a temporary

solution until you can rebuild the failed server, or deploy a new server as a replacement.

Deploying a New Server

You also can deploy a new server with the same server role to replace a failed non-Mailbox server. A new

Hub Transport server immediately replaces the functionality of a failed Hub Transport server without

requiring further configuration. A new Client Access server role also immediately replaces the functionality

of a failed Client Access server. However, you must reconfigure clients to access the new Client Access

server role, or reconfigure the Domain Name System (DNS) to direct clients to the new Client Access

server role.

When replacing a Client Access server with a new one, you must perform additional configurations rather

than rebuild the failed server. Any configuration changes that you made to the websites used on a Client

Access server — such as authentication options — are lost when you replace a Client Access server. To return

the Client Access server role to its previous configuration state, you must have documented your previous

changes so that you can perform them again on the new server. When you rebuild a server, these changes

are restored from backup.




If you use a client access array, then you do not need to redirect clients to the new Client Access server.

The client access array continues to service user requests after a failure. You can add a new Client Access

server to the load-balancing cluster used for the client access array at any time. Configure a new Client

Access server in a client access array with the same customizations as other nodes in the client access

array. This includes the SSL certificate.

Considerations for Deploying a New ServerDeploying a new server may require you to reconfigure some applications. For example, if you configure a

Voice over IP (VoIP) gateway to communicate with the DNS name or IP address of the failed server, then

you must reconfigure the VoIP gateway.

If you choose not to rebuild a failed Exchange server, you must remove it manually from AD DS using the

LDP.exe tool.




Planning the Recovery of Edge Transport Servers

Key Points

Unlike other server roles, Edge Transport servers store most configuration information locally in Active

Directory Lightweight Directory Services (AD LDS). AD LDS is used on Edge Transport servers, because

these servers are not members of the Exchange Server organization’s domain.

Use a cloned configuration to recover an Edge Transport server. To create the cloned configuration, run

the ExportEdgeConfig.ps1 script in the C:\Program Files\Microsoft\Exchange Server\V14\Scripts folder.

When you run this script, Exchange Server writes the Edge Transport server’s configuration information to

an XML file. Spam filtering settings are included in the cloned configuration.

Note You must create the cloned configuration before the Edge Transport server fails.

The cloned configuration does not include the transport configuration object, which includes a few

settings, such as maximum message sizes and maximum number of recipients for a message. Exchange

Server configures the settings in the new server’s transport configuration object with the default settings.

To restore customized settings, you must manually configure them according to your documentation.

Recovery Steps

To use a cloned configuration to recover an Edge Transport server, complete the following steps:

1.

Perform a clean installation of the Edge Transport server. Use the same server name as the server that

you are restoring. However, this server is not joined to a domain, so you do not need to reset a

computer account.

2. Run the ImportEdgeConfig.ps1 script to validate the configuration. The script checks the existing

information in the XML file to verify that the settings are valid. If some settings in the XML file are not

valid, Exchange Server creates an answer file. The answer file specifies the server-specific information

necessary for the next step.




3. Use the ImportEdgeConfig.ps1 script to import the configuration. The script validates the XML file,

and then uses the intermediate XML file and the answer file (if required) to restore the backed-up

configuration information.

4.

Run the Microsoft Exchange EdgeSync process to establish one-way recipient and configuration

information replication from AD DS to the AD LDS instance on an Edge Transport server. The cloned

configuration backup and restore process does not duplicate the Edge Subscription server’s settings,and does not clone the certificates that the Exchange EdgeSync service uses. You must run the

Exchange EdgeSync process separately for each Edge Transport server. The Exchange EdgeSync

service overwrites settings that are included in both the cloned configuration information and the

EdgeSync replication information. These settings include Send connectors, Receive connectors,

accepted domains, and remote domains.




Creating a Disaster Recovery Plan

Key Points

A disaster recovery plan is a plan for restoring functionality when an event occurs that causes IT systems

to fail. It focuses on threats to servers and associated infrastructure, not on threats to business processes.

However, the order in which you restore components may be based on recovery of business processes.

Disaster Recovery Plan Components

Disaster recovery plans include the following components:

•

SLA and recovery requirements with the business impact statement

•

Risk assessment with risk probabilities and costs

• Budget, including funds available to address specific risks

• High-level process document with links to detailed recovery procedures

•

Testing plan, which determines the feasibility and compatibility of backup facilities and procedures

• Auditing plan, which provides a methodology for demonstrating to the organization that the disaster

recovery plan works as designed

•

Maintenance plan, which details how team members keep current the disaster recovery plan and the

change-control procedures that control plan modifications

•

Training plan for team managers and members




Creating a Disaster Recovery Plan

Disaster recovery plans focus more on the technology team responsible for maintaining systems, than on

the business units. They are technical in nature, and do not require business unit approval. However, some

input from business units is desirable.

Like any project, creating a disaster recovery plan must have milestones and eventual sign-off for

acceptance. Sign-off may be an internal IT department process, which does not require business-unit sign-off.

Developing a disaster recovery plan may be an incremental process. It is unlikely that you can

simultaneously address recovery processes for all systems. You should first address the systems that are

the most business critical.




Maintaining a Disaster Recovery Plan

Key Points

Disaster recovery plans are not static documents; they change as organizations change. You need to

update your disaster recovery plan when you add new servers or services to the organization. Also, as you

test the disaster recovery plan, you will find opportunities for improvement.

Testing a Disaster Recovery Plan

Test and evaluate your disaster recovery plan thoroughly at least once a year, and document the

procedures to test the plan. Periodic testing ensures that the plan includes all necessary steps, especiallysince it is unlikely that all business changes are communicated efficiently to the team responsible for

disaster recovery planning. Not only does regular testing capture items that change-management missed,

it also ensures that all members of the disaster recovery team are well-trained on the plan’s execution.

Your testing process should include the following:

•

Procedures for restoring specific components—such as servers and mailboxes

• Media availability for performing a restore

• Results of component failure and system failure

•

Server and infrastructure loads on remaining servers after a failure

•

Workstation impact of a specific failure, and the recovery method performed

• Performance of procedures to meet time frames specified in the SLA

You typically test a disaster recovery plan during non-business hours to minimize the impact on users.

However, more ambitious testing could include testing during normal business hours to ensure that you

can perform recovery with minimal disruptions to the organization’s overall operations.




Refining a Disaster Recovery Plan

Creating a disaster recovery plan is an incremental process. Testing reveals necessary modifications. In

large organizations, you may need to develop the disaster recovery plan in stages, and address the areas

with the highest business impact first.

During disaster recovery plan testing, analyze all data that you collect on the success and failure of the

various tests, and then use it to modify the plan. Most likely, you will find that the tests indicate thatnumerous procedures are not sufficient to meet the RTOs and RPOs specified in the SLA. You may also

discover that some procedures are unnecessary or over-engineered. Save money by scaling back those

procedures. Catalog all of this information in a lessons-learned document.

Always retest disaster recovery plan components that you modify. Be aware that a change to one

component may directly or indirectly impact other systems. Disaster recovery plan testing may require

some time to ensure that you can test all changes.




Lab: Planning a Disaster Recovery Solution

Lab Setup

For this lab, you will use the available virtual machine environment. Before you begin the lab, you must do

the following:


2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, and 10233B-VAN-CL1 virtual machines are

running.



Lab Scenario


locations. A. Datum Corporation is an international corporation involved in technology research and

investment, and it is planning to upgrade from Exchange Server 2003 to Exchange Server 2010.

High availability planning is complete, but the disaster recovery plan needs to be further developed.

Specifically, you need to consider the details of the messaging SLA to ensure that disaster recovery is

possible within the appropriate time frame.

Finally, you must implement part of your proposed disaster recovery plan.






Exercise 1: Planning Disaster Recovery for Vancouver

Scenario

The high-availability plan for Vancouver indicates that your organization will use a DAG to provide high

availability for mailbox databases. There will be two database copies in Vancouver, and another database

copy with a six-hour lag in San Diego, to provide site resilience. Each mailbox database has a maximum

size of 250 gigabytes (GB). Other messaging settings will use default values.

The Client Access servers in this site were customized with a company-specific look, including the

company logo. All changes have been documented.

There are customized Receive connectors configured on one Hub Transport server. The customized

Receive connectors support applications that need to relay messages through the Exchange Server

organization to the Internet.

There are two Edge Transport servers configured in the perimeter network of this location.

Disaster Recovery SLA Notes

The following requirements related to disaster recovery were taken from the messaging SLA:

•

There can be no data loss due the failure of a single server.

• The failure of a single server should result in only minutes of downtime for users.

• High availability can be considered a replacement for backup if there are at least two local copies of a

database, and a remote database copy in another site.

• To consider high availability a replacement for backup, there must be one database copy that is

unaffected by logical corruption in another database copy for at least 12 hours.

• Any message deleted by a user must be recoverable for 30 days.

• Deleted mailboxes must be recoverable for 60 days.

•

Messaging functionality must be recoverable within one hour, while historical data can be recovered

up to 24 hours later.

•

When recovering data from a backup, there is a maximum data loss allowed of up to 4 hours.

• Any location that is not configured with site resilience must archive weekly backups offsite.


1.



3. Document the required configuration for the Vancouver site.


•

Review the following information:

• Disaster Recovery SLA Notes


Question: In the Disaster Recovery SLA Notes, what points are raised that impact your disaster

recovery plan for Vancouver?






A. Datum Disaster Recovery Plan for Vancouver


Document Author

Date

Jason Carlson

5th May 2010


Determine how disaster recovery will be provided for all server roles in Vancouver.

Proposals

Question: Does this site require backups?

Question: Do you need to make any changes to the DAG to meet the SLA requirements?

Question: Are any changes required for deleted item retention?

Question: Are any changes required for deleted mailbox retention?

Question: Do you need to back up data on Client Access servers?

Question: Do you need to back up data on Hub Transport servers?

Question: Do you need to back up data on Edge Transport servers?

Question: Would your backup plan change if public folders were present in Vancouver?

Results: After this exercise, you should have created a disaster recovery plan for the Vancouver site.




Exercise 2: Planning Disaster Recovery for San Diego

Scenario

The high-availability plan for San Diego indicates that a DAG will be used to provide high availability for

mailbox databases. There will be two database copies in San Diego. Each mailbox database has a

maximum size of 250 GB. Other messaging settings will use default values.

You evaluated various backup solutions, and determined that you can move 250 GB data over the

network in about 75 minutes. However, the available tape backup systems require about 120 minutes to

restore 250 GB of data.

The Client Access servers in this site were customized with a company-specific look, including the

company logo. All changes have been documented.

There are customized Receive connectors configured on one Hub Transport server. The customized

Receive connectors support applications that need to relay messages through the Exchange Server

organization to the Internet.

There are two Edge Transport servers configured in the perimeter network of this location.


1.


2.


3. Document the required configuration for the San Diego site.





Question: In the Disaster Recovery SLA Notes, what points are raised that impact yourdisaster recovery plan for San Diego?






A. Datum Disaster Recovery Plan for San Diego


Document Author

Date

Jason Carlson

5th May 2010


Determine how disaster recovery will be provided for all server roles in San Diego.

Proposals

Question: Does this site require backups? If so, how will you perform backups?


Question: Are any changes required for deleted-item retention?


Question: How will you meet the recovery requirement of one hour?

Question: Would your backup plan change if public folders were present in San Diego?

Results: After this exercise, you should have created a disaster recovery plan for the San Diego site.




Exercise 3: Implementing Single-Item Recovery

Scenario

In this exercise, you will implement single-item recovery for a mailbox. This is part of the disaster recovery

plan for the Vancouver site.

To test the functionality of single-item recovery, you will configure Andreas as a member of the DiscoveryManagement role, with the ability to recover items after they have been purged and are no longer

accessible to users. Andreas will recover an item after it has been purged from a mailbox by performing a

mailbox search.


1.

Enable single-item recovery for a mailbox.

2. Configure a user for message recovery.

3.

Delete and purge a message.

4.

Locate a recoverable message.

5.

Create a role group for exporting mailbox contents.

6.

Recover a message.

Task 1: Enable single-item recovery for a mailbox

1. On VAN-EX1, open the Exchange Management Console.

2.

Browse to the Organization Configuration node and click Mailbox. On the Database

Management tab, configure the following settings for Mailbox Database 1:

• Keep deleted items for (days) :30

• Keep deleted mailboxes for (days): 60

3.


4. In the Exchange Management Shell, use the following command to enable single-item recovery for

Luca’s mailbox:

Set-Mailbox Luca –SingleItemRecoveryEnabled $true

Task 2: Configure a user for message recovery

1.

On VAN-CL1, if necessary, log off, and then log on as Luca using the password Pa$$w0rd.

2.

Use the Microsoft Internet Explorer® browser to connect to Outlook Web App at


3.

Log on to Outlook Web App as Adatum\Administrator using the password Pa$$w0rd.

4.

Go to Options, and then click See All Options.

5. Click Manage Myself and select to manage My Organization.

6.

In Roles & Auditing, go to the Administrator Roles tab, and then add Andreas Herbinger to the

Discovery Management role group.

7. Close Internet Explorer.




Task 3: Delete and purge a message

1.

On VAN-CL1, use Outlook 2010 to send a message with the following settings:

•

To: Luca

• Subject: Test of SIR

2.

Delete the Test of SIR message from the Inbox.

3.

Delete the Test of SIR message from Deleted Items.

4. On the Folder tab, use the Recover Deleted Items option to purge the Test of SIR message.

Task 4: Locate a recoverable message

1.

On VAN-CL1, use Internet Explorer to connect to Outlook Web App at


2.

Log on to Outlook Web App as Adatum\Andreas using the password Pa$$w0rd.

3.

Go to Options, and then click See All Options.

4.

Select to manage My Organization.5.

Go to Mail Control.

6.

Create a new Multi-Mailbox Search with the following settings:

• Keywords: SIR

• Mailbox to search: Luca Dellamore

•

Search name: Luca’s lost message

• Copy the search results to the destination mailbox

• Mailbox to store the results: Discovery Search Mailbox

7.

Click the refresh icon to verify that the search succeeded.8. In the search results, click [open] to view the Discovery Search Mailbox.

9.

Expand the contents of the Luca’s lost message folder until you see the Test of SIR message.

Task 5: Create a role group for exporting mailbox contents

• On VAN-EX1, in the Exchange Management Shell, use the following command to create a new role

group with permissions to export and import mailbox contents with Andreas as a member:

New-RoleGroup –Name ExportMail –Roles “Mailbox Import Export” –Members Andreas




Task 6: Recover a message

1.

On VAN-EX1, log off as Administrator, and then log on as Adatum\Andreas using the password

Pa$$w0rd.

2.


3.

In the Exchange Management Shell, use the following command to export the message from theDiscovery Search Mailbox to Luca’s mailbox:

Search-Mailbox “Discovery Search Mailbox” –SearchQuery ‘Subject:”SIR”’ –TargetMailbox

Luca –TargetFolder Recovered

4. On VAN-CL1, in Outlook 2010, expand all of the folders in the Recovered folder to locate the

recovered message.

Results: After this exercise, you should have implemented single-item recovery and recovered a message.



steps:


2.


3.


4. Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3. Close the

virtual machine connection windows.







8.


9.






Review Questions

1. Why might older backup software not support Exchange Server 2010?

2.

How does Recovery mode help restore an Exchange server?

3.

Is it possible to use a DAG for archiving mailbox information?

4. Why is it important to have a formal disaster recovery plan?

Best Practices Related to Recovery of Mailbox Databases and Data


• Whenever possible, use a DAG to protect mailbox databases. DAG recovery is faster and easier than

backup recovery.

•

When you lose a database, use a dial-tone database to quickly recover basic messaging functionality.• Use a recovery database to retrieve specific items from a backup.

•

Allocate disk space for a recovery database when designing server storage.

• Use single-item recovery to prevent users from purging messages before they reach the item-

retention limit.






10-1

Module 10

Planning Microsoft® Exchange Server 2010 Monitoring andTroubleshooting

Contents

Lesson 1: Planning Exchange Server Monitoring 10-3

Lesson 2: Planning Exchange Server Troubleshooting 10-19

Lab: Planning Exchange Server 2010 Monitoring and Troubleshooting 10-27



10-2 Planning Microsoft® Exchange Server 2010 Monitoring and Troubleshooting

Module Overview

To ensure that your messaging system runs efficiently, you must perform routine monitoring and, where

necessary, make adjustments to your Microsoft® Exchange Server 2010 servers. By understanding how to

implement a monitoring program and knowing what and how to monitor, you can optimize your

Exchange servers.

Occasionally, problems may arise with your messaging system. Therefore, it is important to understand

how to troubleshoot problems with Exchange Server 2010. Planning an effective troubleshooting

methodology and having familiarization with the troubleshooting tools helps you to quickly andefficiently resolve even complex problems.


• Plan a monitoring solution for Exchange Server 2010.

• Plan a troubleshooting solution for Exchange Server 2010.




Lesson 1

Planning Exchange Server Monitoring

Monitoring practices are commonly an afterthought, and are often implemented sometime after

Exchange Server is deployed. However, having a well-tuned and consistently used monitoring solution can

greatly improve your ability to identify, troubleshoot, and repair issues before they are noticed by end

users.


•

Identify the options for monitoring Exchange Server.

• Plan performance monitoring for Mailbox servers.

• Plan performance monitoring for Transport servers.

• Plan performance monitoring for Client Access servers.

• Plan message tracking and logging for Transport servers.

• Plan for monitoring baselines and trend analysis.




Options for Monitoring Exchange Server

There are several methods that you can use to collect performance data from Exchange servers in your

organization. You should use the method that best suits your requirements.

Real-time monitoring of Exchange servers is useful when you want to determine the effect of performing

a specific action or troubleshoot specific events. This type of monitoring can also help you to ensure that

you are meeting service level agreements (SLAs).

Analyzing historical data can be useful for tracking trends over time, determining when to relocate

resources, and deciding when to invest in new hardware to meet the changing requirements of yourbusiness. You should use historical performance data to assist you when planning for future Exchange

Server requirements.

Exchange Server 2010 includes a range of tools to assist you in the monitoring of your Exchange Server

environment. The following table lists these tools.

Tool Description

Windows Server® 2008Event Viewer

Collects information related to server operations. This data can help you toidentify performance issues on a server. You should search for specificevents in the event log file to locate and identify problems.

Windows® System

Resource Manager(WSRM)

By using WSRM, you can control how CPU resources are allocated to

applications, services, and processes. Managing these resources improvessystem performance, and reduces the chance that these applications,services, or processes interfere with the rest of the system.

WSRM is a feature of Windows Server 2008.

Network Monitor Network Monitor is a protocol analyzer. It enables you to capture, view, andanalyze network data. You can use it to help troubleshoot problems withapplications on the network.

Network Monitor is provided with Windows Server 2008.




(continued )

Tool Description

Reliability andPerformance Monitor

You can use Windows Reliability and Performance Monitor to examine howprograms you run affect your computer's performance, both in real time,and by collecting log data for later analysis. Windows Reliability and

Performance Monitor uses performance counters, event trace data, andconfiguration information, which can be combined into Data Collector Sets.

Reliability and Performance Monitor is built in to Windows Server 2008.

Microsoft ExchangeServer 2010Management Pack forMicrosoft System CenterOperations Manager2010

System Center Operations Manager 2010 enables you to build a completepicture of the past and current performance of your server infrastructure.System Center Operations Manager can also automatically respond toevents and address problems before they become an issue for you. SystemCenter Operations Manager requires time to configure, and requiresadditional licenses. The Microsoft Exchange Server 2010 Management Packis designed to be used for monitoring Exchange Server 2010 events,collecting Exchange component-specific performance counters in onecentral location, and for raising alerts when operator intervention isnecessary.

Microsoft ExchangeServer 2010Management Pack forSystem Center Essentials2010

Microsoft System Center Essentials 2010 is a management solution thatprovides: monitoring and alert resolution for servers, clients, applications,hardware, and network devices; software distribution; update management;and software and hardware inventory.

Note The Exchange 2010 SP1 version of the Exchange 2010 Management Pack includes a

number of improvements, including cross-premises mail flow monitoring and reporting; this

enables you to use mail flow monitoring and reporting features for Exchange Online. For

further information about additional changes in the Management Pack, see the Microsoft

TechNet website: http://blogs.technet.com/b/kevinholman/archive/2011/04/07

/exchange-2010-sp1-management-pack-ships-version-14-02-0071-0.aspx.

You should consider the cost that monitoring events incurs. The cost that is incurred to monitor systems is

an investment in ensuring that your systems continue to run effectively and efficiently. You can measure

costs by using several metrics, including:

• Time allocated to personnel to perform monitoring tasks.

• Money invested in monitoring systems.

An alternative view is to consider the cost of not monitoring your systems by asking the following

questions:

• What is the monetary cost of reduced user productivity for your organization?

• What is the cost of system outage that is caused by not monitoring systems?

• What is the cost of a reactive approach to troubleshooting?

By using automated systems, you can monitor servers proactively, and possibly reduce the overall number

of staff who are required to perform monitoring. By using tools such as System Center Operations

Manager 2010, you can automatically monitor and fix certain server issues.

http://blogs.technet.com/b/kevinholman/archive/2011/04/07/exchange-2010-sp1-management-pack-ships-version-14-02-0071-0.aspx







By providing an IT infrastructure that automatically responds to events, you create a server infrastructure

that is flexible and dynamic. Windows Server 2008 enables dynamic system responses through Task

Manager, other tools such as System Center Operations Manager 2010, and third-party offerings.

Since Exchange Server 2010 is complex, there are a number of aspects that you need to monitor.

Primarily, you should gather and monitor metrics from the processor, memory, disk, and the Exchange

services. You can monitor additional information depending on the Exchange Server roles that have beeninstalled.




Planning Performance Monitoring for Mailbox Servers

The maximum level of performance for an Exchange Server is determined by the component in the server

that performs least well; in other words, the server bottleneck. Each of the server roles makes different

demands on the operating system and installed hardware, and it is therefore important to consider each

role separately.

When collecting performance data about Mailbox servers, much of the focus is around disk response time,

and how quickly the server responds to requests. The average response time for reading data should be

under 20 milliseconds (ms), and the average write response time should be less than 100 ms. Another

indicator that the disk system is not keeping up with demand is when the disk queue length starts togrow. All of these indicators may require that you purchase additional or faster disks, or modify the disk

configuration.

There are many Mailbox server performance counters that you may find beneficial to trend, depending on

your messaging environment. However, the following counters are crucial, and are a good place to begin

when collecting performance data for the Mailbox server.

Logical Disk

Logical Disk counters determine whether the disk performance is meeting demands. As disk latency

increases, database Read and Write operations take more time.




Monitor the following performance counters for Mailbox server logical disks.

Group Counter Description Expected value

LogicalDisk

Avg. Disksec/Read

Shows the average time forreading data from the disk.

On average, should be below 20 ms at alltimes.

Avg. Disksec/Write

Shows the average time forwriting data to the disk.


Avg. Disksec/Transfer

Shows the average numberof bytes transferred to orfrom the disk during Reador Write operations.

Should be below 20 ms on average, andspikes should not be higher than 50 ms.

MSExchangeIS Mailbox and MSExchangeIS Public

When messages are being queued for submission to the local Hub Transport server, it may indicate a

problem with connectivity to the transport server.

Group Counter Description Expected valueMSExchangeISMailbox andMSExchangeISPublic

MessagesQueued forSubmission

Shows the currentnumber of submittedmessages that are notyet processed bytransport.

Should be below 50 at all times, and not besustained for more than 15 minutes.Otherwise, this counter may indicateconnectivity issues with the transport servers,or that backpressure is occurring.

MSExchangeIS

The Client Access and Transport servers use remote procedure call (RPC) to communicate with Mailbox

servers. Therefore, it is important to monitor the response time for RPC requests to ensure that the

Mailbox server responds quickly enough to support the load.


MSExchangeIS RPCRequests

Shows the overall RPCrequests that arecurrently executingwithin the informationstore process.

Should be below 70 at all times.

RPCAveragedLatency

Shows the RPC latency(in ms) averaged for alloperations in the last1,024 packets.

Should not be higher than 25 ms onaverage.

RPC

Operations /sec

Shows the current

number of RPCoperations occurring persecond.

Should closely correspond to historical

baselines. Values much higher thanexpected indicate that the workload haschanged, while values much lower thanexpected indicate a bottleneck that ispreventing client requests from reachingthe server.




(continued )


MSExchangeIS RPC Num.SlowPackets

Shows the number ofRPC packets in the past1,024 packets that have

latencies longer than 2seconds.

Should be less than 1 on average, andshould be less than 3 at all times.




Planning Performance Monitoring for Transport Servers

The transport servers store message queue information to disk. The average response time for reading

data should be less than 20 ms, and the average write response time should be less than 100 ms. Another

indicator that the disk system is not keeping up with demand is when the disk queue length starts to

grow. All of these may require you to purchase additional or faster disks, or modify the disk configuration.

Logical Disk

Logical Disk counters determine whether disk performance is meeting demands. As disk latency increases,

database Read and Write operations take more time.Monitor the following performance counters for transport server logical disks.


LogicalDisk Avg. Disksec/Read



Avg. Disksec/Write


On average, should be below 100 ms atall times.

Avg. DiskQueue Length

Shows the number ofmessages in the poisonmessage 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.


MSExchangeDatabase==>Instances

LogGenerationCheckpointDepth

Shows the amount of work (in countof log files) that needs to be redoneor undone to the database file(s) if aprocess crashes.

Should be less than 1,000 at alltimes.

Versionbucketsallocated

Shows the total number of allocatedversion buckets. Shows the defaultbackpressure values as listed in theedgetransport.exe.config file.

Should be less than 200 at alltimes.

Log RecordStalls/sec

Shows the number of log records thatcannot be added to the log buffersper-second, because they are full. Ifthis counter is non-zero most of the

time, then the log buffer size may bea bottleneck.

Should be less than 10 persecond on average, and spikesshould not be greater than 100per second.

MSExchange Transport Queues

In addition to the transport server databases, you should also monitor the transport server queues to

ensure email messages are being delivered.


MSExchangeTransportQueues

Aggregate DeliveryQueue Length (AllQueues)

Shows the number of messagesqueued for delivery in all queues.

Should be less than5,000.

Active RemoteDelivery QueueLength

Shows the number of messages in theactive remote delivery queues.

Should be less than 250at all times.

Active MailboxDelivery QueueLength

Shows the number of messages in theactive mailbox queues.


Retry MailboxDelivery QueueLength

Shows the number of messages in aretry state that are attempting todeliver a message to a remotemailbox.


Unreachable Queue

Length

Shows the number of messages in the

Unreachable queue.

Should not exceed 100.

Largest DeliveryQueue Length

Shows the number of messages in thelargest delivery queues.

Should be less than 200.

Poison QueueLength

Shows the number of messages in thepoison message queue. Poisonmessages are messages that weredetected as harmful. These messagesoften cause a Transport service failure.





Planning Performance Monitoring for Client Access Servers

The Client Access server role performs many of the key client connectivity functions for Exchange Server

clients. Disk performance is important for determining overall server health. Additionally, you should

monitor the response time for services used by Client Access servers to ensure proper performance.

Logical Disk

Logical Disk counters determine whether the disk performance is meeting demands. As disk latency

creases, database Read and Write operations take more time.Monitor the following performance counters

for the Client Access server logical disk.Group Counter Description Expected value

LogicalDisk Avg. Disksec/Read


Should be below 20 ms onaverage.

Avg. Disksec/Write


Should be below 100 ms onaverage.

ASP.NET Services and Applications

Microsoft Office Outlook® Web App and Exchange Web Services rely heavily on the Microsoft .NET

Framework and Microsoft ASP.NET files, which are read, processed, and rendered for the end users.

Monitoring the response time and the number of times the application has had to restart can help youverify the overall health of the services.




The following table lists the counters related to ASP.NET and ASP.NET applications.


ASP.NET ApplicationRestarts

Shows the number of times theapplication has been restarted during theWeb server's lifetime.

Should be a low value.

Worker ProcessRestarts

Shows the number of times a workerprocess has restarted on the computer.

Should be a low value.

RequestsCurrent

Shows the current number of requests—including those that are queued—currently executing, or waiting to bewritten to the client. Under the ASP.NETprocess model, when this counter exceedsthe request QueueLimit defined in theprocess model configuration section,ASP.NET begins rejecting requests. Themaximum value is 5,000. The serverreturns a 503 error if the counter exceeds

this value.

Should be less than5,000 at all times.

Request WaitTime

Shows how long (in ms) the most recentrequest was waiting in the queue.

Should be less than1,000 ms at all times.

ASP.NETApplications

Requests inApplicationQueue

Shows the number of requests in theapplication request queue. The maximumvalue is 5,000. The server returns a 503error if the counter exceeds this value.

Should be less than5,000 at all times.

MSExchange Web Services

Outlook Web App, the Outlook Anywhere Proxy, Microsoft Exchange ActiveSync®, offline Address book

downloads, and the Availability Service response times are also valuable metrics to monitor.


MSExchangeOWA

Average ResponseTime

Shows the average time (inms) that elapsed for therequest. Used to determinethe latency that a client isexperiencing.

Should be less than 100 ms atall times. Higher values mayindicate high user load, orhigher-than-normal CPU time.

Average SearchTime

Shows the average time (inms) that elapsed whilewaiting for a search tocomplete.

Should be less than 100 ms atall times.

RPC/HTTPProxy

Number of failedback endconnectionattempts persecond

Shows the rate at which theRPC proxy attempts fail toestablish a connection to aback end server.





(continued )


MSExchangeActiveSync

Average RequestTime

Shows the average time thatelapsed while waiting for arequest to complete.

Determines the rate at whichthe Availability Servicerequests are occurring.

Varies by devices, carrier, orconfiguration. You must use abaseline to set this threshold.

MSExchangeFS:OAB

Download TaskQueued

Shows a value of 1 if the taskis queued for execution,otherwise shows 0.

Should be 0 at all times. Valuesgreater than 0 indicate a failureto copy offline address bookdata files from Mailbox servers.




Planning Message Tracking and Logging for Transport Servers

Exchange Server Hub Transport and Edge Transport servers generate transport logs, which provide useful

information about messages in transit through your messaging pipeline. You can configure your transport

servers to generate logs that relate to:

• Connectivity . These logs record the connection activity of outbound message queues. Specifically,

they track the connection activity from the sending queue to the destination Mailbox server, smart

host, or domain. The default maximum log file size is 10 megabytes (MB) and circular logging is

selected by default. Connectivity logging is disabled by default.

• Protocols. These logs record Simple Mail Transfer Protocol (SMTP) conversations between email

servers. In Exchange Server, these conversations occur at the servers hosting Send or Receive

connectors. As with connectivity logging, the default maximum log file size is 10 MB, and circular

logging is selected by default. Protocol logging is disabled by default.

• Message tracking. These logs provide a detailed log of all message activity as messages flow between

the Hub Transport and Edge Transport servers, and between the transport servers and the Mailbox

server role. Message tracking is enabled by default. Circular logging is also enabled by default, and

the maximum log file size defaults to 10 MB.

• Agent activity . These logs record the actions performed by specific anti-spam agents on the transport

servers. The following agents can write to the log:

•

Connection Filter agent

• Content Filter agent

• Edge Rules agent

• Recipient Filter agent

• Sender Filter agent

• Sender ID agent




As with the other logs, the default maximum log file size is 10 MB, and circular logging is enabled.

Agent logging is also enabled by default.

• Routing tables. These logs record a snapshot of the Exchange Server routing tables on a periodic

basis. The default log file size is 50 MB. The routing log is updated when the following events occur:

• A routing configuration change is detected.

• The time interval specified by the RoutingConfigReloadInterval parameter in the

EdgeTransport.exe.config has passed.

• The Microsoft Exchange Transport service is started.




Planning How to Monitor Baselines and Trend Analysis

You should give careful consideration to the value of performance data to ensure that it reflects the real

server environment. Additionally, you should consider performance analysis in addition to business plans.

By analyzing performance trends, you can predict when existing capacity is likely to be exhausted. You

should review historical analysis with consideration to your business, and use this to determine when

additional capacity is required. Some peaks are associated with one-time activities, such as very large

orders. Other peaks occur on a regular basis—such as a monthly payroll—and these peaks may require

increased capacity to meet increasing numbers of employees.

Planning for future server capacity is a requirement for all organizations. Business planning often requires

additional server capacity to meet targets. By aligning your IT strategy with the strategy of the business,

you can support the business objectives.

The introduction of new services and applications—such as the deployment of Exchange Server 2010—

can affect the performance of your IT infrastructure. These services may receive dedicated hardware,

although they often use the same local area network (LAN) and wide area network (WAN) network

infrastructure.

Planning for future capacity should include all hardware components, and how the new Exchange Servers

and related services and applications affect the existing infrastructure. Factors such as power, cooling, and

rack space are often overlooked during initial exercises to plan capacity expansion. You should consider

how your infrastructure can scale up and scale out to support an increased workload.

Tasks such as upgrading to Exchange Server 2010 and updating operating systems may affect your servers

and network. It is not unknown for an update to cause a problem with an application. Careful

performance monitoring before and after you apply updates can help you identify problems.

Expanding business requires you to provide support for more users. You should consider business

requirements when you purchase hardware. This consideration will ensure that you can meet future

business requirements by increasing the number of servers, or by adding capacity to existing hardware.




Capacity requirements include:

• More servers.

• Additional hardware.

• Reducing application loads.

•

Reducing users.

To determine which thresholds denote an existing problem, set a monitoring baseline by reviewing

monitoring data over a full business cycle. Business cycles vary for each company, and your cycle should

include both busy and slow periods. For some businesses, busy periods might correlate with the end-of-

month accounting-close processes, or periods with notably high sales figures. Gathering a broad data set

will provide sufficient data to determine the appropriate operating thresholds.

To use the collected performance data:

1.

Create a monitoring baseline by averaging performance metrics from a properly operating system:

• Monitor performance for a full business cycle.

•

Note any peaks or troughs in the data.2. Set warning-level and error-level thresholds.

3. Review growth trends regularly to:

• Adjust thresholds.

• Adjust server configurations.

It is important that you review your thresholds periodically, so you can adjust the servers—or the

thresholds themselves—to ensure proper monitoring.




Lesson 2

Planning Exchange Server Troubleshooting

Even in a well-maintained Exchange Server organization, problems can arise, which you must identify and

repair. Although general troubleshooting guidelines exist, often, experience and an analytical approach

provide the best tools for successfully discovering the problem’s source, and then fixing it.


• Describe Windows Server tools that can help you perform troubleshooting tasks.

• Describe the Exchange Server tools that can help you perform troubleshooting tasks.

• Develop a message delivery troubleshooting plan.

• Develop a Client Access server troubleshooting plan.

• Develop a mailbox database troubleshooting plan.




Windows Server Tools

You can use many other tools—in addition to the Microsoft Management Console (MMC) snap-ins, the

Exchange Management Console, the Exchange Management Shell, and Active Directory® Users and

Computers—to manage and troubleshoot an Exchange Server 2010 organization.

The following table lists and describes additional Exchange Server 2010 troubleshooting tools.

Tool name Description

ADSI Edit

(adsiedit.msc)

Use for low-level Active Directory Domain Services (AD DS) and Active

Directory editing. Install with the Remote Server Administration Tools.

DNS Resolver (DNSDiag)

(Dnsdiag.exe)

Use to troubleshoot Domain Name System (DNS) issues. The toolsimulates the SMTP service's internal code path, and prints diagnosticmessages that indicate how the DNS resolution is proceeding.

DSACLS

(dsacls.exe)

Use this command-line tool to query and change permissions andsecurity attributes of AD DS objects.

Error Code Look-up

(Err.exe)

Use to determine error values from decimal and hexadecimal errorcodes in Windows® products. This is a downloadable tool.

Event Viewer

(eventvwr.msc)

Use this MMC snap-in to view logged events such as errors and

warnings.

LDP

(ldp.exe)

Use to perform Lightweight Directory Access Protocol (LDAP) searchesagainst the Active Directory directory service or AD DS for specificinformation–given search criteria. This tool also enables you to querydata that would otherwise not be visible through the administrativetools included in Windows Server and Exchange Server.




(continued )


Microsoft Error Reporting Exchange Server 2010 uses Windows Error Reporting to collect crashdumps and debug information. It enables administrators to track andaddress errors related to the Windows operating system, Windows

components, and applications such as Exchange Server 2010. Thisservice gives administrators and users the opportunity to send dataabout errors to Microsoft, and to receive information about errors.Administrators can use Microsoft Error Reporting to address customerproblems in a timely manner, and to help improve the quality ofMicrosoft products.

Process Monitor

(procmon.exe)

Use to monitor real-time file system, registry, and process or threadactivity.




Exchange Server Tools

Over the years, a number of useful Exchange Server troubleshooting tools have been introduced. Each

tool has a specific use, but they all use detailed product knowledge and information about your

environment to suggest potential problem solutions.

• Exchange Best Practices Analyzer (ExBPA). This is an invaluable tool for identifying potential issues

based on deviations from best practices, and for gathering a great deal of information about the

Exchange Server organization, which you can then use for reference and for troubleshooting

problems.

• Performance Troubleshooter . This tool helps you locate and identify performance-related issues that

could affect Exchange servers. You diagnose problems by selecting the symptoms observed. Based on

the symptoms, the tool walks you through the correct troubleshooting path. Performance

Troubleshooter identifies possible bottlenecks, and suggests corrective actions.

• The Exchange Mail Flow Troubleshooter . This tool helps provide easy access to various data sources

that are required to troubleshoot problems with mail flow, such as non-delivery reports (NDRs),

queue backups, and slow deliveries. The tool then automatically diagnoses the retrieved data,

presents an analysis of the possible root causes, and suggests corrective actions.




Other tools—such as the Performance and Reliability Monitor—check the health of the Exchange Server

processes. You can use the Queue Viewer to view the message status in transport queues. Tools such as

Network Monitor and Telnet can help you troubleshoot network issues and message tracking, and the

Routing Log Viewer can help you troubleshoot message delivery issues. The following table lists additional

tools.


Exchange Server Database Utilities

(Eseutil.exe)

Use this tool to perform offline database procedures, such asdefragmentation and integrity checking.

Exchange Server Jetstress Use this tool as a benchmarking tool to validate your storagesubsystem.

Exchange Profile Analyzer

(epa.msi)

Use this tool to collect estimated statistical information from asingle mailbox store, or from across an entire Exchange Serverorganization. Use the collected data for tasks such as analyzingthe performance and health of a server that has mailboxes.

Exchange Store TreeView Control

(Extreeview.ocx)

Use this tool to display a hierarchical list of node objects that

correspond to folders in the Exchange Server store.

Information Store Integrity Checker

(isinteg.exe)

Use this tool to find and remove errors in the public and privateinformation store databases. This tool is intended for disasterrecovery situations, and not for routine maintenance.

Inter-Organization Replication

(exscfg.exe; exssrv.exe)

Use this tool to replicate public folder information (includingfree/busy information) between Exchange Server organizations.Can be used between forests.

Exchange Load Generator

(Loadgen.msi)

Use this tool as a benchmarking tool to test the response ofservers to mail loads.

Microsoft Baseline Security Analyzer

(MBSA)GUI: MBSA.exe

Command line: mbsacli.exe

Use this tool to scan local or remote systems for common

configuration errors, and to verify security best practices.

RPC Ping utility

(rpings.exe and rpingc.exe)

Use this tool to confirm RPC connectivity between the computerthat is running Exchange Server, and any of the clientworkstations on the network.

Telnet

(telnet.exe)

Establish a direct connection to an SMTP connector on anExchange Server, in order to verify connectivity and inboundmail-flow.




Discussion: Developing a Message Delivery Troubleshooting Plan

You can apply standard troubleshooting techniques to the unique problems that can occur with Hub and

Edge Transport servers. Use tools such as the Queue Viewer, message tracking system, and Mail Flow

Troubleshooter to identify the problem, and then work toward a resolution.

Discussion Question

Question: Users are reporting non-deliverable and slow-to-deliver outbound email. What

process can you use to troubleshoot the problem?




Discussion: Developing a Client Access Troubleshooting Plan

You can apply standard troubleshooting techniques to the unique problems that can occur with Client

Access servers. Use tools such as the Exchange Best Practices Analyzer and the Event Viewer to identify the

problem and work toward a resolution.

Discussion Question

Question: Office Outlook users can no longer connect to the system. What process can you use

to troubleshoot the problem?




Discussion: Developing a Mailbox Database Troubleshooting Plan

You can apply standard troubleshooting techniques to the unique problems that can occur with Mailbox

servers. Use tools such as the Database Troubleshooter and the Event Viewer to identify the problem and

work toward a resolution.

Discussion Question

Question: A database has gone offline. What process can you use to troubleshoot the problem?




Lab: Planning Exchange Server 2010 Monitoring andTroubleshooting

Lab Setup



2. Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, 10233B-VAN-EX2, and the 10233B-VAN-EX3

virtual machines are running.



Lab Scenario


locations. You have been tasked with creating a performance baseline for the new Exchange Server 2010

messaging system that your colleagues are about to deploy.




Exercise 1: Establishing a Baseline for Performance

Scenario

You have created a test environment that is representative of the production messaging environment.

You must use the Load Generator to simulate the expected load.


1. Create a User Defined data collector set.

2. Configure Load Generator with suitable values to simulate the required load.

3.

Gather performance data, and analyze results.

Task 1: Create a User Defined data collector set

1. On VAN-EX1, open Exchange Management Console, and then load the Performance Monitor from

the Toolbox.

2. Create a User Defined data collector set with the following properties:

• Name: Baseline

• Create manually (Advanced)

• Data type: Performance counter

• Counters:

• Memory

• MSExchangeIS

• MSExchangeIS Mailbox

• MSExchangeTransport Queues

• MSExchangeTransport SmtpReceive

• MSExchangeTransport SmtpSend

• Physical Disk

• Processor

• Server

• System

• Sample interval: 1

• Data save location: default

3. Save, but do not start the data collector set.

Task 2: Configure Load Generator with suitable values to simulate the required load

1. Switch to the VAN-DC1 computer.

2. Open Exchange Load Generator 2010 by clicking the Start menu, pointing to All Programs, and then

clicking the Microsoft Exchange folder.




3. Start a new test using the following detailed steps:

a.

In Microsoft Exchange Load Generator 2010, click Start a new test.

b.

Click Create a new test configuration, and then click Continue.

c. On the Specify test settings page, under Define the total length of the simulation, in the

Hours box, type 0.d. In the Minutes box, type 10.

Note Do not configure the Define the length of a ‘simulation day’ value.

e. In the Directory Access Password box, type Pa$$w0rd.

f.

In the Mailbox Account Master Password box, type Pa$$w0rd, and then click Continue with

recipient management.

g.

On the User settings page, in the text box, type 12, and then click Distribute users evenly

across databases.

h.

Click Continue.i.

On the Advanced recipient settings page, select the following check boxes.

• Use distribution lists

• Use dynamic distribution lists

• Create one for all the users

• Create one per mailbox database

• Use contacts

j. In the Number of contact box, type 20 and then click Continue.

k.

On the Specify test user groups page, click the PLUS SIGN (+).

l. In the resulting item, in the Client Type list, click Outlook 2007 Online.

m.

On the Specify test user groups page, click the PLUS SIGN(+).

n.

In the resulting item, in the Client Type list, click Outlook 2007 Cached, and in the Action

Profile list, click Heavy.

o.

Click Continue, and on the Remote configurations page, click Continue.

p. On the Configuration summary page, click Save the configuration file as.

q. In the Save As dialog box, in the File name box, type Baseline, and then click Save.

r.

In the Configuration Saved dialog box, click OK .

s.

Click Skip initialization phase and run the simulation immediately.

4. Switch to VAN-EX1, and switch to Performance Monitor.

5.

Start the Baseline data collector set, and switch back to VAN-DC1. Once the simulation has

completed, switch back to VAN-EX1.

Note This simulation runs for 10 minutes.




Task 3: Gather performance data, and analyze results

1.

On VAN-EX1, switch to Performance Monitor.

2.

Stop the Baseline data collector set.

3. Click System Monitor. Click the red X in the toolbar repeatedly to remove all counters from the

display.4. Press CTRL+L.

5. Click Log files, and then select the DataCollector01.blg log located in the Admin > Baseline > xxxx-

000001 folder.

6. From the Data tab, add the following counters:

Performance object Counter

Memory Pages/sec

MSExchangeIS RPC Requests

MSExchangeIS User Count

MSExchangeIS Mailbox Local delivery rate

MSExchangeIS Mailbox Messages Delivered/sec

MSExchangeIS Mailbox Messages Queued For Submission

MSExchangeIS Mailbox Messages Sent/sec

MSExchangeTransport Queues Active Remote Delivery Queue Length

MSExchangeTransport Queues Retry Remote Delivery Queue Length

MSExchangeTransport Queues Submission Queue Length

MSExchangeTransport SmtpReceive Messages Received/sec

MSExchangeTransport SmtpSend Messages Sent/sec

Physical Disk % Disk Time

Physical Disk Avg. Disk Queue length

Processor % Processor Time

Server Pool Nonpaged Failures

Server Work Item Shortages

System Processor Queue Length

Note If Performance Monitor experiences problems, close and restart it. Then continue

from step 3.




7. Click OK twice, and then view the data as a report.

8.

Complete the following table.

Counter Average

Memory – Pages/sec

MSExchangeIS - User Count

MSExchangeIS - RPC Requests

MSExchangeIS Mailbox - Local delivery rate

MSExchangeIS Mailbox - Messages Delivered/sec

MSExchangeIS Mailbox - Messages Queued For Submission

MSExchangeIS Mailbox - Messages Sent/sec

MSExchangeTransport Queues - Active Remote Delivery QueueLength

MSExchangeTransport Queues - Retry Remote Delivery QueueLength

MSExchangeTransport Queues - Submission Queue Length

MSExchangeTransport SmtpReceive - Messages Received/sec

MSExchangeTransport SmtpSend – Messages Sent/sec

Physical Disk - % Disk Time

Physical Disk - Avg. Disk Queue length

Processor - % Processor Time

Server - Pool Nonpaged Failures

Server - Work Item Shortages

System - Processor Queue Length

Note Do not worry that some values are zero; this is a simulation.

Question: Do any counters indicate a bottleneck?

Results: After this exercise, you should have created an Exchange Server performance baseline.




Exercise 2: Measuring the Production System Performance underAdditional Load

Scenario

The server deployment is complete, but users are now complaining of reduced performance. You must

monitor the messaging system, and then compare the newly recorded results with the baseline that you

previously established.

Note As this is a training exercise, you will use Load Generator to simulate the load.


1.

Generate additional load with Load Generator to simulate the environment of heavier than planned

for usage.

2. Compare the data with the baseline data.

Task 1: Generate additional load with Load Generator to simulate the environment

of heavier than planned for usage

1. Switch to VAN-DC1.

2.

In Microsoft Exchange Load Generator, click Start a new test.

3. Start a new test using the following steps:

a. Click Use the following saved configuration file, and then click Browse.

b.

In the Please select a configuration file dialog box, double-click Baseline.xml, and then click

Continue.

c. On the Specify test settings page, click Continue with recipient management.

d.

On the User settings page, in the text box, type 20, and then click Distribute users evenly

across databases.

e.

Click Continue.

f. On the Advanced recipient settings page, select the following check boxes.




• Create one per server


•

Use contacts

g. In the Number of contact box, type 50 and then click Continue.

h.


i.

In the resulting item, in the Client Type list, click Outlook 2007 Online, and in the Action

Profile list, click Heavy.

j.





k. In the resulting item, in the Client Type list, click Owa2010Module, and in the Action Profile

list, accept the defaults.

l. Click Continue, and on the Remote configurations page, click Continue.

m.

On the Configuration summary page, click Save the configuration file as.

n.

In the Save As dialog box, in the File name box, type Adatum, and then click Save.o. In the Configuration Saved dialog box, click OK .

p. Click Skip initialization phase and run the simulation immediately.

4.

Switch to VAN-EX1, and switch to Performance Monitor.

5. Start the Baseline data collector set, and then switch back to VAN-DC1.

6. When the simulation completes, switch to VAN-EX1.

Task 2: Compare the data with the baseline data

1.

In Performance Monitor, stop the Baseline data collector set.

2.

In the right pane, right-click, and then click Properties.

3.

In the Performance Monitor Properties dialog box, click the Source tab, and then click Remove.

4.

Click Log files, and then click Add.

5. In the Select Log File dialog box, click Up One Level, double-click the folder ending in 000002,

double-click DataCollector01.blg, and then click OK .

6. View the counter values, and then complete the following table.

Counter Average






MSExchangeIS Mailbox - Messages Queued ForSubmission


MSExchangeTransport Queues - Active Remote DeliveryQueue Length

MSExchangeTransport Queues - Retry Remote DeliveryQueue Length

MSExchangeTransport Queues - Submission QueueLength

MSExchangeTransport SmtpReceive - MessagesReceived/sec




Counter Average

MSExchangeTransport SmtpSend - Messages Sent/sec







Question: How do the values compare to the baseline data?

Results: After this exercise, you should have determined which server resources are likely to become

bottlenecked if server load continues to increase.



following steps:

1.




4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3.

Note No virtual machines are required for the next lab.





Review Questions

1. What is an advantage of using automated monitoring systems such as System Center Operations

Manager 2010?

2.

In terms of monitoring Mailbox server performance, what is the most likely performance bottleneck

you will encounter?

3.

Which components’ responsiveness can you monitor to ensure adequate performance of Outlook

Web App clients?

4.

Which transport logs should you enable in order to troubleshoot message flow?

5. Why is it important to analyze performance trends?






11-1

Module 11

Upgrading to Microsoft® Exchange Server 2010

Contents:

Lesson 1: Overview of Upgrading to Exchange Server 2010 11-3





Lab: Upgrading to Exchange Server 2010 11-41



11-2 Upgrading to Microsoft® Exchange Server 2010

Module Overview

Microsoft® Exchange Server is a popular messaging system, and many organizations have selected it as

the foundation for their messaging infrastructure.

When you decide to implement Exchange Server 2010, if you already have a previous Exchange Server

version installed in your organization, then you must plan the upgrade from your existing version of

Exchange Server. Depending on your current Exchange Server version, you can perform a coexistence

upgrade to Exchange Server 2010 by deploying Exchange Server 2010 servers into an existing Exchange

organization; for convenience, we shall refer to this method as an upgrade.

Alternatively, you might choose to deploy the new Exchange Server 2010 organization in parallel to your

existing Exchange Server organization; we shall refer to this method as a migration. To avoid disruption to

users, it is important that you understand the implications of choosing between a coexistence upgrade,

and a side-by-side migration.

This module provides an overview of the options that organizations have when choosing to implement

Exchange Server 2010, and provides details on how to upgrade an existing Microsoft Exchange Server

2003 or Exchange Server 2007 organization to Exchange Server 2010.


• Describe the general Exchange Server 2010 upgrade scenarios and strategies.

•

Plan the upgrade from Exchange Server 2003 to Exchange Server 2010.

• Plan the upgrade from Exchange Server 2007 to Exchange Server 2010.




Lesson 1

Overview of Upgrading to Exchange Server 2010

While you perform the upgrade to Exchange Server 2010, users should still be able to send and receive

email, and perform scheduling tasks with the existing messaging system with minimal disruption.

Consequently, it is important to select the appropriate upgrade strategy to minimize user disruption.


• Describe the upgrade scenarios that are supported in Exchange Server 2010.

• Select a suitable upgrade strategy.

• Describe the components of coexistence and upgrade strategies.

• Plan a multisite upgrade.

• Determine how to support deprecated features in Exchange Server 2010.




Supported Upgrade Scenarios

Key Points

Note It is important to understand that the term upgrade refers to the upgrade of your

Exchange Server organization, rather than specific servers within your organization; you

cannot perform an upgrade of an individual Exchange server to Exchange Server 2010. You

can perform an upgrade of your Exchange organization by deploying new Exchange Server

2010 servers, and then migrating mailboxes and services to them. For brevity, we shall refer

to this process as an upgrade.

Upgrading an Exchange Server organization to Exchange Server 2010 is usually the easiest option.

Therefore, most organizations choose this path for upgrading their existing Exchange Server deployments;

however, this option has several prerequisites.

Active Directory Domain Services Requirements

To upgrade from a previous Exchange Server version to Exchange Server 2010, you must meet the

following Active Directory® Domain Services (AD DS) requirements:

• Your schema master must be running the Windows Server® 2003 operating system with Service Pack

1 (SP1) or newer.

•

You must deploy at least one global catalog server in each site that is running Windows Server 2003with SP1 or newer.

• You must have configured your AD DS forest to be at least at the Windows Server 2003 forest-

functional level or higher.

• You must deploy at least one domain controller and one global catalog server with a writeable AD DS

copy in each Active Directory site; Exchange Server 2010 cannot use read-only domain controllers

(RODCs) or read-only global catalog servers running Windows Server 2008.




Supported Upgrade Deployments

When you upgrade an existing Exchange Server organization to Exchange Server 2010, it is important to

know which upgrade strategies are supported. The following table identifies some common upgrade

strategies.

Exchange Server version

Exchange

organizationupgrade Comments

Exchange 2000 Server Not supported Although an upgrade is not supported, you can use amigration strategy to transition to ExchangeServer 2010. Alternately, you can upgrade the Exchange2000 Server organization completely to ExchangeServer 2003 or Exchange Server 2007, and then performan in-place upgrade to Exchange Server 2010.

Exchange Server 2003with SP2 or newer

Supported Before you install Exchange Server 2010 servers into anexisting Exchange Server 2003 organization, you mustconfigure the organization to run in native mode.

Exchange Server 2007with SP2 or newer Supported When upgrading from Exchange Server 2007, you mustupgrade all of your organization’s Exchange Server2007 servers to SP2.

Mixed ExchangeServer 2007and ExchangeServer 2003 organization

Supported When you are ready to upgrade your mixed modeenvironment, upgrade each Active Directory siteindividually. If you have Active Directory sites with onlyExchange 2007 or Exchange 2003 in them, follow theinstructions for upgrading from that version for thatActive Directory site. For example, if you have ExchangeServer 2007 in Active Directory site A, then follow theupgrade instructions for Exchange Server 2007. If youhave Exchange Server 2003 installed in Active Directorysite B, then follow the upgrade instructions for


After you deploy a new Exchange Server 2010 organization, you cannot add servers running earlier

Exchange Server versions to the organization; Exchange Server 2010 does not support the addition of

earlier Exchange Server versions to an Exchange organization that includes only Exchange Server 2010

servers.




Choosing an Upgrade Strategy

Key Points

Exchange Server 2010 supports several different options for upgrading from other messaging systems.

Exchange Server Upgrade Terminology

The following terminology describes the various upgrade scenarios:

• Upgrade. In this scenario, you upgrade an existing Exchange Server organization to Exchange

Server 2010. To perform the upgrade, install Exchange Server 2010 servers into an existing Exchange

Server 2003 or Exchange Server 2007 organization, and then move data and functionality from the

existing Exchange servers to the new Exchange Server 2010 servers. This is the easiest and least

disruptive scenario for integrating Exchange Server-based messaging systems, because the different

Exchange Server versions share configuration and recipient information automatically.

• Migration. In this scenario, you upgrade from either a non-Exchange Server messaging system or

from an existing Exchange Server organization, to a new Exchange Server 2010 organization, without

retaining any of the existing organization’s Exchange server configuration data. This is more complex

to configure, because by default, the two messaging systems share no information, and consequently

you must configure all connections between the systems.

Note You must deploy a second AD DS forest when you perform a migration from one

Exchange Server organization to another. Then migrate all user accounts to the secondforest.

• In-place upgrade. In this scenario, you upgrade a single computer that is running a previous

Exchange Server version to a newer Exchange Server version. Exchange Server 2010 does not support

in-place upgrades.




Choosing a Single-Phase or Multiphase Upgrade

Once you have decided to perform an upgrade, you must select the appropriate upgrade strategy. You

can choose between several options. The selection you make depends upon your current environment,

your organization’s requirements for data migration, and your project timeline.

Your first choice when planning the upgrade is to decide whether to use a single-phase or multiphase

upgrade:

• Single-phase upgrade. In a single-phase upgrade, you replace your existing messaging system with

Exchange Server 2010, and move all required data and services to the new system. In a single-phase

upgrade, you do not need to plan for an extended period of coexistence between the two systems.

Typically, you perform this type of upgrade over a short period, perhaps a weekend. This enables you

to shut down the entire messaging system, and replace it with Exchange Server 2010, so that when

users return to work the new messaging system is operational. In this scenario, the period of

coexistence or interoperability is quite short.

While this upgrade is the fastest option, it also introduces a significant risk if the upgrade fails. This

scenario is feasible only for small organizations that must replace just a few servers, and there are only

a small number of users to migrate.• Multiphase upgrade with coexistence. In a multiphase upgrade, you upgrade one server or site at a

time to Exchange Server 2010. Because you spread this incremental upgrade over a longer period,

you decrease your 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.




Components of a Coexistence and Upgrade Strategy

Key Points

In most coexistence scenarios, you must ensure that users with mailboxes on both messaging systems

have access to the following:

• Public folder contents. If the organization stores important information in public folders, you may

need to replicate the public folder contents between the messaging systems.

• Email message flow. When you run two messaging systems, users must be able to send email to other

organizational users, and to and from users on the Internet. Message flow should be transparent tousers. Users do not need to know—nor should it matter—which messaging system contains the

recipient’s mailbox.

• Global address list (GAL). To simplify the process of sending messages between messaging systems,

you must ensure that you synchronize the GAL between messaging systems.

• Calendar information. To facilitate scheduling of meetings between the two messaging systems, you

must ensure that Free/Busy information replicates between the two messaging systems.

• Administration of the system. It is important that during the upgrade you can continue to administer

the Exchange Server organization.

If you implement an upgrade to Exchange Server 2010, the design of the upgrade process ensures that

these coexistence components are maintained throughout the coexistence.




Planning a Multisite Upgrade

Key Points

If your organization has multiple AD DS sites that contain Exchange servers, it is important to consider the

order in which you upgrade these sites.

When planning a multisite organization upgrade, remember that Exchange Server does not support the

upgrade of internal sites before you have upgraded Internet-facing sites; this is because Client Access

server-to-Client Access server proxying is only supported from Exchange Server 2010 to Exchange

Server 2007, and not the other way. Consequently, you must upgrade Internet-facing sites first.

Within the site, the recommended order in which you must upgrade the specific Exchange Server roles is

as follows:

1. Client Access

2. Hub Transport

3.

Mailbox

4. Unified Messaging

Once you have upgraded all the Internet-facing sites, you can begin to upgrade the internal AD DS sites.

You should upgrade the server roles in the same order as your Internet-facing sites.

Exchange Server 2003 does not support AD DS sites for message routing; instead, all ExchangeServer 2010 servers are added as members of a single routing group called Exchange Routing Group

(DWBGZMFD01QNBJR). The implications of this are explored in the following lesson.




Options for Supporting Deprecated Features

Key Points

Exchange Server 2010 does not implement certain features from earlier Exchange Server versions. It is

important to understand which features are affected, and to plan implementation of suitable alternatives

to these features.

The following Exchange Server 2003 features are not supported in Exchange Server 2010:

• Novell GroupWise connector. This connector is a component of Exchange Server 2003, and enables

you to implement messaging coexistence between Exchange and Novell GroupWise organizations.The connector provides mail flow connectivity, in addition to the ability to synchronize the two

directories. With directory synchronization in place, each GAL is updated with users from the other

organization. Exchange Server and Novell GroupWise users can send email to each other by selecting

the recipient from their address books. If you require this functionality, retain at least one Exchange

Server 2003 server.

• Network News Transfer Protocol. The Network News Transfer Protocol (NNTP) retrieves newsgroup

content. If you require NNTP functionality, retain at least one Exchange Server 2003 server.

• Microsoft Office Outlook® Mobile Access. The Microsoft Exchange ActiveSync® technology provides

much of this functionality.

• Inter-Organization Replication Tool. In Exchange Server 2003, this utility is made up of two programs:

the Exchange Server Replication Configuration utility (Exscfg.exe), and the Exchange Server

Replication Service (Exssrv.exe). You can use these programs to coordinate meetings, appointments,

and contact information between members of two different legacy Exchange organizations. Exchange

Server 2010 uses the Microsoft Federation Gateway to establish and maintain federation between

Exchange Server organizations, so that users can share availability information, calendaring data, and

contacts.




The following Exchange Server 2007 features are not supported in Exchange Server 2010:

• Single copy clusters (SCC), local continuous replication (LCR), cluster continuous replication (CCR) and

standby continuous replication (SCR). In Exchange Server 2007, these Mailbox features are used to

provide for high availability of storage groups. In Exchange Server 2010, they are replaced by

database availability groups (DAGs) and mailbox database copies.

•

Microsoft Transporter Suite for Lotus Domino. Microsoft Transporter Suite is a set of interoperability

and migration tools that migrate content from Lotus Domino servers to Exchange Server. The suite

contains a set of tools for Directory and Free/Busy interoperability between Lotus Domino and

Exchange Server 2007, and AD DS. In addition, the suite contains migration tools to help migrate

users, groups, personal address lists, mailboxes, personal mail archives, and applications from Lotus

Domino to AD DS, Exchange Server 2007, and Windows SharePoint® Services 3.0. If you require this

functionality, you must maintain an Exchange Server 2007 server in your Exchange organization.

• Programmatic access to Exchange by using Exchange OLE DB Provider (ExOLEDB), Web Distributed

Authoring and Versioning (WebDAV) or CDO for Exchange 2000 Server (CDOEX). Replace the

ExOLEDB, WebDAV or CODEX functionality with Exchange Web Services (EWS) or EWS-Managed

application programming interface (API). Alternatively, maintain an Exchange Server 2007 server in

your organization for mailboxes of applications that use these technologies.




Lesson 2

Planning the Upgrade from Exchange Server 2003 toExchange Server 2010

Many organizations still use Exchange Server 2003 for their messaging system, and they might not have

any plans of upgrading to Exchange Server 2007. Microsoft supports an upgrade from Exchange Server

2003 directly to Exchange Server 2010, specifically for these organizations. This lesson describes how to

upgrade an Exchange Server 2003 organization to Exchange Server 2010.


• Determine whether your Exchange Server 2003 organization is ready to upgrade to Exchange

Server 2010.

• Describe the process for installing Exchange Server 2010 in an Exchange Server 2003 organization.

• Design the Client Services coexistence.

• Design external access for Exchange Server 2003 client services.

• Design the Message Transport upgrade.

• Plan the upgrade of administrative roles.

•

Plan the removal of Exchange Server 2003.

• Troubleshoot the upgrade process.




Prerequisites for Installing Exchange Server 2010 in anExchange Server 2003 Organization

Key Points

Before you start the upgrade process, you must prepare AD DS for the Exchange Server 2010 deployment.

To do this, you must run Exchange Server 2010 setup using the /PrepareLegacyExchangePermissions

parameter and the /PrepareAD parameter. Additionally, your current infrastructure must meet the

following conditions:

• The schema master and at least one global catalog server in each site must be running Windows

Server 2003 with SP1 or newer.

• Both the domain and forest functional levels must be at least Windows Server 2003.

• Your Exchange Server 2003 servers must be running Exchange Server 2003 with a minimum of SP2.

• Your existing Exchange Server 2003 organization must be in native mode.

Changes Made by the PrepareLegacyExchangePermissions Setup Parameter

You must run the PrepareLegacyExchangePermissions setup parameter so that the Exchange

Server 2003 Recipient Update Service functions correctly after you update the Active Directory schema for

Exchange Server 2010. In Exchange Server 2003, the Recipient Update Service updates some mailbox

attributes—such as the proxy address—on mail-enabled user objects. It can do this because the computer

account for the server on which the Recipient Update Service runs is in the Exchange Enterprise Serversgroup.

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.




Changes Made by the PrepareAD Command

After running setup with the PrepareLegacyExchangePermissions parameter, you should run setup with

the PrepareAD command. This command makes the following changes to enable coexistence between

Exchange Server versions:

• Creates the Active Directory universal security group, ExchangeLegacyInterop. This group receives

permissions that allow the Exchange Server 2003 servers to send email to the Exchange Server 2010servers.

• Creates the Exchange Server 2010 administrative group, which is called Exchange Administrative

Group (FYDIBOHF23SPDLT).

• Creates the Exchange Server 2010 routing group, which is called Exchange Routing Group

(DWBGZMFD01QNBJR).

The PrepareAD command also extends the schema to include the Exchange Server 2010 schema objects

and attributes.




Process for Installing Exchange Server 2010 in an Exchange Server 2003Organization

Key Points

When deploying Exchange Server 2010 in a supported Exchange Server organization, you must follow a

specific process.

Installing Exchange Server 2010

If an organization has only a single Active Directory site, use the following process for deploying Exchange

Server 2010.

1. Install the Exchange Server 2010 Client Access server. After you install the Client Access server, you

should use this as the primary connection point for all client connections.

2. Install the Exchange Server 2010 Hub Transport server. When you install the Hub Transport server in

an Exchange Server 2003 environment, it prompts you for the name of an Exchange Server 2003

computer that will be the routing-group bridgehead server between the Exchange Server 2003

routing group, and the Exchange Server 2010 routing group. Exchange Server 2010 no longer uses

routing groups to manage message routing, but you install all Exchange Server 2010 servers in a

routing group for backwards compatibility.

3. Install the Exchange Server 2010 Mailbox servers. After the rest of the infrastructure is in place, you

can deploy the Exchange Server 2010 Mailbox servers, and start moving mailboxes and public folders

to the new servers.

Note If you deploy Exchange Server 2010 in a small or medium-size organization, and you

plan to deploy only one or two Exchange Server 2010 servers, you can perform a typical

installation and install simultaneously the Client Access server role, Hub Transport server

role, and the Mailbox server role.




4. Install Exchange Server 2010 Unified Messaging servers.

5.

For organizations with multiple sites, there are typically two types of Active Directory sites: Internet-

accessible sites, and non-Internet accessible sites. A single Exchange Server organization may have

one or more Internet-accessible sites. When upgrading Active Directory sites, you should upgrade

Internet-accessible sites before non-Internet accessible sites.




Designing Client Services Coexistence

Key Points

After you deploy the Exchange Server 2010 Client Access and Mailbox servers, the process that non-

Messaging Application Programming Interface (non-MAPI) clients use when accessing the user mailboxes

depends on the type of client you are using and the mailbox’s location.

Maintaining Free/Busy Information

Clients using Office Outlook 2003 require the system public folders to access the Free/Busy information,

while Office Outlook 2007 or newer clients can use the availability service on a Client Access server toaccess this information.

If your organization includes Office Outlook 2003 clients, you need to retain the SCHEDULE+ FREE BUSY

system public folder for these clients. When you install the first Exchange Server 2010 Mailbox server in an

organization that includes Exchange Server 2003 servers, you configure a public folder database on the

server. You then can replicate the SCHEDULE+ FREE BUSY system public folder to the Exchange

Server 2010 server.

Maintaining Access to the Offline Address Book

Another difference between Exchange Server 2003 and Exchange Server 2010 is the method that they use

to distribute the offline address book to Office Outlook 2007 clients. In Exchange Server 2003, a public

folder stores the offline address book, and clients must connect to the folder to download it.

Outlook 2007 clients connecting to an Exchange Server 2007 Client Access server use a web service to

download the offline address book.

In an Exchange Server 2003 organization, one of the Exchange servers performs daily updates of the

offline address book. When you deploy an Exchange Server 2010 Mailbox server in your organization, you

can use the Exchange Server 2010 management tools to move this role to a server running Exchange

Server 2010. You also need to configure the offline address book so that it is distributed through the

Exchange Web Service.




If your organization includes Outlook 2003 clients, you need to ensure that you create a replica on the

Exchange Server 2010 Mailbox server of the system folders for the offline address book.

Maintaining Public Folder Availability

When you install Exchange Server 2010, a public folder database is not created by default. If you are

maintaining public folders in Exchange Server 2010, you need to create public folder databases on

Exchange Server 2010 Mailbox servers and replicate the public folder contents to Exchange Server 2010.

Unless usage patterns have changed, in most cases you need to create a public folder database for

Exchange Server 2010 in each location that has a public folder database for Exchange Server 2003.

A common way to move public folders from Exchange Server 2003 to Exchange Server 2010 is by using

the MoveAllReplicates.ps1 script. If you use this script, you do not need to configure replication for each

individual public folder.

Users with an Exchange Server 2010 mailbox can access public folders on Exchange Server 2003. The

routing group connectors between Exchange Server 2010 and Exchange Server 2003 routing groups have

public folder referrals enabled by default. However, in the default referral configuration, Exchange

Server 2010 users are always directed to a public folder replica on Exchange Server 2010 over a replica on

Exchange Server 2003. If you want users to access a replica on Exchange Server 2003 that is physically

closer than replicas on Exchange Server 2010, you need to create a custom public folder referrals list on

the public folder database.

Exchange Server 2003 allows access to public folders by using Internet message access protocol (IMAP)

and NNTP clients. Exchange Server 2010 does not provide IMAP or NNTP access to public folders. You can

use only MAPI or Outlook Web App to access public folders on Exchange Server 2010. If you have users

who need to access public folders by using IMAP or NNTP, you need to maintain a replica of the public

folders on Exchange Server 2003.




Designing External Access for Exchange Server 2003 Client Services

Client Access servers provide Internet users with access to their mailboxes by using Outlook Web App,

ActiveSync, and Outlook Anywhere. It is important to understand how each of these methods behave

during the upgrade process to ensure that user access is not interrupted.

The first step in the upgrade process is to add one or more Exchange Server 2010 Client Access servers to

the site being upgraded. Clients accessing their mailbox from the Internet connect to the Exchange 2010

Client Access server and are then redirected or proxied to the appropriate Exchange 2003 server.

Outlook Web AccessTo support coexistence of Exchange Server 2010 Outlook Web App and Exchange Server 2003 Outlook

Web Access, you need to configure a legacy URL. When Exchange Server 2003 Outlook Web Access users

log on to the Exchange Server 2010 Client Access server, they are redirected to the legacy URL. In a small

organization with a single computer running Exchange Server 2003 and hosting mailboxes, the legacy

URL can point to that single computer.

Larger organizations with multiple computers running Exchange Server 2003 have a front-end server. The

front-end server proxies Outlook Web Access requests to the server hosting the user’s mailbox. This is

required because Outlook Web Access for a specific user can be accessed only on the server that is

hosting that user’s mailbox. In this scenario, the legacy URL points to the front-end server.

The process for implementing the legacy URL is as follows:

1.

Create a new DNS record for the legacy URL, such as legacy.contoso.com.

2. Configure a new certificate on the Exchange Server 2003 front-end server that has a subject matching

the new DNS record for the legacy URL.




3. Configure the Exchange2003URL value on the Exchange Server 2010 Client Access servers. The

parameter is the legacy URL, such as https://legacy.contoso.com/exchange.

4. Update your firewall rules or reverse proxy to direct requests for the original Outlook Web Access

requests to the Exchange Server 2010 Client Access server.

After this process is complete, users who access the original URL (http://mail.contoso.com/exchange)

are serviced by the Exchange Server 2010 Client Access server. The Exchange Server 2010 Client Access

server handles requests for users who have Exchange Server 2010 mailboxes, and it redirects users who

have Exchange Server 2003 mailboxes to the legacy URL.

Considerations for using a legacy URL:

• To support the use of a legacy URL, you need to have two valid Internet IP addresses available. Or,

you can use a single valid Internet IP address if your reverse proxy server supports redirection based

on host headers.

• The Exchange Server 2003 front-end server must be configured to use forms-based authentication for

Outlook Web Access or authentication will fail.

ActiveSync and Outlook AnywhereAn Exchange Server 2010 Client Access server also provides Exchange Server 2003 users with access to

their mailboxes through ActiveSync and Outlook Anywhere. No special configuration is required. The

connection process is as follows:

• When an Exchange ActiveSync client connects to the Client Access server and the user mailbox is

located on an Exchange Server 2003 back-end server, the Client Access server connects to the

Exchange Server 2003 server by using the Hypertext Transfer Protocol (HTTP) and provides access to

the user mailbox.

• When an Outlook Anywhere client connects to the Client Access server and the user mailbox is

located on an Exchange Server 2003 back-end server, the Remote Procedure Call (RPC) proxy service

on the Client Access server connects to the back-end server by using RPC.




Designing the Message Transport Upgrade

Key Points

To support coexistence between different Exchange Server versions, all servers running Exchange

Server 2010 are added automatically to a single routing group when you install Exchange Server 2010.

The Exchange Server 2010 routing group includes all Exchange Server 2010 servers, regardless of the

Active Directory site in which they reside.

Integrating Exchange Server 2010 into Exchange Server 2003 Routing Groups

During the coexistence phase of your planned upgrade, the Exchange Server 2010 servers are presentedto Exchange Server 2003 servers as members of a single routing group called Exchange Routing Group

(DWBGZMFD01QNBJR). When planning your upgrade to Exchange Server 2010, it is important that you

consider these routing topology differences.

During your first Exchange Server 2010 Hub Transport server installation in an existing Exchange

organization, you must specify an Exchange 2003 bridgehead server to establish the first routing group

connector. You should select a bridgehead server that is located either in a hub routing group, or in a

routing group that has many mailboxes. The routing group connector links the routing group where the

Exchange Server 2003 server resides with the Exchange Server 2010 routing group. From the perspective

of the Exchange Server 2003 servers, the Exchange Server 2010 routing group includes all Exchange Server

2010 servers, regardless of the AD DS site in which they reside.

The Exchange Server 2010 Hub Transport server that you install and the Exchange Server 2003bridgehead that you select are configured as the source and target servers on two reciprocal routing

group connectors. This routing group connector creates a single connection point between Exchange

Server 2003 and Exchange Server 2010.




Supporting Multiple Routing Groups

However, if your existing Exchange Server 2003 organization includes multiple routing groups, you may

want to create additional connection points between Exchange Server 2003 and Exchange Server 2010 to

optimize mail flow. Bear in mind that if you create multiple paths between the Exchange Server 2010

routing group and your legacy Exchange Server organization, you must suppress minor link state updates

to ensure that message looping does not occur when Exchange Server 2003 recalculates a route; when

link state updates are suppressed, Exchange Server 2003 servers queue messages at the point of failure,

instead of recalculating the route, in a similar way to Exchange Server 2010.

Upgrade External Connectivity

You can deploy the Edge Transport server as a smart host and Simple Mail Transfer Protocol (SMTP) relay

server for an existing Exchange Server 2003 organization. You can add an Edge Transport server to an

existing Exchange organization without upgrading the internal Exchange servers, or making any

organizational changes. You do not need to perform any AD DS configuration changes in advance of

deploying an Edge Transport server, because it is deployed outside AD DS.

When you deploy an Edge Transport server in an Exchange organization in which you have not yet

deployed Exchange Server 2010, you cannot use some features of the Edge Transport server role. You

cannot create an Edge Subscription in this scenario; consequently, you cannot use the Recipient Lookupor Safelist aggregation features.

Because you cannot enable Edge Synchronization, you must manually configure message routing on the

internal Exchange bridgehead servers and the Edge Transport server, rather than using the Edge

Subscription to configure the settings based on the internal AD DS configuration. You need to:

• Configure the Exchange Server 2003 bridgehead servers to use the Edge Transport server as a relay

for outbound Internet messages. To do this, configure the appropriate SMTP connector to send

messages to the Internet using the IP address of the Edge Transport server as a smart host.

• For inbound Internet messages, ensure that your organization’s mail exchanger (MX) resource records

reference the IP addresses of the Edge Transport servers.

•

Configure SMTP connectors to enable message routing between the Edge Transport servers and the

Exchange Server 2003 bridgehead servers, and between the Edge Transport servers and Internet

SMTP servers. At a minimum, you must configure an SMTP Send connector for sending email, and an

SMTP Receive connector for receiving email from the Exchange Server 2003 servers, and configure a

Send connector for sending email to Internet recipients. By default, a Receive connector is configured

on the Edge Transport server that accepts messages from the Internet SMTP servers.

• Configure the accepted domains. The accepted domain setting specifies the SMTP domains that the

organization uses. You must configure these domains manually on the Edge Transport server if you

do not have the option of configuring an Edge Subscription.




Designing the Upgrade of Administrative Roles

Key Points

As you upgrade to Exchange Server 2010, you also must plan for continued administration of the

organization.

Replicating Exchange Administrative Designs

Due to the design differences of administrative permissions in Exchange Server 2010 compared to

previous Exchange Server versions, you cannot directly replicate the Exchange Server 2003 administrative

design in Exchange Server 2007. One of the main differences that you need to plan for is that ExchangeServer 2010 does not use administrative groups for delegating permissions.

The following table describes some options for creating an Exchange Server 2010 administrative design

that emulates an Exchange Server 2003 design.

Exchange 2003 administrative assignmentoptions Exchange Server 2010 equivalent

Exchange Full Administrator role at theorganization level

Add users or groups to the Exchange OrganizationAdministrator role group.

Exchange Administrator role at theorganization level

Exchange Server 2010 does not have a role groupequivalent to the Exchange Administrator role. You

can create a role group and assign the requiredpermissions through role-based access control(RBAC).

Exchange View Administrator role at theorganization level

Add users or groups to the Exchange View-OnlyAdministrator role.

Exchange Full Administrator role at theadministrative group level

Create a new role group that is assigned allmanagement roles, but with a limited scope.




(continued )

Exchange 2003 administrative assignmentoptions Exchange Server 2010 equivalent

Exchange View Administrator role at theadministrative group level

Create a new role group with View-Only permissionsand a limited scope.

Recipient administrators with Exchange ViewAdministrator role and AD DS permissions

Add users and groups to the Exchange RecipientAdministrator role group.

Using Administrative Tools in a Coexistence Scenario

In addition to planning permissions delegation in Exchange Server 2010, you also must consider the

administrative tools for the different Exchange Server versions. You must use Exchange Server 2010

administration tools to manage all Exchange Server 2010 settings. After installing an Exchange

Server 2010 server, you should configure any global settings by using Exchange Server 2010 tools.

Exchange Server 2003 servers are not listed in the Exchange Server 2010 Exchange Management Console.

To manage Exchange Server 2003 settings, you must use the Exchange System Manager. You also can

manage recipients who have mailboxes on Exchange Server 2003 servers by using Active Directory Users

and Computers. However, the Exchange Server 2010 Exchange Management Console also displays

mailboxes that are located on Exchange Server 2003 servers, and you can use the console to manage

mailbox properties. You cannot view mailboxes on Exchange Server 2010 servers in the Exchange System

Manager.




Planning the Removal of Exchange Server 2003

Key Points

After you deploy the Exchange Server 2010 servers in the Exchange Server 2003 organization, you can

start moving the mailboxes and other resources from the existing servers to the Exchange Server 2010

servers. Then you can start removing the Exchange Server 2003 servers.

Removing Exchange Server 2003 Servers

As you move mailboxes and message delivery to the Exchange Server 2010 servers, you can start

removing the previous Exchange Server versions. Microsoft recommends that you follow the followingprocess for removing Exchange Server 2003 servers:

1. Remove back-end servers first. As you move mailboxes from Exchange Server 2003 servers to

Exchange Server 2010 Mailbox servers, you can start decommissioning the previous back-end servers.

2. Remove the Exchange Server 2003 bridgehead servers. A bridgehead server is a back-end server that

is configured to route messages between routing groups. After you remove the last back-end server

in a routing group, you also can remove the routing group’s bridgehead servers.

3.

To send email to the Exchange Server 2010 Mailbox servers, you must configure at least one

Exchange Server 2003 server as the routing group connector’s bridgehead server between Exchange

Server 2003 and the Exchange Server 2010 routing group. Do not remove this server until the last

user and required system mailboxes are moved to the Exchange Server 2010 servers. If you plan to

remove this bridgehead server before moving all the mailboxes, you must configure another

Exchange Server 2003 server as the new bridgehead server.

4.

Remove the Exchange Server 2003 front-end servers. These are now redundant, as all clients are

connecting to Exchange Server 2010 Client Access servers.




Troubleshooting the Exchange Server 2010 Upgrade

Key Points

The installation of Exchange Server 2010 into an existing Exchange Server 2003 organization has a few

unique requirements that do not apply to a new installation of Exchange Server 2010. Some common

issues during installation include:

• Incorrect forest or domain functional level. Both the forest and domain functional levels must be

Windows Server 2003. To resolve this problem, raise the forest or domain functional level to the

appropriate functional level.

• Incorrect Exchange mode. Your existing Exchange Server 2003 organization must be in native mode;

if it is not, raise the Exchange Server 2003 organizational mode.

• Insufficient AD DS permissions. When you upgrade to Exchange Server 2010, you need sufficient

permissions to update the Active Directory schema and modify the Active Directory configuration

partition. To perform the initial schema extension, you must be a member of the Enterprise Admins

and Schema Admins groups.

• Insufficient Exchange permissions. To install Exchange Server 2010 into an existing organization, you

must be a member of the Exchange Admins group that has permissions to manage Exchange

Server 2003. You must also run Setup.exe with the /PrepareLegacyExchangePermissions switch.

Wait for replication throughout the Exchange Server organization before you continue.

•

Incorrect version of Exchange Server 2003. All computers running Exchange Server 2003 must have at

minimum SP2 installed.

In general, if there is a problem installing Exchange Server 2010 into an existing Exchange Server 2003

organization, there is no specific rollback mechanism required. Instead, use the error messages and setup

log to identify the source of the problem, resolve the issue, and then run the installation again.




After installation, you may experience the following issues:

• No message routing between Exchange Server 2003 and Exchange Server 2010. During installation

of the first Exchange Server 2010 Hub Transport server, a routing group connector should be

automatically created between a specified Exchange Server 2003 bridgehead server and the Exchange

Server 2010 Hub transport server. In some cases, this routing group connector is not automatically

created and you need to manually create it by using the New-RoutingGroupConnector cmdlet.

• Inefficient message routing. Exchange Server 2003 identifies Exchange Server 2010 as one large

routing group. When you are upgrading a large organization with multiple routing groups, you may

need to create additional routing group connectors to ensure that message delivery is efficient. In

general, any site that has both Exchange Server 2010 and Exchange Server 2003 should have a local

routing group connector during coexistence.

• Distribution groups not functional. As you remove computers running Exchange Server 2003, you

may find that some distribution groups cannot be expanded and messages to those groups fail. This

occurs if the distribution group is configured with an expansion server and the expansion server has

been removed. To resolve this issue, remove the expansion server from the distribution group.

• Message moderation is being applied inconsistently. Moderation of messages sent to distribution

groups can be applied only by Exchange Server 2010 Hub Transport servers. If a computer running

Exchange Server 2003 expands the membership of the distribution list, moderation is not applied. To

ensure that moderation is applied to distribution groups, configure an Exchange Server 2010 Hub

Transport server as an expansion server.

• Outlook 2003 clients cannot connect to mailboxes. The RTM release of Exchange Server 2010 requires

RPC encryption when connecting to a mailbox. Outlook 2003 does not support RPC encryption by

default. The solution is to enable RPC encryption in Outlook 2003 or to disable the requirement for

RPC encryption in Exchange Server 2010. New servers installed with media including SP1 or SP2 do

not require RPC encryption by default.




Lesson 3

Planning the Upgrade from Exchange Server 2007 toExchange Server 2010

If your organization is currently running Exchange Server 2007, the upgrade process to Exchange

Server 2010 is similar to upgrading from Exchange Server 2003; however, there are some important

differences.


• Determine whether your Exchange Server 2007 organization is ready for Exchange Server 2010.

• Describe the process for installing Exchange Server 2010 in an Exchange Server 2007 organization.

• Design the Client Access server upgrade.

• Design external access for Exchange Server 2007 client services.

• Design the message transport upgrade.

• Design the administrative roles upgrade.

• Plan the removal of Exchange Server 2007 servers.

• Troubleshoot the upgrade process.




Prerequisites for Installing Exchange Server 2010 in anExchange Server 2007 Organization

Key Points

Before beginning the upgrade, you must prepare AD DS for Exchange Server 2010. Prior to performing

this step, confirm that your current infrastructure meets the following conditions:

• The schema master and at least one global catalog server in each site must be running Windows

Server 2003 with SP1 or newer.

•

The forest functional level must be at least Windows Server 2003.

• The domain functional level must be Windows Server 2003.

• Your Exchange Server 2007 servers must be running Exchange Server 2007 SP2.

Changes Made by the PrepareSchema Setup Command

If your Exchange Server 2007 organization meets the preceding conditions, you must run the setup

PrepareSchema command—running this command prepares the AD DS schema for deployment of

Exchange Server 2010, and it must be run by a user who is a member of both the Enterprise Admins and

Schema Admins groups.

Changes Made by the PrepareAD Command

After running setup with the PrepareSchema command, you should run setup with the PrepareAD command. This command must be run by a member of the Enterprise Admins group, and makes changes

to enable coexistence between Exchange Server versions.

The PrepareAD command also extends the schema to include the Exchange Server 2010 schema objects

and attributes; consequently, you might choose to run only the PrepareAD command rather than first

running the PrepareSchema command.




Process for Installing Exchange Server 2010 in an Exchange Server 2007Organization

Key Points

Exchange Server 2010 Setup checks the server versions of all Exchange servers; the requirement checks

will fail if a server is not upgraded to Exchange Server 2007 SP2. Exchange Server 2007 SP2 includes

several schema updates that are required for interoperability with Exchange Server 2010.

If an organization only has a single Active Directory site, use the following process for deploying Exchange

Server 2010.

1. Install the Exchange Server 2010 Client Access server. After you complete this installation, you should

use this as the primary connection point for all client connections. This means that you should modify

the Autodiscover settings—both internally and externally—to point to the Exchange Server 2010

Client Access server.

2. Install the Exchange Server 2010 Hub Transport server. Both Exchange Server 2007 servers and

Exchange Server 2010 Mailbox servers must use a Hub Transport server that is the same version as the

Mailbox server for routing messages in the same site.

3. Install the Exchange Server 2010 Mailbox servers. After the rest of the infrastructure is in place, you

can deploy the Exchange Server 2010 Mailbox servers, and start moving mailboxes and public folders

to the new servers.

4.

Install Exchange Server 2010 Unified Messaging servers. If you have deployed Unified Messaging in

Exchange Server 2007, add the Exchange Server 2010 Unified Messaging server to one of your

organization’s dial plans.

5. Install the Exchange Server 2010 Edge Transport servers. Exchange Server 2010 Edge Transport

servers can synchronize only with Exchange Server 2010 Hub Transport servers.




For organizations with multiple sites, there typically are two types of Active Directory sites: Internet-

accessible sites, and non-Internet accessible sites. A single Exchange Server organization may have one or

more Internet-accessible sites. When upgrading Active Directory sites, you 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 Internet-

accessible and non-Internet accessible sites. Before deploying any Exchange Server 2010 Mailbox server inany site, you must deploy Exchange Server 2010 Client Access and Hub Transport servers.




Designing the Client Access Server Upgrade

Key Points

During coexistence of Exchange Server 2007 and Exchange Server 2010, the Client Access server that

clients use is determined by where the user’s mailbox is located. Internal users with Exchange Server 2007

mailboxes and Outlook 2010 are unaffected by the addition of Exchange Server 2010 Client Access

servers. Outlook 2010 accesses their mailbox directly on the Exchange Server 2007 Mailbox servers

hosting their mailbox. Other Client Access services, such as free/busy searches and offline address book

downloads, continue to be accessed from an Exchange Server 2007 Client Access server.

When you move a mailbox from an Exchange Server 2007 Mailbox server to an Exchange Server 2010

Mailbox server, the client profile is configured automatically to use the Exchange Server 2010 Client

Access server for MAPI connectivity; you do not need to modify the client profile manually. Outlook 2007

and Outlook 2010 clients use Autodiscover to determine the new configuration. Outlook 2003 clients are

redirected to the new mailbox location by their previous server.




Designing External Access for Exchange Server 2007 Client Services

Client Access servers provide Internet users with access to their mailboxes by using Outlook Web App,

ActiveSync and Outlook Anywhere. It is important to understand how each of these methods behave

during the upgrade process to help ensure that user access is not interrupted.

The first step in the upgrade process is to add one or more Exchange Server 2010 Client Access servers to

the site being upgraded. To implement coexistence, you must configure all clients to connect to the

Exchange Server 2010 Client Access server. If you have been using an external URL—such as

https://mail.adatum.com—to connect to an Exchange Server 2007 Client Access server, you should modify

the Domain Name Service (DNS) or firewall configuration to forward connections to the URL of theExchange Server 2010 Client Access server. Clients accessing their mailbox from the Internet connect to

the Exchange 2010 Client Access server and are then redirected or proxied to the appropriate Exchange

Server 2007 server.

Outlook Web Access

Unlike Exchange Server 2003 coexistence, there is no legacy URL configured for coexistence of Outlook

Web Access with Exchange Server 2007. Instead, the external URL configured on the Exchange

Server 2007 Client Access server is used to redirect client requests to the appropriate Client Access server.

Consider the following:

• Requests for an Exchange Server 2007 mailbox in the same site are redirected to the external URL of

the Exchange 2007 Client Access server in the same site. There is no option to proxy the connectivity

in the same site. Therefore, like the legacy URL for Exchange Server 2003, you must have two

externally accessible IP addresses for coexistence of Outlook Web Access and Outlook Web App.

• Requests for an Exchange Server 2007 mailbox in a different site are redirected if an Exchange

Server 2007 Client Access server in the different site is configured with an external URL. This ensures

that existing externally accessible Exchange 2007 Client Access servers are still used.




• Requests for an Exchange Server 2007 mailbox in a different site are proxied if the Exchange

Server 2007 Client Access servers in the different site are not configured with an external URL. The

Exchange Server 2007 Client Access servers in the different site access the mailbox on the Exchange

Server 2007 Mailbox server.

Use the following process to transition to using the Exchange Server 2010 Client Access server:

1.

Install and configure the Exchange Server 2010 Client Access server. Configure the external URL to

match the existing external URL on the Exchange Server 2007 Client Access server.

2. Create a new DNS record for legacy access to the Exchange Server 2007 Client Access server. For

example, legacy.contoso.com.

3. Update the external URL on the Exchange Server 2007 Client Access server to match the new DNS

record for legacy access.

4. Update the certificate on the Exchange Server 2007 Client Access server with the new legacy name.

ActiveSync

The connectivity process for ActiveSync clients varies depending on the site the mailbox is located in and

whether the ActiveSync client supports Autodiscover. The connection process is as follows:

• If the Exchange Server 2007 mailbox is in the same site and the client supports Autodiscover,

Autodiscover is used to redirect the client to the external URL of the Exchange Server 2007 Client

Access server.

• If the Exchange Server 2007 mailbox is in the same site and the client does not support Autodiscover,

the Exchange Server 2010 Client Access server proxies the request to the Exchange Server 2007 Client

Access server.

• If the Exchange Server 2007 mailbox is in a different site that does not have an external URL

configured on the Exchange Server 2007 Client Access server, the request is proxied to an Exchange

Server 2007 Client Access server in the different site hosting the Exchange Server 2007 mailbox.

Outlook AnywhereThe Outlook Anywhere connection process is consistent regardless of the site the mailbox is located in.

When the Exchange Server 2010 Client Access server receives the request, the Exchange Server 2007

Mailbox server is contacted directly.

The RPC over HTTP service on the Exchange Server 2007 Client Access server is not used after the

Exchange Server 2010 Client Access server is in place. So, you can disable Outlook Anywhere on the

Exchange Server 2007 Client Access server and uninstall the RPC over HTTP feature.




Designing the Message Transport Upgrade

Key Points

A second issue that coexists between the two Exchange Server versions is message transport. Message

transport coexistence is configured automatically, as long as the correct versions of Hub Transport servers

are available.

Message Routing During Coexistence

As you deploy Exchange Server 2010 Hub Transport and Mailbox servers in an Exchange Server 2007

organization, message transport operates as follows:

• Each version of the Mailbox server must use an equivalent version of the Hub Transport server when

routing messages within the same site. Consequently, you must deploy the Exchange Server 2010

Hub Transport server before deploying the Exchange Server 2010 Mailbox servers. Additionally, you

must not remove the last Exchange Server 2007 Hub Transport server until you remove all of the

mailboxes from the Exchange Server 2007 Mailbox servers.

• If you have both Exchange Server 2007 and Exchange Server 2010 servers deployed in a site,

messages flow from the Exchange Server 2010 Mailbox server to the Exchange Server 2010 Hub

Transport server, to the Exchange Server 2007 Hub Transport server, and then to the Exchange

Server 2007 Mailbox server. Messages sent from an Exchange Server 2007 mailbox follow the reverse

route.

•

Message routing between Active Directory sites can use Hub Transport servers on either Exchange

Server version. If you install an Exchange Server 2010 Hub Transport server in one site, it can send

messages to Exchange Server 2007 Hub Transport servers in another site.




• Message routing to and from the Internet can use either Exchange Server 2007 or Exchange

Server 2010 Edge Transport servers. If your current deployment uses Exchange Server 2007 Edge

Transport servers for inbound email, you can continue to have the Edge Transport servers forward all

messages to the Exchange Server 2007 Hub Transport server. For outbound messages, you can add

Exchange Server 2010 Hub Transport servers to the SMTP Send connector that is responsible for

sending messages to the Internet. This enables outbound messages to be sent through either

Exchange Server 2007 or Exchange Server 2010 Hub Transport servers.

Edge Transport Server Coexistence

If you have deployed the Exchange Server 2007 Edge Transport server role, you can retain or replace

these servers with Exchange Server 2010 Edge Transport servers.

You can implement edge synchronization between Exchange Server 2010 Hub Transport servers and

Exchange Server 2007 Edge Transport servers, but you cannot configure edge synchronization between

Exchange Server 2007 Hub Transport servers and Exchange Server 2010 Edge Transport servers. This

means that if you are using edge synchronization, you should not deploy an Exchange Server 2010 Edge

Transport server before deploying at least one Exchange Server 2010 Hub Transport server in the adjacent

Active Directory site.




Designing the Administrative Roles Upgrade

Key Points

When implementing Exchange Server 2010 in an Exchange Server 2007 organization, you also need to

plan for administrative coexistence. In this scenario, you must consider how you will use the Exchange

Server management tools, and how you will delegate permissions.

Management Console Coexistence

The Exchange Management Console is available in both Exchange Server 2007 and Exchange Server 2010.

You can perform the following tasks and actions using either Exchange Management Console:

• You can perform actions that create new objects—such as new mailboxes or a new offline address

book—on a version of the Exchange Management Console that is the same as the target object. For

example, you must create a new mailbox on an Exchange Server 2007 Mailbox server by using the

Management Console in Exchange Server 2007.

• You can view Exchange Server 2007 Mailbox databases from the Exchange Server 2010 Management

Console, although you cannot manage these databases across the different versions.

• You can perform actions that require management on Exchange Server 2007 objects from the

Exchange Management Console in Exchange Server 2010. You cannot perform these actions from the

Management Console in Exchange Server 2007 on Exchange Server 2010 objects.

•

You can use any Exchange Management Console version to perform actions that require viewing ofany version of Exchange Server objects, with the following exceptions:

• You can view Exchange Server 2007 and Exchange Server 2010 transport rule objects only from

the corresponding version of the Exchange Management Console.

• You can view Exchange Server 2007 and Exchange Server 2010 servers only from the

corresponding version of the Exchange Management Console.




• The Queue Viewer tool in Exchange Server 2010 Management Console cannot connect to an

Exchange Server 2007 server to view queues or messages.

• You cannot enable or disable Exchange Server 2007 Unified Messaging mailboxes from the Exchange

Server 2010 Management Console.

• You cannot use the Exchange Server 2010 Management Console to manage mobile devices for users

who have mailboxes on an Exchange Server 2007 Mailbox server.

Delegating Administration During Coexistence

The model for delegating administrative permissions has changed significantly in Exchange Server 2010.

Exchange Server 2007 setup creates several AD DS groups with designated permissions in AD DS and in

the Exchange organization. To delegate permissions, you simply add users to the appropriate AD DS

groups.

RBAC replaces this model in Exchange Server 2010, where you use role groups to configure permissions.

When you install Exchange Server 2010 servers in an Exchange Server 2007 organization, this adds the

Exchange Server 2010 role groups to AD DS, and the Exchange Server 2007 groups are retained. When

you are assigning permissions on Exchange Server 2007 servers, use the Exchange Server 2007 groups.

When assigning permissions on the Exchange Server 2010 servers, use the Exchange Server 2010 role

groups.

You also can delegate permissions in an Exchange Server 2007 organization. The following table describes

some options for creating an Exchange Server 2010 administrative design that emulates an Exchange

Server 2007 design.

Exchange Server 2007 administrative option Exchange Server2010 equivalent

Assign users to the Exchange OrganizationAdministrators group.

Add users or groups to the OrganizationManagement role group.

Assign users to the Exchange View-OnlyAdministrators group.

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

Assign users to the Exchange RecipientAdministratorsgroup.

Add users or groups to the Recipient Managementrole group.

Assign users to the Exchange Public FolderAdministrators group.

Add users or groups to the Public FolderManagement role group.

Assign users as server administrators for aspecific Exchange Server 2007 server.

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




Planning the Removal of Exchange Server 2007

Key Points

After deploying the Exchange Server 2010 servers, you can start moving resources to the Exchange

Server 2010 servers, and removing the Exchange Server 2007 servers.

Removing Exchange Server 2007 Servers

As you move mailboxes and message delivery to the Exchange Server 2010 servers, you can start

removing the previous versions of Exchange servers. It is recommended that you remove the Exchange

Server 2007 servers using the following process.

1. Remove Mailbox servers first. As you move mailboxes from Exchange Server 2007 servers to Exchange

Server 2010 Mailbox servers, you can start decommissioning the Exchange Server 2007 Mailbox

servers.

2. Remove the Exchange Server 2007 Unified Messaging server role. Once you have migrated all the

user mailboxes, you can replace and remove the Unified Messaging servers.

3. Remove the Exchange Server 2007 Hub Transport servers. The Exchange Server 2007 Mailbox server

must be able to communicate with an Exchange Server 2007 Hub Transport server. As you remove

Mailbox servers, you also can begin removing the Hub Transport servers. Do not remove the last Hub

Transport server until the last mailboxes are moved from the Exchange Server 2007 servers.

4.

Remove the Exchange Server 2007 Client Access servers.

After you remove the last mailbox and public folder from the Exchange Server 2007 Mailbox server, you

may remove all other Exchange Server 2007 servers in the Active Directory site.




Troubleshooting the Exchange Server 2010 Upgrade

Key Points

As with the upgrade from Exchange Server 2003, the upgrade from Exchange Server 2007 should be

problem-free if you plan the upgrade carefully; however, unexpected problems can still occur.

Before you start your upgrade, you must ensure that your existing Exchange Server 2007 organization

meets the prerequisites for upgrading to Exchange Server 2010.

If your organization and the servers installed in it meet the specified requirements and you still encounter

problems when installing specific server roles, attempt to re-deploy any server role that fails.

Note For more information, see the topic “Troubleshooting the Exchange Server 2010

Upgrade” in Lesson 2: Planning the Upgrade from Exchange Server 2003 to Exchange Server

2010.




Lab: Upgrading to Exchange Server 2010

Lab Setup

This lab does not require any virtual machines.

Lab Scenario




The A. Datum Corporation headquarters in London and two remote locations (Vancouver and Tokyo) are

running Exchange Server 2003 and Outlook 2003. A. Datum Corporation will be adding two new

locations, and within the next six months it plans to migrate all existing users to Exchange Server 2010 and

Outlook 2010. Much of the Exchange Server 2010 messaging system design is complete.

The Trey Research location continues to run a POP3/SMTP messaging system, which you need to migrate

to Exchange Server 2010 and integrate with the rest of the Exchange organization. The Trey Research

domain is already deployed as a separate tree in the A. Datum forest. This integration of Trey Research will

be completed after the current infrastructure is upgraded.

Use the references on the following pages for this lab.

Note Your instructor may choose to perform this lab as a group discussion rather than anindividual activity.




Adatum_ProposedADSiteDesign.vsd




Adatum_ProposedPerimeterDesign.vsd




A. Datum User Distribution Summary.doc


London(corporate

headquarters)

12,000 currently

10,000 after the new

London office is ready

1,000 Outlook Web Access users


800 Outlook users connecting through a virtual privatenetwork (VPN)

London(new office)

4,000 (anticipated) 200 Outlook Web Access users


San Diego

(former headoffice of TreyResearch)

500 50 POP3 client users

Vancouver 6,000 800 Outlook Web Access users


Tokyo 5,000 1,000 Outlook Web Access users



Chennai(new office)

800 (anticipated) 200 Outlook Web Access users


A. Datum has deployed a single AD DS forest with a dedicated root domain named Adatum.com, and

three child domains in the same tree. These domains are:

• EU.Adatum.com

•

NA.Adatum.com

• AS.Adatum.com



Exchange_Server_2003_Configuration.doc

Location Description

London(corporateheadquarters)

• Configured as a routing group

• 12 Exchange Server 2003 servers hosting mailboxes

•

Two load-balanced front-end servers to provide access for remoteusers (mail.adatum.com)

• A SPAM filtering appliance is in place

Vancouver • Configured as a routing group

• Eight Exchange Server 2003 servers hosting mailboxes

Tokyo • Configured as a routing group

• Eight Exchange Server 2003 servers hosting mailboxes




Exercise 1: Discussion: Reviewing the Exchange Server 2010 Design

Scenario

In this exercise, you will design an upgrade strategy for the A. Datum organization. Based on the review of

the Exchange Server 2010 target state design, you will create an upgrade strategy for migrating from the

current environment to the target state design.



2.

Update the A. Datum Upgrade Design document.


• Review the following A Datum documentation:

• Adatum_ProposedADSiteDesign.vsd

• Adatum_ProposedPerimeterDesign.vsd


• Exchange_Server_2003_Configuration.doc

Task 2: Update the A. Datum Upgrade Design document

• Answer the questions in the A. Datum Upgrade Design Questions document, and then complete the

A. Datum Upgrade Design document.

A. Datum Upgrade Design


Document Author

Date

Jason Carlson

6th June 2010


Describe the upgrade strategy for the A. Datum organization.

Proposals

Question: Based on what you know about the A. Datum organization, what would be a reasonabletimeline for completing this migration?

Question: What are the factors that will affect the timeline?

Question: Where will you perform the schema upgrade?

Question: What is the process for preparing domains for Exchange Server 2010?

Question: How will you ensure that Exchange Server 2010 can coexist with Exchange Server 2003?

Question: Which site should be upgraded first?

Question: Which server role should be implemented first in that site?




(continued )


Question: Should coexistence occur in multiple sites or a single location?

Question: How will client access be configured to allow coexistence in the first site?

Question: How will message transport be configured to allow coexistence in the first site?

Question: How will mailboxes be moved in the first site?

Question: How will you move Internet message delivery from Exchange Server 2003 to ExchangeServer 2010 and use Edge Transport servers?

Question: When you begin migrating the second site to Exchange Server 2010, what process will youuse?

Question: How will you remove Exchange Server 2003?


Results: After this exercise, you should have completed the A. Datum Upgrade document.







Review Questions

1. Contoso, Ltd., currently utilizes servers running Exchange 2000 Server in their organization. They are

excited about the features available in Exchange Server 2010, and want to upgrade to the new

platform. How would you recommend that they proceed?

2. A. Datum Corporation has recently acquired Trey Research, an organization that implements Novell

GroupWise for messaging. A. Datum Corporation has Exchange Server 2003 installed, and itimplements the Novell GroupWise connector to ensure directory synchronization and message flow

between the two organizations. As A. Datum Corporation is planning to upgrade to Exchange

Server 2010, how would you advise they proceed with handling the Trey Research GroupWise

messaging system?




Common Issues Related to Upgrading to Exchange Server 2010

Identify the causes for the following common issues related to upgrading to Exchange Server 2010.

Issue Troubleshooting tip

When you try to remove an Exchange Server2003 server, you receive an error messagethat you cannot remove the server because itis a bridgehead server for a routing-groupconnector. You have upgraded all externalmessage routing to Exchange Server 2010.

The Exchange Server 2003 server may be thedesignated routing group bridgehead server for therouting-group connector between the Exchange Server2003 routing group and the Exchange Server 2010routing group. If this is the last Exchange Server 2003server, you can remove it from the routing-groupconnector. If you have other Exchange Server 2003servers deployed, you need to designate one of themas the routing-group connector bridgehead server.

You are upgrading your ExchangeServer 2007 organization to Exchange Server2010, and you have configured Client Accessservers for Internet access. Users withmailboxes on Exchange Server 2010 Mailboxservers can access their mailbox by usingOutlook Web App from the Internet, butusers with mailboxes on the Exchange Server2007 Mailbox servers cannot.

Check the DNS configuration to ensure that users fromthe Internet can resolve the host name for thealternate or legacy URL that you have configured. Also,check the reverse proxy or firewall configuration toensure that all client requests to the legacy URL aredirected to the Exchange Server 2007 Client Accessserver.

You have deployed Exchange Server 2010servers in your Exchange Server 2007organization. You need to modify the settingson both Exchange Server 2007 and ExchangeServer 2010 servers, but you cannot see bothservers in the Exchange ManagementConsole.

You need to use the same version of the ExchangeManagement Console as the server that you aremanaging.

Best Practices Related to Upgrading to Exchange Server 2010


• If your Exchange Server 2003 organization has multiple routing groups, consider creating additional

routing group connectors between each of the routing groups, and an Exchange Server 2010 Hub

Transport server in each office location. By doing this, you can ensure that all messages are sent from

the Exchange Server 2003 servers to the Exchange Server 2010 servers without crossing the wide area

network (WAN) links between the routing groups.

• Plan to increase the number of Client Access servers as you upgrade to Exchange Server 2010. For

Exchange Server 2003 and Exchange Server 2007 deployments, Microsoft recommends a 1:4 ratio of

Client Access server or front-end server processor cores to Mailbox server or back-end server cores. In

Exchange Server 2010, Microsoft recommends a 3:4 ratio.



12-1

Module 12

Integrating Microsoft® Exchange Server 2010 with OtherMessaging Systems

Contents:

Lesson 1: Designing Exchange Server 2010 Integration with Other

Messaging Systems 12-3


Federated Partners 12-15

Lesson 3: Designing Exchange Server 2010 Integration with Office 365 12-22

Lesson 4: Designing Single Sign-On for Office 365 12-35

Lab: Integrating Exchange Server 2010 with Other Messaging Systems 12-40



12-2 Integrating Microsoft® Exchange Server 2010 with Other Messaging Systems

Module Overview

Microsoft® Exchange Server 2010 provides options to integrate with other messaging systems, with other

organizations using Exchange Server 2010, and with Microsoft Exchange Online. Integration with other

messaging systems is useful when you are migrating from a legacy messaging system to Exchange

Server 2010. Integration with federated partners that are also using Exchange Server 2010 allows you to

share information with partner organizations. Integration with Exchange Online allows you to expand the

messaging system in your organization without adding additional servers.


• Design integration with other messaging systems.

• Design integration with federated partners.

• Design integration with Exchange Online.




Lesson 1

Designing Exchange Server 2010 Integration with OtherMessaging Systems

When you upgrade from a legacy messaging system to Exchange Server 2010, it might be necessary for

the legacy messaging system and Exchange Server 2010 to coexist. There are several configurations you

can use to accomplish this goal. When you plan the coexistence of the two messaging systems, you must

consider several factors, such as message routing, address list synchronization, and calendar

interoperability.


• Describe possible coexistence scenarios.

• Design the integration of Exchange Server 2010 with other Exchange Server organizations.

• Design message routing with unique Simple Mail Transfer Protocol (SMTP) addresses during

coexistence.

• Design message routing with the same SMTP addresses during coexistence.

• Design the synchronization of the global address list (GAL).

• Design calendar and free/busy availability.




Coexistence Scenarios for Exchange Server 2010

Key Points

Typically, only very small organizations can perform a complete migration to a new messaging system as a

single event. Most migrations to a new messaging system require coexistence between the legacy

messaging system and Exchange Server 2010.

Coexistence with Other Exchange Server Organizations

It is a common scenario after a merger and the integration of organizations, for multiple Exchange Server

organizations to coexist. Coexistence is typically a temporary state until the two messaging systems can bemerged.

During an upgrade from Exchange Server 2003 or Exchange Server 2007 to Exchange Server 2010, a

single global address list (GAL) is maintained, and the calendar data is shared between the Exchange

Server versions. When two separate Exchange Server organizations coexist, the calendar data and GALs

are not automatically synchronized between the two organizations. This can make collaboration between

the two organizations difficult.

You can configure message delivery between the Exchange Server organizations by using Send

connectors. This allows you to apply specific configuration settings to messages being transferred

between the organizations.

Integration with Microsoft Office 365 requires coexistence with another Exchange Server organization.

However, in the case of Office 365, coexistence is often long term. Office 365 also includes tools for

directory synchronization and calendar interoperability.

Coexistence with Other SMTP Messaging Systems

Coexistence between Exchange Server 2010 and an SMTP messaging system is typically required when

you upgrade from an SMTP messaging system. The two messaging systems coexist until you configure all

users on Exchange Server 2010.




In this scenario, address lists are not automatically synchronized between the two messaging systems.

Calendars are typically not shared, because most simple SMTP messaging systems do not support

calendars.

You can configure message delivery from Exchange Server 2010 to the SMTP messaging system by using

a Send connector.

Coexistence with Non-SMTP Messaging Systems

Coexistence with non-SMTP messaging systems is typically required when you upgrade from a legacy

non-SMTP messaging system to Exchange Server 2010. The two messaging systems coexist until all users

are configured on Exchange Server 2010.

Most non-SMTP messaging systems support advanced features such as calendar functionality. However,

Exchange Server 2010 does not include connectors to synchronize calendar data or address lists with non-

SMTP messaging systems, such as Lotus Notes or Novell GroupWise.

Note Both Lotus Notes and Novell GroupWise can be configured for coexistence by

treating them as SMTP messaging systems for exchanging email. There are also third-party

products available for coexistence.

Exchange Server 2010 includes support for foreign connectors, but you must obtain the foreign connector

from a third party. When you create configure a foreign connector, you define a namespace for the

foreign connector, and create a drop directory for the foreign connector. The foreign connector picks up

messages from the drop directory.




Designing Integration with Other Exchange Server Organizations

Key Points

Each Active Directory® forest can support only a single Exchange Server organization. But when you

upgrade an Exchange Server organization from a previous version to Exchange Server 2010, both

Exchange Server versions exist in the same organization at the same time. Having a single Exchange

Server organization allows for interoperability between the previous version of Exchange Server, and


Typically, you need to plan for coexistence and integration with a second Exchange Server organization

after a merger between two organizations. For example, say a large company with an Exchange Server

messaging system buys another company that also has an Exchange Server messaging system. Until the

two messaging systems are merged together, the two Exchange Server organizations need to coexist.

Integration with another Exchange Organization can also occur between partner organizations.

When you integrate two Exchange Server organizations, you need to determine:

• The namespace to use. If a smaller organization merges with the larger organization, typically the

users in the smaller organization need to be given an email address that is in the domain of the larger

organization. If the organizations will share a single namespace, you need to determine how

messages will be routed to the appropriate mailbox. Alternatively, the two organizations can use

completely separate domain names.

•

Whether to synchronize the GAL. In most cases, you should synchronize the GAL between the twoorganizations. This makes it easier for users in each organization to address messages to the

appropriate people. However, if the integration is for a very short time period, you might not want to

make the effort required to configure GAL synchronization.

• Whether to synchronize free/busy information. If your organization uses calendars extensively for

booking meetings, you might want to configure synchronizing free/busy information between the

two organizations.




Designing Message Routing with Unique SMTP Namespaces

Key Points

By properly configuring message routing, you can ensure that messages are delivered to the intended

recipient. When each organization is assigned a unique SMTP namespace, the message routing is easier to

understand and implement. However, unique SMTP namespaces may not be desirable from a business

perspective, because it creates the appearance of unique organizations.

Note An Edge Transport server can perform address rewriting to make multiple

messaging systems with unique namespaces appear as a single namespace. To use addressrewriting, the email names for each email account must be unique across organizations.

If you use unique SMTP namespaces, the email address for a user changes when the user’s mailbox is

moved between the two messaging systems. This can be a problem, because the user will not receive

messages sent to the old address in the new mailbox. Users may not get important messages from

customers or internal staff, because they are unaware of the new email address. You can mitigate this

problem by forwarding messages from the old mailbox to the new Exchange Server 2010 mailbox.

You can create unique SMTP namespaces by using:

• Two separate domain names. You can use two separate domain names when two organizations are

merging. For example, in a merger between Contoso, Ltd., and A. Datum Corporation, the twodomains could be contoso.com and adatum.com.

• A domain and a subdomain. You can use a domain name and a subdomain name when one

organization is a subsidiary of another. For example, if Contoso, Ltd., is a subsidiary of A. Datum

Corporation, the domain names could be adatum.com and contoso.adatum.com.

The configuration of message routing varies depending on how you implement the physical infrastructure

for communication. If the two organizations have completely separate data centers and no direct link

between the two locations, you can use standard SMTP delivery over the Internet for messages.




If there are two data centers but there is a direct l ink between them, you can place messaging traffic on

the direct link instead of the Internet. To do this, create Send connectors in each organization to direct

messages to the appropriate IP address for delivery. Each Send connector is scoped with the domain

name for the other organization. If there are multiple locations with direct links, then you can create

multiple Send connectors to optimize delivery.

If there is a single physical location, you can configure both domains as accepted domains on theExchange Server 2010 organization. The second domain is configured as an external relay domain.

Exchange Server 2010 does not host any mailboxes for an external relay domain, but it does accept

messages for a forward relay domain. The messages for an external relay domain are forwarded from

Exchange Server 2010 to the external messaging system by using a Send connector. Centralizing message

delivery through Edge Transport servers simplifies antivirus scanning, and allows you to enforce

messaging policies, such as the application of a disclaimer.




Designing Message Routing with the Same SMTP Namespace

Key Points

You can use a single namespace for two messaging organizations. The second messaging organization

can be an Exchange Server organization, or a different SMTP messaging system.

You typically use a single namespace for two messaging systems temporarily, while two organizations are

merged. You should also configure the recipients of the smaller organization to accept email for both

their old domain and the new domain during the transition period.

To use the same namespace for multiple organizations, all messages are delivered first to the ExchangeServer 2010 organization. The Exchange Server 2010 organization is responsible for determining whether

the recipient is in the Exchange Server 2010 organization, or if the recipient is part of the second

messaging system. If the recipient is part of the second messaging system, the Exchange Server

organization forwards the message to that system for delivery.

To use a single namespace with two messaging organizations, you must perform the following

configuration steps:

1. Configure connectivity between the two messaging systems. The connectivity can be a direct link

between the two systems, or over the Internet.

2.

Configure the shared namespace as an accepted internal relay domain. This allows Exchange

Server 2010 to relay messages for which there is no matching recipient in the Exchange Server 2010

organization.

3. Configure a Send connector for the shared namespace. Exchange Server 2010 uses this Send

connector to forward messages to the other messaging system. This Send connector is only used

when there are no matching recipients in the Exchange Server 2010 organization.

4.

Configure mail exchanger (MX) resource records for the Exchange Server 2010 organization. Internet

messaging systems use the MX records to locate the Edge Transport servers of the Exchange

Server 2010 organization.




In addition to configuring the Exchange Server 2010 organization, you must also configure the other

messaging system to accept messages from the Exchange Server 2010 organization. In most cases,

outgoing messages from the other messaging system are also relayed through the Exchange Server 2010

Edge Transport servers to centralize management of external message delivery.

Question: When a namespace is shared between two messaging systems, is it possible for

one of the messaging systems to also have an additional domain name that is unique to thatmessaging system?




Designing Global Address List Synchronization

Key Points

GAL synchronization is an important part of maintaining two separate messaging systems. If you do not

configure GAL synchronization, users in each messaging organization have only recipients from their own

messaging organization available in the GAL when they address messages. By synchronizing GALs, you

can ensure that all recipients are available for addressing in both organizations.

When you synchronize the GAL of an external messaging system into Exchange Server 2010, the external

recipients are created as contacts. If only a small number of recipients are required, you can create the

contacts manually in the Exchange Server 2010 organization.

When you migrate mailboxes from the external messaging system to the Exchange Server 2010

organization, you need to synchronize the address lists. Before you migrate each mailbox to the Exchange

Server 2010 organization, you need to remove the contact for that user. When you migrate the mailbox,

the mailbox replaces the contacts in the GAL. On the external messaging system, you must remove the

mailbox and replace it with a contact containing the email address for that user in the Exchange

Server 2010 organization. If you plan to move a large number of mailboxes, you should automate this

process.

To automate GAL synchronization, you can use:

• Lightweight Directory Access Protocol (LDAP) replication scripts. To use LDAP replication scripts, the

external messaging system must support the use of LDAP to query mailbox information and createcontacts. Although this is possible for other Exchange Server organizations, it might not be possible

with other messaging systems. You must run LDAP replication scripts manually, or schedule them to

run periodically.




• Microsoft Forefront® Identity Manager 2010. This is a flexible tool for synchronizing information

between directories. Forefront Identity Manager has additional capabilities for synchronizing

information compared to LDAP, and can therefore synchronize data between a wider range of

systems. It can also perform dynamic updates based on events such as creation of new users, and

mailbox moves.

Note Previous versions of Forefront Identity Manager 2010 are called Microsoft Identity

Lifecycle Manager, and Microsoft Identity Integration Server.

Federated sharing is another alternative for sharing contact information between organizations. You can

implement federated sharing to allow specific users in your Exchange Server 2010 organization to share

contacts with specific users in another Exchange Server 2010 organization. This does not synchronize the

GAL between the two Exchange Server organizations, but can be useful for organizations where limited

integration is desired, such as for partners or subsidiaries.

Question: Which GAL synchronization methods should you use to migrate 5,000 users from

an external messaging system to Exchange Server 2010?




Designing Calendar Interoperability

Key Points

By implementing calendar sharing between messaging systems, you can allow users to view the schedule

of users in the other organization when sending meeting requests. The level of importance for this

capability is based on how your organization uses meeting requests, and how long coexistence of the two

messaging systems will be in place. For example, calendar interoperability is important for your

organization if you configure all meeting rooms in your organization as resources, and users in both

messaging systems need to book those rooms. Typically, you configure calendar interoperability only

between Exchange Server organizations.

You have the following options for sharing calendar data:

• The Availability service in Exchange Server 2010 or Exchange Server 2007. You can configure a Client

Access server in one Exchange Server organization to use the Exchange Server Availability service on

the Client Access server in the other Exchange Server organization. This gives the first organization

the ability to read calendar information of the second organization.

• Federated sharing for Exchange Server 2010. This solution is designed for ongoing interoperability

between Exchange Server organizations. One feature of federated sharing is the ability to share

calendar information in a selective and controlled way. However, both organizations must be using


•

The Inter-Organization Replication (IORepl) tool in Exchange Server 2003. The use of IORepl tosynchronize public folder data is supported for Exchange Server 2010 with Service Pack 1 (SP1) or

newer. However, IORepl must be run on the Windows Server® 2003 operating system, and one of the

endpoints for replication must be Exchange Server 2003 with SP2. So, it is not possible to use IORepl

for replication between two Exchange Server 2010 organizations.




Sharing calendar information can be complex to implement. In some cases, it may be preferable to use an

alternative. Alternatives to sharing calendar information between Exchange Server organizations are:

• Mailboxes in both systems. If only a few users need access to calendars in the second Exchange Server

organization, the simplest method may be to give those few users a second mailbox in the second

Exchange Server organization. The user now has two mailboxes that you need to maintain. However,

you can configure a forwarding address on one of the mailboxes to centralize all messages in a singlemailbox.

• Shared calendar in the Microsoft SharePoint® services. SharePoint is a web-based solution designed

for collaboration. One feature of SharePoint is calendars that multiple users can access. This can be

useful for shared events calendars, and for booking resources, such as meeting rooms.

Question: Can you think of an advantage for using federated sharing over the Exchange

Server Availability service between organizations?




Lesson 2

Designing Exchange Server 2010 Integration withFederated Partners

Integration with federated partners allows you to share calendaring information and contacts between

organizations. To configure federated partners, you must understand how to create a federated trust, and

then implement an organization relationship or a sharing policy.


• Describe federated sharing.

• Describe the considerations for designing federated trust and certificates.

• Design organization relationships.

• Design sharing policies.




What Is Federated Sharing?

Key Points

If you implement a federation trust for your organization, you can implement federated sharing with

other organizations and external users. The external organization must also have configured a federation

trust.

Federated Sharing

You can use federated sharing to configure your Exchange Server 2010 organization to share information

with other Exchange Server 2010 organizations. This shared information can include availabilityinformation, calendar information, and contacts.

To configure federated sharing, you must create a federation trust for your organization, and configure

organization relationships or sharing policies. This is a much simpler process than other methods for

sharing calendar and contact information between organizations. However, this method does not

synchronize all GAL information; only user contacts are shared.

To participate in federated sharing, user mailboxes must be on an Exchange Server 2010 Mailbox server.

Organization relationships or sharing policies define the information that is shared.




Considerations for Designing Federation Trusts and Certificates

Key Points

To perform federated sharing, you need to configure a federation trust. The Microsoft Federation

Gateway is used as a central point for federation trusts. You can create a single federation trust with the

Microsoft Federation Gateway, and have the other organizations do the same. You cannot create

federation trusts directly with other organizations.

To implement a federation trust with the Microsoft Federation Gateway, you need to obtain a certificate

from a trusted certification authority (CA). The certificate is used to sign and encrypt tokens, but not to

identify your organization. Therefore, the subject name in the certificate is not relevant.

After you create the federation trust, you are provided with an application identifier for your organization.

To identify ownership of your Domain Name System (DNS) domain, you must create a text (TXT) resource

record in your domain that contains the application identifier.

The specific requirements for a certificate are:

• A trusted CA should issue the certificate. The accepted list of trusted CAs is provided in the Exchange

Server 2010 online help.

• The certificate must contain the subject key identifier (SKI) field. This is typical in certificates from

third-party CAs.

•

You must create the certificate by using the CryptoAPI, and not by Cryptography Next Generation.Both of these cryptography providers are available in Windows Server 2008. To ensure that you use

CryptoAPI, create the certificate request by using the New-ExchangeCertificate cmdlet, or by using

the New Certificate Wizard in the Exchange Management Console.




• The certificate must use the RSA signature algorithm. Select this option during certificate creation.

• The certificate must have an exportable private key. Select this option during certificate creation.

Question: How will you obtain the list of acceptable CAs?




Designing Organization Relationships

Key Points

You can use organization relationships to enable federated sharing with an external Exchange Server

2010 organization. The external Exchange Server 2010 organization must also have a federation trust in

place with the Microsoft Federation Gateway. Each organization relationship is for a single external

organization identified by its domain name and application identity.

When you create an organization relationship, you can select the following options:

•

Enable this organization relationship. Use this option to toggle the organization relationship off andon. If your organization no longer wants to share information with the external organization, you can

quickly disable the organization relationship to stop sharing information.

• Enable free/busy information access. Use this option to specify that your organization will obtain

free/busy information from the external organization. Your access to free/busy information in the

external organization is determined by the configuration of the organization relationship in the

external organization. In most cases, this is enabled.

• Specify free/busy data access level. Use this option to control the free/busy information that your

organization provides to the external organization. You can allow no access, access to times only, or

access to time, subject, and location. To preserve privacy for your organization, prevent access to

subject and location when only basic meeting bookings are required.

•

Specify a security distribution group that indicates what internal users’ free/busy data is accessible.

Use this option to limit the user calendars that are accessible to the external organization. This can be

useful if only one part of your organization is collaborating with a partner on a project.

Note: Even if an organization relationship specifies that all user calendars are shared, users

can override this. Users can configure the default permissions for their own calendars to

prevent sharing. However, changing the default permission also affects sharing with internal

users.




To identify the external organization when creating the organization relationship, you typically use the

domain name of the external organization to automatically populate the necessary information into the

organization relationship. When you specify the domain name, all of the necessary configuration

information is obtained from the Microsoft Federation Gateway.

When you use the Exchange Management Shell, you can still obtain the federation information for the

external organization, but you must use the Get-FederationInformation cmdlet. This information can bepiped to the New-OrganizationRelationship cmdlet when creating the organization relationship.

You can obtain the URL for the Availability Web Service of the external organization by using

Autodiscover. If the external organization has not configured Autodiscover for access from the Internet,

you can enter the URL manually.

Sharing of availability performs best when users are using Microsoft Office Outlook® 2010 or Microsoft

Outlook Web App on an Exchange Server 2010 Client Access server. Office Outlook 2007 users can view

availability information for external users, but the users must be selected from the GAL, which means that

GAL synchronization must be in place. Users with mailboxes on Exchange Server 2007 with SP2 can use

Microsoft Outlook Web Access to view availability information for external users.

Question: Can you vary the users that share calendar information as part of each

organization relationship?




Designing Sharing Policies

Key Points

For controlling federated sharing, sharing policies are an alternative to organization relationships. You can

assign a sharing policy to specific mailboxes, and to determine what information a user can share with

external users. Instead of information being automatically available for users in an external organization,

the user in your organization sends a sharing invitation to the external user to share the calendar or

contacts. Although the organization containing the external user’s mailbox does not need to have a

federation trust, you should configure a federation trust to enable a two-way sharing relationship.

When you create a sharing policy, you can control the calendar information that is shared. You can

choose if you want to allow sharing of only free/busy information, or if you want to include the subject

and location, or the body. You also have the option to allow sharing of contacts. The information that is

allowed to be shared is controlled on a per-domain basis.

For a sharing policy to take effect, you must apply it to mailboxes. You can do this by using the properties

of the sharing policy, or the properties of the recipient. You can apply only a single sharing policy in each

mailbox.

After installation, a sharing policy called the Default Sharing Policy is created. This policy is automatically

applied to all Exchange Server 2010 mailboxes, and allows sharing of free/busy information with all

domains. Because of this policy, users can share their free/busy information with external users

immediately after you create a federation trust.

Only Outlook 2010 and Outlook Web App are capable of creating sharing invitations. Also, an Exchange

Server 2010 Mailbox server must host the user mailbox.

Question: Can you create a sharing policy to enable GAL synchronization between two

users?




Lesson 3

Designing Exchange Server 2010 Integration withOffice 365

Office 365 is a suite of cloud-based services that includes Exchange Online. You can integrate Exchange

Online with your on-premises implementation of Exchange Server 2010. When you use Office 365, you

can implement single sign-on and directory synchronization to support your use of Exchange Online.

When you plan your implementation of Office 365, you need ensure uninterrupted service for users. Part

of your planning process needs to include message routing and how mailbox moves will be performed.


• Describe Office 365.

• Identify the deployment options for Exchange Online.

• Describe the options available for identify management with Office 365.

• Design directory synchronization with Office 365.

• Design message routing with Office 365.

• Describe mailbox moves for hybrid deployments.

•

Design mailbox moves for non-hybrid deployments.




What Is Office 365?

Office 365 is a suite of Microsoft could-based services. The services included in Office 365 are:

• Exchange Online. A hosted version of Exchange Server 2010 with services that vary depending on the

service plan.

• Microsoft Lync® Online. A hosted version of Lync that provides instant messaging and presence,

online meetings, audio and video calling, and screen sharing.

• SharePoint Online. A hosted version of SharePoint 2010 that you can use to host SharePoint sites in

the cloud.

• Office Professional Plus 2010. A suite of Office desktop applications that includes on-demand per-

user subscription licensing that is connected to the cloud.

• Office Web Apps. Web-based versions of Microsoft Office applications that you can access by using a

web browser rather than by installing locally.

Note Documentation often uses the term Office 365 when referring to Exchange Online.

Any reference to Office 365 email features refers to Exchange Online.

Exchange Online

You can obtain Exchange Online as a standalone product or as part of Office 365. The features availableto users vary depending on the service plan. The service plans available for Exchange Online are:

• Exchange Online Kiosk. This service plan limits mailboxes to 500 MB and allows only Outlook Web

App or a POP3 client to be used for accessing mail messages. Advanced features such as delegate

access or inbox rules are not supported.




• Exchange Online Plan 1. This service plan limits mailboxes to a total of 25 GB for the mailbox and

associated archive. Additional client protocols such as Internet message access protocol 4 (IMAP4),

Outlook Anywhere, the ActiveSync® technology, and Exchange Web Services are allowed. The

features supported by this plan are very similar to an on-premises implementation of Exchange

Server 2010.

•

Exchange Online Plan 2. This service plan limits mailboxes to a size of 25 GB but allows an unlimitedarchive size. All of the features of Exchange Online Plan 1 are supported, and in addition, litigation

hold is available.

Considerations for using Exchange Online

You can use Exchange Online to completely replace an on-premises implementation of Exchange Server

or to integrate with an existing on-premises implementation of Exchange Server. Some benefits of using

Exchange Online include:

• Reduction in server hardware and software maintenance.

• Predictable cost for Exchange Server 2010 services.

• Reduction in network utilization on the Internet connection for roaming users.

• Anti-spam and antivirus scanning is provided by Forefront Online Protection for Exchange (FOPE).

In most cases, organizations use Outlook Anywhere to connect to Exchange Online. This provides the

same features as an on-premises implementation of Exchange Server 2010.

Potential concerns for using Exchange Online include:

• Public folders are not included.

• Increased network utilization on the Internet for internal users.




Deployment Options for Exchange Online

You can use Exchange Online for all mailboxes in your organization, or you can implement a hybrid

deployment with some mailboxes hosted on-premises. Which option you select depends on your business

needs.

Exchange Online only

If all mailboxes are hosted in Exchange Online, users typically access their mailbox by using Outlook

Anywhere. Both roaming and local users connect to Exchange Online over the Internet to send and

receive email and to perform other mailbox actions. All incoming Internet email is delivered directly toExchange Online.

By moving all mailboxes to Exchange Online, you gain the following benefits:

• No local hardware.

• Flexible licensing based on current needs.

• Automatic upgrades and updates for Exchange Server 2010.

• Many Exchange Server 2010 management functions, such as performance monitoring and tuning, are

managed by Microsoft.

Hybrid Deployment

A hybrid deployment has a combination of mailboxes hosted in an on-premises deployment and inExchange Online. This allows for coexistence that includes the following functionality:

• Mail routing between Exchange Online, the on-premises deployment, and the Internet for a single

namespace.

• Management of all mailboxes can be performed by using the Exchange Management Console or

Exchange Management Shell in the on-premises location.

• Mailboxes can be moved between Exchange Online and the on-premises deployment.




• Calendars, including free/busy information, are shared between Exchange Online and the on-

premises deployment.

• GAL synchronization is performed between Exchange Online and the on-premises deployment.

• Multi-mailbox search can be performed across mailboxes in Exchange Online and in the on-premises

deployment.

Note A hybrid deployment manages messaging between two separate Exchange

organizations. Consequently, some functions do not work across organizational boundaries.

For example, you cannot assign a Full Mailbox, Send As, or Send on Behalf of permissions

across organizations.

A hybrid deployment is often used when larger organizations are migrating to Exchange Online. The

hybrid deployment helps to ensure uninterrupted messaging functionality for users during the migration.

A hybrid deployment can also support mobile users. Mobile users may have faster or more reliable

connectivity to Exchange Online than they do to the on-premises implementation of Exchange Server.

You can also use Exchange Online to store only personal archives. In this scenario, user mailboxes are inthe on-premises implementation of Exchange Server 2010, but archives are stored in Exchange Online.

Messages can be moved to the personal archive manually by the users or automatically by using archive

policies.




Options for Identity Management

One of the important considerations for implementing Office 365 is how users log on. You can use either

non-federated identity or single sign-on.

Non-federated identity

If you use non-federated identity, you manage user accounts in Office 365 and your local Active Directory

Domain Services (AD DS) implementation separately. Users have two sets of credentials for accessing

resources, and passwords are not synchronized between the two accounts. This can result in user

confusion when passwords are changed.Non-federated identity is easy to implement, but it generally requires more user training and additional

help desk resources.

Single sign-on

Single sign-on is more complex to implement than non-federated identity, but it allows users to access

their Office 365 mailbox by using the same username and password that they use for AD DS in your

location. Using the same username and password for authentication reduces user confusion and help desk

calls.

You enable single sign-on by installing Active Directory Federation Services (AD FS). AD FS is installed on a

server at your site and manages credentials in coordination with Office 365 servers. You must also be

using the Microsoft Online Services Directory Synchronization Tool.For medium-sized and large organizations, the extra complexity of single sign-on is typically outweighed

by the benefit of lower support costs. In most




Designing Directory Synchronization with Office 365

You can use the Microsoft Online Directory Synchronization tool to synchronize information between

Office 365 and your on-premises deployment of AD DS. To implement a hybrid deployment or single

sign-on, you must use this tool.

When all mailboxes are hosted in Office 365, use the Directory Synchronization tool to add user accounts

from AD DS to Office 365. When the accounts are synchronized from AD DS, the user information is the

same in Office 365 as it is in the on-premises deployment of AD DS. New users in AD DS are automatically

added to Office 365, where mailboxes can be created. The default configuration of Directory

Synchronization is one way.

In a hybrid deployment, you should enable two-way synchronization. This way, the GAL is properly

synchronized between Office 365 and the on-premises Exchange Server organization. For example, a

mailbox created in Office 365 is synchronized as a contact in the on-premises Exchange Server

organization.

Two-way synchronization is required for the following features:

• Archiving on-premises mailboxes to Office 365.

• Moving mailboxes from Office 365 to the on-premises Exchange Server organization.

• Synchronizing Safe Sender and Blocked Sender lists from Office 365 to the on-premises Exchange

Server organization.• Synchronizing voice mail notifications from Office 365 to the on-premises Exchange Server

organization.






Messages between the on-premises Exchange Server organization and Office 365 are treated as internal

email. This means features that differentiate internal and external messages such as out of office

messages, operate correctly for all users regardless of the mailbox location.




Mailbox Moves for Hybrid Deployments

If you have a hybrid deployment and you move mailboxes between Office 365 and the on-premises

Exchange Server organization, the moves are remote mailbox moves. To perform remote mailbox moves,

you need to enable the Mailbox Replication Proxy Service (MRSProxy) on your Client Access servers. The

MRSProxy is not enabled by default.

In the RTM version of Exchange Server 2010 and with SP1, you need to modify a web.config file located in

the ews folder to enable the MRSProxy. In Exchange Server 2010 with SP2, you enable the MRSProxy by

using the Set-WebServicesVirtualDirectory cmdlet with the –MSRProxyEnabled $true parameter.

The speed of mailbox moves is limited by the speed and latency of your Internet connection. However,

you can move a mailbox much faster than you can copy a file of the same data size. You should perform

tests to determine the throughput of your move process to understand how quickly you can move

mailboxes.

You can move individual mailboxes from the on-premises Exchange Server organization to Office 365, but

you need to understand the impact of those moves:

• The mailbox is soft deleted when the move is complete. If there are problems with the moved

mailbox, you can recover the soft deleted mailbox for the time period that is set in the deleted

mailbox retention limit for the mailbox database.

• The user account becomes a mail-enabled user account after the mailbox is moved. This way, the

account remains in the GAL of the on-premises Exchange Server organization.

• Distribution list memberships are not affected. In each Exchange Server organization, the user

account is already a member of the distribution list. In the on-premises Exchange Server organization,

the group member changes from being a mailbox user to being a mail-enabled user.




• Delegate and folder permissions are migrated. When you move a resource mailbox, the delegates

for the mailbox are preserved. However, the permissions are not valid unless the delegate and the

resource mailbox are both migrated. If you move a resource mailbox first and the delegate later, the

delegate has proper permissions after the delegate mailbox move is complete.

• Send As and full mailbox permissions are not migrated. When you move a mailbox, the Send As

and full mailbox permissions are not retained. Send As and full mailbox permissions are also notsupported for users outside of the Exchange Server organization.




Designing Mailbox Moves for Non-Hybrid Deployments

If you are not using a hybrid deployment, there are still several other methods for moving mailboxes from

an existing messaging system to Office 365. Which method you select depends on the source messaging

system, whether you want to maintain coexistence, and the number of mailboxes to be moved.

Cutover Migration

A cutover migration can be used to migrate mailboxes from Exchange Server 2010, Exchange Server 2007,

or Exchange Server 2003 to Office 365. In a cutover migration, there is no coexistence between the

existing messaging system and Office 365. When the cutover migration is complete, all mailboxes andother messaging information are located exclusively in Office 365. This method is suitable only for

organizations of 1,000 mailboxes or less, because there is no coexistence.

During the migration, the following data is migrated:

• Mailboxes

• Distribution lists

• Contacts

Staged Migration

A staged migration can be used to migrate mailboxes from Exchange Server 2007 or Exchange

Server 2003 to Office 365. In a staged migration, there is coexistence between the existing messagingsystem and Office 365. You must configure coexistence and directory synchronization between the on-

premises Exchange Server organization and Office 365 before you perform a staged migration.

During the migration, only user and resource mailboxes are migrated. Directory synchronization is used to

migrate user accounts, distribution lists, and contacts before mailboxes are migrated. While directory

synchronization is active, the on-premises AD DS is authoritative, and any changes to user properties

should be done in AD DS.




IMAP Migration

IMAP migration uses the IMAP protocol to copy mailbox contents from to mailboxes in Office 365. Like in

a cutover migration, there is no coexistence between the source messaging system and Office 365. After

IMAP migration is complete, all messages are delivered to Office 365.

In most cases, IMAP migration is used to non-Exchange Server messaging systems or Exchange 2000

Server. IMAP migration does not migrate calendar data. However, you can select which folders aremigrated, so you can avoid migrating deleted items and junk mail.




Lesson 4

Designing Single Sign-On for Office 365

Single sign-on simplifies access to Office 365 resources. When it is implemented, users can log on by using

AD DS credentials, just as they would on-premises. To implement single sign-on, you need to understand

how to implement AD FS. This includes the AD FS topology and certificates.


• Describe the requirements to implement single-sign on.

• Design an AD FS topology.

• Select appropriate certificates for AD FS.




Preparing for Single Sign-On

Single sign-on allows a user to access a mailbox in Office 365 by using the credentials stored in the on-

premises AD DS. This makes access to Office 365 mailboxes easy for users.

AD FS 2.0 is required to implement single sign-on for Office 365. You can use an existing deployment of

AD FS, or you can create a new deployment. AD FS 2.0 is a server role in Windows Server 2008 and

Windows Server 2008 R2.

A federated trust is also required to implement single-sign on. The federated trust allows authentication

tokens from AD FS to be securely passed between the on-premises environment and Office 365.AD DS requirements for single sign-on are as follows:

• AD DS must be running on Windows Server 2003 or newer.

• You must configure a user principal name (UPN) suffix that matches the domain you are using for

single sign-on. This should match the user’s email address.

• The domain must be a publicly registered domain name.

• The Office 365 UPN for the user must match the UPN in the on-premises AD DS. If you modify the

UPN after configuring directory synchronization, you must use the Set-MsolUserPrincipalName

cmdlet in the Microsoft Online Service Module for the Windows PowerShell® command-line

interface in order to modify the user’s UPN on Office 365.




Designing an AD FS Topology

AD FS uses a trust relationship between organizations to allow users in one organization to access

resources in another organization. In the case of Office 365, users in the on-premises AD DS are allowed

to access Office 365 mailboxes. User authentication is performed by on-premises AD FS servers, and the

security tokens generated by AD FS are trusted by Office 365.

AD FS has the following server roles:

• Federation server. A federation server issues security tokens that contain claims. Claims in a security

token can include a user’s name or role. The security token is provided to the trusting organization.This role is placed on the internal network.

• Federation server proxy. A federation server proxy is used to provide access to the federation server

from the Internet. To support any user that is not located on the internal network, you must

implement a federation server proxy. This role is placed in a perimeter network.

Note You can use a third-party reverse proxy, Microsoft Forefront Unified Access Gateway

(UAG), or Forefront Threat Management Gateway (TMG) as an alternative to using

federation server proxies.

To provide high availability, we recommend that you perform load balancing both for federation servers

and for federation server proxies. At least two federation servers and two federation server proxies shouldbe deployed.

The load balanced DNS names that are used to access the federation servers and the federation server

proxies must be the same. They must also be accessible from the Internet and must match the Federation

Service name that you configure. If these are not correct, the authentication request will fail.




Scalability

The number of federation servers and federation server proxies you require depends on the number of

users accessing Office 365. Use the guidelines in the following table.

Number of users Recommendation

1,000 users or less No dedicated AD FS servers are required. Install federation servers ontwo existing domain controllers. Install federation server proxies on twoexisting web or proxy servers in the perimeter network.

1,000 to 15,000 users Use dedicated AD FS servers. Install two federation servers and twofederation server proxies.

15,000 to 60,000 users Use dedicated AD FS servers. Install 3 to 5 federation servers and twofederation server proxies.




AD FS Certificate Requirements

Certificates are a critical part of implementing AD FS. You need to configure the certificates correctly on

both the federation servers and the federation server proxies.

Federation server certificates

Each federation server requires two certificates:

• SSL certificate. This certificate is configured on the Default Web Site in Internet Information Services

(IIS) to help to secure communication between the federation server, the clients, and the federation

server proxies. The subject in this certificate needs to match the DNS name that is configured as theFederation Service name, which also matches the DNS name configured for load balancing. This

certificate should be issued by a third-party CA to ensure that it is trusted by all computers.

• Token-signing certificate. This certificate is used to digitally sign security tokens for validation by

Office 365. The default configuration uses a self-signed certificate that is trusted within AD FS. We

recommend that you use the default certificate because AD FS manages this certificate automatically

and renews it as required. There is no need for this certificate to be issued by a CA.

Federation server proxy certificates

A federation server proxy requires a single certificate:

• SSL certificate. This certificate is configured on the Default Web Site in IIS to help to secure

communication between the federation server proxies, the Internet clients, and the federation servers.The subject in this certificate needs to match the DNS name that is configured as the Federation

Service name, which also matches the DNS name configured for load balancing. This certificate

should be issued by a third-party CA to ensure that it is trusted by all computers. Use the same

certificate as the SSL certificate on the federation servers, because they use the same subject name.




Lab: Integrating Exchange Server 2010 with OtherMessaging Systems

Lab Scenario


locations. A. Datum Corporation is an international corporation involved in technology research and

investment, and has successfully implemented Exchange Server 2010 for messaging and collaboration.

As part of the growth strategy for A. Datum Corporation, your organization has purchased their

competitor company, Northwind Traders. You must design the integration of your Exchange Server 2010

organization, and the POP3/IMAP messaging system of Northwind Traders.




Exercise: Designing Exchange Server 2010 Integration with Office 365

Scenario

After the purchase of Northwind Traders was finalized, the network group created a direct link between

the A. Datum Corporation data center and the Northwind Traders data center. User accounts, computers

accounts, and servers have been moved into the existing adatum.com domain.

The Northwind Traders data center is low on space. To reduce data center utilization, the existing

POP3/IMAP email system will be migrated to Office 365. You need to ensure that those users can receive

messages at their current email address ([email protected]) in addition to the new adatum.com

domain that your organization uses. The adatum.com address will be configured as the primary address.

All incoming messages for A. Datum Corporation are scanned by an Edge Transport server in London. All

outbound messages are stamped with a legal disclaimer that includes a graphical company logo. It is not

possible to add a graphical logo with Exchange Server 2010 transport rules. So, third-party software is

installed on the Edge Transport server in London to add the legal disclaimer.

There are 800 mailboxes at Northwind Traders.

The main task for this exercise is as follows:

5.

Document the required configuration for migrating Northwind Traders email to Office 365.

Task 1: Document the required configuration for migrating Northwind Traders email to

Office 365


A. Datum Corporation and Northwind Traders Integration Plan


Document Author

Date

Jason Carlson

5th June 2010


Determine how to migrate Northwind Traders email to Office 365.

Proposals

Question: Does this scenario require a hybrid implementation of Office 365?

Question: Will inbound routing be to the on-premises Exchange Server organization or toOffice 365?

Question: Will outbound routing be centralized or decentralized?

Question: How will you configure MX records?

Question: How will you migrate mailboxes to Office 365?

Question: Will you configure single sign-on?




(continued )

A. Datum Corporation and Northwind Traders Integration Plan

Question: Do you need to configure a UPN to support single sign-on?

Question: What AD FS servers do you require to support single sign-on?

Question: What certificates do you need to support single sign-on?


Results: After this exercise, you should have created a plan to migrate Northwind Traders email to

Office 365.





Review Questions

1. Does Exchange Server 2010 include specialized connectors for other messaging systems?

2.

How can Forefront Identity Manager help with GAL synchronization between two Exchange Server

organizations?

3. Which option for sharing calendar information can you use for both Exchange Server 2010 and

Exchange Server 2007?

4. Can Exchange Online be integrated with an on-premises Exchange Server organization?

Best Practices Related to Federated Sharing


• Use organization relationships for a large number of users to share calendar information with an

external organization such as a partner or subsidiary.

• Specify a security distribution group in an organization relationship to limit the sharing of calendar

data to specific users.

• Use sharing policies to allow users to share information directly with external users, and control the

information that can be shared.

• Provide users with Outlook 2010 or Outlook Web App to allow them to send sharing invitations.




Course Evaluation

Your evaluation of this course will help Microsoft understand the quality of your learning experience.

Please work with your training provider to access the course evaluation form.

Microsoft will keep your answers to this survey private and confidential, and will use your responses to

improve your future learning experience. Your open and honest feedback is valuable and appreciated.



A-1

Appendix AUnified Messaging in Microsoft® Exchange Server 2010

Contents:

Lesson 1: Planning the Unified Messaging Infrastructure A-3

Lesson 2: Planning the Unified Messaging Configuration A-17

Lesson 3: Planning the Unified Messaging Integration with Lync Server 2010 A-29



A-2 Unified Messaging in Microsoft® Exchange Server 2010

Module Overview

Unified Messaging in Exchange Server 2010 enables the integration of email messaging and voice

messaging into a single infrastructure. Once you deploy Unified Messaging in Exchange Server 2010, the

Exchange servers can provide services to voice messaging clients. For example, your users can access the

email messages in their mailbox by using a phone, and access voice messages in their mailbox by using a

messaging client such as Outlook. With Unified Messaging, users can also use their mobile device, Lync

Server 2010 client or Lync Server 2010 integrated phones to access information in their mailboxes.

After completing this appendix, you will be able to:

• Plan the Unified Messaging 2010 infrastructure.

• Plan the Unified Messaging 2010 configuration.

• Plan the Unified Messaging integration with Lync Server 2010.



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

Lesson 1

Planning the Unified Messaging Infrastructure

When you plan your Exchange Server 2010 Unified Messaging infrastructure deployment, you must

consider several design issues that may affect your ability to reach your organizational goals. These design

issues include:

• The goal of the Unified Messaging deployment

• Current telephony infrastructure

• Types of users (local and remote)


• Describe the Unified Messaging architecture and topology.

• Describe Unified Messaging infrastructure requirements.

• Identify business requirement.

• Identify Unified Messaging planning considerations.

• Discuss planning considerations for IP gateways.

• Plan for server scalability.

• Plan for high availability.




Unified Messaging Architecture and Topology

Key Points

Understanding how the signal or messaging flow in Unified Messaging 2010 occurs is important in the

design phase. The architecture of the Unified Messaging environment determines the topology. The signal

flow in Unified Messaging is the process by which communications traffic that is received by a Unified

Messaging server is routed in an Exchange Server 2010 organization. Depending on the type of incoming

message or call that is received by a Unified Messaging server, various transport protocols are used.

Voice calls that come into an Exchange Server 2010 organization can be received from users who are

inside or outside the organization. When a caller places a call to a Unified Messaging-enabled user's

telephone extension, and the user is unavailable to answer the call, the Private Branch Exchange (PBX)

forwards or routes the incoming call to an IP gateway, and then to the Unified Messaging server.

IP PBX

In a Unified Messaging system that uses an IP PBX, the IP PBX forwards the incoming message to the

Unified Messaging server. Either the IP gateway or the IP PBX translates or converts the incoming stream

into a voice over Internet Protocol (VoIP) protocol, such as the Session Initiation Protocol (SIP) for

incoming voice messages. The stream of IP data is then passed on to the Unified Messaging server. After

the Unified Messaging server receives the call, the Unified Messaging server processes the message, and

determines how to route the message to determine the destination of the message.

Voice

In an incoming call scenario that includes incoming voice messages, a Hub Transport server uses the

Simple Mail Transfer Protocol (SMTP) transport to submit the voice mail message to the Mailbox server. In

a routing scenario that includes multiple Hub Transport servers, the incoming voice mail message is first

submitted to the closest Hub Transport server, and is then routed to the appropriate Mailbox server that

contains the Unified Messaging-enabled mailbox.




Protocols

The Unified Messaging solution provides access to telephony systems by using the standard VoIP

protocols including SIP, and Real-Time Transport Protocol (RTP).




Infrastructure Requirements

Key Points

In each Unified Messaging deployment, there are required Exchange Server 2010 server roles that must be

deployed. These Exchange Server 2010 roles are in addition to other required infrastructure components

that must also be installed.

Mailbox Server Role

The Unified Messaging server communicates with the Mailbox server role to access user-mailbox contents.

This happens in two scenarios. The Mailbox server stores the personal greetings that users create to playfor their callers. The Unified Messaging server retrieves these greetings from the Mailbox server and plays

them when applicable.

When Unified Messaging subscribers call the Unified Messaging server to access their mailbox contents

via Outlook Voice Access, the Unified Messaging server directly accesses the Mailbox server to extract the

mailbox contents. All communications between the Unified Messaging server and the Mailbox server use

MAPI.

Hub Transport

The Unified Messaging server communicates with the Hub Transport server role to send messages to the

Mailbox server. When a caller leaves a voice mail for a Unified Messaging subscriber or sends a fax to a

Unified Messaging subscriber, the Unified Messaging server attaches the voice mail or fax to a message

and forwards it to the Hub Transport server using Simple Mail Transfer Protocol (SMTP).




Client Access

The Unified Messaging server communicates with the Client Access server role when a subscriber uses the

Play on Phone feature or when they reset their personal identification number (PIN) through Outlook

Web App. Using Play on Phone, a Unified Messaging subscriber can use Outlook 2007 or later, or Outlook

Web App to instruct the Unified Messaging server to send a voice mail to a telephone number. When the

user does this, the client communicates with Unified Messaging Web Services, which you install on a

Client Access server. Unified Messaging Web Services then uses SIP to communicate with the Unified

Messaging server, which instructs the VoIP gateway to place the phone call.

Unified Messaging Server

The Unified Messaging server works as the integration point between the voice messaging system and the

email messaging system. The Unified Messaging server accepts incoming calls and provides a variety of

services for voice clients, and then uses the other Exchange Server roles to store voicemail, or to provide

phone access to user mailboxes.

The Client Access server role, Hub Transport server role, Mailbox server role, and Unified Messaging server

role can coexist on the same computer in any combination.

VoIP PhoneThere are two types of VoIP phones available: software-based, and hardware-based. A software-based

phone — such as the Microsoft Lync 2010 — is a communications program that runs from a computer. A

hardware-based phone is similar to the types of phones found currently on desktops, except that they

have added functionality. Lync Server 2010 supports several types of phones, including IP desk phones

and USM phones.

Active Directory Domain Services

Active Directory Domain Services (AD DS) acts as a container for all the Unified Messaging objects and

their configuration settings. Each Unified Messaging object within Exchange Server 2010 is necessary to

support Unified Messaging in an Active Directory environment. Some Unified Messaging Active Directory

objects are created to logically represent a telephony hardware device, such as an IP with VoIP gateway.

Other Unified Messaging Active Directory objects are created to represent a telephony dial plan for an

organization, or to support a specific feature of Unified Messaging.

PBX

Exchange Server 2010 Unified Messaging relies on an IP gateway that can receive incoming calls from a

legacy PBX. Part of the planning process for PBX support is verifying that your PBX is supported by

Microsoft, and that there are configuration notes for the PBX.

The PBX configuration notes contain the configuration and other settings required to deploy a PBX with

Unified Messaging. The notes are organized based on manufacturer and model.

VoIP Gateway

If organizations have deployed a traditional PBX, they need to deploy a VoIP gateway. VoIP gateways arelocated between your telephony network and data network. A VoIP gateway converts the protocols

coming from the telephony network to a protocol understood by the Unified Messaging Server, such as

Session Initiation Protocol over Transmission Control Protocol (SIP/TCP). When you deploy Unified

Messaging, you must configure a Unified Messaging IP gateway to provide the connection to the VoIP

gateway.




Business Requirements

Key Points

There are a number of questions that must be answered in the planning stages of a Unified Messaging

deployment, to ensure that business requirements are met. These requirements must be researched prior

to planning for the deployment of Unified Messaging.

Determining the Overall Number of Clients and Volume of Calls

View call logs and monitor the network for voice sessions, when determining the overall number of a

clients and volume of calls for a customer. It is typical for a customer to underestimate both the volumeand duration of calls. A thorough analysis of customer voice traffic is required to ensure there are enough

servers and other equipment to support the voice traffic and other traffic.

Determining the Number of Supported Users

The total number of expected supported users will influence the number of servers deployed. A small

company can be easily supported by a single Unified Messaging server. However, medium and large

companies will require a reliable determination of the total number of expected users. Another factor

often overlooked is growth. Do not forget to include any expected or potential growth in the future.

What will the users use mainly? Will they just use voice mail available on the PBX, or will they use voice

mail that is voice-enabled for Lync Server 2010? If users are voice-enabled, you must factor in the

bandwidth for phone users. This does not include any bandwidth that conferencing might use. Bandwidth

for conferencing must be determined as well.




General Types of Codecs Used in Unified Messaging

A codec is a software program that transforms — or codes — digital data into an audio file format or audio

streaming format. It then converts the audio file, or decode, back to the digital format. The term codec is a

combination of the words "coding" and "decoding" and is used with digital audio data. Codecs can vary in

sound quality, the amount of bandwidth required to use them, and the system requirements needed to

do the encoding.

In Exchange Server 2010 Unified Messaging, there are two general types of codecs used:

• The codec that is used between IP/VoIP gateways

• The codec that is used to encode voice messages

Deciding which codec to use is dependent on the advantages and disadvantages inherent with each.

Deciding which to use is dependent on bandwidth and compression.

How Codecs Are Used to Encode Voice Messages

The Windows Media Audio (WMA) is the default codec used in Unified Messaging. It was selected for this

role due its sound quality and compression properties. The Group System Mobile 06.10, and G.711 Pulse

Code Modulation (PCM) Linear audio codecs are used to create .wma and .wav audio files for voicemessages in support of other messaging systems. However, the file type that is used depends on the

audio codec that creates the voice message audio file.

In Exchange Server Unified Messaging, the .wma audio codec creates .wma audio files, and the Global

System for Mobile Communications (GSM) 06.10 and G.711 Pulse-code modulation (PCM) Linear audio

codecs produce .wav audio files. However, depending on the codec that is used, an audio file in .wma or

.wav format is sent together with the email message to the intended voice mail recipient. The size of the

Unified Messaging voice message depends on the size of the attachment that holds the voice data.

Additionally, the size of the attachment depends on the following factors:

• The duration of the voice mail recording

• The audio codec that is used

• The audio file storage format

The Effect That Concurrent Connections Have on Planning the Number of Servers

Remote users and the number of concurrent connections will influence the number of servers. A Unified

Messaging server can accept 100 concurrent voice messages by default. Single Unified Messaging servers

can be configured to accept a maximum of 200 concurrent voice messages.

In branch office scenarios or over wide area network (WAN) connections, use the G.723.1 codec instead of

the G.711 µ or G.711A codec to minimize the network traffic that is passed between your IP gateways and

your Unified Messaging servers.




The following table outlines codecs and how they can be used.

Codec Description

G.723.1 • Provides for high quality and high compression

• Must be licensed

G.711 µ-law •

Is a standard codec used for audio codes

• Is used in North America and Japan

G.711 A-law • Is a standard codec used for audio codes

• Is used in Europe and elsewhere

G.711 VoIP codec • Uses 64 kilobits per second (Kbps) bandwidth

G.723.1 • Uses 5.3/6.3 compressed Kbps bandwidth

G.711 • Requires very low processing, but does require 128Kbps for two-waycommunication

• Offers poorer audio quality

G.723.1 •

Offers high compression, with increased processing time




Planning Considerations

Key Points

In most deployment scenarios, it is generally advisable to keep the Unified Messaging topology as simple

as possible. Large enterprises with complex network and telephony environments, multiple business units,

or other complexities, require more planning than smaller organizations with relatively straightforward

Unified Messaging needs. This is especially true when integrating Unified Messaging with a legacy PBX

system.

There are many areas that you must consider or evaluate to be able to successfully deploy the

infrastructure required by Exchange Server 2010 Unified Messaging. You must understand the different

aspects of Exchange Server 2010 Unified Messaging, and each component and feature, so that you can

plan your Unified Messaging infrastructure and deployment appropriately.

Typical Issues

Allocating time to plan and work through the following issues will make deployment more successful.

• Telephony network and current voice mail system. What is your current telephony network, and can it

be used in a Unified Messaging environment? Is your PBX supported by Microsoft? Are there

configuration notes available?

• Current data network design. What is your physical topology? Do you have multiple sites? How are

these sites connected? Are the multiple sites based on a Hub-Spoke method? Are the sites based on a

full-mesh method?

• AD DS environment. What is your logical topology? Do have more than one forest? Do you have

multiple Active Directory sites? What are the links between the sites?

• Are the PBXs networked? Are they centralized, or located in multiple locations? Placement of IP/VoIP

gateways, telephony equipment, and Unified Messaging servers is very important. In most design

scenarios, you must minimize the number of hops the packets must make between the PBX to the

VoIP gateway and telephony equipment.




• Place the physical components in close proximity to each other. The connection point between the

phone system and the Unified Messaging server is the IP gateway. These means that both the PBX

and the Unified Messaging servers should be deployed on the same fast physical network as the IP

gateway.

• Exchange Server roles and Unified Messaging servers. Are any roles collocated, and if so, does the

server have the capacity to run multiple roles at once?

• WAN termination. This is important if you have multiple sites. You should consider terminating them

close to where your telephony equipment is located.

• Codec. The higher the sampling rate, the more bandwidth used and the larger the attachments for

voicemail. The most highly compressed codec used is WMA, where a 5 minute voice mail would be

approximately 250 kilobytes (KB). If other codecs are used, that same 5 minute voice mail would easily

exceed 5 megabytes (MB) in size.




Planning Considerations for VoIP Gateways

Key Points

Properly configuring and deploying IP/VoIP gateways for your organization is a critical step. This must be

done correctly to successfully deploy Exchange Server 2010 Unified Messaging. Microsoft maintains a

website that lists compatible IP gateways, as well as the required configuration notes and files that you

must have to correctly deploy your organization's IP/VoIP gateways to work with Exchange Server 2010

Unified Messaging. It is equally important to match the number of IP/VoIP gateways that you have in your

environment, to the number of Unified Messaging servers that are available.

Unified Messaging and IP/VoIP

Unified Messaging relies on the ability of the IP/VoIP gateway to translate time division multiplexing

(TDM) or telephony circuit-switched based protocols—such as Integrated Services Digital Network (ISDN)

or Q signaling (QSIG)—from a PBX, to protocols based on VoIP or IP—such as SIP, RTP, or T.38—for real-

time facsimile transport.

IP/VoIP gateways are available from multiple manufacturers, in sizes and models that range from 4 to 32

ports. You can deploy as many IP/VoIP gateways as necessary to provide for capacity and fault tolerance.

If the number of calls or ports that are required is larger than the number of calls or ports that are

supported by a single IP/VoIP gateway, you can increase the number of ports or the number of calls that

can be accepted by installing and configuring additional IP/VoIP gateways, creating the Unified

Messaging IP gateway object, and configuring the appropriate hunt groups to support your environment.

Multiple IP Gateways

IP gateways that are supported by Unified Messaging can be configured to route calls to Unified

Messaging servers in a round-robin (a local balancing mechanism used by Domain Name System (DNS)

servers to share and distribute network resource loads)

manner. To enable an IP gateway, you must

configure each IP gateway with the IP address (or addresses) of your Unified Messaging servers that

answer calls from the IP gateway. These are the Unified Messaging servers that are associated with the

same dial plan as the Unified Messaging IP gateway object, which logically represents the IP/VoIP






Planning for Server Scalability

At a high level, there are two options for increasing the capacity of the Unified Messaging server

environment. One option is to deploy more powerful servers as Unified Messaging servers. For example,

you can increase the speed or number of processors on the servers, increase the RAM or increase the

network adapter capacity to enable a single server to handle more concurrent calls.

The second option for increasing capacity is to deploy more Unified Messaging servers. As a single server

reaches its capacity for concurrent calls, you can simply deploy another server and associate it with the

same dial plan as the existing server.

Choosing the best option for an organization will depend on several factors:

• Exchange Server deployment. If the organization has a single data center and all Exchange servers are

deployed in that data center, then you will need to deploy all Unified Messaging servers in that data

center as well. This makes it more likely that you will increase the power of the Unified Messaging

server. If the organization has multiple locations with Exchange servers deployed, you are more likely

to deploy multiple Unified Messaging servers across the locations. If the number of users in an office

is low, you may choose to deploy a less powerful Unified Messaging server, or even collocate the

Unified Messaging server with other Exchange Server roles.

• Availability requirements. If your Unified Messaging environment must be highly available, you may

choose to deploy multiple less powerful Unified Messaging servers in the same dial plan so that they

can provide redundancy for each other.

• IP gateway deployment. There are many different capacity options available when choosing an IP

gateway. It is important to match the capacity of the IP gateways with the capacity of the Unified

Messaging servers that will use the IP gateways.




Planning for High Availability

In most organizations, email messaging and the phone system are considered critical components that

must always be available. Because the Unified Messaging server role provides an integration point

between the two systems, it is important that this server role also be highly available. To implement high

availability, consider the following:

• Configure the Unified Messaging servers with redundant hardware components. Like any other

Exchange Server role, you should begin the high availability design by ensuring that the server has

redundancy at the hardware level. This might include adding multiple network adapters to the server

and configuring network teaming or adding multiple power supplies to the server.

• Deploy multiple Unified Messaging servers. To protect against a single server failure, you can deploy

multiple Unified Messaging servers and add them to the same dial plan. When you add multiple

servers to a single dial plan, the IP gateway will try to connect to the first Unified Messaging server. If

the Unified Messaging server is unavailable, the IP gateway will try to connect to the Unified

Messaging server again after 5 seconds. If there is no response from the server, the IP gateway will try

to connect to the next configured Unified Messaging server.

• Deploy multiple IP gateways. The IP gateway must also be highly available to ensure that the

connections between the PBX and the Unified Messaging server are available.

• Ensure the high availability of the other Exchange Server roles. The Unified Messaging server depends

on the other Exchange 2010 server roles to provide full functionality. As part of planning the UnifiedMessaging server availability, you also need to make sure that the other server roles are also highly

available.




Lesson 2:

Planning the Unified Messaging Configuration

Planning and deploying Exchange Server 2010 Unified Messaging requires the coordination of telephony,

IT, and Exchange Server administrators. This lesson discusses how to develop a plan to deploy and

configure Exchange Server 2010 Unified Messaging for your organization.


• Plan hardware infrastructure requirements.

• Plan the Unified Messaging dial plan object.

• Plan the hunt group object.

• Plan the server objects.

• Plan the mailbox policy objects.

• Discuss Unified Messaging clients.

• Plan the deployment process for Unified Messaging.






Unified Messaging Dial Plan Object

Key Points

A dial plan object is a container object in AD DS that logically represents a set or grouping of PBXs that

share common user extension numbers. In practical terms, users' extensions hosted on PBXs share a

common extension number. Users can dial one another’s telephone extensions without appending a

special number to the extension, or dialing a full telephone number. A UM dial plan is a logical

representation of a telephony dial plan. All users within a dial plan have a unique extension number, and

the combination of dial plan and the user extension uniquely identifies each Unified Messaging user. After

creating the UM dial plan, you need to associate it with a UM server.

The UM dial plan is the basic administration unit in Unified Messaging. It is the telephony extension

numbering plan. Within Unified Messaging, the dial plan plus the extension number provides the unique

identifier for each Unified Messaging user. The dial plan controls the numbering scheme and the

outbound dialing plan. It also represents a logical link that establishes a connection between the users

within a UM dial plan and their telephony network.

Determining an Effective Numbering Plan

Determining an effective numbering plan is based on several factors:

• Does the numbering plan denote the physical sites or departments? One option is to have a different

numbering plan for each physical location, similar to a Dynamic Host Configuration Protocol (DHCP)

address scheme.

• What is the number of users, and is growth factored into the numbering plan? Basing a dial plan on

the current number of users may make your ability to expand the plan more difficult at a later time.




• Numbering plans are determined by several factors: the number of employees in your organization,

the departments, and their physical structure. You may use a numbering plan that denotes not only

the extension, but where the extension is located or the department.

• How are international sites numbered? You are likely limited in your ability to have a standardized

numbering plan with overseas offices.

How Unified Messaging Uses Dial Plans

The UM dial plan is an Active Directory container object that is a logical representation of a telephony dial

plan configured on a PBX. The UM dial plan establishes a link from an Exchange Server 2010 recipient’s

telephone extension number in AD DS, to a Unified Messaging-enabled mailbox. Unified Messaging uses

dial plan information, such as the number of digits on an extension. When you configure an Exchange

Server 2010 UM dial plan, you enter the extension length.

Other Dial-Plan Settings

You also can configure many other dial-plan settings, including:

• Greetings for when dial-plan subscribers call into the UM server.

•

Dial codes for dialing external phone numbers and international numbers. This is designed to limitthe range of calls a user can place. You might allow users to call only local numbers, and control this

by specifying the specific area codes that can be dialed. You can also use this to prohibit calls to a

specific area code, such as area code 900 numbers. You must remember that some metropolitan

areas have a number of area codes associated with them, or may border another state with differing

area codes. For example, Chicago, Illinois has seven area codes to encompass the downtown area, as

well as the suburbs.

• Features such as whether subscribers can transfer callers to other users, and who callers can contact.

By default, the ability to transfer calls is enabled. If you need to disable this feature due to corporate

policy, you can disable it.

• Time limits for calls, messages, and idle timeouts. You can limit the amount of time that an incoming

call can be connected to the system without being transferred to a valid extension. You can set thistimeout value from 10 to 120 minutes. Setting the time too short could cause a call to be dropped

before finally connecting. The usual setting for this value is 30 minutes.

• Default language for voice prompts. If you are in a multi-language environment, you can install the

appropriate Unified Messaging language pack. A user can then access a second language to play

their personal greeting, use the text-to-speech engine, or play Calendar items.




UM Hunt Group Object

Key Points

A hunt group is an extension that is defined as a group or section, such as with a help desk or call center.

It is the means of forwarding calls from a single inbound number to a group or hunt group of extensions.

In most cases, a hunt group represents a set of identical resources shared by an application or a group.

This provides more efficient access to applications such as voice mail or an auto attendant, so callers will

not experience a busy signal; instead, the PBX hunts for an open line to which to connect them.

The UM hunt group object is a logical representation of an existing PBX or IP-PBX hunt group. When the

pilot number of a hunt group receives a call, the PBX or IP-PBX looks for the next available extension

number to which to deliver the call. When an incoming call is unanswered or busy, the PBX or IP-PBX

routes the call to the UM server. UM hunt group objects act as a connection or link between the UM IP

gateway and the UM dial plan. Therefore, you must associate a single UM hunt group with at least one

UM IP gateway and one UM dial plan.

UM hunt group objects locate the PBX hunt group from which the incoming call was received. A pilot

number that is specified for a hunt group in the PBX also must be specified within the UM hunt group.

The pilot number enables the UM server to interpret the call with the correct dial plan so that it can route

the call correctly.

Implementing UM Hunt Groups

When you create a new hunt group object, you enable UM servers in the specified dial plan tocommunicate with the IP gateway object. When creating a new UM hunt group object, you need to

specify the dial plan and the pilot identifier or pilot number to be used with the new UM hunt group.

You can implement a hunt group between the PBX and the VoIP gateway when you need a VoIP gateway

for Exchange Server Unified Messaging. This hunt group accesses Exchange Server Unified Messaging. It is

also the target for diverted calls for an auto attendant, for phone calls that are not answered, or for

phones that are busy.




You can have multiple UM servers associated with a single hunt group. A UM server can be configured to

support up to 200 simultaneous calls. If you estimate having more than that many simultaneous calls in

one group, then you would need to have multiple UM servers.

Pilot Number

A pilot number is the way the PBX identifies a hunt group. In other words, a pilot number is the address or

label for the hunt group. It is a dummy extension, one that does not have a person or phone associated

with it. It is the number to which a coverage path routes a call.

A PBX, when used with Exchange Server Unified Messaging, uses a pilot number to target a diverted ring,

no answer, or busy call to Exchange Server Unified Messaging so a message can be taken. This same pilot

number — or a different number — can be used by subscribers to access the messages in their Exchange

Server mailbox. A pilot number is also used for top-level access to an Exchange Server UM auto attendant.




Unified Messaging Server Object

Key Points

The UM server object performs directory lookups for recipient information in AD DS. Each Unified

Messaging-enabled user must be added to a dial plan, and must be assigned an extension number in AD

DS. This provides the user mailbox with a unique identifier.

How the UM Server Object Is Connected

The UM server is connected to either the UM IP gateway and the PBX, or both, which is dependent on

specific topology and existing telephony architecture. This connection is from the current telephonystructure outside of the Active Directory forest. Inside the Active Directory forest, the Client Access server

is connected to the UM server to provide access from the Internet for clients using Office Outlook,

Outlook Web App, and Exchange Server.

Default Concurrent Connections

A default deployment of the UM server can support up to 100 concurrent voice mail connections. A UM

server can be configured to support up to a maximum of 200 concurrent voice mail connections.

Estimating the number of concurrent connections is critical to ensuring there are enough UM servers.

Unified Messaging Server Directory Lookups

The Unified Messaging server performs directory lookups in AD DS in several different scenarios,

including:

• To locate the Mailbox server hosting the user mailbox so the Unified Messaging server can send voice

messages to the mailbox, or to extract the user’s personal greeting from the mailbox server.

• To locate a user’s prerecorded, spoken name from AD DS.

• To locate subscriber extensions and other attributes—such as department names or email

addresses—when users call the auto attendant.






• Requiring that the mailbox of each Unified Messaging-enabled user is linked to a single UM mailbox

policy. After you create a UM mailbox policy, you link one or more UM-enabled mailboxes to the UM

mailbox policy. This lets you control PIN security settings—such as the minimum number of digits in a

PIN, or the maximum number of logon attempts for the Unified Messaging-enabled users who are

associated with the UM mailbox policy.

•

Linking multiple Unified Messaging-enabled users to a single UM mailbox policy. A single user can beassociated with only one UM mailbox policy.

• UM mailbox policy settings are applied to the Unified Messaging-enabled users. The settings that are

defined on a UM dial plan and a UM mailbox policy are applied to all users who are associated with

the UM mailbox policy.




Unified Messaging Clients

Key Points

This topic describes Unified Messaging client features that give Unified Messaging-enabled users access to

their email and messages in their Exchange Server 2010 mailbox. The Unified Messaging client capabilities

enable you to provide users with simplified voice mail and email access options, and an improved overall

user experience.

Outlook Voice Access

Outlook Voice Access is an Exchange Server 2010 feature that enables subscribers to retrieve emailmessages from their individual mailbox using an analog, digital, or mobile telephone. They can then

interact with their mailbox using touchtone or voice commands. When Unified Messaging-enabled users

access their Exchange Server 2010 mailbox using a telephone, they are presented with a series of voice

prompts. These voice prompts help users navigate the Unified Messaging system, and enable users to

access their Exchange Server 2010 Inbox. Outlook Voice Access lets users retrieve, listen to, reply to,

create, and forward voice or email messages, and listen to or change calendar information.

Unified Messaging and ActiveSync Clients

The Exchange ActiveSync protocol is used to connect mobile clients — such as those found on Internet-

capable mobile phones — to an Exchange Server 2010 server and mailbox. There are many mobile phone

types that users can use to access their Exchange Server 2010 mailbox and view email messages, view and

change calendar information, and listen to their voice messages. When you use Exchange ActiveSync on amobile phone, you can listen to the attached .wma file that contains the voice mail message.




Unified Messaging Integration with Office Outlook 2007 and Office Outlook 2010Clients

Using Office Outlook 2007 or later, users can access their individual Exchange Server 2010 mailboxes and

view email messages in their Inbox, view and change calendar information, and listen to voice messages

using a Windows Media Player. The Windows Media Player is embedded inside the email messages on

their portable device or computer. Using the Outlook 2010 client, users gain additional features, such as

Play on Phone.

Unified Messaging Integration with Outlook Web App Clients

Outlook Web App provides users with a set of Unified Messaging interfaces and tools comparable to a

full-featured email client—such as Exchange Server 2010. As in earlier versions (known as Outlook Web

Access), users can access their Exchange Server 2010 mailbox using a Web browser. However, similar to

the Exchange Server 2010 email client, Outlook Web App offers users a Windows Media Player embedded

in the email message, which can be used to listen to voice messages, and enables users to access other

features such as Play on Phone.

Note The advanced Unified Messaging features found in the Outlook Web App Premiumclient—such as the voice mail configuration options—are not available in Outlook Web App

Light.




Process for Deploying Unified Messaging

Key Points

There are several steps involved in deploying Unified Messaging. First, you must decide upon a UM dial

plan configuration. To integrate with VoIP gateway, you must then configure a UM IP gateway. A hunt

group is created when you create an IP gateway. For users to have Unified Messaging capability, you must

enable them for Unified Messaging.

UM IP Gateway Object

You must create a UM IP gateway object. A UM IP gateway object represents a physical VoIP gatewaywith an IP address, from which a Unified Messaging server can receive calls. The Unified Messaging server

requires this information to connect to the VoIP gateway and the PBX.

Hunt Group Object

An IP gateway object contains hunt groups. You can associate one or more hunt groups with an IP

gateway. A default hunt group is created automatically if you create an IP gateway and associate it with a

UM dial plan. You can customize that hunt group, or create additional ones.

Enabling Users

User mailboxes must be UM-enabled to access Unified Messaging services. You must associate each user

mailbox with a UM mailbox policy, and a unique extension number. A UM mailbox policy specifies policy

properties, such as: the maximum greeting length, the number of unsuccessful login attempts before theUnified Messaging server resets the password, the minimum digits that a PIN requires, and restrictions on

international calling.




Lesson 3:

Planning the Unified Messaging Integration with LyncServer 2010

The integration of Lync Server 2010 and Unified Messaging is built around the concept of user presence.

Lync Server 2010 uses user availability, communication endpoints, and user relationships to connect

people using the most appropriate medium at any point in time. Since Lync Server 2010 ties together

voice, email, instant messaging (IM) and other communication paths, it can help you route messages in

the most productive way possible.

Note Lync Server 2010 is the newest version of Microsoft’s instant messaging,

conferencing and voice server. Lync Server 2010 replaces Office Communications Server

2007 R2, but many of the same Unified Messaging integration options are available in both

Lync Server 2010 and Office Communications Server 2007 R2.


• Describe the Lync Server 2010 features.

• Describe how Unified Messaging integrates with Lync Server 2010.

•

Plan for Unified Messaging and Lync Server 2010 integration.




Lync Server 2010 Features

Key Points

Lync Server 2010 changes how users access network communications. A central feature in Lync Server

2010 is the concept of user presence. User presence displays information about the current state for the

user – they may be online and available, online but in a meeting or busy, or offline. The user’s presence

follows them when they log on to a different computer, when they log on to their laptop at home, or

even when using a mobile device with a Lync client installed. Users are not denoted by a telephone

number—like they would be in a traditional PBX system, although they do have a number associated for

their account—but rather by their presence.

Lync Server 2010 Features

Some of the features in Lync Server 2010 include:

• Instant messaging. The Lync 2010 client provides IM functionality that is hosted by Lync Server 2010.

The solution provides IM features such as group IM, and extends the internal IM infrastructure to

external IM providers.

• Presence information. Lync Server 2010 tracks presence information for all Lync Server 2010 enabled

users. It provides this information to the Lync Server 2010 client and other applications, such as Office

Outlook 2007 or later, or within the Outlook Web App interface.

• Web and audio/video conferencing. Lync Server 2010 can host on-premise conferences, which can be

scheduled or unscheduled. They can include IM, audio, video, application sharing, slide presentations,

and other forms of data collaboration.

• VoIP telephony. Enterprise voice enables Lync Server 2010 users to place calls from their computers

by clicking an Office Outlook or Lync Server 2010 contact. Users receive calls simultaneously on all

their registered user endpoints, which may be a VoIP phone, mobile phone, or Lync 2010 client.




Benefits of Unified Messaging Integration with Lync Server 2010

Voicemail, Email, and IM Benefits

When Lync Server 2010 and Lync 2010 clients are integrated with the Unified Messaging capability in

Exchange Server 2010 SP1:

• Users can see if they have new voice mail either from the main Lync 2010 window or by looking at

the icon in the notification area at the bottom of the screen.

• Users can click the Play button on the voice message to hear the audio portion of messages, or use

Exchange Server 2010 SP1 to open the message in Outlook 2010 and view the transcript.

• Lync Server 2010 can divert calls to Exchange Unified Messaging, dynamically or on a static basis, as

well as allow users to connect to the Unified Messaging service to change their greetings or access

other voice functionality.

• Lync Server 2010 presence features encourage instant communication when possible, but also

provide information about whether a user is in a meeting or out of the office, indicating that instant

communication is not possible.

Message Waiting Indicator

Message Waiting Indicator is an Exchange Unified Messaging feature that notifies a user that they have a

new voice mail message. With Lync 2010, you no longer need to switch to Outlook to manage your voice

mail. You do not even need Outlook on your computer, because Lync 2010 will instead use ExchangeWeb Services (EWS). Lync 2010 can manage the read/unread state as you listen to the voice mail. Voice

mail can be played back from within Lync 2010. You can also reply directly to the voice mail from within

Lync 2010.




Unified Contacts

In environments that integrate Lync Server 2010 with Exchange Server 2010 SP1 Unified Messaging,

Exchange Server maintains a single unified contact store for contacts across Lync 2010, the Outlook 2010

messaging and collaboration client, and other endpoints, eliminating the need to maintain multiple

contact lists, and provides a consistent experience across programs.

All contact identities between Lync Server 2010, Exchange Server 2010, and other endpoints are sharedand remain one identity, with Exchange Server acting as the single contact store. Users may also rename

contacts or add other details to their contacts’ cards for additional context or personal reference.

Unified Conferencing

Lync 2010 integrates with Outlook to make scheduling, joining, and facilitating meetings easier. Lync 2010

is the only client needed for all types of meetings, both scheduled and spontaneous.

Outlook 2010 calendar integration also reflects Lync 2010 presence settings; for example:

• In a Meeting. The contact’s Outlook calendar shows that the contact has a scheduled meeting.

• Out of Office. The contact’s Outlook calendar or Out of Office Assistant indicates that he or she is out

of the office.






Step 5: Run the exchucutil.ps1 Script

On the Exchange UM server, open the Exchange Management Shell and run the exchucutil.ps1 script,

which does the following:

• Grants Lync Server 2010 permission to read Exchange UM AD DS objects; specifically, the SIP dial

plans created in the previous task.

• Creates a UM IP gateway object in AD DS for each Lync Server 2010 Enterprise Edition pool or

Standard Edition server that hosts users who are enabled for Enterprise Voice.

• Creates an Exchange UM hunt group for each gateway. The hunt group pilot identifier will be the

name of the dial plan that is associated with the corresponding gateway. These need to be mapped

one-to-one if there is more than one dial plan.

Step 6: Configure Lync Server 2010 Dial Plans

If you are integrating with Exchange Server 2007 (SP1) or higher, or Exchange Server 2010, create a new

Enterprise Voice dial plan with a name that matches the Exchange UM dial plan fully qualified domain

name (FQDN).

If you are integrating with Exchange Server 2010 SP1, ensure that suitable global/site-level or pool-levelEnterprise Voice dial plans have been configured.

Note If you are integrating with Exchange Server 2010 SP1, the Lync Server 2010 dial plan

and Exchange UM SIP dial plan names do not need to match.

Step 7: Run the Exchange Unified Messaging Integration Utility

On the Lync Server 2010 server, run ocsumutil.exe, which:

• Creates Subscriber Access and Auto Attendant contact objects.

• Validates that there is an Enterprise Voice dial plan with a name that matches the Exchange UM dial

plan FQDN.If you are running Exchange Server 2010 (SP1), the dial plan names do not need to match, and you can

ignore the tool’s warning about this.

This utility works by scanning AD DS for Exchange Unified Messaging settings and allowing the

Lync Server 2010 administrator to view, create, and edit contact objects.

Step 8: Enable Enterprise Voice Users for Exchange Unified Messaging

On the Exchange UM server, ensure that a UM mailbox policy has been created and that each user has a

unique extension number assignment, and then enable the user for Unified Messaging.



L1-1

Module 1: Introduction to Designing a Microsoft® ExchangeServer 2010 Deployment

Lab: Introduction to Designing an Exchange

Server 2010 DeploymentExercise 1: Evaluating an Existing Messaging Infrastructure

Task 1: Review A. Datum documentation


• Adatum_Info.vsd

• Requirements interview notes document

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

Analysis document• Complete the Current Network Infrastructure Analysis document.



Document Author

Date

Jason Carlson

31st January 2010

Active Directory Infrastructure – Sites

Active Directory site name Directory servers in each site

LondonSite RD-LON-DC1RD-LON-DC1

EU-LON-DC1

EU-LON-DC2

LondonSite2 EU-LON-DC3

VancouverSite RD-TOR-DC1

NA-TOR-DC1

NA-TOR-DC2

SanDiegoSite AD-SAN-DC1

AD-SAN-DC2

TokyoSite RD-TOK-DC1

AS-TOK-DC1

AS-TOK-DC2

Chennai AS-CHE-DC1



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

(continued )


Additional notes

Active Directory Infrastructure – Forest and domain topology

Forest Domains in each forest

Adatum.com Adatum.com

EU.Adatum.com

NA.Adatum.com

AS.Adatum.com

TreyResearch.net

Additional notes

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

Analysis document

• Complete the relevant sections of the following document.

A Datum Current Messaging Infrastructure Analysis


Document Author

Date

Jason Carlson

31st January 2010


Server name Exchange version andSP level

Server role Location

LON-MSG-FE1 Exchange Server 2003 Front-end server London

LON-MSG-BH1 Exchange Server 2003 Front-end server London

LON-MSG-BE1 Exchange Server 2003 Back-end server London








Lab: Introduction to Designing an Exchange Server 2010 Deployment L1-3

(continued )

A Datum Current Messaging Infrastructure Analysis


Server name Exchange version andSP level

Server role Location

LON-MSG-PF1 Exchange Server 2003 Public Folder server London

VAN-MSG-FE1 Exchange Server 2003 Front-end server Vancouver

VAN-MSG-BH1 Exchange Server 2003 Front-end server Vancouver

VAN-MSG-BE1 Exchange Server 2003 Back-end server Vancouver



VAN-MSG-PF1 Exchange Server 2003 Public Folder server Vancouver

TOK-MSG-FE1 Exchange Server 2003 Front-end server Vancouver

TOK-MSG-BH1 Exchange Server 2003 Front-end server Vancouver

TOK-MSG-BE1 Exchange Server 2003 Back-end server Vancouver



TOK-MSG-PF1 Exchange Server 2003 Public Folder server Vancouver

Additional notes

Exchange Organization information

Configuration Settings

Administrativegroups

LondonAG, VancouverAG, TokyoAG, RoutingGroupAG

Administrator groups LondonExAdmins, VancouverExAdmins, TokyoExAdmins,EnterpriseExAdmins

Routing groups LondonRG, VancouverRG, TokyoRG

SMTP namespaces Adatum.com, TreyResearch.net

Additional notes




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

Infrastructure Analysis document.

Exercise 2: Creating a Requirements Document

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

1. What are A. Datum Corporation’s requirements and pain points? Answers below:

• Madeleine Kelly, the CEO, anticipates rapid growth and multiple acquisitions.

• Karen Toh, VP Europe, says her Sales staff needs access to e-mail from anywhere.

• Marcel Truempy, CIO, cited a period of unavailability that resulted in business lost; high-

availability is important.

• Scott MacDonald, VP North America, is concerned about legal and corporate regulatory

compliance issues.

•

Gareth Chan, VP Asia, needs a means of confidential communication with Contoso, Ltd.

• Shane DeSeranno, Network Operations Manager, requires that all network traffic entering the

corporate network is encrypted.

• Jason Carlson, Network Specialist, states that the wide area network (WAN) is pretty reliable, but

that it lacks bandwidth between some company locations.

• Tzipi Butnaru, Directory Services Manager, explains that all domain controllers are running

Windows Server® 2008 Service Pack 1 (SP1), and does not anticipate wanting to make additional

Active Directory® Domain Services (AD DS) infrastructure changes.

• Conor Cunningham, Messaging Services Manager, wants to make Outlook® Web App available

to users currently using Post Office Protocol (POP) from home. Additionally, he states that many

users are requesting access to e-mail services from their mobile phones.

2. How can Exchange Server 2010 help address the requirements? Answers below:

• Exchange Server 2010 is very scalable, and can easily support the anticipated mergers and

acquisitions.

• Exchange Server 2010 supports e-mail from many devices, including web browsers and mobile

phones.

• Exchange Server 2010 provides a number of high-availability features, including Database

Availability Groups, Mailbox Database Copies, and Active Manager.

• Exchange Server 2010 implements features that enable organizations to remain compliant with

legal and corporate messaging policies. Features include: messaging records management, Multi-mailbox search, legal hold, information rights management protection, personal archive, and

transport rules.

• Exchange Server 2010 can support secure communication channels between partner

organizations.

• Exchange Server 2010 supports a number of encryption methods so that only encrypted traffic

can enter the corporate network through the internal firewall.




• Exchange Server 2010 can be configured to use the existing site configuration, or to use an

Exchange-specific site configuration; this enables a network administrator to get the most out of

their WAN links.

• There is no reason why the AD DS configuration needs to be modified in order to support

Exchange Server; however, Exchange Server does support an Exchange-specific site configuration.

•

Exchange Server 2010 supports the POP protocol. It also supports e-mail access from web

browsers and mobile phones. The users’ requirement for secure anywhere-access to their e-mail

is supported.

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

document


• Complete the relevant section of the following document.

A Datum Project Requirements Analysis


Document Author

Date

Jason Carlson

31st January 2010

Summary of business requirements

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

• The messaging solution must be very flexible and easily expanded.

• The messaging solution must provide users with e-mail access anywhere in the world at anytime.

• The messaging solution must be able to enforce compliance requirements.

•

Need to provide access to the mailbox servers for more messaging clients, including clientswith more functionality than POP3 and mobile clients.

Summary of functional requirements

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

• The messaging system must have very high availability.

• The messaging system must provide a high level of security for exchanging e-mail withpartner organizations.

Summary of additional requirements

This section lists the additional requirements identified during the requirements analysis task.Additional requirements may include data related to additional stakeholders, required technology,and user requirements:

• Mailbox size limits need to be increased.




(continued )

A Datum Project Requirements Analysis

Project priorities and constraints

This section outlines the identified project priorities and constraints. During the requirements

analysis task, specific priorities should have been identified related to the schedule, resources, orfeatures that must, or must not, be included in the project:

• The budget may be a constraint on the project.

• Unencrypted traffic can be allowed into the perimeter network, but not to the internal network.

• There may be resistance to making any changes to the Active Directory configuration.

Task 3: Discuss the components that you will need to include in the Exchange Server

design to meet the company requirements


• Discuss the following questions:

1.


business requirements?

• Answer: Configure the Client Access server role to provide users with e-mail access

anywhere in the world at any time.

• Answer: Configure the Hub Transport server role to enforce compliance requirements.

• Answer: Configure the Client Access server role to provide access to the mailbox servers for

more messaging clients, including clients with more functionality than POP3 and mobile

clients.

2.


technical and additional requirements?

• Answer: Configure Database Availability Groups, Mailbox Database Copies, and Active

Manager to provide for high availability.

• Answer: Configure the messaging transport to provide a high level of security for

exchanging e-mail with partner organizations.

• Answer: Configure Mailbox policies to increase the mailbox size limits.

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




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

Task: Answer the following questions

1. What information is required to set the preliminary budget?

Answer: Answers include:

• Project vision and scope

• Business requirements (What business problems is this project expected to solve?)

• Functional requirements

• Project constraints

2. How do you resolve scenarios where addressing all of the requirements will cost significantly more

than the proposed budget?

Answer: This can be very complicated. In the project’s early stage, the most important step is to alert

business sponsors that there may be budget issues. This enables them to prepare for a future tradeoff

discussion, or consider increasing the budget. You also may need to provide the business sponsorwith an initial proposal identifying the project components that will cost the most money.

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




Exercise 4: Discussion: Refining the Scope of SLA Requirements

Task 1: Review the High Availability Requirements document that the CIO and COO

have created

• Review the High Availability Information Requirements document.

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

1.

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

SLA.

2.

Complete the relevant section of the following document.

A Datum Refining the Scope of SLA Requirements


Document Author

Date

Jason Carlson

31st January 2010

Questions

• Are these objectives specific and measurable?

• Are these objectives reasonable and attainable?

• Do these objectives add value to the organization?

• What types of users are accessing the system and when?

• Do all users have the same availability requirements?

• How does an internal or Internet e-mail outage affect various user groups?

• What availability percentage is our goal?

• Which users have priority when restoring mailboxes?

• Which business processes does an internal e-mail outage affect?

•

What is the cost of an internal e-mail outage?• Which business processes does an Internet e-mail outage affect?

• What is the cost of an Internet e-mail outage?

• What budget is available for high-availability infrastructure improvements?

• What times are available for maintenance?

• How will we measure internal message delivery times?

• Within exactly how many minutes should message delivery occur?

• Exactly what outage types are acceptable when an Exchange Server fails? Seconds? Minutes?Hours?

• When an Exchange Server fails, is it acceptable to quickly recover users’ ability to send andreceive e-mail, or do we also need to recover mailbox contents quickly?

•

Do all users have a requirement to lose no messages during a server failure?• How quickly do we need to recover if an entire physical location is lost?

• What is the reliability of our existing network infrastructure?

• What is the reliability of our existing Internet connection?




Task 3: Discuss your solution with the class

• Participate in the discussion led by your instructor.

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


When you finish the lab, start the virtual machines that will be required for the next lab. To do this,


1.

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

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

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

4.

Log on using the following credentials:

• User name: Administrator


• Domain: Contoso

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






L2-11

Module 2: Designing Microsoft® Exchange Server 2010Integration with the Current Infrastructure

Lab: Designing Exchange Server Integration

with the Current InfrastructureExercise 1: Evaluating the Current Network Infrastructure at Contoso

Task 1: Review the supplied documentation

• Review the diagram and read the supporting documentation.




Question: Based on the supplied information, is there anything you might need to

reconfigure before deploying Exchange Server?

Answer: Answers will vary. However, it depends on how you propose to implement the

Microsoft Exchange Server for users in Branch Office 2. Exchange Server 2010 does not

support deployment in sites that contain read only domain controllers (RODCs). Therefore,

you must either remove the RODC and replace it with a domain controller, or else store user

mailboxes for that branch in the head office site in NYC. This latter solution may have

implications for the available bandwidth over the 10 megabits per second Mbps) link

between the head office and Branch Office 2. To mitigate, you could consider deploying

Microsoft Outlook® Web App to Branch Office 2.

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

2010?

Answer: Answers will vary. You will need to know:

• Whether there is an existing version of Exchange Server or other messaging system installed.

• What email clients users are currently using.

• What the firewall configuration is (in terms of allowed ports) and both the Windows® Firewall

settings and any firewalls that separate the corporate network from the Internet.

• The specifics of the delegated administration Ed Meadows envisages at the branches.

• Whether the current Domain Name System (DNS) configuration is appropriate to support

Exchange Server 2010, and both the internal DNS and external DNS.

• Whether there is a certification authority (CA) in place to provide the necessary certificates for

Exchange Server. In the early test phases, using the self-signed certificates is acceptable; however,

thereafter, commercial certificates should be sought in the absence of a suitable internal Public

Key Infrastructure (PKI).



L2-12 Module 2: Designing Microsoft Exchange Server Integration with the Current Infrastructure

Task 3: Complete a report that provides information about necessary changes

required to the network and AD DS infrastructure to enable support for Exchange Server

2010




Document Author

Date

Jason Carlson

11th February 2010


To determine what changes, if any, are required to the existing network and AD DS infrastructure tosupport Exchange Server 2010.


Proposals

Question: The internal and external DNS zone names are the same for Contoso—i.e. Contoso.com.What issue does this raise for clients connecting to their mailboxes using Outlook Web App fromtheir home computers?

Answer: You may need to configure split DNS to ensure host names are resolved the appropriateinternal or external IP address.

Question: What DNS records must you configure in the external Contoso.com DNS zone?

Answer: Host (A or AAAA) resource records, mail exchanger (MX) resource records, and SenderPolicy Framework (SPF) resource records are required.

Question: How do you propose to support the messaging needs of users in Branch Office 2?

Answer: As Exchange Server 2010 does not support deployment in sites that contain an RODC; the

RODC must either be removed and replaced with a full domain controller, or else the users mustuse an Exchange Mailbox server in the head office site.

Question: What messaging client will you deploy to Branch Office 2?

Answer: That depends on how the RODC issue is resolved. If the RODC is removed, the users coulduse Outlook Web App to ensure that the bandwidth of the connection to the head office is notexcessively consumed. If a full DC is deployed to the Branch Office 2 site, then any suitable client—including Microsoft Office Outlook 2007 or 2010—could be deployed.

Question: What server role must you consider deploying in the head office to facilitate inboundand outbound messaging to and from the Internet?

Answer: An Exchange Edge Transport server should be deployed in the perimeter network.

Question: How many Client Access servers do you envisage needing?Answer: At least one per site where mailboxes reside; if Branch Office 2 does not host a Mailboxserver, then there is no need to provide a Client Access server there. For high availability, considerdeploying at least two Client Access servers per site.



Lab: Designing Exchange Server Integration with the Current Infrastructure L2-13

(continued )


Question: How many Hub Transport servers are required?

Answer: At least one per site where mailboxes reside. If Branch Office 2 does not host a Mailboxserver, then there is no need to provide a Hub Transport server there. For high availability, consider

deploying at least two Hub Transport servers per site.

Question: Ed Meadows has explained that the administrators at the Branch Office 1 site needs tobe able to perform limited recipient management tasks. To which built-in role group should youassign these branch administrators?

Answer: They should be assigned to the Help Desk role group.


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

infrastructure report.




Exercise 2: Determining Suitability for Exchange Server 2010

Task 1: Evaluate the AD DS requirements

1.

On NYC-DC1, click Start, right-click Computer, and then click Properties.

2. On the System page, in the Windows edition section, verify that the domain controller operating

system is compatible with Exchange Server 2010 requirements.

3.

Close the System page.

4. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.

5.

Right-click Contoso.com, and then click Properties.

6. In the Contoso.com Properties dialog box, verify that the domain and forest functional levels are

compatible with the Exchange Server 2010 requirements.

7.

Click OK , and then close Active Directory Users and Computers.

8. Click Start, in the Search box, type adsiedit.msc, and then press Enter.

9. Right-click ADSI Edit, and then click Connect to.

10.

In the Connection Settings dialog box, in the Connection Point section, in the Select a well known

Naming Context list, click Configuration, and then click OK .

11.

In the left pane, expand Configuration[NYC-DC1.Contoso.com], and then click

CN=Configuration,DC=Contoso,DC=com.

12. Expand CN=Services, and verify that the CN=Microsoft Exchange has not been created.

13.

Close ADSI Edit.

Task 2: Evaluate the DNS requirements

1. On NYC-SVR1, click Start, in the Search box, type cmd, and then press Enter.

2.

At the command prompt, type IPConfig /all, and then press Enter. Verify that the DNS server IPaddress for the Local Area Connection is 10.10.10.10.

3. At the command prompt, type Ping NYC-DC1.contoso.com. Verify that you have network

connectivity with the domain controller.

4. At the command prompt, type Nslookup, and then press Enter.

5.

At the command prompt, type set type=all, and then press Enter.

6.

At the command prompt, type _ ldap._tcp.dc._msdcs.Contoso.com, and then press Enter. Verify that

an SRV record is returned.

7.

Close the command prompt.




Task 3: Evaluate the server requirements

1.

On NYC-SVR1, click Start, point to Administrative Tools, and then click Server Manager.

2.

In the left pane, click Features. Verify that no Windows Server® 2008 features are installed, including

the Active Directory® Domain Services (AD DS) management tools.

3.

In the left pane, click Roles. Verify that no Windows Server 2008 roles are installed.4. Click Start, and point to Administrative Tools. Verify that Internet Information Services (IIS)

Management is not listed.

5. Click Start, click All Programs, click Accessories, click Windows PowerShell, and then click

Windows PowerShell.

6.

At the Windows PowerShell™ prompt, type help about_windows_powershell, and then press Enter.

Verify that about_Windows_PowerShell_2.0 is listed. It is installed with Windows PowerShell 2.0.

7.

Close Windows PowerShell.

8. Click Start, and then click Control Panel.

9.

In Control Panel, click Programs.10.

In the Programs and Features window, click Programs and Features. Verify that Microsoft Filter

Pack 2.0 is installed.

11.

Close the Programs and Features window.

Results: After this exercise, you should have evaluated whether your organization meets the AD DS, DNS,

and server requirements for installing Exchange Server 2010. You should have identified the additional

components that need to be installed or configured to meet the requirements.




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

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

1.

On NYC-SVR1, in Server Manager, click Features, and then click Add Features.

2. In the Select Features page, expand Remote Server Administration Tools, expand Role

Administration Tools, expand AD DS and AD LDS Tools, expand AD DS Tools, and then select theAD DS Snap-Ins and Command-Line Tools check box.

3.

Expand .NET Framework 3.5.1 Features, and then select the .NET Framework 3.5.1 check box.

4.

Expand WCF Activation, select the HTTP Activation check box, and then click Add Required Role

Services.

5.

Select the RPC over HTTP Proxy check box, click Add Required Role Services, and then click Next.

6. On the Web Server (IIS) page, click Next.

7. On the Select Role Services page, under Security, select the Digest Authentication check box.

8.

Under Performance, select the Dynamic Content Compression check box.

9.

Under IIS 6 Management Compatibility, select the IIS 6 Management Console check box.

10. Click Next, and then click Install.

11.

Click Close.

12.

Click Start, point to Administrative Tools, and then click Services.

13. In the Services list, double-click Net.Tcp Port Sharing Service.

14.

In the Net.TCP Port Sharing Service Properties dialog box, in the Startup type drop-down list,

click Automatic, and then click Apply.

15. Click Start, wait for the service to start, and then click OK .

16.

Close the Services console.

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

This task requires that the Exchange Server 2010 .iso be attached to the NYC-SVR1 virtual machine as a

DVD drive. Complete the following steps to attach it.

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

Settings.

2.

Click DVD Drive, and then click Image File.

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

\10233\Drives.

4.

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

5. On NYC-SVR1, close the autoplay dialog box, and open a command prompt.

6.

Type D:\setup.com /PrepareAD /OrganizationName:“Contoso”, and then press Enter.

7. When the task completes, close the command prompt window.

Results: After this exercise, you should have prepared the AD DS and server configuration for the

Exchange Server 2010 installation.




Exercise 4: Configuring Exchange Server Delegation

Task: Configure permissions for Adam Carter, the branch administrator

1.

On NYC-SVR1, open Active Directory Users and Computers.

2. Expand Users, right-click Users, point to New and then click User.

3.

In the New Object – User dialog box, in the Full Name box, type Adam Carter.

4.

In the User logon name box, type Adam, and then click Next.

5. In the Password and Confirm password boxes, type Pa$$w0rd.

6. Click Next and then click Finish.

7.

In Active Directory Users and Computers, click Microsoft Exchange Security Groups, and then

double-click Help Desk .

8. On the Members tab, click Add.

9.

In the Enter the object names to select field, type Adam Carter, and then click OK twice.

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


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

following steps:


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

3.


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




6.









L3-19

Module 3: Planning and Deploying Mailbox Services

Lab: Planning and Deploying MailboxServices

Exercise 1: Designing the Mailbox Server Deployment



• Server Design Interviews

• Server Design Statistics



Question: In the Server Design Interviews, what points are raised that impact your Mailbox server


Answer:

• A single server or component failure cannot be the cause of messaging system unavailability. Multiple

Mailbox servers must be deployed in each site.

• The system must be scalable to grow capacity by at least 30 percent over 3 years.

• There is a Storage Area Network (SAN) in London, Tokyo, and Toronto. These will be high

performance, but expensive.

•

San Diego and Chennai do not have a SAN and need to use direct access storage (DAS).

• Mailbox sizes are increasing to 500 megabytes (MB) for basic users, and a personal archive of 1 GB.

Exceptional users — about 25 percent of users — will have a mailbox of 1 GB and a personal archive of

2 GB.

Question: In the Server Design Statistics, what information is relevant to determining a server design, and

why?

Answer: All of the information in this document is relevant to developing a server design. This document

describes the size of mailboxes and the amount of user activity.



L3-20 Module 3: Planning and Deploying Mailbox Services

Task 3: Perform high level planning for Mailbox server storage in London


A. Datum high level planning for mailbox servers in London


Document Author

Date

Jason Carlson

2nd April 2010


Create a high level plan for Mailbox server storage in London.


N/A

Question: Assuming that there are 12,000 users in London, how much disk space is required formailbox databases?

Answer: There will be 9,000 users with a 500 MB mailbox and a personal archive of 1 GB. There willbe 3,000 users with a 1 GB mailbox and a 2 GB personal archive. The total storage space potentiallyrequired is 22.5 terabytes (TB).

The initial deployment will not require this much space because user mailboxes will not all be attheir limit, but this shows the maximum potential size.

Question: Should the disk space for Mailbox servers be SAN or DAS?

Answer: The SAN has only 10 TB free and cannot support holding even a single copy of all mailboxdata. Expanding the SAN will be very expensive. Therefore, DAS should be used.

Question: If DAS is used, will the disk space use RAID or JBOD?

Answer: Because there are three replicated copies of the data, consider using JBOD. From aperformance perspective, there is no reason to use RAID. If the final design includes more than

three data copies, JBOD should be used.

Question: What size and speed of disk do you think is appropriate?

Answer: To support the large volume of data, slower and less expensive disks such as 7200 RPMSAS disks should be used. The 7200 RPM SAS disks are close to the same price as SATA drives butare more reliable. You do not need disks with a higher RPM because Exchange Server 2010 haslower I/O requirements.

Question: Should transaction logs be stored on a separate LUN from database files?

Answer: When there are multiple replicated copies, you do not need a separate LUN fortransaction logs. Recovery is performed by using an alternate copy of the database rather than byrestoring and then replaying transaction logs. In most cases, circular logging is used and there is nooption to replay transaction logs.



Lab: Planning and Deploying Mailbox Services L3-21

Task 4: Use the Exchange 2010 Mailbox Server Role Requirements Calculator

spreadsheet to determine the configuration

1. On VAN-CL1, open the \\VAN-EX1\E$\Labfiles\LabResources\E2010Calc18.2.xlsm spreadsheet.

Click Enable Content and then click Yes.

2. Enter the following data on the Input tab:

• Exchange Environment Configuration

• Global Catalog Architecture: 64-bit

• Server Multi-Role Configuration: No

• Server Role Virtualization: No

• High Availability Deployment: YES

• Number of Mailbox Servers Hosting Active Mailboxes/DAG (Primary Datacenter): 2

• Number of Database Availability Groups: 1

• Mailbox Database Copy Configuration

• Total Number of HA Database Copy Instances (Includes Active Copy) within DAG: 3

• Total Number of Lagged Database Copy Instances within DAG: 0

• Number of HA Database Copy Instances Deployed in Secondary Datacenter: 1

• Exchange Data Configuration

• Data Overhead Factor: 20%

• Mailbox Moves / Week Percentage: 1%

• Dedicated Maintenance / Restore LUN: Yes

• LUN Free Space Percentage: 20%

• Exchange I/O Configuration

• I/O Overhead Factor: 20%

• Additional I/O Requirement / Server: 0

• Site Resilience Configuration

• Site Resilient Deployment: Yes

• Site Resilience User Distribution Model: Active/Passive

• Site Resilience Recovery Point Objective (Hours): 24

• Activation Block Secondary Datacenter Mailbox Servers: Yes

• Database Configuration

• Maximum Database Size Configuration: Default

• Automatically Calculate Number of Unique Databases / DAG: Yes

• Calculate Number of Unique Databases / DAG for Symmetrical Distribution: No


• Total Number of Tier 1 User Mailboxes: 3000




• Projected Mailbox Number Growth Percentage: 30%

• Total Send/Receive Capability / Mailbox / Day: 100 messages

• Average Message Size (KB): 50

• Mailbox Size Limit (MB): 1000

•

Personal Archive Mailbox Size Limit (MB): 2000








•

Tier 2 User Mailbox Configuration

• Total Number of Tier 2 User Mailboxes: 9000

• Projected Mailbox Number Growth Percentage: 30%

• Total Send/Receive Capability / Mailbox / Day: 50 messages

• Average Message Size (KB): 25

• Mailbox Size Limit (MB): 500

• Personal Archive Mailbox Size Limit (MB): 1000


•

Single Item Recovery: Enabled






• Backup Configuration

• Backup Methodology: Exchange Native Data Protection

•

Database and Log Isolation Configured: No

• Backup/Truncation Failure Tolerance: 3

• Network Failure Tolerance (Days): 0

• Storage Options

• Consider Storage Designs Utilizing JBOD (if applicable): Yes

• Primary Datacenter Disk Configuration




• Database + Log: 2000 GB, 7.2K RPM SAS 3.5”

• Restore Lun: 2000 GB, 7.2K RPM SAS 3.5”

• Secondary Datacenter Disk Configuration

• Database + Log: 2000 GB, 7.2K RPM SAS 3.5”

•

Restore Lun: 2000 GB, 7.2K RPM SAS 3.5”

• Server Configuration

• Primary Datacenter Mailbox Servers: 12 cores per server, SPECint2006 Rate of 400

• Primary Datacenter Mailbox Servers: 12 cores per server, SPECint2006 Rate of 400

• Log Replication Configuration

• For Hours 1-5,20-24: 1%

• For Hours: 6-7,18-19: 5%

• For Hours 8-17, 7%

•

Network Configuration:

• Network Link Type: Fast Ethernet

• Network Link Latency: 50.00


Task 5: Update the A. Datum Large Mailbox server design document




Document Author

Date

Jason Carlson

2nd April 2010


Determine the hardware configuration for large Mailbox servers that use DAS.


N/A

Proposals

Question: What is the processor configuration for each server?

Answer: 12 server cores with a SPECint2006 Rate value of 400

Question: What type of disks are being used?

Answer: 2000 GB, 7.2K RPM SAS

Question: How many databases are recommended?

Answer: The DAG requires 30 databases.




(continued )


Question: How many mailboxes are recommended for each database?

Answer: 500 mailboxes are recommended for each database.

Question: What is the recommended RAM for this server?

Answer: 96 GB

Question: What is the expected CPU utilization for this server?

Answer: 33 percent

Question: What is the recommended number of LUNs on the server?

Answer: Total recommended LUNs for Exchange are 31:

• 30 LUNs for databases and logs

• 1 LUN for restores

Question: How many databases are recommended per LUN?

Answer: 1

Question: What is the total disk space required per server?

Answer: The total disk space required is approximately 53 TB (53118 GB):

• 51553 GB for database and log LUNs

• 1565 GB for a restore LUN

Question: What type of RAID is recommended?

Answer: JBOD is recommended for the primary datacenter because there are three database

copies. RAID 1/0 (also known as RAID 10) is recommended for the secondary datacenter LUNs thathold database copies and logs. RAID 5 is recommended for the secondary datacenter restore LUN.

Question: How many database disks are recommended for the primary datacenter servers?

Answer: 31

Question: How many database disks are recommended for the secondary datacenter server?

Answer: 59





Exercise 2: Designing Recipient Management



• Recipient Management Interviews



Question: In the Recipient Management Interviews, what points are raised that impact your Mailbox

server deployment plan, and how do they impact it?

Answer: This entire document is relevant to the planning of recipient management. However, the specific

points raised are:

• When sending mail, users must use the email address associated with their business unit, but when

receiving email, all domains must be allowed.• Information Technology (IT) Client Services staff in each location must be able to manage recipients

in that location only. Team leaders must be able to manage recipients throughout the entire

organization.

• Automated booking of meeting rooms is desired, with exceptions approved by a designated person.

• Group management by department representatives is desired.





Document Author

Date

Jason Carlson

2nd April 2010


Determine the configuration required to meet recipient management needs.

Proposals

Question: How will you ensure that recipients are assigned the correct email addresses?

Answer: Two email address policies need to be created:

• The first e-mail address policy will have a condition that matches only A. Datum recipients.

The condition could be based on recipients in specific organizational units (OUs) orrecipients with the Company defined in Active Directory® Domain Services.

• The second e-mail address policy will have a condition that matches only Trey Researchrecipients.

Each policy will be configured with both domains. The e-mail address policy for A. DatumCorporation will use adatum.com as the Reply To address. The e-mail address policy for TreyResearch will use TreyResearch.net as the Reply To address.




(continued )


Question: How will you enable the IT Client Services staff to perform recipient management?

Answer: Team leaders can be made members of the Recipient Management role group. This grouphas management permissions for the recipients in the entire Exchange Server organization.

New Recipient Management role groups should be created for each physical location. These rolegroups will be scoped to limit management permissions to manage recipients only within a specificOU that represents each physical location.

Question: How will you meet the needs for meeting room bookings?

Answer: Each meeting room will be created as a resource mailbox. You can then determine the in-policy and out-of-policy settings for each meeting room. A delegate for each meeting room will beconfigured to arbitrate conflicts, and approve or deny out-of-policy requests.

Question: How will you address the needs for distribution group management?

Answer: Exchange Server 2010 supports delegation of distribution group membershipmanagement. The person that is configured as group manager is able to modify the distribution list

membership by using the Exchange Control Panel.

Question: How will you address the need for separating the address books for A. Datum and TreyResearch?

Answer: Create separate address lists for each organization and then distribute the appropriateaddress lists by using address book policies. The appropriate address book policy must beassociated with each user. To simplify this you must have an identifying attribute that can bequeried when performing the assignment. You should also have an identifying attribute that can bequeried when specifying GAL members.





Exercise 3: Designing a Public Folder Deployment



• Public Folder Interviews

•

Server Design Interview



Question: In the Public Folder Interviews, what points are raised that impact your public folder


Answer: This entire document is relevant to the planning of recipient management. However, the specific

points raised are:

•

The Executives want a new public folder for private communication that is available quickly from anylocation, and is not impacted by a server failure.

• Requests for new public folders are being encouraged to evaluate Microsoft® SharePoint® as an

alternative.

• IT Client Services would like a new collaboration tool.

Question: In the Server Design Interview, what points are raised that impact your public folder


Answer: Many clients still use Microsoft Office Outlook® 2003. Office Outlook 2003 clients require public

folders to access free/busy information, and to download offline address books.






A. Datum public folder configuration


Document Author

Date

Jason Carlson

2nd April 2010


Determine the configuration required to meet public folder needs.

Proposals

Question: How will you address the executive’s desire for public folders?

Answer: Since Erik has made it clear that he does not want to use SharePoint, a public foldershould be created. This public folder should be replicated to all locations in the organization for fastaccess regardless of location. The replication also helps ensure high availability.

Question: How will you address the IT Client Services request for a public folder?Answer: IT Client Services should be encouraged to use SharePoint instead of public folders. Thiswill provide them with many more options for collaboration.

Question: Other than the public folder for executives, which other public folders are required?

Answer: To support Office Outlook 2003 clients, the system public folders for free/busy searchesand offline address books must be available in all locations. This requires that you create at leastone public folder database in each physical location. Public folder databases will not exist in eachphysical location by default.





Exercise 4: Implementing Mailbox Services

Task 1: Configure an address book policy for Trey Research

1.

On VAN-EX1, click Start, point to Administrative Tools, and click Active Directory Users and

Computers.

2.

In Active Directory Users and Computers, right-click Adatum.com, point to New, and clickOrganizational Unit.

3.

In the New Object – Organizational Unit window, in the Name box, type Trey, and click OK .

4.

In the left pane, click Marketing then click and drag Wei Yu to the Trey organizational unit.

5. In the Active Directory Domain Services window, click Yes.

6. Close Active Directory Users and Computers.

7.

Click Start, point to All Programs, click Microsoft Exchange Server 2010, and then click Exchange

Management Console.

8.

In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand

Organization Configuration, and then click Mailbox.

9. In the Actions pane, click New Address List.

10.

In the New Address List wizard, on the Introduction page, enter the following settings and click

Next.

• Name: Trey Users

• Display Name: Trey Users

• Container: \

11.

On the Filter Settings page, click Browse, click Trey, and click OK .

12.

Click The following specific types, select the Users with Exchange mailboxes check box, and click

Next.

13.

On the Conditions page, click Next.

14. On the Schedule page, click Next to apply all changes immediately.

15. On the New Address List page, click New.

16.

On the Completion page, click Finish.

17. In the Actions pane, click New Address List.

18. In the New Address List wizard, on the Introduction page, enter the following settings and click

Next.

•

Name: Trey Rooms

• Display Name: Trey Rooms

• Container: \

19. On the Filter Settings page, click Browse, click Trey, and click OK .

20. Click The following specific types, select the Resource mailboxes check box, and click Next.

21.

On the Conditions page, click Next.






Task 2: Create and configure a resource mailbox

1.

On VAN-EX1, open the Exchange Management Console, browse to Recipient Configuration, and

then click Mailbox.

2. In the Actions pane, click New Mailbox.

3.

In the New Mailbox window, click Room Mailbox, and then click Next.4. On the User Type page, click New user, and then click Next.

5. On the User Information page, enter the following information, and then click Next.

• First name: Room 100

• User logon name: Room100

6. On the Mailbox settings page, in the Alias box, type Room100, and then click Next.

7.

On the New Mailbox page, click New.

8. On the Completion page, click Finish.

9.

Right-click Room 100, and then click Properties.10.

In the Room 100 Properties window, click the Resource General tab, and then select the Enable the

Resource Booking Attendant check box.

11. Click the Resource Policy tab. Under Specify delegates of this mailbox, click Add, click Andreas

Herbinger, and then click OK .

12. Click the Resource Out-of-Policy Requests tab, click Add, click Luca Dellamore, and then click OK .

13.

In the Room 100 Properties window, click OK .

Task 3: Test the delegation of a resource mailbox

1. On VAN-CL1, log on as Adatum\Luca using the password Pa$$w0rd.

2.

Click Start, point to All Programs, click Microsoft Office, and then click Microsoft Outlook 2010.

3.

In Outlook, click New Items and Meeting.

4. In the Untitled Meeting window, enter the following, and then click the Check Names button.

• To: Luca; Conor

• Subject: Exchange Planning

• Start time: Tomorrow 1pm

• End Time: Tomorrow 2pm

5.

Click Rooms, double-click Room 100, and then click OK .

6.

Click Send.

Notice that an automatic response is received indicating that the booking was accepted by Room

100, because the request is in-policy. The response may take a minute or so to appear.

7. In Outlook, click New Items, and then click Meeting.




8. In the Untitled Meeting window, enter the following, and then click the Check Names button.

• To: Luca; Conor

• Subject: Exchange Project Review

• Start time: 9 months from today at 1pm

•

End Time: 9 months from today at 2pm

9.

Click Rooms, double-click Room 100, and then click OK .

10. Click Send.

11. Wait for the response to be delivered, and then click the new message.

Notice that the request was received, but is pending approval. Because the request is Out-of-Policy, it

has been forwarded to the delegate.

12.

On the taskbar, click Internet Explorer.

13. In the address bar for the Internet Explorer® browser, type https://van-ex1.adatum.com/owa, and

then press ENTER.

14.

Log on as Adatum\Andreas using the password Pa$$w0rd.

15. If prompted for language and time zone settings, click OK to accept the default.

16.

If necessary, click the Exchange Project Review item in the Inbox.

17.

In the reading pane, click the check mark, and then click Send the response now.

18. In Outlook, verify that the request is now accepted by Room 100.

Task 4: Configure a distribution group for delegated management and moderation

1.

On VAN-EX1, in the Exchange Management Console, in the console tree, expand Recipient

Configuration, and then click Distribution Group.

2.

Right-click Executives , and then click Properties.

3.

In the Executives Properties window, click the Group Information tab.

4. Under Managed by, click Add, click Conor Cunningham, and then click OK .

5. Click the Membership Approval tab, and verify that group membership is closed.

6.

Click the Mail Flow Settings tab.

7. Click Message Moderation, and then click Properties.

8. Select the Messages sent to this group have to be approved by a moderator check box.

9.

In the Message Moderation window, under Specify group moderators, click Add, click Luca

Dellamore, and then click OK .10. Under Specify senders who don’t require message approval, click Add, click Executives, and then

click OK .

11. In the Message Moderation window, click OK .

12.

In the Executives Properties window, click OK .




Task 5: Test moderation of a distribution group

1.

On VAN-CL1, in Outlook Web App, click New.

2.

In the Untitled Message window, enter the following information and then click Send.

• To: Executives

•

Subject: New Public Folder

• Body: The Executives public folder has been created for you.

3. In the left pane, click Sent Items, right-click New Public Folder, and then click Open Delivery

Report.

4. When prompted to allow the pop-up, click Yes.

5. In the Delivery Report window, notice that the message has been sent to the moderator, and then

click Close.

6. In Office Outlook, in the Inbox, click the Approval requested: New Public Folder message, and read

the contents.

7.

Click the New Public Folder message, and then click Approve.

8. In Outlook Web App, right-click New Public Folder, and then click Open Delivery Report.

9.

When prompted to allow the pop-up, click Yes.

10. In the Delivery Report window, notice that the message has been delivered to both group members,

and then click Close.



following steps:



3.


4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-CL1. Close the virtual

machine connection windows

5.















L4-36 Module 4: Planning and Deploying Client Access Services in Microsoft Exchange Server 2010

• Simple Mail Transfer Protocol (SMTP) traffic for the Adatum.com organization currently passes to

and from the Internet through the London site.

• Hypertext Transfer Protocol/Secure (HTTPS) traffic is allowed through most firewalls. Configure

Client Access servers to use SSL for services.

Question: Is there anything in the Adatum_CurrentPerimeterDesign.vsddiagram that

raises Client Access server deployment issues? If so, what?

Answer:

• Only the firewall in the San Diego site allows Post Office Protocol version 3 (POP3) inbound

network traffic.

• Only the London and San Diego sites allow for inbound and outbound SMTP traffic.

Question: Is there anything in the Adatum_CurrentADSiteDesign.vsddiagram that raises

Client Access server deployment issues? If so, what?

Answer: Answers will vary, but there do not appear to be any issues that will impact Client

Access server deployment decisions.

Task 3: Update the A. Datum Client Access server deployment plan document


A Datum Client Access Server Deployment Plan


Document Author

Date

Jason Carlson

4th April 2010


Determine the number and placement of Client Access servers within the existing networkinfrastructure.



Proposals

Question: With reference to the Adatum_CurrentADSiteDesign diagram, how many Client Accessservers do you propose to deploy in each site?

Answer: Deploy at least two in each site to address the high availability concerns raised in thedocumentation.

Question: Do you have sufficient information from the documents reviewed so far, to determinewhether some sites require additional Client Access servers?

Answer: No. You also need information about the number of users connecting to the Client Accessservers. This information is provided in a supplemental document that you will review in the nextexercise.

Question: Based on the documentation you have reviewed, what client types must you support?

Answer: Messaging Application Programming Interface (MAPI), Microsoft Exchange ActiveSync,POP3/SMTP, and Outlook Web App. Outlook Anywhere is not mentioned in this documentation.



Lab: Planning and Deploying Client Access Services in Exchange Server 2010 L4-37

(continued )

A Datum Client Access Server Deployment Plan

Question: Is it clear from the documentation that you have reviewed which sites support whichclient types?

Answer: No. Additional information is supplied in the A. Datum User Distribution Summarydocument that you will review in the next exercise.


Answer: Answers will vary, but might include:

• Upgrading the Office Outlook 2003 clients to Outlook 2010 would mean that Public foldersare no longer required. Additionally, this would mean that free/busy information would beprovided to users more quickly.

• Replacing POP3 clients with another client type would simply firewall configuration. Byusing either Outlook Anywhere or Outlook Web App, only HTTPS traffic (already permitted)would be configured through the firewalls.

Question: Which Client Access servers do you propose to make Internet-facing?Answer: Answers will vary. There are two choices:

• Deploy Internet-facing Client Access servers in one site, and rely on redirection and/orproxying (depending on the client type) to enable clients to connect to the appropriateClient Access server in other sites. With this approach, you only need to configure onenamespace, which simplifies certificate deployment. However, not all client types supportredirection and proxying. For example, POP3 clients do not support redirection andproxying.

• Deploy Internet-facing Client Access servers in each site, and provide users with thenecessary URLs for the servers in the site that hosts their mailboxes. This means you mustobtain a certificate for each Client Access server, or else use a certificate that supportsmultiple host names.

Question: How will you configure Autodiscover to support your Client Access server model?Answer: Register a server connection point for each Client Access server on the Active Directorysite. This server connection point is the fully qualified domain name (FQDN) of the server that hoststhe role and is used by domain-joined computers to locate the Autodiscover service. Domain-disjoined computers use Domain Name System (DNS) to locate the Autodiscover service. Considermodifying both these values (the server connector point and the DNS records) to match.


Results: After this exercise, you should have completed the A. Datum Client Access server deployment

plan document.




Exercise 2: Designing Client Access


• Review the contents of the following documents:

• Policy Requirements.doc

•

A Datum User Distribution Summary.doc


Question: In the Policy Requirements document, what points are raised that impact your

Client Access server deployment plan, and why?

Answer: Mobile messaging will be very important — as far as executives are concerned, this is

principle reason for upgrading to Exchange Server 2010.

Security issues:

• All users who access email on the Exchange server must be required to have an alphanumeric

password that is at least six characters long.

• Users who want to download attachments to the device must have encryption enabled on the

device, and the device must be configured to lock after five failed logon attempts.

• Exchange administrators must be able to remotely wipe any mobile devices.

• All executives and managers must be able to download attachments to their mobile devices.

Other users do not require this functionality.

• The Exchange administrators do not want to be involved every time a user gets a new mobile

device, but they also do not want users to have many mobile devices associated with their

mailboxes.

Question: In the A. Datum User Distribution Summary document, what points are raised

that impact your Client Access server deployment plan, and why?Answer:

• The number of internal users at each location will affect the number of required Client Access

servers.

• There are a mix of remote client types at many locations, including Outlook Web App users,

Outlook Anywhere users, Office Outlook (over a virtual private network (VPN)) users, POP3 users,

and Exchange ActiveSync users.

• Placement of Internet-facing Client Access servers in various sites raises the issue of the

namespace that you will use.

• Using multiple Internet-facing Client Access servers means that you must carefully plan the

external URLs used on certificates. Certificates must support multiple computer names.






(continued )


Question: To support the other client types, what other configuration changes must you make?

Answer: You must:

Configure the external URLs for services that you want to make available across theInternet. For example, to support Exchange ActiveSync, configure the external URL value onservers providing this feature.

Start the POP3 service on Client Access servers that provide this service.

Configure a SMTP connector to support remote client relaying. Typically, you do this on theHub Transport server role, and then publish using a reverse proxy such as a MicrosoftInternet Security and Acceleration (ISA) Server.

Configure the required authentication settings on all services. For example, Outlook WebApp uses forms-based authentication by default.

Obtain and install the required certificates to enable SSL.


Answer: Aside from those mentioned already, you should migrate Office Outlook users thatimplement a connection over a VPN to Outlook Anywhere. This avoids the need for VPNs.


Results: After this exercise, you should have completed the A. Datum Client Access server configuration

document.




Exercise 3: Implementing Client Access

Task 1: Verify the Exchange ActiveSync virtual directory configuration

1.

On VAN-EX2, click Start, point to All Programs, point to Microsoft Exchange Server 2010, and

then click Exchange Management Console.

2.

In the Exchange Management Console, expand Microsoft Exchange On-Premises, expand ServerConfiguration, and then click Client Access.

3.

In the result pane, click VAN-EX2, and then in the work pane, click the Exchange ActiveSync tab.

4.

Right-click Microsoft-Server-ActiveSync (Default Web Site), and then click Properties.

5. Review the information on the General tab.

6. Click the Authentication tab. Notice that Basic authentication is enabled. This is acceptable, because

SSL will be used to secure the credentials in transit.

7. Click OK .

Task 2: Create a new Exchange ActiveSync mailbox policy

1.

On VAN-EX2, in Exchange Management Console, in the console tree, expand Organization

Configuration, and then click Client Access.

2.

In the Actions pane, click New Exchange ActiveSync Mailbox Policy.

3. In the Mailbox policy name box, type Executive Policy.

4. Select the Allow non-provisionable devices check box. Confirm that the Allow attachments to be

downloaded to device option is selected.

5. Select the Require password check box.

6. Select the Enable password recovery check box. This will enable users to recover their Windows

Mobile password through the Exchange Control Panel.

7. Select the Require encryption on device check box.

8.

Clear the Allow simple password check box.

9. Select the Minimum password length check box, and then in the Minimum password length box,

type 6.

10.

Click New to create the mobile mailbox policy.

11. Read the completion summary, and then click Finish.

12.

Right-click Executive Policy, and then click Properties.

13.

Click the Password tab, and then select the Require encryption on storage card check box.

14.

Select the Number of failed attempts allowed check box, and then in the Number of failedattempts allowed box, type 5.

15.

On the Sync Settings tab, review the configuration options.

16. On the Device tab, review the configuration options.

17.

On the Device Applications tab, review the configuration options. To implement these settings, you

must have an Enterprise Client Access License for each mailbox.

18. On the Other tab, review the options for allowing or blocking specific applications, and then click OK .




19. Close Exchange Management Console.

20.

Click Start, point to All Programs, point to Microsoft Exchange Server 2010, and then click

Exchange Management Shell.

21.

In the Exchange Management Shell, type the following command, and then press Enter.

Get-Mailbox -OrganizationalUnit Executives | Set-CASMailbox-activesyncmailboxpolicy "Executive Policy"

22. Close the Exchange Management Shell.

Task 3: Configure Exchange ActiveSync settings from the Exchange Control Panel

(ECP)

1. Click Start, point to All Programs, and then click Internet Explorer.

2.

In the address bar, type https://van-ex2.adatum.com/ecp and then press Enter.

3. On the Outlook Web App webpage, in the Domain\user name box, type adatum\administrator.

4. In the Password box, type Pa$$w0rd and then click Sign in.

5.

In the Exchange Control Panel, in the navigation pane on the left, click Phone & Voice.

6. In the center pane, click ActiveSync Device Policy.

7. In the results pane, click Executive Policy and then click Details.

8.

In the Executive Policy dialog box, expand Device Security. Review the settings.

9.

Expand Sync Settings. Review the settings.

10. Expand Device Settings. Notice that text messaging is allowed. Click Cancel.

11.

In the center pane, click ActiveSync Access.

12. Under Device Access Rules, click New.

13. In the New Device Access Rule dialog box, under Device family, click Browse.

14. Select All families and click OK .

15.

Under When devices of the selected family or model try to connect, click Quarantine – Let me

decide to block or allow later, and then click Save.

16.

In the Error dialog box, click Close. There are currently no devices in use in the Adatum organization.

Click Cancel.

17.

Close Internet Explorer.

Results: After this exercise, you should have deployed and configured Exchange ActiveSync for members

of the Executives group.






steps:


2.


4. Repeat these steps for 10233B-VAN-EX1, and 10233B-VAN-EX2. Close the virtual machine connection

windows.






7.

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

machine.

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

9.

Wait for 10233B-VAN-EX2 to start, and then start 10223A-VAN-EDG. Connect to the virtual

machine.






L5-45

Module 5: Planning and Deploying Message Transport inMicrosoft® Exchange Server 2010

Lab: Planning and Deploying Message

Transport in Exchange Server 2010Exercise 1: Designing a Message Routing Topology




• Adatum_CurrentADSiteDesign.vsd

• Adatum_Info.vsd

Task 2: Modify the A. Datum current AD DS site design diagram with proposedchanges to the site design

1. Use callouts in the following diagram to document proposed changes to the site design. For each

proposed change, provide:



2.

Indicate which server roles need to be deployed in each AD DS site.

3.

Document message flow within the organization. Document the changes that you will need to make

to the AD DS configuration to enable optimal message flow.




L5-46 Module 5: Planning and Deploying Message Transport in Microsoft Exchange Server 2010

Adatum_ProposedADSiteDesign.vsd

Results: After this exercise, you should have successfully modified the A. Datum AD DS site design.



Lab: Planning and Deploying Message Transport in Exchange Server 2010 L5-47

Exercise 2: Designing a Messaging Perimeter




•


• Adatum_Info.vsd

Task 2: Modify the A. Datum current perimeter design diagram with proposed


1.

Use callouts in the following diagram to document proposed changes to the perimeter design. For

each proposed change, provide:



2.

Indicate whether you need to deploy any additional server roles in each AD DS site.3. Indicate the required firewall changes to meet your design requirements.

4. Indicate any other infrastructure changes that you must implement to meet your design

requirements.

5.

For each company location, document how messages are delivered to the Internet, and how inbound

messages are delivered to internal recipients.





Adatum_ProposedPerimeterDesign.vsd

Results: After this exercise, you should have successfully designed the A. Datum messaging perimeter.




Exercise 3: Discussion: Improving an AD DS and Message Routing Design

Task 1: Discuss as a class, and then answer the following questions

Question: What changes did you make to the AD DS site configuration and the

organization’s message routing?

Answer: Answers should include:

• The current site link setting will create very inefficient message routing. By default, the

DefaultIPSiteLink site link has a cost of 100, which means that all messages will be routed directly

to the site with the closest proximity. To use the network connections with the highest bandwidth

and ensure that messages are queued outside the main offices if a destination server is

unavailable, you must make the following changes:

• The LondonSite to SanDiegoSite connection must have a higher cost than the LondonSite-

VancouverSite-SanDiegoSite connection.

• The LondonSite to ChennaiSite connection must have a higher cost than the LondonSite-

TokyoSite-ChennaiSite connection.

•

The VancouverSite to TokyoSite connection must have a higher cost than the VancouverSite-LondonSite-TokyoSite connection.

• You must create new site links to implement these changes. At a minimum, you will need new

three new site links:

• LondonSite to SanDiegoSite

• LondonSite to ChennaiSite

• VancouverSite to TokyoSite

• The cost for the new site links must be 201 or higher, or the route’s Exchange cost must be

assigned at 201 or higher.

•

You should merge LondonSite and LondonSite2 to address the issues of messages remaining inthe categorizer queue, and with the global address list (GAL) lookups for clients. This enables the

LondonSite clients to access the global catalog server in the LondonSite2 location, and does not

require deployment of an additional domain controller.

• You must deploy at least one Mailbox server role, one Hub Transport server role, and one Client

Access server role in each site.

• Recommendation: Retain the domain controller in Chennai, and build the secure server room. If

this is not done, the users in Chennai will have a very poor experience, as the logon process and

access to any email services will be very slow. As an alternative, you could propose upgrading the

network connection between Chennai and London, or between Chennai and Tokyo.

Question: If your recommended changes are implemented, how will messages flow betweenthe AD DS sites? Where will messages be queued in the event of a server or network

connection failure?

Answer: Message routing will flow as follows:

• From San Diego: San Diego-Vancouver-London-Tokyo-Chennai

• From Vancouver: Vancouver-London-Tokyo-Chennai, and Vancouver-San Diego

• From London: London-Tokyo-Chennai, and London-Vancouver-San Diego




• From Tokyo: Tokyo-London-Vancouver-San Diego, and Tokyo-Chennai

• From Chennai: Chennai-Tokyo-London-Vancouver-San Diego

In each case, the messages are queued on an available Hub Transport server in the Active

Directory site that is closest to the destination site.

Question: How did you design message routing to the Internet?Answer: To save network bandwidth and to decrease the messages queued on the Hub

Transport server in London, install an Edge Transport server in Vancouver and in Tokyo, and

enable inbound and outbound SMTP traffic. You can save additional bandwidth by

deploying Edge Transport servers in San Diego and Chennai as well, but the network

administrators are hesitant to open more ports, so the two requirements will need to be

balanced. For outbound email, the Edge Transport server could be configured to send email

to the Internet through the local Internet connection in each location.

To ensure that inbound messages are distributed evenly between the three Edge Transport

servers, you should create three mail exchanger (MX) resource records in the Adatum.com

zone with equal priorities. One MX record should be created for the TreyResearch.net

domain, and should use the Edge Transport server in Vancouver.

Question: What conflicting requirements were presented in the scenario? How did you

resolve conflicting requirements?

Answer: Conflict may result from resistance to changing the AD DS structure. If this arises,

emphasize the fact that creating the additional site links is the only way to meet message

routing requirements. Thus, you either have to change the requirements, or modify the AD

DS structure. Suggest that if you do not change the AD DS site link costs, AD DS replication

remains unaffected. You can still control message flow by configuring Exchange costs to the

site links.

The requirement for creating a positive experience for Microsoft® Outlook® Web App users

conflicts with the network administrators’ requirement to reduce firewall changes.

In particular, this will create a problem in Chennai. If Outlook Web App users connect to a

Client Access server in Tokyo or London, the Client Access server will proxy the client request

to the Client Access server in Chennai across a very slow network connection. To resolve this

issue, you can:

• Enable Internet access to the Client Access server in Chennai.

• Move the mailboxes for Outlook Web App users from Chennai to London or Tokyo.

• Significantly increase the bandwidth between Tokyo and Chennai, or between London and

Chennai.

Question: What additional information should you consider when designing message

routing in this scenario?Answer: In a real-world scenario, an important additional piece of information that you need

is how many messages are sent between company locations. This may affect the design, and

in particular, this information may help to resolve some of the conflicting requirements.

Results: After this exercise, you should have successfully improved on the A. Datum AD DS and message

routing design.




Exercise 4: Modifying the Routing Topology

Task 1: Determine the current organizational settings

1.

On VAN-EX1, click Start, point to All Programs, click Microsoft Exchange Server 2010, and then

click Exchange Management Console.

2.

In the navigation tree, expand Microsoft Exchange On-Premises, expand OrganizationConfiguration, click Hub Transport, and in the results pane, click the Send Connectors tab.

Question: Have any connectors been configured?

Answer: No

3. Click the Edge Subscriptions tab.

Question: Has an Edge Subscription been defined?

Answer: No

Task 2: Examine the current routing topology

1.

In Exchange Management Console, click Toolbox, and then double-click Routing Log Viewer.2.

In Routing Log Viewer, click the File menu, and then click Open log file.

3.

In the Open Routing Table Log File dialog box, click Browse server files.

4. In the Open dialog box, double-click the most recently created file in the list.

5.

In Routing Log Viewer, on the Active Directory Sites & Routing Groups tab, expand Active

Directory sites.

6. Expand Default-First-Site-Name.


Answer: No

7. Expand Servers.

8.

Under Servers, click the VAN-EX1.Adatum.com link.

Question: What is the AD DS cost of the link to VAN-EX1.Adatum.com?

Answer: 0

9.

Click the Send Connectors tab.

10. Expand Delivery agent connectors.

Question: What Send Connectors are listed?

Answer: The following Send Connector is listed: Text Messaging Delivery Agent Connector.

11.

Click the Address Spaces tab.

12. Expand OTHER.

Question: What Address Spaces are listed?

Answer: The following Address Space is listed: MOBILE:*

13. Close Routing Log Viewer.




Task 3: Add a new accepted domain

1.

In Exchange Management Console, and in the navigation pane, click Organization Configuration.

2.

In Organization Configuration, click Hub Transport, and in the results pane, click the Accepted

Domains tab.

3.

In the Actions pane, click New Accepted Domain.4. In the New Accepted Domain Wizard, in the Name box, type Contoso.

5. In the Accepted Domain box, type Contoso.com.

6.

Click External Relay Domain, and then click New.


Task 4: Configure a send connector to support the new accepted domain

1.

In the Actions pane, click New Send Connector.

2. In the New Send Connector Wizard, in the Name box, type Contoso Connector.

3.

In the Select the intended use for this Send Connector list, click Partner, and then click Next.4. On the Address space page, click Add.

5. In the SMTP Address Space dialog box, in the Address box, type Contoso.com.

6. Select the Include all subdomains check box, in the Cost box, type 10, and then click OK .

7.

On the Address space page, click Next.

8.

On the Network settings page, click Next.

9. On the Source Server page, click Next.

10. On the New Connector page, click New.

11.

Click Finish.

Task 5: Update the default site configuration with Exchange Server-specific values

1. Click Start, point to All Programs, click Microsoft Exchange Server 2010, and then click Exchange

Management Shell.

2. At the Shell, type the following command, and then press Enter:

set-AdSite –id “Default-First-Site-Name” –HubSiteEnabled $true

3. At the Shell, type the following command, and then press Enter:

set-AdSiteLink –id “DEFAULTIPSITELINK” –ExchangeCost 25

4.

Close the shell.

Task 6: Add an Edge subscription

1.

Switch to VAN-EDG.

2.


Management Shell.




3. At the Exchange Management Shell, type the following command, and then press Enter:

new-edgesubscription –filename C:\EdgeSubscriptionExport.xml

4.

When prompted, type Y, and then press Enter.

5. At the Exchange Management Shell, type the following command, and then press Enter:

copy c:\EdgeSubscriptionExport.xml \\VAN-EX1\c$

6. Switch to the VAN-EX1 server.

7.

In the Exchange Management Console, in the Actions pane, click New Edge Subscription.

8. In the New Edge Subscription Wizard, on the New Edge Subscription page, adjacent to the Active

Directory site box, click Browse.

9.

In the Select Active Directory Site dialog box, double-click Default-First-Site-Name.

10. On the New Edge Subscription page, adjacent to the Subscription file box, click Browse.

11. In the File name box, type C:\EdgeSubscriptionExport.xml, and then click Open.

12.

On the New Edge Subscription page, click New.

13. When prompted, click Finish.

Note You may receive a warning. This is expected.

Task 7: Review the updated topology

1. In Exchange Management Console, click Toolbox, and then double-click Routing Log Viewer.

2. In Routing Log Viewer, click the File menu, and then click Open log file.

3.

In the Open Routing Table Log File dialog box, click Browse server files.4. In the Open dialog box, double-click the most recent file in the list.

5. In Routing Log Viewer, on the Active Directory Sites & Routing Groups tab, expand Active

Directory sites.

6. Expand Default-First-Site-Name.


Answer: Yes.

7. Click the Send Connectors tab.

8.

Expand SMTP connectors.

Question: What SMTP Send Connectors are listed?

Answer: The following Send Connectors are listed:

• Contoso Connector

• EdgeSync – Default-First-Site-Name to Internet

• EdgeSync – Inbound to Default-First-Site-Name.

9.

Click the Address Spaces tab.




10. Expand SMTP.

Question: What SMTP Address Spaces are listed?

Answer: *; --; *.contoso.com.

11. Expand *.contoso.com, expand Connectors, and then expand Contoso Connector.

Question: What is the connector cost for the Contoso Connector?

Answer: 10

12. Close the Routing Log Viewer.

Results: After this exercise, you should have modified the message routing topology.



following steps:

1.


2.



4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EDG. Close the virtual



6.

To connect to the virtual machine for the next module’s lab, click 10233B-VAN-DC1, and then in the




7.

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

machine.




L6-55

Module 6: Planning and Deploying Messaging Security

Lab: Planning and Deploying MessagingSecurity

Exercise 1: Designing Message Security


• Review the contents of the Message Security Requirements section in the Security Requirements.doc.


message security plan

• Complete the relevant section of the following document. In the document, provide:





Document Author

Date

Jason Carlson

12th March 2010



Hub Transport rule Adds a disclaimer to all messages sent to the Internet.

Apply to all users, and then configure an exception for members of the

Sales team.

Hub Transport rule Adds a disclaimer to all messages sent to the Internet.

Apply to members of the Sales team.

Hub Transport rule Block all messages with a Company Internal classification from being sentto the Internet.

Send a response to users indicating they are not allowed to send messageswith this classification to the Internet.

Classification Create a new classification named Strategic Acquisitions.

Hub Transport rule Block messages with a classification of Strategic Acquisitions from beingsent to any user not on the Strategic Acquisitions team.



L6-56 Module 6: Planning and Deploying Messaging Security

(continued )




SMTP Send andReceive connectors

Install a certificate trusted by Contoso Simple Mail Transfer Protocol (SMTP)servers on the Edge Transport server that will be used to send and receiveemail from Contoso, Ltd.

Configure a Receive connector that will accept connections only from theContoso SMTP server’s IP address.

Configure a Send connector that will use the Contoso’s SMTP servers as asmart host.

Configure an address space on the SMTP Send connector of Contoso.com.

Configure inbound and outbound Domain Security.

SMTP Send andReceive connectors

Configure a Receive connector that will accept connections only from theBrussels law firm’s SMTP server’s IP address.

Configure a Send connector that will use the law firm’s SMTP server as asmart host.

Configure an address space on the SMTP Send connector that matches thedomain name of the law firm.

Configure the security on the Send and Receive connector as externallysecured.

S/MIMEconfiguration forOffice Outlook

Install an Enterprise certification authority (CA) on a Windows Server®2008. Configure the CA as a subordinate server to a commercial CA byobtaining a subordinate CA certificate.

Configure an Active Directory® Group Policy object that will assign acertificate to all users in the Active Directory forest.

Provide instructions for users to configure Secure/Multipurpose Internet

Mail Extensions (S/MIME) in Office Outlook.

Additional notes




Lab: Planning and Deploying Messaging Security L6-57



Question: How did you address the need to exchange secure email between A. Datum

Corporation and Contoso, Ltd.?

Answer: The design calls for the Domain Security solution to ensure that all email messages

are encrypted and connections are authenticated.

Question: Does your organization have a requirement for the Domain Security solution?

What barriers will there be to adopting this solution?

Answer: The Domain Security solution requires that you negotiate with the partner

organization to ensure that their Exchange Servers also are configured to support Domain

Security. This may be an issue in some organizations.

Results: After this exercise, you should have successfully designed message security for A Datum.




Exercise 2: Designing Antivirus and Anti-Spam Solutions


• Review the contents of the Virus and Spam Filtering Requirements in the Security Requirements.doc.


antivirus and anti-spam solution

• Complete both the Anti-Spam and Antivirus Solution Components section of the following

document. In the document, provide:





Document Author

Date

Jason Carlson

12th

March 2010Anti-Spam Solution Components


Anti-spam software Must be installed on each Edge Transport server that will accept incomingemail from the Internet.

IP Allow List provider Configure the IP Allow List setting on the Edge Transport server to use theIP Allow List provider.

IP Block List provider Configure the IP Block List setting on the Edge Transport server to use theIP Block List providers.

SMTP connectors The messages from Contoso, Ltd will not be scanned for spam, because themessages are Domain Secured. The messages from the law firm will not bescanned for spam, because the messages will be treated as authenticated.

Content filter andquarantine mailbox

In order to implement content filtering, but still ensure that not too manyfalse positives are filtered, configure a content filtering Quarantine mailbox,and then regularly monitor the Quarantine mailbox for false positives.Modify the content filter as required to reduce false positives.

Sender ID filtering In order to reduce the number of messages with spoofed addresses, enableSender ID filtering. Configure the filter to mark all messages that do notpass the Sender ID filter. Most of these messages will then be filtered by thecontent filter.

Safelist aggregation Implement edge synchronization between the Edge Transport server andthe Active Directory sites where inbound messages will be allowed. Thenimplement safelist aggregation for all user mailboxes in the organization.

Blocked recipient lists Add the SMTP addresses for all distribution lists with more than 200members to the blocked recipients list on the Edge Transport servers.

Note: You can also configure the distribution list properties to acceptmessages from only authenticated users.




(continued )


Antivirus Solution Components


Antivirus software Must be installed on each Edge Transport server that will accept incomingemail from the Internet, and on each Hub Transport server in theorganization.

Antivirus software Must be installed on each client computer in the organization.

Antivirus stamping The Hub Transport servers in the organization should be configured to notscan any messages that have a valid antivirus stamp.

Edge Transport servers should scan all outbound and inbound messages,whether the message has a valid antivirus stamp or not.

Antivirus update Configure to automatically update the antivirus files on the Hub Transportservers daily, and to update the antivirus files on the Edge Transport serversevery six hours.

On the Hub Transport servers, configure an alert if the files have not beenupdated for two days. On the Edge Transport servers, configure an alert ifthe files have not been updated for 12 hours.

Additional notes




Question: How did you design the antivirus and anti-spam solution for A. Datum

Corporation? How does this compare to the solution you would implement for your

organization?

Answer: Organizations will have varying requirements for designing the antivirus and anti-

spam solutions.

Results: After this exercise, you should have successfully designed an antivirus and anti-spam strategy for

A Datum.




Exercise 3: Implementing Message Security

Task 1: Create a new certificate template

1.

On VAN-DC1, click Start, in the Search box, type mmc, and then press Enter.

2. On the File menu, click Add/Remove Snap-in.

3.

In the Add or Remove Snap-ins dialog box, in the Available snap-ins list, double-click Certificate

Templates, and then click OK .

4. In the console tree, click Certificate Templates.

5.

In the details pane, right-click the User template, and then click Duplicate Template.

6. In the Duplicate Template dialog box, click Windows Server 2003 Enterprise, and then click OK .

7. In Properties of New Template dialog box, on the General tab, in the Template display name box,

type S/MIME Certificate.

8. Click the Security tab.

9. In the Group or user names list, click Domain Users (ADATUM\Domain Users).

10.

In Permissions for Domain Users, under Allow, select the Enroll and Autoenroll check boxes, and

then click OK .

11.

Close Console1, and do not save changes.

Task 2: Import the certificate template

1. Click Start, point to Administrative Tools, and then click Certification Authority.

2. In certsrv – [Certification Authority (Local)], expand AdatumCA, and then click Certificate

Templates.

3. Right-click Certificate Templates, point to New, and then click Certificate Template to Issue.

4.

In the Enable Certificate Templates dialog box, in the Name list, double-click S/MIME Certificate.

5. Close certsrv – [Certification Authority (Local)].

Task 3: Configure user certificate auto-enrollment

1. Click Start, point to Administrative Tools, and then click Group Policy Management.

2.

If necessary, expand Forest: Adatum.com, expand Domains, expand Adatum.com, and then click

Default Domain Policy. Click OK to close the Group Policy Management Console prompt.

3.

Right-click Default Domain Policy, and then click Edit.

4. In Group Policy Management Editor, expand User Configuration, expand Policies, expand Windows

Settings, expand Security Settings, and then click Public Key Policies.

5.

In the Object Type list, double-click Certificate Services Client – Auto-Enrollment.

6. In the Certificate Services Client – Auto-Enrollment Properties dialog box, in the Configuration

Model list, click Enabled.




7. In the Certificate Services Client – Auto-Enrollment Properties dialog box, select both the Renew

expired certificates, update pending certificates, and remove revoked certificates and the

Update certificates that use certificate templates check boxes, and then click OK .

8.

Close Group Policy Management Editor, and then close Group Policy Management.

Task 4: Update the group policy on VAN-CL11. Switch to VAN-CL1.

2. Click Start, in the Search box, type cmd, and then press Enter.

3. At the command prompt, type gpupdate /force, and then press Enter.

4. Close the command prompt.

5. Log off VAN-CL1.

Task 5: Verify the presence of the certificate for Scott

1. Log on to VAN-CL1 using the following credentials:



• Domain: Adatum

2. Click Start, in the Search box, type mmc, and then press Enter.

3.

On the File menu, click Add/Remove Snap-in.

4. In the Add or Remove Snap-ins dialog box, in the Available snap-ins list, double-click Certificates,

and then click OK .

5.

In the console tree, expand Certificate – Current User, expand Personal, and then click Certificates.

6. Verify the presence of a certificate based on the Secure/Multipurpose Internet Mail Extensions

(S/MIME) Certificate template, and then close Console1. Do not save settings.

Task 6: Configure Outlook for Scott

1. Click Start, point to All Programs, click Microsoft Office, and then click Microsoft Outlook 2010.

2. In the Outlook 2010 Startup Wizard, click Next.

3.

On the Email Accounts page, click Yes, and then click Next.

4. On the Auto Account Setup page, click Next.

5.

When prompted, click Finish.

6.

In User Name dialog box, click OK .

7.

In the Welcome to the Microsoft Office 2010 wizard, click Don’t make changes and then click OK .

8. Close Microsoft Outlook.

9.

Log off.




Task 7: Verify the presence of the certificate for Marcel

1.


• User name: Marcel


•

Domain: Adatum

2. Click Start, in the Search box, type mmc, and then press Enter.

3. On the File menu, click Add/Remove Snap-in.

4. In the Add or Remove Snap-ins dialog box, in the Available snap-ins list, double-click Certificates,

and then click OK .

5. In the console tree, expand Certificate – Current User, expand Personal, and then click Certificates.

6.

Verify the presence of a certificate based on the S/MIME Certificate template, and then close

Console1. Do not save settings.

Task 8: Configure Outlook for Marcel

1.

Click Start, point to All Programs, click Microsoft Office, and then click Microsoft Outlook 2010.

2. In the Outlook 2010 Startup Wizard, click Next.

3. On the E-mail Accounts page, click Yes, and then click Next.

4.

On the Auto Account Setup page, click Next.

5. When prompted, click Finish.

6. In User Name dialog box, click OK .

7.

In the Welcome to the Microsoft Office 2010 wizard, click Don’t make changes and then click OK .

Task 9: Send a signed and sealed message to Scott1. Click New E-mail.

2. In the Untitled – Message (HTML) dialog box, in the To box, type Scott, and then press the CTRL+K

keys.

3. In the Subject box, type S/MIME Test.

4.

Click the Options tab.

5. On the ribbon, expand More Options.

6. In the Properties dialog box, click Security Settings.

7.

In the Security Properties dialog box, select the following check boxes, and then click OK :

•

Encrypt message contents and attachments

• Add a digital signature to this message

• Request S/MIME receipt for this message

8. In the Properties dialog box, click Close, and then click Send.

9. Close Microsoft Outlook.

10.

Log off.




Task 10: Verify receipt of the secured message

1.




•

Domain: Adatum

2. Click Start, point to All Programs, click Microsoft Office, and then click Microsoft Outlook 2010.

3. Double-click the new message called S/MIME Test.

4. In the message, click the padlock symbol. Read the information, and then click Close.

5.

In the message, click the symbol next to the padlock symbol. Read the information, and then click

Close.

Results: After this exercise, you should have successfully implemented some aspects of the messaging

security design for A Datum.



following steps:

1. On the host computer, start Hyper-V™ Manager.


3.


4. Repeat these steps for 10233B-VAN-EX1 and 10233B-VAN-CL1. Close the virtual machine connection

windows.

5.












L7-65

Module 7: Planning and Deploying Messaging Compliance

Lab: Planning and Deploying MessagingCompliance

Exercise 1: Planning a Message Transport Implementation


• Review the points related to message transport in the Exercise 1 scenario.

Task 2: Document the required configuration for message transport


A. Datum Message Transport Plan


Document AuthorDate

Jason Carlson15th Apr 2010


Determine how you will manage message transport.

Proposals

Question: Are transport rules required? If so, how should you configure them?

Answer: Yes. Four transport rules are required.

The first transport rule applies to Internet-delivered messages for the Sales group, and adds adisclaimer to each email message.

The second transport rule applies to Internet-delivered messages for everyone except the Sales

group, and adds a disclaimer to each email message. An exception excludes members of the Salesgroup.

The third transport rule applies to Internet-delivered messages with the Company Internalclassification, and blocks these messages.

The fourth transport rule applies to messages classified as Acquisitions Confidential. ExchangeServer blocks these messages if they are addressed to anyone other than the Strategic Acquisitionsteam.

Question: Is message moderation required? If so, how should you configure it?

Answer: No. There are no requirements that indicate a need for message moderation.

Question: Are message classifications required? If so, how should you configure them?

Answer: Yes. You must create two classifications: Company Internal, and Strategic Acquisitions.


Results: After this exercise, you should have created a message transport plan.



L7-66 Module 7: Planning and Deploying Messaging Compliance

Exercise 2: Planning a Message Journaling and Archiving Solution






Question: In the Message Compliance Interview, what points are raised that impact your message

journaling and archiving plan?

Answer:

• You must create personal archives to replace personal folders (PST) files.

• Auditors must be able to prevent specific users from deleting messages and must be able to review

the saved messages for those users.

• Auditors need to monitor and review messages sent to the Executives group.

Task 3: Document the required configuration for journaling and archiving




Document Author

Date

Jason Carlson

15th Apr 2010


Determine how you will configure journaling and archiving.

Proposals

Question: Are personal archives required?

Answer: Yes. That is an explicit requirement.

Question: Should you remove PST files?

Answer: Yes. PST files are a management problem. You should prevent users from creating newPST files, and you should provide them with instructions about how to move the content from PSTfiles to personal archives.

Question: How can users access personal archives? Does this affect which users will receivepersonal archives usage?

Answer: Users can access personal archives by using the Microsoft® Office Outlook® 2010messaging client, Office Outlook 2007, or Microsoft Outlook Web App. You may want to enablepersonal archives only after users upgrade to a version of Outlook that supports personal archives.



Lab: Planning and Deploying Messaging Compliance L7-67

(continued )


Question: Is journaling required? If so, how should you configure it?

Answer: Yes. The Executives group requires journaling. You can create a journal rule for messagessent to this group.

Question: How can you prevent users from deleting messages?

Answer: Enable mailboxes with litigation holds to prevent the mailbox owners from deletingmessages.

Question: Can auditors prevent users from deleting messages?

Answer: Yes. You can assign auditors to the Legal Hold management role. The auditors can thenenable a litigation hold on a mailbox-by-mailbox basis.


Results: After this exercise, you should have created a journaling and archiving plan.




Exercise 3: Planning a Messaging Records Management Implementation






Question: In the Message Compliance Interview, what points are raised that impact your MRM plan?

Answer:

• Archiving should affect only Exchange Server 2010 mailboxes.

• Archive all messages after one year.

• Archive deleted items after 30 days.

•

Allow users to mark individual items not to be archived.

Task 3: Document the required MRM configuration


A. Datum Messaging Records Management Plan


Document Author

Date

Jason Carlson

15th Apr 2010


Determine how you will implement MRM.

Proposals

Question: Will you use managed folder policies for MRM? If so, how should you configure them?

Answer: No, you will not use managed folder policies, because there are no requirements for them.Managed folder policies cannot archive messages.

Question: Will you use retention policies for MRM? If so, how should you configure them?

Answer: Yes, you will use retention policies, because you can meet all of the requirements by usingthem. The retention policies apply if a mailbox is on Exchange Server 2010.

Create one retention policy, in which the:

• Default policy tag archives messages after one year.

• Archive policy tag removes deleted items after 30 days.

•

Personal tag allows items to not be archived.

Apply the retention policy to all mailboxes on the Exchange Server 2010 Mailbox servers.


Results: After this exercise, you should have created an MRM plan.




Exercise 4: Implementing a Message Compliance Plan

Task 1: Prevent ‘Company Internal’ classification messages from being sent to the

Internet

1. On VAN-EX1, click Start, point to All Programs, click Microsoft Exchange Server 2010, and then

click Exchange Management Shell.2. At the shell, type the following command, and then press ENTER:

New-MessageClassification -name “Company Internal” –DisplayName “Company Internal”

-DisplayPrecedence Highest -RetainClassificationEnabled $true

-SenderDescription “This message is for internal distribution only; it will not be

forwarded on to the Internet”

3. At the shell, type the following command, and then press ENTER:

New-SystemMessage –DsnCode 5.7.999 –Text “Internal recipients only”–Internal $True –Language En


Management Console.

5. Expand Microsoft Exchange On-Premises (van-ex1.adatum.com), and then expand Organization

Configuration.

6. Click the Hub Transport node, and then, in the Actions pane, click New Transport Rule.

7. In the New Transport Rule Wizard, on the Introduction page, in the Name box, type Company

Internal Rule, and then click Next.

8. On the Conditions page, in the Step 1: Select condition(s) list, select the sent to users that are

inside or outside the organization, or partners check box.

9. In the Step 2: Edit the rule description by clicking an underlined value box, click ‘Inside the

organization’.

10. In the Scope list, click Outside the organization, and then click OK .

11. In the Step 1: Select condition(s) list, select the marked with classification check box.

12.

In the Step 2: Edit the rule description by clicking an underlined value box, click classification.

13.

In the Select message classification window, click Company Internal, and then click OK .

14. On the Conditions page, click Next.

15. On the Actions page, in the Step 1: Select actions list, select the send rejection message to sender

with enhanced status code check box.

16. In the Step 2: Edit the rule description by clicking an underlined value box, click rejection

message.

17. In the Specify rejection message dialog box, in the Bounce message box, type Messages

classified as Company Internal cannot be sent to the Internet, and then click OK .

18. In the Step 2: Edit the rule description by clicking an underlined value box, click enhanced

status code.

19. In the Specify Enhanced Status Code dialog box, in the text box, type 5.7.999, and then click OK .




20. On the Actions page, click Next.

21.

On the Exceptions page, click Next.

22.

On the Create Rule page, click New.


Task 2: Test the classification rules

1.

On VAN-EX1, click Start, point to All Programs and then click Internet Explorer.

2. In the address bar for the Microsoft Internet Explorer® browser, type

https://van-ex1.adatum.com/owa, and then press ENTER.

3. Click This is a private computer.

4. In the Domain\user name box, type adatum\paul.

5.

In the Password box, type Pa$$w0rd, and then click Sign in.

6.

On the Language page, click OK .

7.

In Outlook Web App, click New.

8.

In the To box, type [email protected].

9.

In the Subject box, type Company financial results.

10. In the menu bar, click the Permission button, and then click Company Internal.

11. Click Send.

12.

After a moment, click the new message.

Question: Was the delivery successful?

Answer: No.

13.

Scroll through the message.

Question: What error do you see?

Answer: #550 5.7.999 Messages classified as Company Internal cannot be sent to the Internet # #

14.


Task 3: Enable personal archives for all mailboxes in Mailbox Database 1

1. ON VAN-EX1, in the Exchange Management Console, expand Recipient Configuration, and then

click Mailbox.

2. In the Mailbox – Entire Forest pane, click Create Filter.

3. Configure the filter as Database Equals Mailbox Database 1, and then click Apply Filter.

4.

Select all visible mailboxes by using SHIFT+click.

5. Right-click the selected mailboxes, and then click Enable Archive.

6. In the Enable Archive Mailbox window, click Create a local archive.

7.

Select the Select a specific mailbox database rather than having on selected automatically

check box.




8. Click the Browse button, click Mailbox Database 1, and then click OK .

9.

In the Enable Archive Mailbox window, click OK .

10.

In the warning window, click Yes.

Task 4: Review the default policy tags and retention policies

1.

In the Exchange Management Console, in Organization Configuration, click Mailbox.

2.

Click the Retention Policy Tags tab, and then read the list of retention policy tags.

3. Click the Retention Policies tab, and then double-click Default Archive and Retention Policy.

4. In the Default Archive and Retention Policy Properties window, on the General tab, review the list

of retention policy tags that are part of this policy.

5. Click the Mailboxes tab, and then review the list of mailboxes that this retention policy is applied to.

6.

Click Cancel.

Task 5: Create the Standard Mailbox Retention Policy

1.

On VAN-EX1, in the Exchange Management Console, in the Actions pane, click New RetentionPolicy Tag.

2. In the New Retention Policy Tag Wizard, on the Introduction page, enter the following, and then

click New:

• Tag Name: Default 1 year archive

• Tag Type: All other folders in the mailbox


• Action to take when the age limit is reached: Move To Archive

• Comment: Archive messages after 1 year

3.


4.

In the Actions pane, click New Retention Policy Tag.

5. In the New Retention Policy Tag Wizard, on the Introduction page, enter the following, and then

click New:

• Tag Name: Deleted Items 30 day removal

• Tag Type: Deleted Items


• Action to take when the age limit is reached: Delete and Allow Recovery

•

Comment: Remove deleted items after 30 days

6.


7.

In the Actions pane, click New Retention Policy.

8. In the New Retention Policy Wizard, on the Introduction page, in the Name box, type Standard

Mailbox Retention Policy.

9.

Click Add, click Default 1 year archive, and then click OK .




10. Click Add, click Deleted Items 30 day removal, and then click OK .

11.

Click Next.

12.

On the Select Mailboxes page, click Next.

13. On the New Retention Policy page, click New.

14.


Task 6: Apply the retention policy to the mailboxes in Mailbox Database 1

1. On VAN-EX1, in the Exchange Management Console, in Recipient Configuration, click Mailbox.

Notice that the filter for Mailbox Database 1 is still applied.

2. Click Add Expression.

3. Configure the new expression as Recipient Details Does Not Equal Discovery Mailbox, and then

click Apply Filter.

4. Select all visible mailboxes by using SHIFT+click.

5. Right-click the selected mailboxes, and then click Properties.

6.

In the User Mailbox Properties window, click the Mailbox Settings tab.

7. On the Mailbox Settings tab, click Messaging Records Management, and then click Properties.

8. In the Messaging Records Management window, select the Apply Retention Policy check box.

9.

Click Browse, click Standard Mailbox Retention Policy, and then click OK .

10. In the Messaging Records Management window, click OK .

11. In the User Mailbox Properties window, click OK .

12.

In the Bulk Edit Summary window, click OK .

13. Click Paul West, and then click Properties.

14. In the Paul West Properties window, click the Mailbox Settings tab, and then double-click

Messaging Records Management.

15. In the Messaging Records Management window, confirm that the Standard Mailbox Retention

Policy is applied, and then click Cancel.

16. In the Paul West Properties window, click Cancel.

Results: After this exercise, you should have prevented messages classified as Company Internal from

being sent to the Internet, created a retention policy, and applied it to all of the mailboxes in Mailbox

Database 1.

To prepare for the next moduleWhen you finish the lab, revert the machines to their initial state. To do this, complete the following steps:

1.

On the host computer, start the Microsoft Hyper-V® Manager.


3.








6.

To connect to the virtual machine for the next module’s lab, click 10233B-VAN-DC1, and then, in the





8.








L8-75

Module 8: Planning and Deploying High Availability

Lab: Planning and Deploying HighAvailability

Exercise 1: Designing High Availability for Exchange Servers



• High Availability Interviews

• User Distribution Summary

• Network Configuration



Question: In the High Availability Interviews, what points are raised that impact your high availability

design, and how do they impact it?

Answer: The High Availability Interviews raises the following points:

• The Chief Information Officer (CIO) wants all locations to be highly available. A single server failure

should not affect functionality. This means that all server roles in all locations must be highly

available.

• There is limited bandwidth on the wide area network (WAN) links. The WAN links may need to be

upgraded if transaction logs are replicated across them.

• The major sites with more than 3,000 users should be configured with an alternate site for disaster

recovery. The alternate site for disaster recovery should be in a different city, in case of a major

infrastructure problem.

• The major sites are using dedicated mailbox servers. Any restrictions caused by combining roles do

not apply in the major sites.

• Existing Mailbox servers are at capacity, and should not be used to host passive database copies. The

major sites require additional Mailbox servers specifically for hosting failed-over databases.

• Smaller sites will be highly available only within the site.

• Smaller sites are currently supported by only a single server with combined roles. An additional server

must be added to support high availability.

• Logical corruption should be prevented for 6 hours in each database availability group (DAG). There

should be one lagged copy in each DAG with a 6 hour delay.



L8-76 Module 8: Planning and Deploying High Availability

Question: Is there anything in the User Distribution Summary that raises high availability issues? If so,

what is it?

Answer: The User Distribution Summary raises the following points:

• It provides information about the number of users in each site. These figures are used to determine

whether offsite disaster recovery is required.

Question: Is there anything in the Network Configuration that raises high availability issues? If so, what is

it?

Answer: The Network Configuration raises the following points:

• All sites except for LondonSite2 have a connection to the Internet. All sites with a connection to the

Internet have Edge Transport servers.

• SanDiegoSite does not allow inbound traffic to Client Access servers. Access to the SanDiego Client

Access servers will be proxied through other sites.





Document Author

Date

Jason Carlson

24th April 2010


Determine how high availability will be provided for all server roles in San Diego.



Proposals


Answer: No, this is a small site with only 500 users. Offsite disaster recovery is not part of therequirements.


Answer: Provide high availability by creating a DAG.


Answer: Provide high availability by creating a client access array.


Answer: Provide high availability by installing a second Hub Transport server.


Answer: Yes, outgoing mail is routed through a local Edge Transport server. To make it highlyavailable, there should be two Edge Transport servers in the San Diego site.



Lab: Planning and Deploying High Availability L8-77

(continued )



Answer: There will be four servers, and in the perimeter network there will be two Edge Transportservers.

On the internal network, there will be two Exchange servers. Each Exchange server on the internalnetwork will have the Mailbox, Hub Transport, and Client Access server roles.


Answer: Half of the active databases will be located on each server, with passive copies on theother server. Even though a single server has the capacity to support all mailboxes, splitting theload may improve performance.

Each passive database copy will be configured with a 6-hour replay lag to prevent logicalcorruption of both databases.


Answer: Hardware load balancing must be used, because DAG members cannot be part of a

Network Load Balancing (NLB) cluster.

Question: Is any additional configuration required for the Hub Transport server role?

Answer: No, you can achieve high availability just by having two Hub Transport servers.





Document Author

Date

Jason Carlson

24th April 2010


Determine how high availability will be provided for all server roles in Vancouver.



Proposals


Answer: Yes, this is a large site with 5,000 users. Offsite disaster recovery is required.

To reduce the cost of network connectivity, the offsite disaster recovery should be located in NorthAmerica. The San Diego site can be used for offsite disaster recovery. Network links to San Diegofrom Vancouver may need to be improved with increased bandwidth for communication.


Answer: Provide high availability by creating a DAG, which will include a server in San Diego foroffsite disaster recovery.




(continued )



Answer: Provide high availability by creating a client access array in Vancouver. The client accessarray in San Diego can be used when offsite disaster recovery is performed.


Answer: Provide high availability by installing a second Hub Transport server in Vancouver. TheHub Transport servers in San Diego will be used when offsite disaster recovery is performed.


Answer: Yes, incoming and outgoing mail is routed through a local Edge Transport server. To makeit highly available, there should be two Edge Transport servers in the San Diego site.


Answer: In the perimeter network, there will be two Edge Transport servers.

On the internal network there will be:

• Two dedicated Hub Transport servers to provide high availability for message transportwithin the site and between sites.

• Three dedicated Client Access servers in a client access array. This ensures that even if aClient Access server fails, there is sufficient capacity to support all users.

• Three mailbox servers in Vancouver, and two additional Mailbox servers in San Diego. Tosupport the 6,000 users in Vancouver, two Mailbox servers are required. To provide highavailability in Vancouver, a third server is required. To provide site resilience, two Mailboxservers are located in San Diego.


Answer: One third of the active databases will be located on each server, with passive copies onanother local server, and on a server in San Diego. Evenly spreading the load in Vancouver canincrease performance. In San Diego, two servers provide sufficient capacity to host all mailboxes, ifrequired.

Each passive database copy in San Diego will be configured with a 6-hour replay lag to preventlogical corruption of the databases. Logical corruption is a very rare event. So, there will be noreplay lag for passive database copies in Vancouver.


Answer: The Client Access server role is not combined with the Mailbox server role. Therefore, NLBcan be used. It is also possible to use hardware load balancing, if desired.





Exercise 2: Implementing High Availability for Exchange Servers

Task 1: Prepare VAN-DC1 to be a DAG witness server

1.

On VAN-DC1, click Start, point to Administrative Tools, and then click Active Directory Users and

Computers.

2.

In Active Directory Users and Computers, expand Adatum.com, and then click Builtin.

3.

Right-click Administrators, and then click Properties.

4. In the Administrators Properties window, on the Members tab, click Add.

5.

In the Enter the object names to select box, type Exchange Trusted Subsystem, and then click

OK .

6. In the Administrators Properties window, click OK .

7.

Close Active Directory Users and Computers.

Task 2: Create a three-member DAG

1.

On VAN-EX3, click Start, point to All Programs, click Microsoft Exchange Server 2010, and thenclick Exchange Management Console.

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

Organization Configuration, and then click Mailbox.

3. Click the Database Availability Groups tab.

4. In the Actions pane, click New Database Availability Group.

5.

In the New Database Availability Group window, in the Database availability group name box,

type VancouverDAG.

6. Select the Witness Server check box, and then type VAN-DC1.

7.

Select the Witness Directory check box, type C:\VanDAGWitness, and then click New.

Note Step 7 will generate a warning, because the witness server is not an Exchange Server.



9.

In the Exchange Management Console, right-click VancouverDAG, and then click Properties.

10.

In the VancouverDAG Properties window, click the IP Addresses tab.

11. On the IP Addresses tab, click Add.

12. In the Add database availability group IP address(es) window, type 10.10.0.200 and click OK .

13.

In the VancouverDAG Properties window, click OK .

Note Step 13 generates a warning, because the witness server is not an Exchange server.

This does not indicate a problem.

14. Open the properties of VancouverDAG, and then add 10.10.0.200 as an IP address for the DAG.

15.

In the Microsoft Exchange Warning window, click OK .




16. In the Exchange Management Console, right-click VancouverDAG, and then click Manage Database

Availability Group Membership.

17. In the Manage Database Availability Group Membership window, click Add.

18.

In the Select Mailbox Server window, press the CTRL key while clicking to select VAN-EX1, VAN-

EX2, and VAN-EX3, and then click OK .

19. In the Manage Database Availability Group Membership window, click Manage.

20.


Task 3: Configure replication for Mailbox Database 1

1. On VAN-EX3, in the Exchange Management Console, click the Database Management tab, and then

click Mailbox Database 1.

2. In the Actions pane, under Mailbox Database 1, click Add Mailbox Database Copy.

3. In the Add Mailbox Database Copy window, click the Browse button.

4.

In the Select Mailbox Server window, click VAN-EX2, and then click OK .

5.

In the Add Mailbox Database Copy window, click Add.


7.

In the Actions pane, under Mailbox Database 1, click Add Mailbox Database Copy.

8.

In the Add Mailbox Database Copy window, click the Browse button.

9. In the Select Mailbox Server window, click VAN-EX3, and then click OK .

10. In the Add Mailbox Database Copy window, click Add.



Management Shell.

13. In the Exchange Management Shell, type the following command, and then press ENTER:

Set-MailboxDatabaseCopy –Identity “Mailbox Database 1\VAN-EX3” –ReplayLagTime 0.6:0:0

14. In the Exchange Management Shell, type the following command, and then press ENTER:

Get-MailboxDatabase “Mailbox Database 1” | Format-List ReplayLagTimes

15.

In the Exchange Management Shell, type the following command, and then press ENTER:

Get-MailboxDatabaseCopyStatus –Identity “Mailbox Database 1\VAN-EX3”




Task 4: Simulate the failure of VAN-EX1

1.

On the host computer, in the 10233B-VAN-EX1 window, click the Action menu, and then click Turn

Off .

2. In the Turn Off Machine window, click Turn Off .

3.

On VAN-EX3, in the Exchange Management Console, in the Actions menu, click Refresh.4. If any database copy has a status of Disconnected, click Refresh again.


Answer: The status for Mailbox Database 1 on each server is as follows:

• VAN-EX1: ServiceDown

• VAN-EX2: Mounted

• VAN-EX3: Healthy

Question: Why is the server where the database is mounted selected?

Answer: The database on VAN-EX3 is a lagged copy. During a failover, a non-lagged copy isselected over a lagged copy.

Task 5: Recover VAN-EX1

1. On the host computer, in the 10233B-VAN-EX1 window, click the Action menu, and then click Start.

2.

On VAN-EX1, select Start Windows Normally, and then press ENTER.

3. Wait a few minutes for VAN-EX1 to start.

4. On VAN-EX3, in the Exchange Management Console, in the Actions menu, click Refresh.


Answer: The status for Mailbox Database 1 on each server is as follows:


• VAN-EX2: Mounted


5. If the status of Mailbox Database 1 on VAN-EX1 is initializing, wait a few minutes, and then click

Refresh again. You may need to select Mailbox Database 1 on VAN-EX1 to refresh its status.





L9-83

Module 9: Planning a Disaster Recovery Solution

Lab: Planning a Disaster Recovery Solution

Exercise 1: Planning Disaster Recovery for Vancouver


• In the Exercise 1 scenario, review the Disaster Recovery SLA Notes.


Question: In the Disaster Recovery SLA Notes, what points are raised that impact your

disaster recovery plan for Vancouver?

Answer:

• There can be no data loss due to the failure of a single server.


•

You can consider high availability as a replacement for backup if there are at least two local

copies of a database, and a remote database copy in another site.

• To consider high availability as a replacement for backup, you must have one database copy that

is unaffected by logical corruption in another database copy for at least 12 hours.

• Any message deleted by a user must be recoverable for 30 days.

• Deleted mailboxes must be recoverable for 60 days.



A. Datum Disaster Recovery Plan for VancouverDocument Reference Number: JC040430/1

Document Author

Date

Jason Carlson

5th May 2010


Determine how disaster recovery will be provided for all server roles in Vancouver.

Proposals

Question: Does this site require backups?

Answer: No. According to the service level agreement (SLA) requirements, you do not need to backup a database availability group (DAG) with three copies, including site resilience. A three-memberDAG meets the requirement for no data loss when a single server fails. It also meets therequirement for only minutes of downtime.


Answer: Yes. The database copies in San Diego have only a 6-hour replay lag. The SLA specifiesthat to use a DAG as a replacement for backup, you must have at least a 12-hour replay lag. Alonger replay lag provides more time to discover a corruption, and to stop the replay process.



L9-84 Module 9: Planning a Disaster Recovery Solution

(continued )

A. Datum Disaster Recovery Plan for Vancouver

Question: Are any changes required for deleted item retention?

Answer: Yes. The default retention time for deleted items is 14 days. The SLA specifies that youmust increase deleted-item retention to retain messages for 30 days. Also, you should enable

single-instance recovery on the Mailbox servers. This ensures that you can recover even hard-deleted messages for the full 30 days.


Answer: Yes. The default retention time for deleted mailboxes is 30 days. The SLA specifies that youmust increase deleted-mailbox retention to 60 days.

Question: Do you need to back up data on Client Access servers?

Answer: No, you do not need to back up each Client Access server. However, you do need todocument your configuration changes. If a Client Access server fails, you can replace it with a newone, and then make the required configuration changes. You can copy customized webpages froma remaining server, but it would be easier to have a copy of those pages stored elsewhere so that

you can easily restore them.

Question: Do you need to back up data on Hub Transport servers?

Answer: No. All Hub Transport configuration data is stored in Active Directory® Domain Services(AD DS), including the customized Receive connectors. When replacing a failed Hub Transportserver, reuse the same computer account to retain the configuration by installing in Recoverymode.

Question: Do you need to back up data on Edge Transport servers?

Answer: No. There are two Edge Transport servers, so, you can export the configuration data fromthe remaining server, and then import it to the new server. However, to speed up this process, youcould have a copy of the configuration data already exported and waiting for recovery.

Question: Would your backup plan change if public folders were present in Vancouver?Answer: It depends on the type of data that is stored in the public folders. If the public folderswere being used only to support free/busy searches and offline address book downloads forMicrosoft® Office Outlook® 2003 clients, then a backup is not required. You can regenerate thatdata. If the public folders are used for collaboration between users, then they do need to be backedup, because public folder databases are not replicated in a DAG.


Results: After this exercise, you should have created a disaster recovery plan for the Vancouver site.



Lab: Planning a Disaster Recovery Solution L9-85

Exercise 2: Planning Disaster Recovery for San Diego





Question: In the Disaster Recovery SLA Notes document, what points are raised that impact

your disaster recovery plan for San Diego?

Answer:

• There can be no data loss due to the failure of a single server.


• You can consider high availability as a replacement for backup if there are at least two local

copies of a database, and a remote database copy in another site.

•

Any message deleted by a user must be recoverable for 30 days.• Deleted mailboxes must be recoverable for 60 days.

• Messaging functionality must be recoverable within one hour. You can recover historical data up

to 24 hours later.

• When recovering data from a backup, the maximum allowable data loss is four hours.

• Any location that is not configured with site resilience must archive backups offsite for one week.






A. Datum Disaster Recovery Plan for San Diego


Document Author

Date

Jason Carlson

5th May 2010


Determine how disaster recovery will be provided for all server roles in San Diego.

Proposals

Question: Does this site require backups? If so, how will you perform backups?

Answer: Yes, the site requires backups, because the DAG does not have site resilience. Therefore,you must perform a backup for mailbox databases. The two-member DAG will mean that thebackup is seldom required.

A disk-based backup solution is the most efficient way to perform backups. The data loss

requirements mean that a backup must be performed every four hours. If you use a disk-basedbackup solution — such as Microsoft System Center Data Protection Manager — then each backupwill finish very quickly.

To meet the archive requirements, you must back up to tape once a week for offsite storage.


Answer: No, this DAG does not require replay as part of the SLA, because a backup is beingperformed.

Question: Are any changes required for deleted-item retention?

Answer: Yes. The default retention time for deleted items is 14 days. The SLA specifies that deleted-item retention must be increased to retain messages for 30 days. Also, you should enable single-instance recovery on the Mailbox servers. This ensures that you can recover even hard-deleted

messages for 30 days.


Answer: Yes. The default retention time for deleted mailboxes is 30 days. The SLA specifies that youmust increase deleted mailbox retention to 60 days.

Question: How will you meet the recovery requirement of one hour?

Answer: If a server or database fails, you can use dial-tone recovery to quickly restore basicmessaging functionality. Next, you can restore historical data to a recovery database, and mergethe historical data into the dial-tone database.

Question: Would your backup plan change if public folders were present in San Diego?

Answer: No, backups are already being performed.


Results: After this exercise, you should have created a disaster recovery plan for the San Diego site.




Exercise 3: Implementing Single-Item Recovery

Task 1: Enable single-item recovery for a mailbox

1.

On VAN-EX1, click Start, point to All Programs, click Microsoft Exchange Server 2010, and then

click Exchange Management Console.

2.

In the Exchange Management Console, expand Microsoft Exchange On-Premises, expandOrganization Configuration, and then click Mailbox.

3.

On the Database Management tab, right-click Mailbox Database 1, and then click Properties.

4.

In the Mailbox Database 1 Properties window, click the Limits tab.

5. In the Keep deleted items for (days) box, type 30.

6. In the Keep deleted mailboxes for (days) box, type 60, and then click OK .

7.


Management Shell.

8.

In Exchange Management Shell, type the following command, and then press ENTER:

Set-Mailbox Luca –SingleItemRecoveryEnabled $true

Task 2: Configure a user for message recovery

1. On VAN-CL1, if necessary, log off, and then log on as Luca using the password Pa$$w0rd.

2.

On the taskbar, click Internet Explorer.

3.

In the Address bar of the Microsoft Internet Explorer® browser, type

https://van-ex1.adatum.com/owa, and then press ENTER.

4.

Log on as Adatum\Administrator using the password Pa$$w0rd.

5. Click OK to accept the default time zone.

6. Click Options, and then click See All Options.

7.

Click Manage Myself , and then click My Organization.

8. Click Roles & Auditing, and then click the Administrator Roles tab.

9. Click the Discovery Management role group, and then click Details.

10. In the Role Group window, scroll to Members, click Add, double-click Andreas Herbinger, and then

click OK .

11. Click Save.

12.


Task 3: Delete and purge a message

1. On VAN-CL1, click Start, point to All Programs, click Microsoft Office, and then click Microsoft

Outlook 2010.

2. Click New E-mail to create a new message.




3. In the Untitled – Message (HTML) window, type the following, and then click Send:

• To: Luca

• Subject: Test of SIR

4. In the Inbox, right-click the Test of SIR message, and then click Delete.

5.

Click the Deleted Items folder.

6.

Right-click the Test of SIR message, and then click Delete.

7. Click Yes to permanently delete the item.

8. Click the Folder tab, and then click Recover Deleted Items.

9.

In the Recover Deleted Items From – Deleted Items window, click Test of SIR, and then click the X

to purge the message.

10.

Click OK to confirm purging the message.

Task 4: Locate a recoverable message

1.

On VAN-CL1, on the taskbar, click Internet Explorer.

2.

In the Address bar, type https://van-ex1.adatum.com/owa, and then press ENTER.

3.

Log on as Adatum\Andreas using the password Pa$$w0rd.

4. Click OK to accept the default time zone.

5. Click Options, and then click See All Options.

6.

Click Manage Myself , and then click My Organization.

7. Click Mail Control.

8.

In Multi-Mailbox Search, click New.

9.

In the New Mailbox Search window, in the Keywords area, type SIR.

10. Click Mailboxes to Search to expand the settings.

11. Click Search specific mailboxes or the mailboxes of members of distribution groups, and then

click Add.

12. In the Select Mailbox window, double-click Luca Dellamore, and then click OK .

13.

In the New Mailbox Search window, click Search Name, Type, and Storage Location to expand

the settings.

14. In the Search name box, type Luca’s lost message.

15.

Click Copy the search results to the destination mailbox.

16.

In Select a mailbox in which to store the search results, click Browse, click Discovery SearchMailbox, and then click OK .

17. Click Save.

18. Click Luca’s lost message to view the results. You may need to click the refresh button.

19.

In the search results, click [open].




20. In the new Outlook Web App window, click OK to accept the default language and time zone.

21.

Click the Luca’s lost message folder.

22.

Expand Luca’s lost message, and then click Results -date and time,.

Task 5: Create a role group for exporting mailbox contents

•

On VAN-EX1, in the Exchange Management Shell, type the following command, and then press

ENTER:

New-RoleGroup –Name ExportMail –Roles “Mailbox Import Export” –Members Andreas

Task 6: Recover a message

1. On VAN-EX1, log off as Administrator, and then log on as Adatum\Andreas using the password

Pa$$w0rd.

2. Open the Exchange Management Shell.

3.

In the Exchange Management Shell, type the following command, and then press ENTER:

Search-Mailbox “Discovery Search Mailbox” –SearchQuery ‘Subject:“SIR”’ –TargetMailboxLuca –TargetFolder Recovered

4.

On VAN-CL1, in Microsoft Outlook 2010, in the folder list, expand Recovered, expand Discovery

Search Mailbox–DateandTime, expand Primary Mailbox, expand Luca’s lost message, and then

click Results–DateandTime.

Results: After this exercise, you should have implemented single-item recovery and recovered a message.



steps:



3.


4. Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3. Close the

virtual machine connection windows.







8.








L10-91

Module 10: Planning Microsoft® Exchange Server 2010Monitoring and Troubleshooting

Lab: Planning Exchange Server 2010

Monitoring and TroubleshootingExercise 1: Establishing a Baseline for Performance

Task 1: Create a User Defined data collector set

1. On VAN-EX1, click Start, point to All Programs, point to Microsoft Exchange Server 2010, and

then click Exchange Management Console.

2. In the console tree, expand Microsoft Exchange On-Premises (van-ex1.adatum.com), and then

click Toolbox.

3.

In the results pane, double-click Performance Monitor.

4.

In the left pane, expand Performance Logs and Alerts.

5. Expand Data Collector Sets, right-click User Defined, click New, and then click Data Collector Set.

6.

In the Name box, type Baseline, click Create manually (Advanced), and then click Next.

7. On the What type of data do you want to include page, select the Performance counter check

box, and then click Next.

8.

On the Which performance counters would you like to log page, click Add.

9. In the Available counters list, click and expand each of the following objects, and for each, click Add.

• Memory

•

MSExchangeIS• MSExchangeIS Mailbox

• MSExchangeTransport Queues

• MSExchangeTransport SmtpReceive

• MSExchangeTransport SmtpSend

• Physical Disk

• Processor

• Server

• System

10.

Click OK .

11. In the Sample Interval box, type 1, and then click Next.

12. On the Where would you like the data to be saved page, click Next.

13.

On the Create the data collector set page, click Finish.





Lab: Planning Exchange Server 2010 Monitoring and Troubleshooting L10-93

23. Switch to Exchange Server Performance Monitor.

24.

Right-click Baseline, and then click Start.

25.

Switch back to VAN-DC1, and wait until the simulation has finished.

26. After the simulation has finished, switch back to the VAN-EX1 server.

Note This simulation runs for 10 minutes.

Task 3: Gather performance data, and analyze results

1. On VAN-EX1, switch to Exchange Server Performance Monitor.

2.

Right-click Baseline, and then click Stop.

3. In the left pane, click System Monitor. Click the red X in the toolbar repeatedly to remove all

counters from the display.

4.

Press Ctrl+L.

5.

Click Log files, and then click Add.

6.

In the Select Log File dialog box, double-click Admin, double-click Baseline, double-click the folder

that ends 000001, and then double-click DataCollector01.blg.

7. Click the Data tab.

8.

Click Add.

9.

In Performance object list, expand Memory.

10. In Available counters list, select Pages/sec, and then click Add.

11.

Use the information in the following table to add additional counters.


MSExchangeIS RPC Requests

MSExchangeIS User Count

MSExchangeIS Mailbox Local delivery rate

MSExchangeIS Mailbox Messages Delivered/sec

MSExchangeIS Mailbox Messages Queued For Submission

MSExchangeIS Mailbox Messages Sent/sec

MSExchangeTransport Queues Active Remote Delivery Queue Length

MSExchangeTransport Queues Retry Remote Delivery Queue Length

MSExchangeTransport Queues Submission Queue Length



L10-94 Module 10: Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

(continued )


MSExchangeTransport SmtpReceive Messages Received/sec

MSExchangeTransport SmtpSend Messages Sent/sec

Physical Disk % Disk Time

Physical Disk Avg. Disk Queue length

Processor % Processor Time

Server Pool Nonpaged Failures

Server Work Item Shortages

System Processor Queue Length

Note If Performance Monitor experiences problems, close and restart it. Then continue

from step 3.

12. Click OK , and then click OK again.

13. Click the down arrow on the toolbar, and then click Report.

14.

View the counter values, and then complete the following table.

Counter Average








MSExchangeTransport Queues - Active RemoteDelivery Queue Length






(continued )

Counter Average

MSExchangeTransport SmtpReceive - MessagesReceived/sec








Note Do not worry that some values are zero; this is a simulation.

Question: Do any counters indicate a bottleneck?

Answer: No.

Results: After this exercise, you should have created an Exchange Server performance baseline.




Exercise 2: Measuring the Production System Performance underAdditional Load

Note As this is a training exercise, you will use Load Generator to simulate the load.

Task 1: Generate additional load with Load Generator to simulate the environment

of heavier than planned for usage

1. Switch to VAN-DC1.

2.

In Microsoft Exchange Load Generator, click Start a new test.

3. Click Use the following saved configuration file, and then click Browse.

4. In the Please select a configuration file dialog box, double-click Baseline.xml, and then click

Continue.

5. On the Specify test settings page, click Continue with recipient management.

6. On the User settings page, in the text box, type 20, and then click Distribute users evenly across

databases.

7. Click Continue.

8.

On the Advanced recipient settings page, select the following check boxes.




• Create one per server


•

Use contacts

9.

In the Number of contacts box, type 50 and then click Continue.

10. On the Specify test user groups page, click the PLUS SIGN (+).

11. In the resulting item, in the Client Type list, click Outlook 2007 Online, and in the Action Profile

list, click Heavy.

12. On the Specify test user groups page, click the PLUS SIGN (+).

13.

In the resulting item, in the Client Type list, click Owa2010Module, and in the Action Profile list,

accept the defaults.

14. Click Continue, and on the Remote configurations page, click Continue.

15.

On the Configuration summary page, click Save the configuration file as.

16. In the Save As dialog box, in the File name box, type Adatum, and then click Save.

17.

In the Configuration Saved dialog box, click OK .

18.

Click Skip initialization phase and run the simulation immediately.

19. Switch to VAN-EX1.




20. Switch to Exchange Server Performance Monitor.

21.

Expand Data Collector Sets, expand User Defined, right-click Baseline, and then click Start.

22.

Switch to VAN-DC1.

23. When the simulation completes, switch to VAN-EX1.

Task 2: Compare the data with the baseline data

1.

Switch to Exchange Server Performance Monitor.

2. Right-click Baseline, and then click Stop.

3. In the right pane, right-click, and then click Properties.

4.

In the Performance Monitor Properties dialog box, click the Source tab, and then click Remove.

5. Click Log files, and then click Add.

6. In the Select Log File dialog box, click Up One Level, double-click the folder ending in 000002,

double-click DataCollector01.blg, and then click OK .

7.

View the counter values, and then complete the following table.

Counter Average








MSExchangeTransport Queues - Active RemoteDelivery Queue Length



MSExchangeTransport SmtpReceive - Messages

Received/sec







(continued )

Counter Average





Question: How do the values compare with those you previously recorded in the baseline

data?

Answer: Answer may vary.

• Processor resources are influenced by the increased load.

• There has been an increase in paging suggesting additional memory load.

• Disk load has not increased.

Results: After this exercise, you should have determined which server resources are likely to become

bottlenecked if server load continues to increase.



following steps:



3.


4. Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3.

Note You do not need to start any virtual machines, as this is the last lab of the course.



L11-99

Module 11: Upgrading to Microsoft® Exchange Server 2010

Lab: Upgrading to Microsoft ExchangeServer 2010

Exercise 1: Designing an Exchange Server 2010 Upgrade Strategy


• Review the following A Datum documentation:

• Adatum_ProposedADSiteDesign.vsd

• Adatum_ProposedPerimeterDesign.vsd


• Exchange_Server_2003_Configuration.doc

Task 2: Update the A. Datum Upgrade Design document• Answer the questions in the A. Datum Upgrade Design Questions document, and then complete the

A. Datum Upgrade Design document.



Document Author

Date

Jason Carlson

6th June 2010


Describe the upgrade strategy for the A. Datum organization.

Proposals

Question: Based on what you know about the A. Datum organization, what would be a reasonabletimeline for completing this migration?

Answer: Answers will vary. Because this upgrade does not require any client reconfigurations forusers, the organization could pursue a fairly aggressive timeline. Estimates for completing theupgrade should range from 3 to 12 months.

Question: What are the factors that will affect the timeline?

Answer: Factors that will impact the upgrade time line include:

• Project budget

• Resource availability (both personnel and hardware)

•

Test requirements

Question: Where will you perform the schema upgrade?

Answer: The schema upgrade must be done in the domain where the Schema Master is located. Asa best practice, you should disable schema replication on the Schema Master while performing theupgrade. After the upgrade is successfully completed, you can re-enable replication. In a largeorganization, allow enough time for the schema upgrade to replicate to all domain controllersbefore you prepare the domains.



L11-100 Module 11: Upgrading to Microsoft Exchange Server 2010

(continued )


Question: What is the process for preparing domains for Exchange Server 2010?

Answer: Each domain with Exchange Server 2010 users or servers must be prepared. After theschema upgrade has replicated to all domain controllers, you can run the setup with the

PrepareAllDomains option.

Question: How will you ensure that Exchange Server 2010 can coexist with Exchange Server 2003?

Answer: Run setup with the PrepareLegacyExchangePermissions option.

Question: Which site should be upgraded first?

Answer: London is the best site to upgrade first. The most experienced Exchange Serveradministrators are likely located in London, as well as the central team of administrators who havepermission throughout the organization. London is also the site with the most users and the front-end servers for Exchange Server 2003.

Question: Which server role should be implemented first in that site?

Answer: The Client Access server role should be implemented first. It is required to providecoexistence between Exchange Server 2003 and Exchange Server 2010.

Question: Should coexistence occur in multiple sites or a single location?

Answer: In general, it is better to limit coexistence to a single location to simplify the migrationprocess. If only a single location has coexistence, it is easy to configure message routing with asingle routing group connector. If time constraints dictate that multiple locations must havecoexistence, it is possible, but complexity increases.

Question: How will client access be configured to allow coexistence in the first site?

Answer: A client access array will be configured in the London site. The client access array will usethe external name of mail.adatum.com, which is currently used by the load-balanced front-endservers for Exchange Server 2003. A new legacy.adatum.com name will be configured for the load-

balanced front-end servers. The Exchange Server 2010 Client Access servers will be configured withthe legacy URL for the Exchange Server 2003 front-end servers.

All users will initially connect to mail.adatum.com. Outlook Web Access users with ExchangeServer 2003 mailboxes will be redirected to the Exchange Server 2003 front-end servers. TheExchange Server 2010 Client Access server will proxy connections for ActiveSync users. TheExchange Server 2010 Client Access server will communicate directly with Exchange Server 2003computers hosting mailboxes for Outlook Anywhere users.

Question: How will message transport be configured to allow coexistence in the first site?

Answer: The initial installation will have a single routing group connector between ExchangeServer 2010 and the London routing group. This will allow messages to be delivered betweenExchange Server 2003 and Exchange Server 2010.

Question: How will mailboxes be moved in the first site?Answer: Mailboxes can be moved from Exchange Server 2003 to Exchange Server 2010 as soon asall of the Exchange Server 2010 infrastructure is in place in London. Live mailbox moves are notsupported from Exchange Server 2003 to Exchange Server 2010. So, you will need to movemailboxes outside of standard business hours or arrange for downtime to move mailboxes.



Lab: Upgrading to Microsoft Exchange Server 2010 11-101

(continued )


Question: How will you move Internet message delivery from Exchange Server 2003 to ExchangeServer 2010 and use Edge Transport servers?

Answer: Edge transport servers can be introduced before Exchange Server 2010 Hub Transport

servers, but there is no reason to do so because there is already an anti-spam solution in place.After Exchange Server 2010 Hub Transport servers are introduced, then you can implement EdgeSynchronization, which simplifies the management of Edge Transport servers.

After Edge Synchronization is configured, then you can direct incoming messages to the new EdgeTransport servers rather than the existing anti-spam appliances. To support outgoing mail directlyfrom Exchange Server 2010 to the Internet, you must create a send connector. Then you mustdisable outbound mail delivery from Exchange Server 2003 to the Internet.

Question: When you begin migrating the second site to Exchange Server 2010, what process willyou use?

Answer: The same process as was used in London. The Client Access server will be implementedfirst, and then other server roles. After you verify that message delivery and all services workcorrectly, you can begin migrating mailboxes in the site.

To ensure that message delivery is efficient, you should create an additional routing groupconnector between Exchange Server 2010 and the routing group for the second site.

Question: How will you remove Exchange Server 2003?

Answer: Exchange Server 2003 cannot be completely removed until all mailboxes are migrated toExchange Server 2010. Any Exchange Server 2003 computers that no longer have mailboxes can beuninstalled. Care should be taken to ensure that bridgehead servers are not accidentally removed,which could affect message routing.

The Exchange Server 2003 front-end servers should be the last servers removed. They must remainin place to provide external Outlook Web Access connectivity for all external users with ExchangeServer 2003 mailboxes.


Results: After this exercise, you should have completed the A. Datum Upgrade document.





L11-102 Module 11: Upgrading to Microsoft Exchange Server 2010

Documents

10233BD-ENU-TrainerHandbook