10233BD-ENU-TrainerHandbook

O F F I C I A L

M I CRO S O F T

L EA RN I N G

PRO DU C T

10233B Designing and Deploying Messaging Solutions with Microsoft® Exchange Server 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

MICROSOFT LICENSE TERMS OFFICIAL MICROSOFT LEARNING PRODUCTS MICROSOFT OFFICIAL COURSE Pre-Release and Final Release Versions

These license terms are an agreement between Microsoft Corporation and you. Please read them. They apply to the Licensed Content named above, which includes the media on which you received it, if any. These license terms also apply to any updates, supplements, internet based services and support services for the Licensed Content, unless other terms accompany those items. If so, those terms apply. BY DOWNLOADING OR USING THE LICENSED CONTENT, YOU ACCEPT THESE TERMS. IF YOU DO NOT ACCEPT THEM, DO NOT DOWNLOAD OR USE THE LICENSED CONTENT. If you comply with these license terms, you have the rights below. 1.

DEFINITIONS. a. “Authorized Learning Center” means a Microsoft Learning Competency Member, Microsoft IT Academy Program Member, or such other entity as Microsoft may designate from time to time. b. “Authorized Training Session” means the Microsoft-authorized instructor-led training class using only MOC Courses that are conducted by a MCT at or through an Authorized Learning Center. c. “Classroom Device” means one (1) dedicated, secure computer that you own or control that meets or exceeds the hardware level specified for the particular MOC Course located at your training facilities or primary business location. d. “End User” means an individual who is (i) duly enrolled for an Authorized Training Session or Private Training Session, (ii) an employee of a MPN Member, or (iii) a Microsoft full-time employee. e. “Licensed Content” means the MOC Course and any other content accompanying this agreement. Licensed Content may include (i) Trainer Content, (ii) software, and (iii) associated media. f.

“Microsoft Certified Trainer” or “MCT” means an individual who is (i) engaged to teach a training session to End Users on behalf of an Authorized Learning Center or MPN Member, (ii) currently certified as a Microsoft Certified Trainer under the Microsoft Certification Program, and (iii) holds a Microsoft Certification in the technology that is the subject of the training session.

g. “Microsoft IT Academy Member” means a current, active member of the Microsoft IT Academy Program. h. “Microsoft Learning Competency Member” means a Microsoft Partner Network Program Member in good standing that currently holds the Learning Competency status. i.

“Microsoft Official Course” or “MOC Course” means the Official Microsoft Learning Product instructorled courseware that educates IT professionals or developers on Microsoft technologies.

j.

“Microsoft Partner Network Member” or “MPN Member” means a silver or gold-level Microsoft Partner Network program member in good standing.

k. “Personal Device” means one (1) device, workstation or other digital electronic device that you personally own or control that meets or exceeds the hardware level specified for the particular MOC Course. l. “Private Training Session” means the instructor-led training classes provided by MPN Members for corporate customers to teach a predefined learning objective. These classes are not advertised or promoted to the general public and class attendance is restricted to individuals employed by or contracted by the corporate customer. m. “Trainer Content” means the trainer version of the MOC Course and additional content designated solely for trainers to use to teach a training session using a MOC Course. Trainer Content may include Microsoft PowerPoint presentations, instructor notes, lab setup guide, demonstration guides, beta feedback form and trainer preparation guide for the MOC Course. To clarify, Trainer Content does not include virtual hard disks or virtual machines. 2.

INSTALLATION AND USE RIGHTS. The Licensed Content is licensed not sold. The Licensed Content is licensed on a one copy per user basis, such that you must acquire a license for each individual that accesses or uses the Licensed Content. 2.1

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

a. If you are a Authorized Learning Center: i. If the Licensed Content is in digital format for each license you acquire you may either: 1. install one (1) copy of the Licensed Content in the form provided to you on a dedicated, secure server located on your premises where the Authorized Training Session is held for access and use by one (1) End User attending the Authorized Training Session, or by one (1) MCT teaching the Authorized Training Session, or 2. install one (1) copy of the Licensed Content in the form provided to you on one (1) Classroom Device for access and use by one (1) End User attending the Authorized Training Session, or by one (1) MCT teaching the Authorized Training Session. ii. You agree that: 1. you will acquire a license for each End User and MCT that accesses the Licensed Content, 2. each End User and MCT will be presented with a copy of this agreement and each individual will agree that their use of the Licensed Content will be subject to these license terms prior to their accessing the Licensed Content. Each individual will be required to denote their acceptance of the EULA in a manner that is enforceable under local law prior to their accessing the Licensed Content, 3. for all Authorized Training Sessions, you will only use qualified MCTs who hold the applicable competency to teach the particular MOC Course that is the subject of the training session, 4. you will not alter or remove any copyright or other protective notices contained in the Licensed Content,

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

d. If you are a MCT. i. For each license you acquire, you may use the Licensed Content solely to prepare and deliver an Authorized Training Session or Private Training Session. For each license you acquire, you may install and use one (1) copy of the Licensed Content in the form provided to you on one (1) Personal Device and install one (1) additional copy on another Personal Device as a backup copy, which may be used only to reinstall the Licensed Content. You may not install or use a copy of the Licensed Content on a device you do not own or control. ii.

Use of Instructional Components in Trainer Content. You may customize, in accordance with the most recent version of the MCT Agreement, those portions of the Trainer Content that are logically associated with instruction of a training session. If you elect to exercise the foregoing rights, you agree: (a) that any of these customizations will only be used for providing a training session, (b) any customizations will comply with the terms and conditions for Modified Training Sessions and Supplemental Materials in the most recent version of the MCT agreement and with this agreement. For clarity, any use of “customize” refers only to changing the order of slides and content, and/or not using all the slides or content, it does not mean changing or modifying any slide or content.

2.2 Separation of Components. The Licensed Content components are licensed as a single unit and you may not separate the components and install them on different devices. 2.3 Reproduction/Redistribution Licensed Content. Except as expressly provided in the applicable installation and use rights above, you may not reproduce or distribute the Licensed Content or any portion thereof (including any permitted modifications) to any third parties without the express written permission of Microsoft. 2.4 Third Party Programs. The Licensed Content may contain third party programs or services. These license terms will apply to your use of those third party programs or services, unless other terms accompany those programs and services. 2.5 Additional Terms. Some Licensed Content may contain components with additional terms, conditions, and licenses regarding its use. Any non-conflicting terms in those conditions and licenses also apply to that respective component and supplements the terms described in this Agreement. 3.

PRE-RELEASE VERSIONS. If the Licensed Content is a pre-release (“beta”) version, in addition to the other provisions in this agreement, then these terms also apply: a. Pre-Release Licensed Content. This Licensed Content is a pre-release version. It may not contain the same information and/or work the way a final version of the Licensed Content will. We may change it for the final version. We also may not release a final version. Microsoft is under no obligation to provide you with any further content, including the final release version of the Licensed Content. b. Feedback. If you agree to give feedback about the Licensed Content to Microsoft, either directly or through its third party designee, you give to Microsoft without charge, the right to use, share and commercialize your feedback in any way and for any purpose. You also give to third parties, without charge, any patent rights needed for their products, technologies and services to use or interface with any specific parts of a Microsoft software, Microsoft product, or service that includes the feedback. You will not give feedback that is subject to a license that requires Microsoft to license its software, technologies, or products to third parties because we include your feedback in them. These rights

survive this agreement. c. Term. If you are an Authorized Training Center, MCT or MPN, you agree to cease using all copies of the beta version of the Licensed Content upon (i) the date which Microsoft informs you is the end date for using the beta version, or (ii) sixty (60) days after the commercial release of the Licensed Content, whichever is earliest (“beta term”). Upon expiration or termination of the beta term, you will irretrievably delete and destroy all copies of same in the possession or under your control. 4.

INTERNET-BASED SERVICES. Microsoft may provide Internet-based services with the Licensed Content, which may change or be canceled at any time. a. Consent for Internet-Based Services. The Licensed Content may connect to computer systems over an Internet-based wireless network. In some cases, you will not receive a separate notice when they connect. Using the Licensed Content operates as your consent to the transmission of standard device information (including but not limited to technical information about your device, system and application software, and peripherals) for internet-based services. b. Misuse of Internet-based Services. You may not use any Internet-based service in any way that could harm it or impair anyone 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 third party sites. Microsoft is not responsible for webcasting or any other form of transmission received from any third party sites. Microsoft is providing these links to third party sites to you only as a convenience, and the inclusion of any link does not imply an endorsement by Microsoft of the third party site.

12.

ENTIRE AGREEMENT. This agreement, and the terms for supplements, updates and support services are the entire agreement for the Licensed Content.

13.

APPLICABLE LAW. a. United States. If you acquired the Licensed Content in the United States, Washington state law governs the interpretation of this agreement and applies to claims for breach of it, regardless of conflict of laws principles. The laws of the state where you live govern all other claims, including claims under state consumer protection laws, unfair competition laws, and in tort. b. Outside the United States. If you acquired the Licensed Content in any other country, the laws of that country apply.

14.

LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the laws of your country. You may also have rights with respect to the party from whom you acquired the Licensed Content. This agreement does not change your rights under the laws of your country if the laws of your country do not permit it to do so.

15.

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

16.

LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. TO THE EXTENT NOT PROHIBITED BY LAW, YOU CAN RECOVER FROM MICROSOFT CORPORATION AND ITS SUPPLIERS ONLY DIRECT DAMAGES UP TO USD$5.00. YOU AGREE NOT TO SEEK TO RECOVER ANY OTHER DAMAGES, INCLUDING CONSEQUENTIAL, LOST PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES FROM MICROSOFT CORPORATION AND ITS RESPECTIVE SUPPLIERS. This limitation applies to o anything related to the Licensed Content, services made available through the Licensed Content, or content (including code) on third party Internet sites or third-party programs; and o claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence, or other tort to the extent permitted by applicable law. It also applies even if Microsoft knew or should have known about the possibility of the damages. The above limitation or exclusion may not apply to you because your country may not allow the exclusion or limitation of incidental, consequential or other damages.

Please note: As this Licensed Content is distributed in Quebec, Canada, some of the clauses in this agreement are provided below in French. Remarque : Ce le contenu sous licence étant distribué au Québec, Canada, certaines des clauses dans ce contrat 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. Vous pouvez obtenir de Microsoft et de ses fournisseurs une indemnisation en cas de dommages directs uniquement à hauteur de 5,00 $ US. Vous ne pouvez 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



xi

Acknowledgments Microsoft Learning would like to acknowledge and thank the following for their contribution towards developing this title. Their effort at various stages in the development has ensured that you have a good classroom experience.

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 Exchange Server, 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 in Siemens 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 Serverrelated topics. He received an MBA from Open University in England, and is a Microsoft Certified Systems Engineer (MCSE) since 1997.

xii


Contents Module 1: Introduction to Designing a Microsoft® Exchange Server 2010 Deployment Lesson 1: Gathering Business Requirements Lesson 2: Identifying Additional Requirements Lesson 3: Introduction to Service Level Management Lesson 4: Analyzing the Current Messaging Environment Lesson 5: Overview of Microsoft Office 365 Lab: Introduction to Designing an Exchange Server 2010 Deployment

1-3 1-12 1-24 1-36 1-52 1-59

Module 2: Designing Microsoft Exchange Server 2010 Integration with the Current Infrastructure Lesson 1: Designing the Network Infrastructure Lesson 2: Designing the AD DS Infrastructure Lesson 3: Designing the DNS Infrastructure Lesson 4: Planning Exchange Server Administration Lab: Designing Exchange Server Integration with the Current Infrastructure

2-3 2-16 2-32 2-40 2-55

Module 3: Planning and Deploying Mailbox Services Lesson 1: Overview of Mailbox Services in Exchange Server 2010 Lesson 2: Designing Mailbox Servers Lesson 3: Designing Recipient Management Lesson 4: Designing a Public Folder Architecture Lab: Planning and Deploying Mailbox Services

3-3 3-8 3-21 3-37 3-51

Module 4: Planning and Deploying Client Access Services in Microsoft® Exchange Server 2010 Lesson 1: Overview of the Client Access Server Role Lesson 2: Designing Client Access Server Deployment Lesson 3: Designing Client Access Lesson 4: Designing Client Access Policies Lab: Planning and Deploying Client Access Services in Exchange Server 2010

4-3 4-14 4-34 4-48 4-57

Module 5: Planning and Deploying Message Transport in Microsoft Exchange Server 2010 Lesson 1: Designing Message Routing for Exchange Server 2010 Lesson 2: Designing Hub Transport Servers Lesson 3: Designing the Message Routing Perimeter Lab: Planning and Deploying Message Transport in Exchange Server 2010

5-3 5-13 5-29 5-44


Module 6: Planning and Deploying Messaging Security Lesson 1: Designing Message Security Lesson 2: Designing Antivirus and Anti-Spam Solutions Lab: Planning and Deploying Messaging Security

6-3 6-16 6-32

Module 7: Planning and Deploying Messaging Compliance Lesson 1: Designing Transport Compliance Lesson 2: Designing AD RMS Integration with Exchange Server 2010 Lesson 3: Designing Message Journaling and Archiving Lesson 4: Designing Messaging Records Management Lab: Planning and Deploying Messaging Compliance

7-3 7-12 7-20 7-30 7-37

Module 8: Planning and Deploying High Availability Lesson 1: Introduction to High Availability Planning in Exchange Server 2010 Lesson 2: Designing High Availability for Mailbox Databases Lesson 3: Designing High Availability for Other Server Roles Lesson 4: Designing Site Resilience Lab: Planning and Deploying High Availability

8-3 8-14 8-25 8-32 8-45

Module 9: Planning a Disaster Recovery Solution Lesson 1: Planning for Disaster Mitigation Lesson 2: Planning Exchange Server Backup Lesson 3: Planning Exchange Server Recovery Lab: Planning a Disaster Recovery Solution

9-3 9-17 9-27 9-41

Module 10: Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting Lesson 1: Planning Exchange Server Monitoring Lesson 2: Planning Exchange Server Troubleshooting Lab: Planning Exchange Server 2010 Monitoring and Troubleshooting

10-3 10-19 10-27

Module 11: Upgrading to Microsoft® Exchange Server 2010 Lesson 1: Overview of Upgrading to Exchange Server 2010 Lesson 2: Planning the Upgrade from Exchange Server 2003 to Exchange Server 2010 Lesson 3: Planning the Upgrade from Exchange Server 2007 to Exchange Server 2010 Lab: Upgrading to Microsoft Exchange Server 2010

11-3 11-12 11-28 11-41

xiii

xiv


Module 12: Integrating Microsoft Exchange Server 2010 with Other Messaging Systems Lesson 1: Designing Exchange Server 2010 Integration with Other Messaging Systems Lesson 2: Designing Exchange Server 2010 Integration with Federated Partners Lesson 3: Designing Exchange Server 2010 Integration with Office 365 Lesson 4: Designing Single Sign-On for Office 365 Lab: Integrating Exchange Server 2010 with Other Messaging Systems

12-3 12-15 12-22 12-35 12-40

Appendix A: Unified Messaging in Microsoft® Exchange Server 2010 Lesson 1: Planning the Unified Messaging Infrastructure Lesson 2: Planning the Unified Messaging Configuration Lesson 3: Planning the Unified Messaging Integration with Office Communications Server

A-3 A-17 A-29

Lab Answer Keys Appendix Module 1 Lab: Introduction to Designing an Exchange Server 2010 Deployment Module 2 Lab: Designing Exchange Server Integration with the Current Infrastructure Module 3 Lab: Planning and Deploying Mailbox Services Module 4 Lab: Planning and Deploying Client Access Services in Exchange Server 2010 Module 5 Lab: Planning and Deploying Message Transport in Exchange Server 2010 Module 6 Lab: Planning and Deploying Messaging Security Module 7 Lab: Planning and Deploying Messaging Compliance Module 8 Lab: Planning and Deploying High Availability Module 9 Lab: Planning a Disaster Recovery Solution Module 10 Lab: Planning Exchange Server 2010 Monitoring and Troubleshooting Module 11 Lab: Upgrading to Microsoft Exchange Server 2010 Module 12 Lab: Integrating Exchange Server 2010 with Other Messaging Systems

L1-1 L2-11 L3-19 L4-35 L5-45 L6-55 L7-65 L8-75 L9-93 L10-91 L11-99 L12-103

About This Course

xv

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

Course Description This course 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 the second 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 new messaging 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 Materials The following materials are included with your kit: •

Course Handbook A succinct classroom learning guide that provides all the critical technical information in a crisp, tightly-focused format, which is just right for an effective in-class learning experience. •

Lessons: Guide you through the learning objectives and provide the key points that are critical to the success of the in-class learning experience.

•

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

•

Module Reviews and Takeaways: Provide improved on-the-job reference material to boost knowledge and skills retention.

•

Lab Answer Keys: Provide step-by-step lab solution guidance at your finger tips when it’s needed.

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

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

•

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

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

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

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

About This Course

Virtual Machine Environment This section provides the information for setting up the classroom environment to support the business scenario of the course.

Virtual Machine Configuration In this course, you will use 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. In Hyper-V Manager, right click the virtual machine name and click Revert. 2. In the Revert dialog box, click Yes.

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

Role

10233B-VAN-DC1

Domain controller in the Adatum.com domain

10233B-VAN-EX1

Exchange 2010 server in the Adatum.com domain

10233B-VAN-EX2


10233B-VAN-EX3


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.

xix

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

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 the technology 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 has significantly 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 two organizations 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 from negotiations 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 be quite 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 Compliance Requirements

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 the legislated 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, does your 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?

1-10

Introduction to Designing a Microsoft® Exchange Server 2010 Deployment

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 cannot continue. 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 feature from the solution design.

1-12


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

Identify additional stakeholders for a project.

•

Define technology requirements.

•

Identify IT requirements.

•

Identify security requirements.

•

Identify user requirements.

•

Resolve conflicting requirements.


Typical Stakeholders

Who Are Stakeholders? A project stakeholder is anyone who sponsors a project, or has interest in the project’s completion. The business sponsor is one of the most important stakeholders for most projects. The business sponsor typically provides the project’s business requirements and budget. However, a large project—such as deploying a new messaging system—will significantly impact an entire organization, and many people throughout the organization must have input into the project’s design. A stakeholder’s interest may be determined by how the project: •

Affects the way in which a person works.

•

Affects a technological area for which a stakeholder is responsible.

•

Provides new opportunities. For example, if a project provides new offerings to customers, they may be important stakeholders.

•

Increases workload. A stakeholder may be involved in the product’s deployment or future support.

A project such as an Exchange Server 2010 deployment can have several additional stakeholders besides the project sponsor, including: •

IT personnel. The Exchange Server 2010 deployment will affect almost all aspects of IT administration. Therefore, IT personnel have an interest in the technical design. The specific roles that will be affected include: network administrators, storage area network (SAN) administrators, Active Directory® Domain Services (AD DS) administrators, administrators for network services such as Domain Name System (DNS), and messaging administrators.

•

Security and compliance officers. These people typically are important stakeholders because of the data types being sent via email, and the integration of email into many business processes.

•

Messaging users. A new technology often affects users directly, and they may have different requirements than a business sponsor.

1-14


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. In almost 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, if the 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).

1-16


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 are planning 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 with IT 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 longstanding 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.

1-18


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

1-20


•

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 limits 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 most closely 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?

1-22


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.


Discussion: Dealing with Conflicting Requirements

As you gather all of the requirements for the Exchange Server 2010 deployment, it is likely that you will identify conflicting requirements. For example, certain business requirements—such as the budget—may conflict with other business requirements, such as security requirements. In this example, the IT department may have security requirements that add significant cost to a project, thereby exceeding the budget that the business sponsor set.

Discussion Questions Based on your experience, consider the following questions: Question: What examples have you seen where requirements conflicted?

Question: One of the most common scenarios for incompatible requirements occurs between security and business requirements. How can security requirements be balanced with other requirements?

Question: What guidelines would you suggest for addressing conflicting requirements?

1-24


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

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

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.

1-26


The internal parties are accountable for what they do and do not achieve as outlined in the SLA. There may be repercussions within the organization when an agreed-upon service is not fulfilled, even though the document is not a legal contract. IT’s status may suffer, for example, if there are issues on chargeable services, or if the costs of providing an agreed-upon service cannot be justified. Note: The IT Infrastructure Library (ITIL) refers to an internal SLA agreement as an operational level agreement (OLA).

External SLA External SLAs are more formal, legally-binding contracts than internal SLAs. An external SLA may have more structure because it usually includes cost and bonus clauses, and sometimes includes penalty clauses. However, an external SLA always includes the service’s specific cost and deliverables, which often include availability and security services. Additionally, an external SLA typically involves a stated cost that will apply if changes in service criteria occur. For example, if support hours from a service desk outsourced under an SLA increase, then costs for the increased availability of staff and services are incurred. These costs typically pass on to the contracting organization. However, such costs likely are justifiable, because business revenues will most likely have increased as a result of longer service hours. If an external SLA must be legally binding, it should be checked by a qualified legal professional, either from an internal legal department or an external legal counsel. In other words, you should not enter into an SLA contract without confirming the contract’s legal implications, including the definition and description of costs, bonuses, penalties, and the reasons for contract termination.

Informal SLA Not all SLAs are contracts with formal terms and conditions. In some cases, service level expectations are based on a verbal agreement between the IT provider and the organization. This is an informal SLA, and often these types of agreements develop over time through casual conversations with the IT provider. An internal agreement is usually informal. While an informal SLA avoids the negotiation process that a formal SLA requires, the undocumented nature of an informal SLA can lead to the customer misunderstanding the SLA terms and conditions. The IT provider can publish an informal SLA to the entire organization to help minimize misunderstandings.


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 service catalog

Written in business language, a service catalog is the definitive guide to the services available to the business. It provides end-to-end descriptions of the service components 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 is developed according to the priority and business requirements of the service.

Negotiate SLAs

An SLA is a mutually agreed-upon and negotiated agreement between the IT provider and the business. An SLA and availability requirements are important parts of service level management, but must not be viewed as an endpoint when providing 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 mutually agreed-upon service-level thresholds, and the initiation of corrective actions if the thresholds are breached. Without this process, the value of the SLA diminishes.

1-28


(continued) Task

Description

Report the service level

Using the service catalog and the SLA, reports should be designed and scheduled. If required, 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 a service-level review at required intervals with the customer department representative, using reports produced from historical data and the monitoring function.

Review the service level agreement

The SLA review provides an opportunity to review performance against SLA objectives, and more importantly, to gather perceptions and opinions from business representatives on any service changes. If any service levels are perceived to be breached, but are not highlighted by the service review or reports, there might be issues with the SLA criteria and objectives. Issues might include providing additional resources to support new services or service levels, if these resources were not initially considered. You should work with the business representatives to identify any issues from the previous period, and any current issues that you need to address before 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 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 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?

1-30


•

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 you consider 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-critical applications, 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.

1-32


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

1-34


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 business objectives

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

Be specific and measurable

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

Be attainable

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

Bring value to the organization

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

1-36


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

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

1-38


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 is expected 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?

1-40


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. These points 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 trust relationships 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 of Windows 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?

1-42


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 Practices Analyzer (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, and develop 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 Exchange Server 2010.

1-44


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 messaging environment, 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

1-46


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 of memory, 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, antispam 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 you need 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.

1-48


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

•

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 and message 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, and tracking 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.

1-50


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 service level, 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 change control process includes a risk analysis and processes for mitigating risks.

1-52


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

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

1-54


•

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.

1-56


•

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 automatically expire 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 onpremise 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.

1-58


•

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 enable messages 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 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 is planning 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 Corporate Headquarters

12,000 currently 10,000 after the new London office is ready

• 1,000 Outlook Web Access users • 500 Outlook Anywhere and mobile client users • 800 Office Outlook users connecting through a virtual private network (VPN)

London (new office)

4,000 (anticipated)

• 200 Outlook Web Access users • 50 Outlook Anywhere and mobile client users

San Diego Former head office of Trey Research

500

• 50 POP3 client users

Vancouver

6,000


1-60


(continued) Location

Internal users

Mobile users

Tokyo

5,000

• 1,000 Outlook Web Access users • 200 Outlook Anywhere and mobile client users • 200 Office Outlook users connecting through a VPN

Chennai (new office)

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:

1-62


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 hightech 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 be viewed 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.

1-64


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

1-66


 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

Additional notes

Domains in each forest


 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 Reference Number: JC310110/2 Document Author Date


Exchange Server Configuration Server name

Exchange version and SP level

Server role

Location

LON-MSG-FE1


Frontend server

London

1-68


(continued) A. Datum Current Messaging Infrastructure Analysis Exchange Server Configuration Additional notes

Exchange Organization information Configuration

Settings

Administrative groups Administrator groups Routing groups SMTP namespaces 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. The main tasks for this exercise are as follows: 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 Reference Number: JC310110/3 Document Author Date


Summary of business requirements This section provides a summary of the information collected during the business requirements analysis task. It is important to clearly define the needs that must be addressed so that the organization 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. The functional requirements define how the proposed technology will address the project’s business requirements. This section may be quite extensive, as it relates to many areas such as: performance, security, manageability, usability, availability, and scalability:

1-70


(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 requirements analysis task, specific priorities should have been identified related to the schedule, resources, or features 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 You will complete these sections as a group. •

Discuss the following questions: 1.

What components will you need to include in the Exchange Server 2010 deployment to meet the business requirements?

2.

What components will you need to include in the Exchange Server 2010 deployment to meet the 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 Budget Expectations 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 project is 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 cost significantly more than the proposed budget?

Results: After this exercise, you should have answered the preceding questions.

1-72


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



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 Reference Number: JC310110/4 Document Author Date


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.

1-74


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

5.

•

User name: Administrator

•

Password: Pa$$w0rd

•

Domain: Contoso

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.

1-76


•

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 Integration with 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-32

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

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

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 2010 Deployments

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 schema changes 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 using server fully qualified domain names (FQDNs). Avoid this practice, as it creates additional management issues. For example, if the server providing an email client service changes, you must update the configuration of all affected client computers. Additionally, digital certificates that are provided to enable authentication and encryption between 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.


•

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

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 is not trusted by clients. You should remove this certificate, and install a certificate from a trusted 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, Windows Internet Explorer®, and Window Mobile 6 or newer clients support wildcard certificates, but you need to verify this functionality for all messaging clients that are used in your organization before deploying these certificates. •

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 or configuration 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 site using 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.

2-10

Designing Microsoft® Exchange Server 2010 Integration with the Current Infrastructure

•

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 Online implementation when designing your Client Access Server network configuration. For further information about the changes that may be introduced by Exchange Online deployments, 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.

2-12


Note Client access to public folder content is handled by the Mailbox server rather than the Client Access server role. Note In Exchange Server 2007 or earlier Exchange Server versions, MAPI clients such as Office Outlook connect directly to Mailbox servers. In Exchange Server 2010, with the introduction of the Remote Procedure Call (RPC) Client Access service, MAPI clients no longer connect directly to the Mailbox servers for mailbox access. 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. To enable this option, you must configure an external URL for each Client Access server. You also must ensure that clients can resolve the URL name in 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 can automate 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 between geographic 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 the destination 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 lowestcost 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.

2-14


Note Use the Set-ADSite –Identity sitename –HubSiteEnabled $true cmdlet to configure a site 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 serverspecific cost to the site link, the Hub Transport server uses this attribute instead of the AD DSassigned cost to determine the least-cost routing path. Note Use the Set-AdSiteLink –Identity ADsitelinkname –ExchangeCost value cmdlet to assign Exchange specific routing costs. You also can use the Set-AdSiteLink –Identity ADsitelinkname – MaxMessageSize value cmdlet to assign a maximum message size limit for messages sent between 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 accept anonymous connections on port 25 using a network interface that is accessible from the Internet. To enable outbound email flow, configure an SMTP Send connector with an address space of “*”that can use DNS or a smart host to send messages to the Internet. 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 to send and receive messages from the Internet. If you are using an SMTP gateway server other than an Exchange Server 2010 Edge Transport server role, you still will need to configure the SMTP Send connector and SMTP Receive connector. The only difference is that you should configure the SMTP gateway server as the smart host on the SMTP Send connector, and accept only connections from the SMTP gateway server on the SMTP Receive connector. As an alternative to managing your own Edge Transport server role, you should also consider Exchange Hosted Services. 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 stored in 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 Exchange Online deployments, refer to Module 12.

2-16


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

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 between AD 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, the AD DS and Exchange Server 2010 design teams must work together to ensure an optimal AD 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 Admins and Enterprise Admins groups can be considered the AD DS design owners. However, these groups should be used only to implement decisions that the actual design owners make.

2-18


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

2-20


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, public folder 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 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.

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 Exchange resource 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 Exchange organization. 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 using single 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.

2-22


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 most common 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 you deploy in the forest always is the forest root domain. By default, this domain contains the Schema Master and Domain Naming Master roles, and the Schema Admins and Enterprise Admins security groups. Exchange Server uses the forest root as a location for its security groups.


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 Exchange Server 2010 must be Microsoft Windows® 2000 Server native mode or higher. One reason is that Exchange Server 2010 allows only universal security groups or universal distribution groups to be mail-enabled. Additionally, when you prepare the AD DS forest for the Exchange Server 2010 installation, several Exchange universal security groups are created that set permissions on Exchange configuration objects. You can create universal security groups 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 the Exchange 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.

2-24


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 Exchange Server 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 the Mailbox 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 DS will 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 implement a 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 Server 2010 servers and messaging clients.

2-26


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 whether to 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 Transport server and clustered mailbox servers—on the same server. This means that in a small site, a single 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 servers are 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.

2-28


Note The Windows Server® 2008 operating system provides a new type of domain controller—a read-only domain controller (RODC). Exchange Server 2010 does not use RODCs, or RODCs that you configure as read-only global catalog (ROGC) servers. This means that you should not deploy an Exchange 2010 server in any site that contains only RODCs 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 a domain controller. Once you install Exchange Server 2010, changing its role from a member server 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?

2-30


Planning for AD DS Preparation to Support the Exchange Server 2010 Deployment

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 Exchange Universal Security Groups in the root domain, and prepares the current domain. • Must be run by a member of the Enterprise Admins group.

/PrepareLegacy ExchangePermissions

• Is necessary if the organization contains Exchange Server 2003 servers. • Modifies the permissions assigned to the Enterprise Exchange Servers group to allow the Recipient Update Service to run. • Must be run by a member of the Enterprise Admins group.

/PrepareSchema

• Prepares the schema for the Exchange Server 2010 installation. • Must be run by a member of the Enterprise Admins and Schema Admins groups.


(continued) Setup switch /PrepareDomain /PrepareDomain domainname /PrepareAllDomains

Explanation • Prepares the domain for Exchange Server 2010 by creating a new global group in the Microsoft Exchange System Objects container called Exchange Install Domain Servers. • Is not required in the domain where /PrepareAD is run. • Can prepare specific domains by adding the domain’s FQDN, or prepare all domains in the forest. • Must be run by a member of the Enterprise Admins and Domain Admins groups.

Note You must prepare the AD DS forest in the same domain and the same site as the domain 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 Schema Admins group member.

•

Prepares the permissions if /PrepareLegacyExchangePermissions has not been run, and the command is run by an Enterprise Admins group member.

•

Creates the Microsoft Exchange container in the Configuration partition in 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 OU are management role groups that use role-based access control (RBAC) to assign permissions in the Exchange organization.

2-32


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

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/IP properties 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 is Internet-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.

2-34


•

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 servers in 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) was required in order to support multi-domain environments. This is no longer a requirement in Exchange 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 msDSAllowedDNSSuffixes AD DS attribute on the domain object container. You must add all of the DNS suffixes to the attribute. In addition, to make sure that the DNS suffix search list contains 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.

2-36


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 of the 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: Host

Record type

IP address

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: Host

Record type

IP address

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.

2-38


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 from the 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 onpremises Exchange servers and then, where necessary, routed onwards to the Exchange Online environment for those users whose mailboxes are hosted online. However, if you wish to have email routed primarily to the Exchange Online environment, perhaps to take advantage of the message hygiene services provided by Forefront Online Protection for Exchange (FOPE), you can configure this behavior in the Online Portal, or in your DNS MX records, or within FOPE.

2-40


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

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.

2-42


•

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 enduser management roles. Role assignment policies consist of roles that control what users can do with their mailboxes or distribution groups. These roles do not allow management of features with which users are not associated directly. 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 the AD 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. You must 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 split permissions model; this is not true with Active Directory split permissions.

2-44


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

Organization Management

Role holders have access to the entire Exchange Server 2010 organization, and can perform almost any task against any Exchange Server object.

View-Only Organization Management

Role holders can view the properties of any object in the organization.

Recipient Management

Role holders have access to create or modify Exchange 2010 recipients within the Exchange Server organization.

UM Management

Role holders can manage the Unified Messaging features within the organization, such as Unified Messaging server configuration, mailbox properties, prompts, and auto-attendant configuration.

Discovery Management

Role holders can perform searches of mailboxes in the Exchange organization for data that meets specific criteria.

Records Management

Role holders can configure compliance features, such as retention policy tags, message classifications, and transport rules.

Server Management

Role holders have access to Exchange server configuration. They do not have access to administer recipient configuration.

2-46


(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 in AD DS. This OU contains several other universal security groups that grant permissions to the 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 settings and to distribution groups that they own. Every user with an Exchange Server 2010 mailbox receives a role assignment policy, by default. You can: •

Decide which role assignment policy to assign by default.

•

Choose what to include in the Default Role Assignment Policy.

•

Override the default policy for 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 ability to use the cmdlets in the management role. When you create a role assignment, you cannot specify a scope. The scope that the assignment applies is based on the management role, and is either Self or MyGAL.


•

Management role. A management role is a container for a group of management role entries. Roles define the specific tasks that users can do with their mailboxes or distribution groups.

•

Management role entry. A management role entry is a cmdlet, script, or special permission that enables users to perform a specific task. Each role entry consists of a single cmdlet, and the parameters that the management role can access.

2-48


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 removing management roles. For example, if you want to enable users to perform additional tasks on their mailboxes, you can identify the management role that grants them the necessary permissions, and add the role to the Default Role Assignment Policy.

•

Define a new role assignment, and then configure that role assignment to be the default for all mailboxes. Use the Set-RoleAssignmentPolicy cmdlet to replace the built-in Default Role Assignment Policy with your own. When you do this, RBAC assigns the role assignment policy that you specify to new mailboxes, by default. Note When you change the Default Role Assignment Policy, RBAC does not assign the new Default Role Assignment Policy automatically. You will need to use the Set-Mailbox cmdlet to update previously created mailboxes to the new Default Role Assignment Policy.

•

Configure additional role assignment policies, and assign the policies to a mailbox manually. 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 who only need to manage recipient tasks for branch-office users, and mailboxes on branch office Mailbox servers. To implement this scenario, you would: 1.

Create a new role group, and then add the branch office administrators to the role group. You can use the New-RoleGroup cmdlet to create the group. When you create the group, you must specify the management roles. Additionally, you also can specify the management scope for the role.

2.

Assign management roles to the branch office administrators. To delegate permissions to a custom role group, you can use one or more of the default built-in management roles, or you can create a custom management role that is based on one of the built-in management roles. Exchange Server 2010 includes approximately 70 built-in management roles that provide granular levels of permissions. To view a complete list of all the management roles, use the get-managementrole cmdlet. To view detailed information about a management role, type get-managementrole rolename | FL, and then press Enter. Note You also can configure a new management role rather than use one of the existing management roles. To do this, use the New-ManagementRole cmdlet to create a custom management role based on one of the existing management roles. You can then add and remove management role entries as needed. By default, the new management role inherits all of the permissions assigned to the parent role. You can remove permissions from the role as necessary, by using the Remove-managementroleentry cmdlet. However, it can be complicated to create a new management role or remove unnecessary management role entries, so we recommend that you use one of the existing roles whenever possible.

3.

Identify the management scope for the management role. For example, in the branch office scenario, you could create a role assignment with an OU scope that is specific to the branch office OU.

4.

Create the management role group using the information that you collect. Use the New-RoleGroup cmdlet to create the link between the role group, the management roles, and the management scope. For example, consider the following 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.

2-50


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 a four-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, productkey 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 Exchange organization with information on the number of databases, servers and Client Access Licenses that have been deployed. The Customer Feedback tab is where both the Customer Experience Improvement Program can be enabled, and links to Exchange documentation can 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 Windows PowerShell shell design. Exchange Management Shell is more than just a command-line interface that you can use to manage Exchange Server 2010. Exchange Management Shell is a complete management shell that offers a complex and extensible scripting engine that has sophisticated looping functions, variables, and other programmatic features so that you can create powerful administrative scripts quickly.

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 Panel The 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

2-52


•

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 create and manage management role groups and management role assignment policies in the ECP, including the ability to: add and remove management roles to role groups and role assignment policies; add and remove members to and from role groups; and assign users to role 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.

2-54


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?



Lab Setup For this lab, you will use the available virtual machine environment. Before beginning the lab, you must complete the following steps: 1.


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 an individual activity.

2-56


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] Subject: 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

2-58


 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 Server 2010?

 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 Reference Number: JC110210/1 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 to support 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 from their 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 inbound and 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 to be able to perform limited recipient management tasks. To which built-in role group should you assign 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 Server 2003 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 along with the following role services: • ISAPI Extensions • IIS 6 Metabase Compatibility • IIS 6 Management Console • Basic Authentication • Windows Authentication • Digest Authentication • Dynamic Content Compression • .NET Framework Extensibility

Yes or No

Windows Server 2008 features: • WCF Hypertext Transfer Protocol (HTTP) Activation • RPC over HTTP Proxy

Yes or No


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.

2-60


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

2.

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

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.

2-62


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.

2.

Create a new user in the Users folder in Active Directory Users and Computers: •

Full name: Adam Carter

•

User logon name: Adam

•

Password: Pa$$w0rd

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.

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

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 started before 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?


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

2-64


•

Use a self-signed certificate only for small deployments, or for testing purposes. Replace the selfsigned 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-37

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

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

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?


3-5

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


3-7

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

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.


3-9

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 server performance, 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.

3-10

Planning and Deploying Mailbox Services

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 archive rather 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 litigation 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 running POP3 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?


3-11

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 consider more than just the mailbox databases. In most cases, you may want to enable indexing on databases to speed up searches. Each index uses approximately 5 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.

3-12


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.


3-13

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 uses DAGs to replicate mailbox databases for high availability, consider the number of database copies when you calculate how much disk space you need and what it costs.

•

Slower disks 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 with available space then you might prefer to use the SAN for the higher reliability it provides.

•

You can consider JBOD if you have three or more replicas of a database in a DAG. JBOD provides no redundancy, but this is acceptable because the DAG has multiple database copies. JBOD is used with DAS.

3-14


•

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 in Exchange 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?


3-15

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.

3-16


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.


3-17

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

•

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.

3-18


•

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?


3-19

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 Exchange Server 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 as the disks expand.

•

Differencing or delta mechanisms such as snapshots are not supported. This is because the snapshot mechanisms are not application-aware and, as a consequence, recovery to the snapshot is unpredictable.

•

Test virtual disk performance to be sure that it meets your needs. Virtual disk performance is typically slightly lower than physical disk performance.

3-20


•

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


3-21

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 load generated 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?

3-22


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

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.


3-23

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.

3-24


•

The Exchange Control Panel provides access to a limited set of recipient management tasks. It is wellsuited 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.


3-25

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.

3-26


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


3-27

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

3-28


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


3-29

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?

3-30


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?


3-31

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 the group 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 Users group 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.

3-32


•

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?


3-33

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.

3-34


•

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

Delegates In 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?


3-35

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

•

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

3-36


Question: Do you see a need for online mailbox moves in your organization?


3-37

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 deemphasizes public folders, they are still fully supported, and some organizations use them extensively. After completing this lesson, you will be able to: •

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.

3-38


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 following information: •

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


3-39

•

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?

3-40


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 Folders When 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 a public 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.


3-41

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.

3-42


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.


3-43

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 calculating the 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 –id databasename –PublicFolderReferralServerList ‘Servername:Cost’ -UseCustomReferralServerList $True command in the Exchange Management Shell. This command enables public folder referrals to the specified servers in different Active Directory sites, 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?

3-44


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 Outlook 2007, 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.


3-45

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.

3-46


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 structure Typically, a public folder hierarchy is organized according to a into logical and consistent company’s business model, so that each top-level folder represents one groupings that are easy for department within the company. users to explore and access. Use a consistent and logical naming scheme for public folders.

Users should be able to identify the contents of a public folder from the public folder name.

Create a public folder hierarchy that enables you to delegate administrative tasks.

By assigning the appropriate permissions at the top-level folders, you can allow users to perform tasks such as adding permissions, or adding and removing folders within their department’s top level public folder.

Create a public folder hierarchy that can simplify administrative processes.

You can manage public folder settings such as permissions, folder size, and replication. Whenever possible, group public folders that require the same configuration under a top-level folder, so that you can apply the required settings to all of the folders in the hierarchy at the same time.


3-47

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 of administrators who will administer public folders.

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 to create and configure top-level public folders.

Plan to delegate administrative permissions for lowerlevel folders.

In most cases, the public folder users understand the public folder requirements better than the messaging administrators. This means you can delegate the public folder administration tasks—such as creating new public folders and assigning client permissions—to advanced users. In many organizations, 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.

3-48


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-enabled universal groups to enable public folder permissions.

You can grant access to public folders for individual users, but managing groups is more efficient than managing individual users. Start by determining the users who require access to public folders, which folders they require access to, and the level of access required to the public folders. Then create groups for each unique set of permissions, assign permission roles to the groups, and add users to the groups.

Plan for default and anonymous permissions.

Default permissions are assigned to all authenticated users. In Exchange Server 2010, the default group is assigned the Author permission role. This means that all users can view the folder contents and can create new items in the folder. If you have public folders containing confidential information, you must modify the default permission. Anonymous permissions are assigned to unauthenticated users, including those without a mailbox, and those who are not custom recipients in the organization. However, an anonymous user is restricted to accessing public folder content that has been granted anonymous permissions. Because all Office Outlook clients must be authenticated in order to access a user mailbox, you rarely allow anonymous access to public folders in Exchange Server 2010.

Limit permissions at higher levels of the hierarchy.

When you create a new public folder, it inherits the permissions from the parent public folder. Limiting permissions in the parent folder ensures that unnecessary 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?


3-49

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.

3-50


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?


3-51


Lab Setup For this lab, you will use the available virtual machine environment. Before you begin the lab, do the following: 1.


2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-CL1 virtual machines are running.

3.

If required, connect to the virtual machines. Log on to the virtual machines as 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.

3-52


Exercise 1: Designing the Mailbox Server Deployment Scenario In this exercise, you will examine the current topology and messaging infrastructure. You will determine the appropriate Mailbox server deployment based on the information supplied in the A. Datum Exchange Server 2010 project documentation. The main tasks for this exercise are as follows: 1.

Review the A. Datum Corporation documentation.

2.

Answer questions related to the documentation.

3.

Perform high level planning for Mailbox server storage in London.

4.

Use the Exchange 2010 Mailbox Server Role Requirements Calculator spreadsheet to determine the configuration.

5.

Update the A. Datum Large Mailbox server design document.

Server Design Interviews 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.

Carole Poland, IT Manager We have deployed a very good 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 DAS. 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 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.

Andreas Herbinger, Messaging Specialist 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 Server servers. The SANs that we have in place right now have only about 10 terabytes of free disk. Unless we keep our mailboxes very small, it simply won’t be sufficient.


3-53

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 of the 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 •


Server Design Interviews

•

Server Design Statistics

3-54


 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 server design, and why?

 Task 3: Perform high level planning for Mailbox server storage in London •

Complete the following proposal document by answering the questions. A. Datum high level planning for mailbox servers in London Document Reference Number: JC040400/1 Document Author Date

Jason Carlson 2nd April 2010

Requirement Overview 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 for mailbox 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?


3-55

 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

3-56


•

•

•

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

•


•


•


•


•


•


•


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 •

•

•

•

•

•

3.

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

Log off of VAN-CL1.

 Task 5: Update the A. Datum Large Mailbox server design document •

Complete the following proposal document by answering the questions. A. Datum Large Mailbox server design Document Reference Number: JC040400/2 Document Author Date


Requirement Overview Determine the hardware configuration for large Mailbox servers that use DAS. Additional Information N/A Proposals Question: What is the processor configuration for each server?

Question: What type of disks are being used?

3-57

3-58


(continued) A. Datum Large Mailbox server design 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.


3-59

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


2.


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 should be 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

3-60


 Task 2: Answer questions related to the documentation 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 Reference Number: JC040400/3 Document Author Date


Requirement Overview Determine the configuration required to meet recipient management needs. A. Datum recipient management configuration 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 Trey Research?

Results: After this exercise, you should have designed the appropriate configuration for recipient management.


3-61

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


2.


3.

Document the required configuration

Public Folder Interviews Scott MacDonald, Vice President – North America 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 using Outlook 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.

Conor Cunningham, Messaging Services Manager 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

 Task 2: Answer questions related to the documentation Question: In the Public Folder Interviews, what points are raised that impact your public folder deployment plan, and how do they impact it?

Question: In the Server Design Interview, what points are raised that impact your public folder deployment plan, and how do they impact it?

3-62



Complete the following proposal document by answering the questions. A. Datum public folder configuration Document Reference Number: JC040400/4 Document Author Date


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


3-63

Exercise 4: Implementing Mailbox Services Scenario The main tasks for this exercise are as follows: 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:

4.

•

Name: Trey Users

•

Display Name: Trey Users

•

Container: \

•

Recipient container: Adatum.com/Trey

•

Recipient types: Users with Exchange mailboxes

•

Conditions: None

•

Schedule: Immediately

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”

3-64


7.

Create a new OAB for Trey Research by using the following command: New-OfflineAddressBook TreyOAB –AddressLists TreyGAL

8.

9.

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

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. 14. Log off of VAN-CL1.

 Task 2: Create and configure a resource mailbox 1.

2.

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

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://vanex1.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.

3-65

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

3-66


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


2.

Right-click 10233B-VAN-DC1 in the Virtual Machines list, and then click Revert.

3.


4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-CL1. Close the virtual machine connection windows

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


8.



3-67


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

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 limits on mailboxes.

3-68


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

Lesson 4: Designing Client Access Policies

4-48

Lab: Planning and Deploying Client Access Services in Exchange Server 2010

4-57

4-2 Planning and Deploying Client Access Services in Microsoft® Exchange Server 2010

Module Overview

Microsoft® Exchange Server 2010 provides access to user mailboxes for most types of messaging clients that can connect from almost anywhere. 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. After completing this module, you will be able to: •

Describe how the Client Access server role works.

•

Design the Client Access server deployment.

•

Design access for messaging clients.

•

Design policies for managing client access.


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

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.


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 expectations when 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 Server 2010 mailboxes through the Client Access server role. MAPI clients require RPC connectivity to the Client Access server.

Outlook Anywhere

Outlook Anywhere enables Office Outlook 2003 or newer clients to access user mailboxes by using RPCs encapsulated in a Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol/Secure (HTTPS) packet. This enables secure 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 from any web browser. Exchange Server 2010 provides a complete set of features for the following browsers on a computer running Windows® XP, Windows Server® 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 Exchange ActiveSync®

Exchange ActiveSync lets you synchronize data between your mobile phone and Exchange Server 2010. You can synchronize email, Contacts, Calendar information, 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 is available on a large variety of mobile devices.

POP3 and IMAP4

Besides supporting MAPI and HTTP clients, Exchange Server 2010 supports Post Office Protocol version 3 (POP3) and Internet message access protocol version 4 (IMAP4) clients. By default, POP3 and IMAP4 install at the same time you install the Client Access server role. However, the services needed to support POP3 and IMAP4 require a manual start. To use POP3 and IMAP4, you must first start the POP3 and IMAP4 services.

Entourage 2008, Web Services Edition

Entourage 2008, Web Services Edition, uses Exchange Web Services instead of Web Distributed Authoring and Versioning (WebDAV) to provide access to the user mailboxes, which provides support for Autodiscover. You can use Autodiscover 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 Access Service

Enables MAPI clients such as Office Outlook 2010 to connect to user mailboxes. The client connects to the Client Access server using a MAPI connection.

Autodiscover

The Autodiscover service configures client computers that are running Office Outlook 2007 or newer, or supported mobile devices. The Autodiscover process configures the Office Outlook client profile, including the Mailbox server, Availability service, and OAB download locations.

Availability

The Availability service makes free/busy information available for Office Outlook 2007 and Outlook 2010 and Outlook Web App clients. The Availability service retrieves free/busy information from Mailbox servers or Public folders, and presents the information to the clients.

Address Book

The Client Access server makes OABs available through a web service. Only Office Outlook 2007 or later clients are capable of retrieving OABs from a web service.


(continued) Service

Description

Exchange Web Services

Exchange Web Services enables client applications to communicate with the Exchange server. You can also access Exchange Web Services programmatically, and it provides access to much of the same data that is available through Office Outlook. Exchange Web Services clients can integrate Office Outlook data into line–of–business (LOB) applications.

MailTips

The MailTips feature provides notifications for users regarding potential issues with sending messages, before they send the messages.

Exchange Control Panel

The Exchange Control Panel is a web–based management interface that enables self–service for mailbox users, and enables users to perform specific management tasks without having access to the entire Exchange Management 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

4-10

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

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 be available on the external firewall.

2.

If the client connects from the internal network using Office Outlook configured as a MAPI client, then the client connects to the Client Access server using MAPI RPC connections.

3.

The Client Access server connects to 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.

4-12


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 Access server 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 DS site 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 must use 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 server that 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.

4-14


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

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 Protocol logging

Descriptions and recommendations 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 server that handles a large number of messages, consider moving these log files to a dedicated disk.

4-16


(continued) Activity

Descriptions and recommendations

Content conversion

Content conversion for all Exchange Server 2010 protocols occurs on the Client Access server. Disk access can become an issue for Client Access servers if you have a large number of Internet clients that access mailbox data through either POP3 or IMAP4. The POP3 and IMAP4 client requires that the content be converted into Multipurpose Internet Mail Extensions (MIMEs) before sending it to the client. This conversion occurs on the Client Access server, and if the message is larger than 64 kilobyte (KB), the conversion occurs 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 a dedicated 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 certificate issued 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

4-18


•

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 the client 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 connections using 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.

4-20


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 the case 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. Certificate type Public CA

Explanation Advantages: • Client computers already trust the root CA, so you can chain certificates to the root without further configuration. • The public CA provides full certificate and certificate revocation management services. Disadvantage: • The certificates issued by public CAs are more expensive than self-signed certificates, or certificates issued by internal CAs.


(continued) Certificate type

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 manage certificate distribution. Disadvantages: • Implementing an internal CA can be complicated, and the complexity may cause security problems if incorrectly managed. • While the certificates issued by internal CAs are free, the cost of implementing and managing a CA implementation can be higher than buying certificates from a public CA. • Client computers that are not members of an internal AD DS domain do not automatically trust the root CA, so you must add certificates for the trusted rootto-client machines, where necessary.

Self-signed certificates

Advantage: • You can deploy self-signed certificates without a Public Key Infrastructure (PKI). When you install Exchange Server 2010, it automatically creates a self-signed certificate 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 certificate and stop relying on the existing one. • Client computers do not automatically trust the self-signed certificate, so you must 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 Transfer Protocol (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.

4-22


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 organization when 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 the Internet, 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.

4-24


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 first 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./autodiscover/autodiscover.xml

•

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


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

•


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.

4-26


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 Service Consider 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 crossforest 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.


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.

4-28


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 with the 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 Data Group 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 large audience.

•

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 the recipients in the message.

2.

The Client Access server gathers MailTips data:

3.

•

The Client Access server queries AD DS, and reads group metrics data.

•

The Client Access server queries the Mailbox server to gather the Recipient Out-of-Office and Mailbox Full MailTips. If the recipient's mailbox is on another site, then the Client Access server requests MailTips information from the Client Access server in the remote site.

The Client Access server returns MailTips data back to the client.

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.

4-30


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—if necessary—a per-user throttling policy. Additionally, if you are hosting multiple tenants within your Exchange Server organization, you can configure a per-tenant client throttling policy. You can configure the following components to adhere to a client throttling policy: •

Exchange ActiveSync

•


•

IMAP4

•

POP3

•

Outlook Web App

•

Windows PowerShell®

For each of these components, you can configure the following client throttling policy parameters: •

MaxConcurrency. Indicates how many concurrent connections a user can have against an Exchange server. If a user tries to make more connections than allowed by the policy, the new connection attempts fail. Use a value between 0 and 100. To unthrottle this component, specify the value $NULL.


•

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 an AD 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 the maximum number of cmdlets as defined by the PowerShellMaxCmdlets parameter.

•

PowerShellMaxCmdletQueueDepth. Defines the number of operations that a user can run at the same time. 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.

4-32


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. An organization that uses this model could be made up of two partner companies. Namespaces might include mail.usa.adatum.com, and mail.europe.contoso.com.

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

4-34


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

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 a Group 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

4-36


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

4-38


•

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

4-40


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.


•

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.

4-42


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 devices supporting 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 MicrosoftServer-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 commercial CA, 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 mobile devices 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.

4-44


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 to start 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 Transport Layer Security (TLS) or SSL connections.

Authentication

Configures the supported authentication options, such as basic authentication, Integrated Windows authentication, and secure logon requiring TLS. The default setting is secure logon.

Connection settings

Configures server settings, such as time-out settings, connection limits, and the command relay or proxy target port (used for connections to an Exchange Server 2003 back-end server).

Retrieval settings

Configures the message formats used for the protocols, and configures how clients will 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.

4-46


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 the server from the Internet. You may need to instruct users to use the two server names, or you may need to configure the internal 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.

4-48


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

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"

4-50


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 selfsigned certificate. Remove the default certificate and install a certificate from a trusted CA to ensure that 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 attachments will 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 storage cards that fit into mobile device expansion slots store increasingly large amounts of data. While this datastorage 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.

4-52


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 the Messaging 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, as you 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.

4-54


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


Designing Mobile Device Remote Wipe Policies

Exchange Server 2010 provides the option to wipe a mobile device remotely if it appears to be a security issue. For example, for lost or stolen devices, you may choose to wipe the device to ensure that unauthorized users cannot access corporate data via the device. Both the Exchange administrator and the device user can initiate the remote wipe.

Considerations for Implementing Remote Wipe Policies Wiping a mobile device remotely returns the device to its factory default condition the next time the device synchronizes to the Exchange server. This can protect the device’s data, and ensure that no one can use the device to access the user’s mailbox. However, remotely wiping a device that was only temporarily lost can cause user dissatisfaction. Therefore, you should design policies that allow administrators to wipe users’ mobile devices, and that allow users to wipe their own devices. Note The remote wipe does not delete data stored on a memory card in the computer. To protect this data, you should require encryption for all data stored on the mobile device. When defining policies for performing remote wipes, you must: •

Define a policy so that Exchange administrators can wipe devices remotely. This policy should identify who can perform the remote wipe, and under what circumstances. For example, you may develop a policy that allows Help Desk personnel to wipe a mobile device remotely, but only with the approval of a Help Desk manager or an Exchange administrator. You also should develop a reporting procedure for users with lost or stolen devices, so they know how to report missing devices.

•

Develop policies and procedures for rebuilding wiped devices or rebuilding new devices. It is easy to wipe a mobile device, but more difficult to rebuild the device and restore lost data. To improve efficiency, create procedures so that users can back up and restore their data and configuration information. Also provide training to Help Desk personnel to support users during this process.

4-56


•

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 Setup For this lab, you will use the available virtual machine environment. Before you begin the lab, you must: 1.


2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, and 10233B-VAN-EX2 virtual machines are running.

3.


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

4-58


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.

Carole Poland, IT Manager 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.

Andreas Herbinger, Messaging Specialist 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 have only 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 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 must always be available.

Scott MacDonald, Vice President – North America 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.

4-60


Carole Poland, IT Manager 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.

Shane DeSeranno, Network Operations Manager 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.

Jason Carlson, Network Specialist 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.

Tzipi Butnaru, Directory Services Manager 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.

Andreas Herbinger, Messaging Specialist 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 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 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 Tzipi Butnaru, Directory Services Manager 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.

Andreas Herbinger, Messaging Specialist 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.

Shane DeSeranno, Network Operations Manager 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 email messages 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.

Jason Carlson, Network Specialist 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 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 would need to know that the email messages are being scanned for viruses and spam in all locations where we allow SMTP traffic.

4-62


Adatum_CurrentPerimeterDesign.vsd


Adatum_CurrentADSiteDesign.vsd

4-64


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 a maximum 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 expecting many 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 of email 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.

4-66


A. Datum User Distribution Summary.doc Location

Internal users

Mobile users



• 1,000 Outlook Web Access users • 500 Outlook Anywhere and mobile client users • 800 Office Outlook users connecting through a virtual private network (VPN)

London (new office)

4,000 (anticipated)


San Diego Former head office of Trey Research

500

• 50 POP3 client users

Vancouver

6,000


Tokyo

5,000

• 1,000 Outlook Web Access users • 200 Outlook Anywhere and mobile client users • 200 Office Outlook users connecting through a VPN


800 (anticipated)

• 200 Outlook Web Access users • 50 Office Outlook users connecting through a VPN

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

Review the A. Datum documentation.

2.


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

•


•


 Task 2: Answer questions related to the documentation 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?

4-68


 Task 3: Update the A. Datum Client Access server deployment plan document •

Complete the following proposal document by answering the questions. A. Datum Client Access Server Deployment Plan Document Reference Number: JC040410/1 Document Author Date

Jason Carlson 4th April 2010

Requirement Overview Determine the number and placement of Client Access servers within the existing network infrastructure. Additional Information Identify infrastructure changes that may be required due to the proposed deployment. Proposals Question: With reference to the Adatum_CurrentADSiteDesign diagram, how many Client Access servers do you propose to deploy in each site? Question: Do you have sufficient information from the documents reviewed so far, to determine whether 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 which client 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?

Note


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


2.


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

 Task 2: Answer questions relating to the documentation 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 •

Complete the following proposal document by answering the questions. A. Datum Client Access Server Configuration Document Reference Number: JC040410/2 Document Author Date


Requirement Overview Determine the feature configuration for Client Access servers in the A. Datum Exchange Server 2010 upgrade. Proposals Question: Based on the information in the A. Datum User Distribution Summary document, do you envisage deploying additional Client Access servers in any sites? Question: Which features must you enable on the Client Access servers to support the current client-types? Question: Which client protocols must you enable through the firewalls?

4-70


A. Datum Client Access Server Configuration 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? Question: While maintaining compliance with the requirements mentioned in the documentation, can you propose changes to the client types that will simplify the configuration?

Note


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

Verify the Exchange ActiveSync virtual directory configuration.

2.

Create a new Exchange ActiveSync mailbox policy.

3.

Configure Exchange ActiveSync 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 Mailbox policy 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.

4-72


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.

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


2.


3.


4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2. Close the virtual machine connection windows.

5.


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


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.

4-74


•

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

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

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

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 the message 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 the Multipurpose Internet Mail Extensions (MIME) or Secure/Multipurpose Internet Mail Extensions (S/MIME) format.

•

Applies organizational message policies. You can use organizational policies to control messaging aspects such as size, permission to send messages to specific users, the number of message recipients, and other characteristics.


Pickup 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 the categorizer 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 Route In 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 how to 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.


Modifying the Default Message Routing Topology

In some cases, you may want modify the default message routing configuration by configuring specific AD DS sites as hub sites, and by assigning Exchange-specific routing costs to AD DS site links.

Options for Modifying the Default Message Routing Topology By default, Hub Transport servers in one site attempt message delivery to another site’s recipient by establishing a direct connection to a Hub Transport server in the remote AD DS site. However, you can modify the default message routing topology in three ways: •

Configure hub sites. You can configure one or more AD DS sites in your organization as hub sites. When a hub site exists along the least-cost routing path between two Hub Transport servers, the messages are routed to and processed in a Hub Transport server in the hub site before they are relayed to the destination server.

•

Configure Exchange Server-specific routing costs. You also can modify the default message routing topology by configuring an Exchange Server-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 rather than the AD DS-assigned cost to determine the least-cost routing path.

•

Configure expansion servers for distribution groups. You also can modify the default routing topology by assigning expansion servers for distribution groups. By default, when a message is sent to a distribution group, the first Hub Transport server that receives the message expands the distribution list and calculates how to route the messages to each recipient. If you configure an expansion server for the distribution list, all messages sent to the distribution list are sent to the specified Hub Transport server, which expands the list and then distributes the messages.

5-10

Planning and Deploying Message Transport in Microsoft® Exchange Server 2010

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 link 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 the top-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 Routing Failure

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

5-12


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.


Lesson 2

Designing Hub Transport Servers

Hub Transport servers provide the message-routing backbone in any Exchange Server organization. Therefore, it is important for you to plan the configuration and placement of your Hub Transport servers with care, as a poor routing design may lead to degraded performance.


Describe the hardware requirements for Hub Transport servers.

•

Describe the default Hub Transport server configuration.

•

Plan SMTP send and receive connectors.

•

Plan for internal SMTP relay.

•

Design accepted domains and remote domains.

•

Design message throttling, back pressure, and size limits.

•

Troubleshoot internal message delivery.

5-14


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.


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

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

5-16


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 your organization 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 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 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 servers are 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.

5-18


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 Exchange organization 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, you should 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 for another 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 addresses that 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.

5-20


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

5-22


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, you control the types of messages that are sent to that domain. You also can apply message format policies and acceptable character sets for messages that are sent from your organization’s users to the remote domain. The settings for remote domains determine the Exchange Server organization’s global configuration settings. 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 subdomains. The wildcard character must appear at the start of the domain name entry. The SMTP domain name is limited to 256 characters. The default settings may be suitable for most situations, but when you work with a partner organization, you may choose to create a remote domain for their SMTP namespace, and configure specific settings accordingly.

5-24


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.

5-26


•

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

5-28


•

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


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.

5-30


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


•

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

5-32


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 are deploying 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 loadbalance outbound message delivery. If one of the Edge Transport servers is not available, both inbound and outbound email is sent through the available servers.

5-34


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 through multiple 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 an extended 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 Transport server. Additionally, Edge synchronization configures a Send connector to enable message delivery from the Edge Transport server to the Internet.

•

Create additional SMTP Send connectors. You might have additional requirements for Send connectors. 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 nameresolution services for the Edge Transport servers, rather than using internal DNS servers.

5-36


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 message routing through multiple locations? If your organization has more than one location with an Internet connection, you can enable inbound message routing through each location. To do this, you can 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 first SMTP servers are not available.

•

How will you configure SMTP Receive connectors? By default, an Edge Transport server is configured with an SMTP Receive connector that accepts anonymous connections from all IP addresses. You can use this Receive connector to accept incoming email. All Hub Transport servers 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 TLS encryption to ensure that messages are secured from a partner organization. Each Receive connector must use a unique combination of IP address bindings, port number assignments, and the remote IP address ranges from which the connector will accept mail.

5-38


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 you deploy 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 site that 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 the organization, 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 Send connector’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.

5-40


•

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, and Americas.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 outboundonly Address Rewriting agent:

5-42


•

•

•

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.


•

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

5-44





2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, 10233B-VAN-EX2, and the 10233B-VAN-EDG virtual machines are running.

3.


4.

Log on to 10233B-VAN-EDG as Administrator using the password Pa$$w0rd

Lab Scenario You are a messaging engineer for A. Datum Corporation, an enterprise-level organization with multiple 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. Note Your instructor may choose to perform this lab as a group discussion rather than an individual activity.


AD DS and Routing Interview Notes.doc Tzipi Butnaru, Directory Services Manager 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.

Andreas Herbinger, Messaging Specialist 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.

Shane DeSeranno, Network Operations Manager 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 that email 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.

Jason Carlson, Network Specialist 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.

5-46


Adatum_Info.vsd (WAN Links)




5-48


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.

 Task 1: Review the A. Datum Corporation documentation •

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


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 changes to the site design 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. Note


Results: After this exercise, you should have successfully designed the A. Datum messaging perimeter.

5-50


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

5-52


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


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: Is Default-First-Site-Name a hub site?

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.

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


2.


3.


4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EDG. Close the virtual machine connection windows.

5.


5-54


6.


7.


8.




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?

5-56


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.

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


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.

6-4


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 Contents To 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 personal account—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 corporate policies 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.

6-6


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 applied on 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 which the 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 cloned configuration 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 Web App. 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 that Exchange 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.

6-8


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 Receive connectors, 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.

6-10


•

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 or TLS\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 Windows authentication, 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 partner organization’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 certificate trusted 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.

6-12


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 “Domain Secured”. 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 Alternative Names value on the certificate stores the domain name information. You can create a certificate 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 Exchange Management 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 the messages sent and received, and the failed mutual TLS sessions.

6-14


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 that can 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 the public 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 computer running 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 Outlook 2003 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.

6-16


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.


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.

6-18


•

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 in Exchange 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 an administrator-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

6-20


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 the past, 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's DNS 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 Email folder.

•

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

6-22


•

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.

6-24


•

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 should not 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 must continually 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 become more 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 Help Desk 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.

6-26


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

6-28


•

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 that email 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 gatewaylayer 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 Server Forefront 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?

6-30


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

6-32




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.

3.


Lab Scenario You are a messaging engineer for the A. Datum Corporation, an enterprise-level organization with 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. Note Your instructor may choose to perform this lab as a group discussion rather than an individual activity.


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 disclaimer added 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 are concerned 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.

6-34


•

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 viruses inside 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. To complete this exercise, review the existing A. Datum documentation: •

Security Requirements.doc



2.

Modify the A. Datum Proposed Security Policies document with a proposed message security plan.

3.


 Task 1: Review the A. Datum 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 Reference Number: JC120310/1 Document Author Date

Jason Carlson 12th March 2010

Message Security Components Component type

Configuration details

6-36


(continued) A. Datum Proposed Security Policies Component type


Additional notes

Note


 Task 3: Answer questions relating to the documentation 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. To complete this exercise, review the existing A. Datum documentation: •

Security Requirements.doc



2.

Modify the A Datum security Proposed Policies Document with a proposed antivirus and anti-spam solution.

3.




Virus and Spam Filtering Requirements in the Security Requirements.doc

 Task 2: Modify the A. Datum Proposed Security Policies document with a proposed antivirus and anti-spam solution •

Complete both the Anti-Spam and Antivirus Solution Components sections of the following document. In the document, provide: •


•




Anti-Spam Solution Components Component type Configuration details Anti-spam software IP Allow List provider IP Block List provider SMTP connectors Content filter and quarantine mailbox

6-38


(continued) A. Datum Proposed Security Policies Anti-Spam Solution Components Component type Configuration details Sender ID filtering Safelist aggregation Blocked recipient lists Antivirus Solution Components Component type Configuration details Antivirus software Antivirus software Antivirus stamping Antivirus update

Additional notes

Note




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

6-40


c. 5.

Update certificates that use certificate templates: Selected

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

•

Password: Pa$$w0rd

•

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.


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

•

Password: Pa$$w0rd

•

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.


User name: Scott

•

Password: Pa$$w0rd

•

Domain: Adatum

2.


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.



2.


3.


4.

Repeat these steps for 10233B-VAN-EX1 and 10233B-VAN-CL1. Close the virtual machine connection windows.

5.


6-42


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. Note Start the 10233B-VAN-DC1 virtual machine first, and ensure that it is fully started before starting the other virtual machines.

7.




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?

6-44



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

Lab: Planning and Deploying Messaging Compliance

7-37

7-2

Planning and Deploying Messaging Compliance

Module Overview

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 can use messaging compliance features to control message transport, apply Rights Management Services (RMS), implement journaling and archiving, and manage messages. After completing this module, you will be able to: •

Design transport compliance.

•

Design Active Directory® Rights Management Services (AD RMS) integration with Exchange Server 2010.

•

Design message journaling and archiving.

•

Design messaging records management (MRM).


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

Identify the requirements and options for implementing transport compliance.

•

Design transport rules.

•

Design message classifications.

•

Design message moderation.

7-3

7-4


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


7-5

•

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 text string “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.

7-6


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 may unintentionally modify or delete messages.

•

Use regular expressions to check message contents. Use regular expressions to simplify the list of terms when you are including a text string in a condition. You can use one regular expression, rather than a list of variations on the same word. For example, when searching for a phone-number pattern, you can use the expression “\d\d\d(-|.)\d\d\d\d”, which denotes a pattern of 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.


7-7

•

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.

7-8


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

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


7-9

•

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.

7-10


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 as fundraising 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 messageapproval 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.


7-11

•

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.

7-12


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

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.


7-13

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.

7-14


•

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.


7-15

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.

7-16


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.


•

7-17

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.

7-18


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


•

7-19

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.

7-20


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

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.


7-21

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.

7-22


•

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.


7-23

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

7-24


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.


7-25

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

7-26


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 user mailbox 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 organizational policies.

•

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.


•

•

7-27

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.

7-28


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 of mailboxes, 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 litigation 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.


7-29

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.

7-30


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

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.


7-31

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.

7-32


•

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.


7-33

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.

7-34


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.


7-35

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

7-36


Discussion: Designing a User Communication Plan for Messaging Compliance

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?


7-37


Lab Setup For this lab, you will use the available virtual machine environment. Before you begin the lab, you must do the following: 1.


2.

Ensure that the 10233B-VAN-DC1 and 10233B-VAN-EX1 virtual machines are running.

3.


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

7-38


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.



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 •

Complete the following proposal document by answering the questions. A. Datum Message Transport Plan Document Reference Number: JC040417/1 Document Author Date

Jason Carlson 15th Apr 2010

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

7-39

7-40


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 Conor Cunningham, Messaging Services Manager 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. The main tasks for this exercise are as follows: 1.


2.


3.

Document the required configuration for journaling and archiving.



Message Compliance Interview

 Task 2: Answer questions related to the documentation Note


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 •

Complete the following proposal document by answering the questions. A. Datum Journaling and Archiving Plan Document Reference Number: JC040417/2 Document Author Date


Requirement Overview 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 receive personal 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?

Note


Results: After this exercise, you should have created a journaling and archiving plan.

7-41

7-42


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


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 •

Complete the following proposal document by answering the questions. A. Datum Messaging Records Management Plan Document Reference Number: JC040417/3 Document Author Date


Requirement Overview 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?

Note


Results: After this exercise, you should have created an MRM plan.


7-43

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

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.

7-44


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:

7.

•

To: [email protected]

•

Subject: Company financial results

•

Permission: Company Internal

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.

2.

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

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.

7-45

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.

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


3.


4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3. Close the virtual machine connection windows.

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


8.


9.


7-46



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

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

Lab: Planning and Deploying High Availability

8-45

8-2 Planning and Deploying High Availability

Module Overview

Messaging systems are considered a critical business tool in most organizations. Outages of even a few hours reflect poorly upon the IT departments, and can result in lost sales or loss of business reputation. High availability helps ensure that messaging systems built on Microsoft® Exchange Server 2010 can survive the failure of a single server, or even multiple servers. You can implement high availability for all the server roles in Exchange Server 2010. After completing this module, you will be able to: •

Describe high availability in Exchange Server 2010.

•

Design high availability for mailbox databases.

•

Design high availability for non-Mailbox server roles.

•

Design site resilience.


8-3

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

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.


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 Requirements One 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?


8-5

•

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 you consider 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 that an alternate power source—such as a battery or a generator—is available when the electrical utility experiences outages. You can make cooling capacity highly available by using multiple cooling units with sufficient capacity to keep the data center cool when one unit fails. In cases of a catastrophic failure, you can use an alternate data center location.

•

Server hardware. To make server hardware highly available, there must be redundant components in the server. Redundant components can include power supplies, network adapters, processors, and memory. Error-correction code (ECC) memory helps to resolve minor errors in memory.

•

Storage. To make storage highly available on a single server, you can use a version of Redundant Array of Independent Disks (RAID). RAID uses parity information to ensure that a server can survive the loss of at least one hard drive without losing any data. If multiple servers are available, you can replicate data between servers. This allows the data to survive the loss of an entire server, rather than just a hard drive.


8-7

•

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.


8-9

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.

8-10

Planning and Deploying High Availability

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.


8-11

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?

8-12


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.


8-13

•

Eliminates the need for storage hardware redundancy for transport servers.

•

Consumes less bandwidth than duplicate copies of messages on multiple servers. The only additional network traffic generated with shadow redundancy is the exchange of discard status between transport servers. Discard status is the information each transport server maintains, indicating when the transport database is ready to discard a message.

8-14


How High Availability Works for Client Access Servers

Key Points A client access array is a load-balanced collection of Client Access servers that is in a single site. Because all client connections—including Messaging Application Programming Interface (MAPI)—rely on connections to Client Access servers, it is important to provide a redundant server array to improve availability. To create a client access array, first deploy multiple Client Access servers. Next, use either hardware-based or software-based Network Load Balancing (NLB) to create a cluster. Then, add the name for the network load-balanced cluster into DNS. For example, you could add a host (A) resource record for caa1.contoso.com that points to 10.10.10.25. After adding the DNS record, you can create the client access array and assign it to an Active Directory site using the New-ClientAccessArray cmdlet. Finally, assign the client access array to each of the mailbox databases in the site by using the SetMailboxDatabase cmdlet with the RpcClientAccess parameter. A client access array can exist only in a single Active Directory site. Therefore, you need to create a client access array in each Active Directory site that needs to load balance client access servers. As a best practice, you should create the client access array before you create mailbox databases. When new mailbox databases are created, the RpcClientAccess parameter is automatically configured to use a client access array if one exists for that site. This avoids the need to update mailbox databases later. Question: Why is high availability important for Client Access servers?


8-15

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

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.

8-16


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


8-17

Network Configuration 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 there is an even number of members in the DAG. The witness server is a file share located on a server that is not a 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?

8-18


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.

8-19

8-20


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 member failure. 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?


8-21

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 logs from 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 which transaction 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.

8-22


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.


8-23

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.

8-24


•

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?


8-25

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

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.

8-26


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 shadow redundancy, messages remain in the transport dumpster of other Hub Transport servers until they are notified that the message has been delivered.


8-27

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?

8-28


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.


8-29

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?

8-30


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?


8-31

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

8-32


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.


8-33

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

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.

8-34


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?


8-35

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

8-36


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?


8-37

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 different content 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?

8-38


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 threemember DAG with two members in the primary site and one member in an alternate data center can experience 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 finds another 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-DatabaseAvailabilityGroup dagname –DatacenterActivationMode DagOnly in the Exchange Management Shell.


8-39

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 rebooted at 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 RestoreDatabaseAvailabilityGroup cmdlet.

8-40


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.


8-41

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 the RPCClientAccessServer 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. To ensure that clients can access the Client Access servers in the alternate data center quickly, you must provide clients with an alternate hostname to access services.

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 a lower priority number is contacted first. The MX record for the alternate data center has a higher priority number than the MX record for the primary data center. With this configuration, mail servers attempt delivery to the primary data center first, and if the primary data center is unavailable, the messages are delivered to the alternate data center. Messages transported through the alternate data center automatically use the Edge Transport server in the alternate data center for message delivery, because it is the closest Edge Transport server.

8-42


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


8-43

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?

8-44


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?


8-45




2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EX3 virtual machines are running.

3.


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 corporation involved in technology research and investment, and is planning to upgrade from Exchange Server 2003 to Exchange Server 2010. 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 individual activity.

8-46


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.

Jason Carlson, Network Specialist 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.

Shane DeSeranno, Network Operations Manager 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.

Conor Cunningham, Messaging Services Manager 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.

Andreas Herbinger, Messaging Specialist 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.


8-47

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

User Distribution Summary Location

Internal users

Mobile users



• • •

1,000 Outlook Web Access users 500 Outlook Anywhere and mobile client users 800 Outlook users connecting through a virtual private network (VPN)

London (new office)

4,000 (anticipated)

• •

200 Outlook Web Access users 50 Outlook Anywhere and mobile client users

San Diego 500 Former head office of Trey Research Corporation

•

50 POP3 client users

Vancouver

6,000

• •


Tokyo

5,000

• • •

1,000 Outlook Web Access users 200 Outlook Anywhere and mobile client users 200 Outlook users connecting through a VPN


800 (anticipated)

• •

200 Outlook Web Access users 50 Outlook users connecting through a VPN

8-48


Network Configuration




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

•




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?

8-49

8-50


 Task 3: Document the required configuration for the San Diego site •

Complete the following proposal document by answering the questions. A. Datum High Availability Design for San Diego Document Reference Number: JC040422/1 Document Author Date


Requirement Overview Determine how high availability will be provided for all server roles in San Diego. Additional Information Identify infrastructure changes that may be required due to the proposed deployment. 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 •

Complete the following proposal document by answering the questions. A. Datum High Availability Design for Vancouver Document Reference Number: JC040422/2 Document Author Date


Requirement Overview Determine how high availability will be provided for all server roles in Vancouver. Additional Information Identify infrastructure changes that may be required due to the proposed deployment. 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?

Results: After this exercise, you should have created a high availability design for the San Diego and Vancouver sites.

8-51

8-52


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


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. This does not indicate a problem. The necessary permissions were configured in Task 1.


4.

8-53

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. Question: What is the status for Mailbox Database 1 on each server?

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.

8-54




2.


3.


4.


5.


6.


7.


8.




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

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.

8-55

8-56


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

Plan for disaster mitigation.

•

Plan Exchange Server 2010 backup.

•

Plan Exchange Server 2010 recovery.

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

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

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 the default 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 not lost 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 item retention 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 singledisk 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.


9-11

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 will implement?


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 Copies Exchange 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 Copies To 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.


9-13

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 time that 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 expensive storage. 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?


9-15

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, the RTO for sending and receiving messages might be one hour, but the RTO for historical data in mailboxes might be 12 hours. The RPO for a service defines 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-item recovery, 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?


9-17

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

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, or to 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.


9-19

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 a

Hub Transport

• Message transport logs. Backing up these logs may be useful for later

Edge Transport

• Server configuration. This is stored locally rather than in AD DS. You should

Unified Messaging

• Customized audio prompts. If not backed up, the prompts are lost when the

system state backup to back up configuration settings in Internet Information Services (IIS) 7.0, just a backup of the configuration directory. If you do not have this data backed up, you can reconfigure it. • Secure Sockets Layer (SSL) certificate with private key. However, if you do not back up the SSL certificate, you can always purchase another one. troubleshooting. However, no backups are required to restore functionality.

clone the configuration to back up the server configuration. Unified 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.


9-21

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 SANbased 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 SANbased snapshots for Exchange Server backup, your backup application must support your specific SAN hardware.


9-23

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 that mailboxes 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 Servers Other 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.


9-25

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. Assigning responsibility 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 physical location. 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 thirdparty 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 rotation before 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.


9-27

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

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


9-29

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

•

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 are configured to use a specific server. For example, an application may be using a specific Hub Transport server as a mail relay. Recovering the server means that you do not need to reconfigure a new Hub Transport server with an appropriate Simple Mail Transfer Protocol (SMTP) receive connector.


Options 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 the database. After restoration, replay the transaction logs to bring the database up to 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 database that is mounted on a Mailbox server, but is not directly accessible to users. After restoring a database in the recovery database, extract the messages or mailboxes 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 Mailbox server in the organization. This is useful when one of several Mailbox servers fails, and you want to recover the database to a functional Mailbox server. You can also restore to a recovery database located on a different server. After restoring a database to an alternate server, you must use the Set-Mailbox cmdlet with the –Database parameter to link the mailboxes with the new location.


9-31

(continued) Option

Description

Dial-tone recovery

When a mailbox database fails, users with mailboxes in that database can no longer send and receive messages. You can create a dial-tone database by creating and mounting an empty database for the mailboxes contained in the failed database. This quickly allows users to send and receive messages again. After the dial-tone database is functional, restore historical data to a recovery database, and then merge the data into the dial-tone database. If the dial-tone database is located on a different server than the failed database, use the Set-Mailbox cmdlet with the –Database parameter to link the mailboxes with the new location.

DAG recovery

Performing a DAG recovery means that you do not need to perform a database restore. Assuming you have multiple database copies in a DAG, then when one database copy fails, Exchange Server automatically mounts and redirects users to another database copy. To restore redundancy, create another database copy on a different server.

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 the disks containing the database are lost.

•

Recover basic functionality as soon as possible if you do not use a DAG, and a Mailbox server or database fails. Use a dial-tone recovery database to allow users to send and receive messages as quickly as possible. This is much faster than waiting for a database to restore.

•

Ensure that you have enough free disk space to hold a restored database. Allocate enough free disk space to hold any database from which you might need to recover data. You can 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?


9-33

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 Exchange server 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 Server Deploying a new server may require you to reconfigure some applications. For example, if you configure a Voice over IP (VoIP) gateway to communicate with the DNS name or IP address of the failed server, then you must reconfigure the VoIP gateway. If you choose not to rebuild a failed Exchange server, you must remove it manually from AD DS using the LDP.exe tool.


9-35

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.


9-37

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


9-39

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, especially since 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 that numerous 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.


9-41


Lab Setup For this lab, you will use the available virtual machine environment. Before you begin the lab, you must do the following: 1.


2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, and 10233B-VAN-CL1 virtual machines are running.

3.


Lab Scenario You are a messaging engineer for A. Datum Corporation, an enterprise-level organization with multiple 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. Note Your instructor may choose to perform this lab as a group discussion rather than an individual activity.


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.



2.


3.

Document the required configuration for the Vancouver site.



Disaster Recovery SLA Notes

 Task 2: Answer questions related to the documentation Question: In the Disaster Recovery SLA Notes, what points are raised that impact your disaster recovery plan for Vancouver?



Complete the following proposal document by answering the questions. A. Datum Disaster Recovery Plan for Vancouver Document Reference Number: JC040430/1 Document Author Date

Jason Carlson 5th May 2010

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

9-43


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


2.


3.

Document the required configuration for the San Diego site.




 Task 2: Answer questions related to the documentation Question: In the Disaster Recovery SLA Notes, what points are raised that impact your disaster recovery plan for San Diego?



Complete the following proposal document by answering the questions. A. Datum Disaster Recovery Plan for San Diego Document Reference Number: JC040430/2 Document Author Date


Requirement Overview 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: 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: 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.

9-45


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


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 https://van-ex1.adatum.com/owa.

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.


9-47

 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 https://van-ex1.adatum.com/owa.

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



2.


3.


4.


5.


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.


8.


9.



9-49


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

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


10-1

Module 10 Planning Microsoft® Exchange Server 2010 Monitoring and Troubleshooting 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 and efficiently resolve even complex problems. After completing this module, you will be able to: •

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

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.

10-4


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 your business. 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® 2008 Event Viewer

Collects information related to server operations. This data can help you to identify performance issues on a server. You should search for specific events 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 improves system 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, and analyze network data. You can use it to help troubleshoot problems with applications on the network. Network Monitor is provided with Windows Server 2008.


(continued) Tool

Description

Reliability and Performance Monitor

You can use Windows Reliability and Performance Monitor to examine how programs 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, and configuration information, which can be combined into Data Collector Sets. Reliability and Performance Monitor is built in to Windows Server 2008.

Microsoft Exchange Server 2010 Management Pack for Microsoft System Center Operations Manager 2010

System Center Operations Manager 2010 enables you to build a complete picture of the past and current performance of your server infrastructure. System Center Operations Manager can also automatically respond to events and address problems before they become an issue for you. System Center Operations Manager requires time to configure, and requires additional licenses. The Microsoft Exchange Server 2010 Management Pack is designed to be used for monitoring Exchange Server 2010 events, collecting Exchange component-specific performance counters in one central location, and for raising alerts when operator intervention is necessary.

Microsoft Exchange Server 2010 Management Pack for System Center Essentials 2010

Microsoft System Center Essentials 2010 is a management solution that provides: 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.

10-6


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


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

10-8


Monitor the following performance counters for Mailbox server logical disks. Group

Counter

Description

Expected value

Logical Disk

Avg. Disk sec/Read

Shows the average time for reading data from the disk.

On average, should be below 20 ms at all times.

Avg. Disk sec/Write

Shows the average time for writing data to the disk.


Avg. Disk sec/Transfer

Shows the average number of bytes transferred to or from the disk during Read or Write operations.

Should be below 20 ms on average, and spikes 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

MSExchangeIS Messages Mailbox and Queued for MSExchangeIS Submission Public

Description

Expected value

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

Should be below 50 at all times, and not be sustained for more than 15 minutes. Otherwise, this counter may indicate connectivity issues with the transport servers, or that backpressure is occurring.

MSExchangeIS The Client Access and Transport servers use 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. Group

Counter

Description

Expected value

MSExchangeIS

RPC Requests

Shows the overall RPC requests that are currently executing within the information store process.

Should be below 70 at all times.

RPC Averaged Latency

Shows the RPC latency (in ms) averaged for all operations in the last 1,024 packets.

Should not be higher than 25 ms on average.

RPC Operations /sec

Shows the current number of RPC operations occurring per second.

Should closely correspond to historical baselines. Values much higher than expected indicate that the workload has changed, while values much lower than expected indicate a bottleneck that is preventing client requests from reaching the server.


(continued) Group

Counter

Description

Expected value

MSExchangeIS

RPC Num. Slow Packets

Shows the number of RPC packets in the past 1,024 packets that have latencies longer than 2 seconds.

Should be less than 1 on average, and should be less than 3 at all times.

10-10


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

Counter

Description

Expected value

LogicalDisk Avg. Disk sec/Read



Avg. Disk sec/Write



Avg. Disk Queue Length

Shows the number of messages in the poison message queue.

Should be 0 at all times.


MSExchange Database ==> Instances Transport servers store message queue information in databases. Therefore, monitoring database performance will help you identify issues with reading or storing queue information in the databases. Group

Counter

Description

Expected value

MSExchange Database ==> Instances

Log Generation Checkpoint Depth

Shows the amount of work (in count of log files) that needs to be redone or undone to the database file(s) if a process crashes.

Should be less than 1,000 at all times.

Version buckets allocated

Shows the total number of allocated version buckets. Shows the default backpressure values as listed in the edgetransport.exe.config file.

Should be less than 200 at all times.

Log Record Stalls/sec

Shows the number of log records that cannot be added to the log buffers per-second, because they are full. If this counter is non-zero most of the time, then the log buffer size may be a bottleneck.

Should be less than 10 per second on average, and spikes should not be greater than 100 per second.

MSExchange Transport Queues In addition to the transport server databases, you should also monitor the transport server queues to ensure email messages are being delivered. Group

Counter

Description

Expected value

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

Should be less than 5,000.

Active Remote Delivery Queue Length

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


Active Mailbox Delivery Queue Length

Shows the number of messages in the active mailbox queues.


Retry Mailbox Delivery Queue Length

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


Unreachable Queue Length

Shows the number of messages in the Unreachable queue.

Should not exceed 100.

Largest Delivery Queue Length

Shows the number of messages in the largest delivery queues.

Should be less than 200.

Poison Queue Length

Shows the number of messages in the poison message queue. Poison messages are messages that were detected as harmful. These messages often cause a Transport service failure.


MSExchange Aggregate Delivery Queue Length (All Transport Queues) Queues

10-12


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. Disk sec/Read


Should be below 20 ms on average.

Avg. Disk sec/Write


Should be below 100 ms on average.

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 you verify the overall health of the services.


The following table lists the counters related to ASP.NET and ASP.NET applications. Group

Counter

Description

Expected value

ASP.NET

Application Restarts

Shows the number of times the application has been restarted during the Web server's lifetime.

Should be a low value.

Worker Process Restarts

Shows the number of times a worker process has restarted on the computer.

Should be a low value.

Requests Current

Shows the current number of requests— including those that are queued— currently executing, or waiting to be written to the client. Under the ASP.NET process model, when this counter exceeds the request QueueLimit defined in the process model configuration section, ASP.NET begins rejecting requests. The maximum value is 5,000. The server returns a 503 error if the counter exceeds this value.


Request Wait Time

Shows how long (in ms) the most recent request was waiting in the queue.

Should be less than 1,000 ms at all times.

Requests in Application Queue

Shows the number of requests in the application request queue. The maximum value is 5,000. The server returns a 503 error if the counter exceeds this value.


ASP.NET Applications

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

Counter

Description

Expected value

MSExchange OWA

Average Response Time

Shows the average time (in ms) that elapsed for the request. Used to determine the latency that a client is experiencing.

Should be less than 100 ms at all times. Higher values may indicate high user load, or higher-than-normal CPU time.

Average Search Time

Shows the average time (in ms) that elapsed while waiting for a search to complete.

Should be less than 100 ms at all times.

Number of failed back end connection attempts per second

Shows the rate at which the RPC proxy attempts fail to establish a connection to a back end server.


RPC/HTTP Proxy

10-14


(continued) Group

Counter

Description

Expected value

MSExchange ActiveSync

Average Request Time

Shows the average time that Varies by devices, carrier, or elapsed while waiting for a configuration. You must use a request to complete. baseline to set this threshold. Determines the rate at which the Availability Service requests are occurring.

MSExchangeFS: OAB

Download Task Queued

Shows a value of 1 if the task Should be 0 at all times. Values is queued for execution, greater than 0 indicate a failure otherwise shows 0. to copy offline address book data 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

10-16


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.

10-18


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

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.

10-20


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 tool simulates the SMTP service's internal code path, and prints diagnostic messages that indicate how the DNS resolution is proceeding.

DSACLS (dsacls.exe)

Use this command-line tool to query and change permissions and security attributes of AD DS objects.

Error Code Look-up (Err.exe)

Use to determine error values from decimal and hexadecimal error codes 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) searches against the Active Directory directory service or AD DS for specific information–given search criteria. This tool also enables you to query data that would otherwise not be visible through the administrative tools included in Windows Server and Exchange Server.


(continued) Tool name

Description

Microsoft Error Reporting

Exchange Server 2010 uses Windows Error Reporting to collect crash dumps and debug information. It enables administrators to track and address errors related to the Windows operating system, Windows components, and applications such as Exchange Server 2010. This service gives administrators and users the opportunity to send data about errors to Microsoft, and to receive information about errors. Administrators can use Microsoft Error Reporting to address customer problems in a timely manner, and to help improve the quality of Microsoft products.

Process Monitor (procmon.exe)

Use to monitor real-time file system, registry, and process or thread activity.

10-22


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

Description

Exchange Server Database Utilities (Eseutil.exe)

Use this tool to perform offline database procedures, such as defragmentation and integrity checking.

Exchange Server Jetstress

Use this tool as a benchmarking tool to validate your storage subsystem.

Exchange Profile Analyzer (epa.msi)

Use this tool to collect estimated statistical information from a single mailbox store, or from across an entire Exchange Server organization. Use the collected data for tasks such as analyzing the performance and health of a server that has mailboxes.

Exchange Store TreeView 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 private information store databases. This tool is intended for disaster recovery situations, and not for routine maintenance.

Inter-Organization Replication (exscfg.exe; exssrv.exe)

Use this tool to replicate public folder information (including free/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 of servers to mail loads.

Microsoft Baseline Security Analyzer Use this tool to scan local or remote systems for common (MBSA) configuration errors, and to verify security best practices. GUI: MBSA.exe Command line: mbsacli.exe RPC Ping utility (rpings.exe and rpingc.exe)

Use this tool to confirm RPC connectivity between the computer that is running Exchange Server, and any of the client workstations on the network.

Telnet (telnet.exe)

Establish a direct connection to an SMTP connector on an Exchange Server, in order to verify connectivity and inbound mail-flow.

10-24


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?

10-26


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?





2.

Ensure that the 10233B-VAN-DC1, 10233B-VAN-EX1, 10233B-VAN-EX2, and the 10233B-VAN-EX3 virtual machines are running.

3.


Lab Scenario You are a messaging engineer for A. Datum Corporation, an enterprise-level organization with multiple 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.

10-28


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

3.

•

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

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.

10-30


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

6.

From the Data tab, add the following counters: Performance object

Counter

Memory

Pages/sec

MSExchangeIS

RPC Requests

MSExchangeIS

User Count


Local delivery rate


Messages Delivered/sec


Messages Queued For Submission


Messages Sent/sec




Retry Remote Delivery Queue Length


Submission Queue Length


Messages Received/sec


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

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.

10-32


Exercise 2: Measuring the Production System Performance under Additional 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. The main tasks for this exercise are as follows: 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.


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 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 Queue Length MSExchangeTransport Queues - Retry Remote Delivery Queue Length MSExchangeTransport Queues - Submission Queue Length MSExchangeTransport SmtpReceive - Messages Received/sec

Average

10-34


Counter

Average

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



2.


3.


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?

10-36


11-1

Module 11 Upgrading to Microsoft® Exchange Server 2010 Contents: Lesson 1: Overview of Upgrading to Exchange Server 2010

11-3

Lesson 2: Planning the Upgrade from Exchange Server 2003 to Exchange Server 2010

11-12

Lesson 3: Planning the Upgrade from Exchange Server 2007 to Exchange Server 2010

11-28

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

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.


11-3

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

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.

11-4


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 2003 with SP1 or newer.

•

You must have configured your AD DS forest to be at least at the Windows Server 2003 forestfunctional 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.


11-5

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 organization upgrade

Exchange 2000 Server

Not supported

Although an upgrade is not supported, you can use a migration strategy to transition to Exchange Server 2010. Alternately, you can upgrade the Exchange 2000 Server organization completely to Exchange Server 2003 or Exchange Server 2007, and then perform an in-place upgrade to Exchange Server 2010.

Exchange Server 2003 with SP2 or newer

Supported

Before you install Exchange Server 2010 servers into an existing Exchange Server 2003 organization, you must configure the organization to run in native mode.

Exchange Server 2007 with SP2 or newer

Supported

When upgrading from Exchange Server 2007, you must upgrade all of your organization’s Exchange Server 2007 servers to SP2.

Mixed Exchange Server 2007and Exchange Server 2003 organization

Supported

When you are ready to upgrade your mixed mode environment, upgrade each Active Directory site individually. If you have Active Directory sites with only Exchange 2007 or Exchange 2003 in them, follow the instructions for upgrading from that version for that Active Directory site. For example, if you have Exchange Server 2007 in Active Directory site A, then follow the upgrade instructions for Exchange Server 2007. If you have Exchange Server 2003 installed in Active Directory site B, then follow the upgrade instructions for Exchange Server 2003.

Comments

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.

11-6


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

•

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.


11-7

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.

11-8


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


11-9

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

11-10


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.


11-11

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.

11-12


Lesson 2

Planning the Upgrade from Exchange Server 2003 to Exchange Server 2010

Many organizations still use Exchange Server 2003 for their messaging system, and they might not have any plans of upgrading to Exchange Server 2007. Microsoft supports an upgrade from Exchange Server 2003 directly to Exchange Server 2010, specifically for these organizations. This lesson describes how to upgrade an Exchange Server 2003 organization to Exchange Server 2010. After completing this lesson, you will be able to: •

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.


11-13

Prerequisites for Installing Exchange Server 2010 in an Exchange 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 Servers group. When you extend the Active Directory schema in preparation for Exchange Server 2010, the schema is modified so that the server running Recipient Update Services no longer has the required permissions to update the recipient properties. Running setup with the PrepareLegacyExchangePermissions parameter modifies the permissions to ensure that the server can continue to modify recipient properties.

11-14


Changes Made by the PrepareAD Command After running setup with the PrepareLegacyExchangePermissions parameter, you should run setup with the PrepareAD command. This command makes the following changes to enable coexistence between Exchange Server versions: •

Creates the Active Directory universal security group, ExchangeLegacyInterop. This group receives permissions that allow the Exchange Server 2003 servers to send email to the Exchange Server 2010 servers.

•

Creates the Exchange Server 2010 administrative group, which is called Exchange Administrative Group (FYDIBOHF23SPDLT).

•

Creates the Exchange Server 2010 routing group, which is called Exchange Routing Group (DWBGZMFD01QNBJR).

The PrepareAD command also extends the schema to include the Exchange Server 2010 schema objects and attributes.


11-15

Process for Installing Exchange Server 2010 in an Exchange Server 2003 Organization

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.

11-16


4.

Install Exchange Server 2010 Unified Messaging servers.

5.

For organizations with multiple sites, there are typically two types of Active Directory sites: Internetaccessible sites, and non-Internet accessible sites. A single Exchange Server organization may have one or more Internet-accessible sites. When upgrading Active Directory sites, you should upgrade Internet-accessible sites before non-Internet accessible sites.


11-17

Designing Client Services Coexistence

Key Points After you deploy the Exchange Server 2010 Client Access and Mailbox servers, the process that nonMessaging 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 to access 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.

11-18


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.


11-19

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

11-20


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


11-21

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 presented to 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 2003 bridgehead 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.

11-22


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


11-23

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 Exchange Server 2010 does not use administrative groups for delegating permissions. The following table describes some options for creating an Exchange Server 2010 administrative design that emulates an Exchange Server 2003 design. Exchange 2003 administrative assignment options

Exchange Server 2010 equivalent

Exchange Full Administrator role at the organization level

Add users or groups to the Exchange Organization Administrator role group.

Exchange Administrator role at the organization level

Exchange Server 2010 does not have a role group equivalent to the Exchange Administrator role. You can create a role group and assign the required permissions through role-based access control (RBAC).

Exchange View Administrator role at the organization level

Add users or groups to the Exchange View-Only Administrator role.

Exchange Full Administrator role at the administrative group level

Create a new role group that is assigned all management roles, but with a limited scope.

11-24


(continued) Exchange 2003 administrative assignment options

Exchange Server 2010 equivalent

Exchange View Administrator role at the administrative group level

Create a new role group with View-Only permissions and a limited scope.

Recipient administrators with Exchange View Administrator role and AD DS permissions

Add users and groups to the Exchange Recipient Administrator 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.


11-25

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 following process for removing Exchange Server 2003 servers: 1.

Remove back-end servers first. As you move mailboxes from Exchange Server 2003 servers to Exchange Server 2010 Mailbox servers, you can start decommissioning the previous back-end servers.

2.

Remove the Exchange Server 2003 bridgehead servers. 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.

11-26


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.


11-27

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.

11-28


Lesson 3

Planning the Upgrade from Exchange Server 2007 to Exchange 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. After completing this lesson, you will be able to: •

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.


11-29

Prerequisites for Installing Exchange Server 2010 in an Exchange 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.

11-30


Process for Installing Exchange Server 2010 in an Exchange Server 2007 Organization

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.


11-31

For organizations with multiple sites, there typically are two types of Active Directory sites: Internetaccessible sites, and non-Internet accessible sites. A single Exchange Server organization may have one or more Internet-accessible sites. When upgrading Active Directory sites, you must begin your upgrade by upgrading Internet-accessible sites first, followed by non-Internet accessible sites. You should follow the same process for deploying Exchange Server 2010 servers in both Internetaccessible and non-Internet accessible sites. Before deploying any Exchange Server 2010 Mailbox server in any site, you must deploy Exchange Server 2010 Client Access and Hub Transport servers.

11-32


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.


11-33

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

11-34


•

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


11-35

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.

11-36


•

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.


11-37

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

11-38


•

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 Organization Administrators group.

Add users or groups to the Organization Management role group.

Assign users to the Exchange View-Only Administrators group.

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

Assign users to the Exchange Recipient Administratorsgroup.

Add users or groups to the Recipient Management role group.

Assign users to the Exchange Public Folder Administrators group.

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

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

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


11-39

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.

11-40


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.


11-41

Lab: Upgrading to Exchange Server 2010

Lab Setup This lab does not require any virtual machines.

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 corporation involved in technology research and investment, and is planning to upgrade from Exchange Server 2003 to Exchange Server 2010. 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 an individual activity.

11-42


Adatum_ProposedADSiteDesign.vsd


Adatum_ProposedPerimeterDesign.vsd

11-43

11-44


A. Datum User Distribution Summary.doc Location

Internal users

Mobile users

London (corporate headquarters)


1,000 Outlook Web Access users 500 Outlook Anywhere and mobile client users 800 Outlook users connecting through a virtual private network (VPN)

London (new office)

4,000 (anticipated)


San Diego (former head office of Trey Research)

500

50 POP3 client users

Vancouver

6,000


Tokyo

5,000

1,000 Outlook Web Access users 200 Outlook Anywhere and mobile client users 200 Office Outlook users connecting through a VPN


800 (anticipated)

200 Outlook Web Access users 50 Office Outlook users connecting through a VPN

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 (corporate headquarters)

• Configured as a routing group • 12 Exchange Server 2003 servers hosting mailboxes • Two load-balanced front-end servers to provide access for remote users (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


11-45

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


2.

Update the A. Datum Upgrade Design document.


Review the following A Datum documentation: •


•


•


•

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 Reference Number: JC060610/1 Document Author Date

Jason Carlson 6th June 2010

Requirement Overview 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 reasonable timeline 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?

11-46


(continued) A. Datum Upgrade Design 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 Exchange Server 2010 and use Edge Transport servers? Question: When you begin migrating the second site to Exchange Server 2010, what process will you use? Question: How will you remove Exchange Server 2003?

Note


Results: After this exercise, you should have completed the A. Datum Upgrade document.

 To prepare for the next module Note No virtual machines are required for the next lab.


11-47


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 it implements 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?

11-48


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 Server 2003 server, you receive an error message that you cannot remove the server because it is a bridgehead server for a routing-group connector. You have upgraded all external message routing to Exchange Server 2010.

The Exchange Server 2003 server may be the designated routing group bridgehead server for the routing-group connector between the Exchange Server 2003 routing group and the Exchange Server 2010 routing group. If this is the last Exchange Server 2003 server, you can remove it from the routing-group connector. If you have other Exchange Server 2003 servers deployed, you need to designate one of them as the routing-group connector bridgehead server.

You are upgrading your Exchange Server 2007 organization to Exchange Server 2010, and you have configured Client Access servers for Internet access. Users with mailboxes on Exchange Server 2010 Mailbox servers can access their mailbox by using Outlook Web App from the Internet, but users with mailboxes on the Exchange Server 2007 Mailbox servers cannot.

Check the DNS configuration to ensure that users from the Internet can resolve the host name for the alternate or legacy URL that you have configured. Also, check the reverse proxy or firewall configuration to ensure that all client requests to the legacy URL are directed to the Exchange Server 2007 Client Access server.

You have deployed Exchange Server 2010 You need to use the same version of the Exchange servers in your Exchange Server 2007 Management Console as the server that you are organization. You need to modify the settings managing. on both Exchange Server 2007 and Exchange Server 2010 servers, but you cannot see both servers in the Exchange Management Console.

Best Practices Related to Upgrading to Exchange Server 2010 Supplement or modify the following best practices for your own work situations: •

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 Other Messaging Systems Contents: 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

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

Design integration with other messaging systems.

•

Design integration with federated partners.

•

Design integration with Exchange Online.


12-3

Lesson 1

Designing Exchange Server 2010 Integration with Other Messaging 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. After completing this lesson, you will be able to: •

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.

12-4


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


12-5

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

12-6


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


12-7

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 address rewriting, 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 two domains 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.

12-8


If there are two data centers but there is a direct link 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 the Exchange 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.


12-9

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

12-10 Integrating Microsoft® Exchange Server 2010 with Other Messaging Systems

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 that messaging system?


12-11

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 create contacts. 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?


12-13

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

•

The Inter-Organization Replication (IORepl) tool in Exchange Server 2003. The use of IORepl to synchronize 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 single mailbox.

•

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?


12-15

Lesson 2

Designing Exchange Server 2010 Integration with Federated 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. After completing this lesson, you will be able to: •

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 availability information, 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.


12-17

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?


12-19

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 and on. 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 be piped 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?


12-21

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

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.


12-23

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 peruser 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 available to 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 unlimited archive 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.


12-25

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 to Exchange 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 in Exchange 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 onpremises 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 in the 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.


12-27

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.


12-29

Designing Message Routing with Office 365

For organizations with all mailboxes hosted in a single Exchange Server organization, message routing can be as simple as configuring a single MX record for inbound messages and configuring a single Send connector for outbound messages. If your organization has all mailboxes hosted in Office 365, configure the MX record to deliver mail to the Office 365 servers.

Inbound message routing In a hybrid deployment, Office 365 and the on-premises Exchange Server organization both share the same address space. You can configure inbound messages to be delivered either to Office 365 or to the on-premises Exchange Server organization. In either case, the receiving organization delivers the message locally if possible, and it passes the message on to the other organization if no local recipient exists. For example, a message received by the on-premises Exchange Server organization is delivered locally if the recipient mailbox is in the on-premises Exchange Server organization. If the recipient is not in the onpremises Exchange Server organization, the message is forwarded through a Send connector to Office 365. The main reason to direct incoming messages through Office 365 is for the anti-spam and antivirus protection provided by FOPE. All Office 365 mailboxes are licensed for FOPE. You need to purchase additional user licenses for FOPE if you want to route messages for on-premises mailboxes through Office 365.

Outbound message routing Outbound message delivery can be centralized or decentralized. If you implement decentralized message delivery, all messages are delivered directly from the on-premises Exchange Server organization or Office 365 to the Internet. Centralized message delivery is supported only from the on-premises Exchange Server organization. The primary purpose of centralized message delivery is compliance, which is implemented in the on-premises Exchange Server organization. For example, you can archive a copy of all outbound messages to the Internet, or you can apply a legal notification to all messages.


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.


12-31

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 not supported for users outside of the Exchange Server organization.


12-33

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 and other 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 messaging system and Office 365. You must configure coexistence and directory synchronization between the onpremises 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 are migrated, so you can avoid migrating deleted items and junk mail.


12-35

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

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


12-37

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 should be 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 on two existing domain controllers. Install federation server proxies on two existing web or proxy servers in the perimeter network.

1,000 to 15,000 users

Use dedicated AD FS servers. Install two federation servers and two federation server proxies.

15,000 to 60,000 users

Use dedicated AD FS servers. Install 3 to 5 federation servers and two federation server proxies.


12-39

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

•

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 Other Messaging Systems

Lab Scenario You are a messaging engineer for A. Datum Corporation, an enterprise-level organization with multiple 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.


12-41

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 •

Complete the following proposal document by answering the questions. A. Datum Corporation and Northwind Traders Integration Plan Document Reference Number: JC040495/1 Document Author Date


Requirement Overview 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 to Office 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?

Note


Results: After this exercise, you should have created a plan to migrate Northwind Traders email to Office 365.


12-43


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

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 A Unified 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)

After completing this lesson, you will be able to: •

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.

A-4


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

A-6


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 play for their callers. The Unified Messaging server retrieves these greetings from the Mailbox server and plays them when applicable. When Unified Messaging subscribers call the Unified Messaging server to access their mailbox contents 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 Phone There 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 are located 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.

A-8


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 volume and 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 voice messages 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.

A-10


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-way communication

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

A-12


•

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

A-14


gateway. This enables all the Unified Messaging IP gateways to forward incoming calls to the Unified Messaging servers that are associated with the same dial plan. Then, if an IP gateway fails, the PBX will send the call to another IP gateway, one that can answer the call. The IP gateway, in turn, forwards the call to a Unified Messaging server within the same dial plan. If the call is sent to a Unified Messaging server that is not available, the IP gateway tries a second time to contact the Unified Messaging server. If it is once again unsuccessful, it then uses the next Unified Messaging server in the list to answer the call.

Multiple Locations A company with multiple physical locations will most likely have the same number of logical sites. If this is the case, then each of those sites would have their own PBX and IP gateway. Each site would also have to configure one or more Unified Messaging Dial Plans, Unified Messaging Mailbox policies, and hunt groups. You must also consider site links between the physical sites. Ensure that the links have the necessary bandwidth to support the required network traffic, and the increased Unified Messaging traffic. This is of special concern if you deploy Lync Server 2010 to support voice calls and conferencing. Adding these two new elements requires even more bandwidth.


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.

A-16


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

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.

A-18


Hardware Infrastructure Requirements

Key Points There are many factors to consider when selecting hardware for Exchange Server 2010. Three of the most critical factors to consider are: choice of processor, amount of memory, and selection of storage.

Processors For production environments, you must use a X64-bit processor. These include Intel processors that support Intel Extended Memory 64 Technology, or AMD processors that support AMD64. Extensive testing on dual-core processors shows that Exchange Server benefits significantly when using multi-core processor technology, with four cores being optimal. The performance benefit for Exchange Server from dual-core technology depends upon the specific processor.

Memory Having enough memory is critical to ensure the best performance for Unified Messaging. The minimum memory requirement for Unified Messaging is 4 gigabytes (GB), which is 2 GB per core with a minimum of 4 GB total. Having more than 8 GB is not shown to improve overall performance. You should also review the physical memory specifications for the physical server, to verify the type and size of memory modules.

Hard Drive Requirements for Storage To install Exchange Server 2010, you need at least 1.2 GB on the installation hard drive, plus an additional 500 MB for each Unified Messaging language pack you install. Another consideration is the duration of recorded messages in Unified Messaging. By default, there is a 20 minute maximum recording duration. You can modify this setting to anywhere between 5 and 100 minutes. Using the WMA codec, a 5 minute voice mail is approximately 250 KB in size. You must also consider the number of voice-enabled users, and the size of their mailboxes to help determine hard drive space. Users who receive large numbers of voice mails may quickly fill their mailboxes if mailbox quotas are implemented.


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.

A-20


•

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 limit the 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 this timeout 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 to communicate 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.

A-22


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

A-24


Unified Messaging Mailbox Policy Object

Key Points UM mailbox policies are created in the Configuration container in AD DS by using the Exchange Management Shell or the Exchange Management Console. By default, a single UM mailbox policy is created every time you create a UM dial plan.

Using UM Mailbox Policies You can use UM mailbox policies to set Unified Messaging user settings, such as: •

Personal Identification Number (PIN) policies

•

Dialing restrictions

•

Other general UM mailbox policy properties

For example, you can create a UM mailbox policy for a specific group of Unified Messaging-enabled users—such as executives—to increase the level of PIN security by reducing the maximum number of logon failures before a user is locked out.

Planning UM Mailbox Policies Planning ideas for UM Mailbox policies include: •

Creating additional UM mailbox policies based on the needs of your organization.

•

Requiring a single UM mailbox policy to enable users for Unified Messaging.

•

Creating additional UM mailbox policies, and applying a common set of mailbox policy settings for other groups of users.


•

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

A-26


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 email messages 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 Internetcapable 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 a mobile 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 2010 Clients 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 Premium client—such as the voice mail configuration options—are not available in Outlook Web App Light.

A-28


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 gateway with an IP address, from which a Unified Messaging server can receive calls. The Unified Messaging server requires this information to connect to the VoIP gateway and the PBX.

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

Describe the Lync Server 2010 features.

•

Describe how Unified Messaging integrates with Lync Server 2010.

•

Plan for Unified Messaging and Lync Server 2010 integration.

A-30


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

A-32


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


Integrating Exchange Server 2010 Unified Messaging with Lync Server 2010

If you want to integrate Exchange Unified Messaging with Lync Server 2010, you must perform the tasks described in this section. This topic assumes that you have deployed Lync Server 2010 with a collocated Mediation server and that you have enabled users for Lync Server 2010, but that you have not necessarily performed all deployment and configuration steps to enable Enterprise Voice.

Step 1: Create and Configure a New Exchange UM SIP Dial Plan On the Exchange UM server, create a SIP dial plan based on your organization’s specific deployment requirements, and then associate the UM servers and users with the appropriate SIP dial plan. To perform this task, you must have Exchange Organization Administrator permissions.

Step 2: Configure Security Settings for the Exchange UM SIP Dial Plan To encrypt Enterprise Voice traffic, configure the security settings on the Exchange UM SIP dial plan as SIP Secured or Secured. This is an especially important step if you have deployed or plan to deploy Lync 2010 Phone Edition devices in your environment. For Lync 2010 Phone Edition devices to function in an environment with Exchange Unified Messaging integration, Lync Server 2010 encryption settings must align with the Exchange Unified Messaging dial plan security settings.

Step 3: Add UM Servers to the Exchange UM SIP Dial Plan To enable a newly installed UM server to answer and process incoming calls, you must add the UM server to a UM dial plan. In this case, add the server to the Exchange UM SIP dial plan.

Step 4: Configure Mailboxes with SIP Addresses Assign SIP addresses to the mailboxes of Enterprise Voice users who will be using Exchange Unified Messaging features.

A-34


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-level Enterprise 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® Exchange Server 2010 Deployment

Lab: Introduction to Designing an Exchange Server 2010 Deployment Exercise 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. A. Datum Current Network Infrastructure Analysis Document Reference Number: JC310110/1 Document Author Date


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

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) A. Datum Current Network Infrastructure Analysis 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 Reference Number: JC310110/2 Document Author Date


Exchange Server Configuration Server name

Exchange version and SP level

Server role

Location

LON-MSG-FE1


Front-end server

London

LON-MSG-BH1


Front-end server

London

LON-MSG-BE1


Back-end server

London

LON-MSG-BE2


Back-end server

London

LON-MSG-BE3


Back-end server

London

LON-MSG-BE4


Back-end server

London

LON-MSG-BE5


Back-end server

London

LON-MSG-BE6


Back-end server

London


(continued) A Datum Current Messaging Infrastructure Analysis Exchange Server Configuration Exchange version and SP level

Server name

Server role

Location

LON-MSG-PF1


Public Folder server

London

VAN-MSG-FE1


Front-end server

Vancouver

VAN-MSG-BH1


Front-end server

Vancouver

VAN-MSG-BE1


Back-end server

Vancouver

VAN-MSG-BE2


Back-end server

Vancouver

VAN-MSG-BE3


Back-end server

Vancouver

VAN-MSG-PF1



Vancouver

TOK-MSG-FE1


Front-end server

Vancouver

TOK-MSG-BH1


Front-end server

Vancouver

TOK-MSG-BE1


Back-end server

Vancouver

TOK-MSG-BE2


Back-end server

Vancouver

TOK-MSG-BE3


Back-end server

Vancouver

TOK-MSG-PF1



Vancouver

Additional notes

Exchange Organization information Configuration

Settings

Administrative groups

LondonAG, VancouverAG, TokyoAG, RoutingGroupAG

Administrator groups

LondonExAdmins, VancouverExAdmins, TokyoExAdmins, EnterpriseExAdmins

Routing groups

LondonRG, VancouverRG, TokyoRG

SMTP namespaces

Adatum.com, TreyResearch.net

Additional notes

L1-3


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 questions Discuss as a group. You will incorporate your answers in to the requirements documentation. 1.

2.

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

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


L1-5

•

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 You will complete these sections as a group. •

Complete the relevant section of the following document. A Datum Project Requirements Analysis Document Reference Number: JC310110/3 Document Author Date


Summary of business requirements This section provides a summary of the information collected during the business requirements analysis task. It is important to clearly define the needs that must be addressed so that the organization 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 any time. • The messaging solution must be able to enforce compliance requirements. • Need to provide access to the mailbox servers for more messaging clients, including clients with more functionality than POP3 and mobile clients. Summary of functional requirements This section lists the functional requirements identified during the requirements analysis task. The functional requirements define how the proposed technology will address the project’s business requirements. 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 with partner 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, or features 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 You will complete these sections as a group. •

Discuss the following questions: 1.

2.

What components will you need to include in the Exchange Server 2010 deployment to meet the 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.

What components will you need to include in the Exchange Server 2010 deployment to meet the 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.


L1-7

Exercise 3: Discussion: Real-World Best Practices for Setting Budget Expectations  Task: Answer the following questions 1.

What information is required to set the preliminary budget? Answer: Answers include:

2.

•

Project vision and scope

•

Business requirements (What business problems is this project expected to solve?)

•

Functional requirements

•

Project constraints

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 sponsor with 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 Reference Number: JC310110/4 Document Author Date


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 and receive 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?


L1-9

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


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:

5.

•

User name: Administrator

•

Password: Pa$$w0rd

•

Domain: Contoso

Repeat steps 2 to 4 for virtual machines 10233B-NYC-SVR1.

L1-10

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

L2-11

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

Lab: Designing Exchange Server Integration with the Current Infrastructure Exercise 1: Evaluating the Current Network Infrastructure at Contoso  Task 1: Review the supplied documentation •

Review the diagram and read the supporting documentation.

 Task 2: Answer questions relating to the documentation Note Your instructor may choose to perform this lab as a group discussion rather than an individual activity. 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 •

Complete the following proposal document by answering the questions. Contoso Exchange Server network infrastructure Document Reference Number: JC110210/1 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 to support Exchange Server 2010. Contoso Exchange Server network infrastructure 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 from their home computers? Answer: You may need to configure split DNS to ensure host names are resolved the appropriate internal 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 Sender Policy 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 must use 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 could use Outlook Web App to ensure that the bandwidth of the connection to the head office is not excessively 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 inbound and 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 Mailbox server, then there is no need to provide a Client Access server there. For high availability, consider deploying at least two Client Access servers per site.


L2-13

(continued) Contoso Exchange Server network infrastructure 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 Mailbox server, 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 to be able to perform limited recipient management tasks. To which built-in role group should you assign these branch administrators? Answer: They should be assigned to the Help Desk role group. Note


Results: After this exercise, you should have completed the Contoso Exchange Server network infrastructure report.

L2-14


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 IP address for the Local Area Connection is 10.10.10.10.

3.

At the command prompt, type Ping NYC-DC1.contoso.com. Verify that you have network connectivity with the domain controller.

4.

At the command prompt, type Nslookup, and then press Enter.

5.

At the command prompt, type set type=all, and then press Enter.

6.

At the command prompt, type _ ldap._tcp.dc._msdcs.Contoso.com, and then press Enter. Verify that an SRV record is returned.

7.

Close the command prompt.


L2-15

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

L2-16


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


L2-17

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.

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


2.

Right-click 10233B-NYC-DC1 in the Virtual Machines list, and then click Revert.

3.


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

6.


7.


8.


L2-18


L3-19

Module 3: Planning and Deploying Mailbox Services

Lab: Planning and Deploying Mailbox Services Exercise 1: Designing the Mailbox Server Deployment  Task 1: Review the A. Datum Corporation documentation •


Server Design Interviews

•

Server Design Statistics



Question: In the Server Design Interviews, what points are raised that impact your Mailbox server deployment plan, and how do they impact it? 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


 Task 3: Perform high level planning for Mailbox server storage in London •

Complete the following proposal document by answering the questions. A. Datum high level planning for mailbox servers in London Document Reference Number: JC040400/1 Document Author Date


Requirement Overview 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 for mailbox databases? Answer: There will be 9,000 users with a 500 MB mailbox and a personal archive of 1 GB. There will be 3,000 users with a 1 GB mailbox and a 2 GB personal archive. The total storage space potentially required is 22.5 terabytes (TB). The initial deployment will not require this much space because user mailboxes will not all be at their 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 mailbox data. 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 a performance 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 RPM SAS disks should be used. The 7200 RPM SAS disks are close to the same price as SATA drives but are more reliable. You do not need disks with a higher RPM because Exchange Server 2010 has lower 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 for transaction logs. Recovery is performed by using an alternate copy of the database rather than by restoring and then replaying transaction logs. In most cases, circular logging is used and there is no option to replay transaction logs.


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

L3-22


•

•

•

•

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

•


•


•


•


•


•


•



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

•


•


•


•


•


•


•


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


•

•

•

•

3.

•

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

Log off of VAN-CL1.

 Task 5: Update the A. Datum Large Mailbox server design document •

Complete the following proposal document by answering the questions. A. Datum Large Mailbox server design Document Reference Number: JC040400/2 Document Author Date


Requirement Overview Determine the hardware configuration for large Mailbox servers that use DAS. Additional Information 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.

L3-23

L3-24


(continued) A. Datum Large Mailbox server design 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 that hold 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

Note



L3-25

Exercise 2: Designing Recipient Management  Task 1: Review the A. Datum Corporation documentation •


Recipient Management Interviews

 Task 2: Answer questions relating to the documentation Note


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.


Complete the following proposal document by answering the questions. A. Datum recipient management configuration Document Reference Number: JC040400/3 Document Author Date


Requirement Overview 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) or recipients with the Company defined in Active Directory® Domain Services. • The second e-mail address policy will have a condition that matches only Trey Research recipients. Each policy will be configured with both domains. The e-mail address policy for A. Datum Corporation will use adatum.com as the Reply To address. The e-mail address policy for Trey Research will use TreyResearch.net as the Reply To address.

L3-26


(continued) A. Datum recipient management configuration 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 group has management permissions for the recipients in the entire Exchange Server organization. New Recipient Management role groups should be created for each physical location. These role groups will be scoped to limit management permissions to manage recipients only within a specific OU 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 inpolicy and out-of-policy settings for each meeting room. A delegate for each meeting room will be configured 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 membership management. 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 Trey Research? Answer: Create separate address lists for each organization and then distribute the appropriate address lists by using address book policies. The appropriate address book policy must be associated with each user. To simplify this you must have an identifying attribute that can be queried when performing the assignment. You should also have an identifying attribute that can be queried when specifying GAL members. Note



L3-27

Exercise 3: Designing a Public Folder Deployment  Task 1: Review the A. Datum Corporation documentation •


Public Folder Interviews

•

Server Design Interview

 Task 2: Answer questions relating to the documentation Note


Question: In the Public Folder Interviews, what points are raised that impact your public folder 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: •

The Executives want a new public folder for private communication that is available quickly from any location, 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 deployment plan, and how do they impact it? 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.

L3-28



Complete the following proposal document by answering the questions. A. Datum public folder configuration Document Reference Number: JC040400/4 Document Author Date


Requirement Overview 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 folder should be created. This public folder should be replicated to all locations in the organization for fast access 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. This will 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 searches and offline address books must be available in all locations. This requires that you create at least one public folder database in each physical location. Public folder databases will not exist in each physical location by default.

Note



L3-29

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

L3-30


22. On the Schedule page, click Next to apply all changes immediately. 23. On the New Address List page, click New. 24. On the Completion page, click Finish. 25. Click Start, point to All Programs, click Microsoft Exchange Server 2010, and then click Exchange Management Shell. 26. In the Exchange Management Shell, type the following command, and then press ENTER. New-GlobalAddressList TreyGAL –RecipientContainer “ou=Trey,dc=adatum,dc=com”

27. In the Exchange Management Shell, type the following command, and then press ENTER. New-OfflineAddressBook TreyOAB –AddressLists TreyGAL

28. In the Exchange Management Console, click New Address Book Policy. 29. In the New Address Book Policy wizard, in the Name box, type TreyABP. 30. Beside the Global address list box, click Browse, click TreyGAL, and click OK. 31. Beside the Offline address list box, click Browse, click TreyOAB, and click OK. 32. Beside the Room list box, click Browse, click Trey Rooms, and click OK. 33. Under Address lists, click Add, click Trey Users, and click OK. 34. Click New. 35. On the Completion page, click Finish. 36. Close the Exchange Management Console. 37. In the Exchange Management Shell, type the following command, and then press ENTER. Get-Mailbox –OrganizationalUnit Trey | Set-Mailbox –AddressBookPolicy TreyABP

38. Close the Exchange Management Shell. 39. On NYC-CL1, log on as Adatum\Wei with the password Pa$$w0rd. 40. Click Start, point to All Programs, click Microsoft Office, and click Microsoft Outlook 2010. 41. In the Microsoft Outlook 2010 Startup wizard, click Next three times to configure Outlook. 42. Click Finish to close the wizard. 43. In the User Name window, click OK. 44. In the Welcome to Microsoft Office 2010 window, click Don’t make changes and then click OK. 45. On the Home tab, click Address Book. 46. Notice that the Global Address List does not have any content because the OAB has not been generated yet. 47. Select the Trey Users address book and verify that Wei is the only user listed. 48. Close all open windows and log off of VAN-CL1.


L3-31

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

L3-32


8.

9.

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

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.


L3-33

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



2.


3.


4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-CL1. Close the virtual machine connection windows

5.


6.


7.


8.


L3-34


L4-35

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

Lab: Planning and Deploying Client Access Services in Exchange Server 2010 Exercise 1: Designing the Client Access Server Deployment  Task 1: Review the A. Datum documentation •


Server Design Interview Notes.doc

•

Requirements Interview Notes.doc

•


•


•


 Task 2: Answer questions related to the documentation Question: In the Server Design Interview Notes document, what points are raised that impact your Client Access server deployment plan, and why? Answer: •

A single server or component failure cannot be the cause of messaging system unavailability. Multiple Client Access servers must be deployed in each site that has a deployed Mailbox server.

•

Microsoft® Office Outlook® 2003 is still in use throughout the organization. Public folders are required to support free/busy schedule information and offline address book distribution.

Question: In the Requirements Interview Notes document, what points are raised that impact your Client Access server deployment plan, and why? •

Answer:

•

The sales team requires anywhere access to their email, most likely by using their cell phones. Microsoft Exchange ActiveSync® addresses this need.

•

Various examples cite unavailable messaging and subsequent business losses because of this unavailability. High availability is important.

•

The requirements allow unencrypted traffic into the perimeter network from the Internet, but not into the corporate network. The inner firewalls block unencrypted network traffic. When planning Client Access protocols, consider using Secure Sockets Layer (SSL) to secure traffic.

Question: In the AD DS and Routing Interview Notes document, what points are raised that impact your Client Access server deployment plan, and why? Answer: •

There is currently widespread use of Outlook Web App in Exchange Server 2003, so ensure that Outlook Web App makes a positive impact on users.

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.vsd diagram 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.vsd diagram 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 •

Complete the following proposal document by answering the questions. A Datum Client Access Server Deployment Plan Document Reference Number: JC040410/1 Document Author Date


Requirement Overview Determine the number and placement of Client Access servers within the existing network infrastructure. Additional Information Identify infrastructure changes that may be required due to the proposed deployment. Proposals Question: With reference to the Adatum_CurrentADSiteDesign diagram, how many Client Access servers do you propose to deploy in each site? Answer: Deploy at least two in each site to address the high availability concerns raised in the documentation. Question: Do you have sufficient information from the documents reviewed so far, to determine whether some sites require additional Client Access servers? Answer: No. You also need information about the number of users connecting to the Client Access servers. This information is provided in a supplemental document that you will review in the next exercise. 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.


L4-37

(continued) A Datum Client Access Server Deployment Plan Question: Is it clear from the documentation that you have reviewed which sites support which client types? Answer: No. Additional information is supplied in the A. Datum User Distribution Summary document that you will review in the next exercise. Question: While maintaining compliance with the requirements mentioned in the documentation, can you propose changes to the client types that will simplify the configuration? Answer: Answers will vary, but might include: • Upgrading the Office Outlook 2003 clients to Outlook 2010 would mean that Public folders are no longer required. Additionally, this would mean that free/busy information would be provided to users more quickly. • Replacing POP3 clients with another client type would simply firewall configuration. By using 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/or proxying (depending on the client type) to enable clients to connect to the appropriate Client Access server in other sites. With this approach, you only need to configure one namespace, which simplifies certificate deployment. However, not all client types support redirection and proxying. For example, POP3 clients do not support redirection and proxying. • Deploy Internet-facing Client Access servers in each site, and provide users with the necessary URLs for the servers in the site that hosts their mailboxes. This means you must obtain a certificate for each Client Access server, or else use a certificate that supports multiple 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 Directory site. This server connection point is the fully qualified domain name (FQDN) of the server that hosts the role and is used by domain-joined computers to locate the Autodiscover service. Domaindisjoined computers use Domain Name System (DNS) to locate the Autodiscover service. Consider modifying both these values (the server connector point and the DNS records) to match. Note


Results: After this exercise, you should have completed the A. Datum Client Access server deployment plan document.

L4-38


Exercise 2: Designing Client Access  Task 1: Review the A. Datum documentation •

Review the contents of the following documents: •

Policy Requirements.doc

•

A Datum User Distribution Summary.doc

 Task 2: Answer questions relating to the documentation 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.


L4-39

 Task 3: Update the A. Datum Client Access server configuration document •

Complete the following proposal document by answering the questions. A. Datum Client Access Server Configuration Document Reference Number: JC040410/2 Document Author Date


Requirement Overview Determine the feature configuration for Client Access servers in the A Datum Exchange Server 2010 upgrade. Proposals Question: Based on the information in the A. Datum User Distribution Summary document, do you envisage deploying additional Client Access servers in any sites? Answer: Answers will vary. However, London, Toronto, and Tokyo have large numbers of users. Two Client Access servers are probably insufficient to support timely connections to user mailboxes and features. Question: Which features must you enable on the Client Access servers to support the current client-types? Answer: Enable MAPI, Exchange ActiveSync, POP3/SMTP, Outlook Web App, and Outlook Anywhere. Question: Which client protocols must you enable through the firewalls? Answer: Enable HTTPS, POP3, and SMTP. Question: What would you do to address the security concerns raised regarding mobile clients? Answer: Configure the following settings in Exchange ActiveSync: At the organizational level, configure two Exchange ActiveSync Mailbox policies, one for Managers and Executives, and one for everyone else. Configure both with the following security settings:  Require passwords  Require minimum password length of 6  Require encryption on storage card  Require encryption on device  Disallow simple password  Restrict number of failed attempts to 5 To support attachment downloads for executives and managers only, in Sync Settings, configure the Allow attachments to be downloaded to device only for the Managers and Executives policy. Use Exchange Management Shell to assign the appropriate Exchange ActiveSync Mailbox policy to the appropriate users.

L4-40


(continued) A. Datum Client Access Server Configuration 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 the Internet. For example, to support Exchange ActiveSync, configure the external URL value on servers 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 the Hub Transport server role, and then publish using a reverse proxy such as a Microsoft Internet Security and Acceleration (ISA) Server.  Configure the required authentication settings on all services. For example, Outlook Web App uses forms-based authentication by default.  Obtain and install the required certificates to enable SSL. Question: While maintaining compliance with the requirements mentioned in the documentation, can you propose changes to the client types that will simplify the configuration? Answer: Aside from those mentioned already, you should migrate Office Outlook users that implement a connection over a VPN to Outlook Anywhere. This avoids the need for VPNs. Note


Results: After this exercise, you should have completed the A. Datum Client Access server configuration document.


L4-41

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 Server Configuration, 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 failed attempts 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.

L4-42


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.


L4-43

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


2.


3.


4.

Repeat these steps for 10233B-VAN-EX1, and 10233B-VAN-EX2. Close the virtual machine connection windows.

5.


6.


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.

L4-44


L5-45

Module 5: Planning and Deploying Message Transport in Microsoft® Exchange Server 2010

Lab: Planning and Deploying Message Transport in Exchange Server 2010 Exercise 1: Designing a Message Routing Topology  Task 1: Review the A. Datum Corporation documentation •



•


•

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: •


•


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


L5-46

Module 5: Planning and Deploying Message Transport in Microsoft Exchange Server 2010


Results: After this exercise, you should have successfully modified the A. Datum AD DS site design.


L5-47

Exercise 2: Designing a Messaging Perimeter  Task 1: Review the A. Datum Corporation documentation •



•


•

Adatum_Info.vsd

 Task 2: Modify the A. Datum current perimeter design diagram with proposed changes to the site design 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. Note


L5-48



Results: After this exercise, you should have successfully designed the A. Datum messaging perimeter.


L5-49

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 LondonSiteVancouverSite-SanDiegoSite connection.

•

The LondonSite to ChennaiSite connection must have a higher cost than the LondonSiteTokyoSite-ChennaiSite connection.

•

The VancouverSite to TokyoSite connection must have a higher cost than the VancouverSiteLondonSite-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 in the 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 between the 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

L5-50


•

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.


L5-51

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 Organization Configuration, 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. Question: Is Default-First-Site-Name a hub site? 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.

L5-52


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

7.


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



3.

L5-53

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. Question: Is Default-First-Site-Name a hub site? 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:

9.

•

Contoso Connector

•

EdgeSync – Default-First-Site-Name to Internet

•

EdgeSync – Inbound to Default-First-Site-Name.

Click the Address Spaces tab.

L5-54


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.



2.


3.


4.

Repeat these steps for 10233B-VAN-EX1, 10233B-VAN-EX2, and 10233B-VAN-EDG. Close the virtual machine connection windows.

5.


6.


7.


8.


L6-55

Module 6: Planning and Deploying Messaging Security

Lab: Planning and Deploying Messaging Security Exercise 1: Designing Message Security  Task 1: Review the A. Datum documentation •

Review the contents of the 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 section of the following document. In the document, provide: •


•




Message Security Components Component type


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 sent to the Internet. Send a response to users indicating they are not allowed to send messages with 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 being sent to any user not on the Strategic Acquisitions team.

L6-56


(continued) A. Datum Proposed Security Policies Message Security Components Component type


SMTP Send and Receive 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 receive email from Contoso, Ltd. Configure a Receive connector that will accept connections only from the Contoso SMTP server’s IP address. Configure a Send connector that will use the Contoso’s SMTP servers as a smart host. Configure an address space on the SMTP Send connector of Contoso.com. Configure inbound and outbound Domain Security.

SMTP Send and Receive connectors

Configure a Receive connector that will accept connections only from the Brussels law firm’s SMTP server’s IP address. Configure a Send connector that will use the law firm’s SMTP server as a smart host. Configure an address space on the SMTP Send connector that matches the domain name of the law firm. Configure the security on the Send and Receive connector as externally secured.

S/MIME configuration for Office Outlook

Install an Enterprise certification authority (CA) on a Windows Server® 2008. Configure the CA as a subordinate server to a commercial CA by obtaining a subordinate CA certificate. Configure an Active Directory® Group Policy object that will assign a certificate 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

Note





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.

L6-57

L6-58


Exercise 2: Designing Antivirus and Anti-Spam Solutions  Task 1: Review the A. Datum Corporation documentation •

Review the contents of the Virus and Spam Filtering Requirements in the Security Requirements.doc.

 Task 2: Modify the A. Datum Proposed Security Policies document with a proposed antivirus and anti-spam solution •

Complete both the Anti-Spam and Antivirus Solution Components section of the following document. In the document, provide: •


•




Anti-Spam Solution Components Component type


Anti-spam software

Must be installed on each Edge Transport server that will accept incoming email from the Internet.

IP Allow List provider

Configure the IP Allow List setting on the Edge Transport server to use the IP Allow List provider.

IP Block List provider

Configure the IP Block List setting on the Edge Transport server to use the IP Block List providers.

SMTP connectors

The messages from Contoso, Ltd will not be scanned for spam, because the messages are Domain Secured. The messages from the law firm will not be scanned for spam, because the messages will be treated as authenticated.

Content filter and quarantine mailbox

In order to implement content filtering, but still ensure that not too many false 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, enable Sender ID filtering. Configure the filter to mark all messages that do not pass the Sender ID filter. Most of these messages will then be filtered by the content filter.

Safelist aggregation

Implement edge synchronization between the Edge Transport server and the Active Directory sites where inbound messages will be allowed. Then implement safelist aggregation for all user mailboxes in the organization.

Blocked recipient lists

Add the SMTP addresses for all distribution lists with more than 200 members to the blocked recipients list on the Edge Transport servers. Note: You can also configure the distribution list properties to accept messages from only authenticated users.


L6-59

(continued) A. Datum Proposed Security Policies Antivirus Solution Components Component type


Antivirus software

Must be installed on each Edge Transport server that will accept incoming email from the Internet, and on each Hub Transport server in the organization.

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 not scan 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 Transport servers daily, and to update the antivirus files on the Edge Transport servers every six hours. On the Hub Transport servers, configure an alert if the files have not been updated for two days. On the Edge Transport servers, configure an alert if the files have not been updated for 12 hours.

Additional notes

Note




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 antispam solutions. Results: After this exercise, you should have successfully designed an antivirus and anti-spam strategy for A Datum.

L6-60


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.


L6-61

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

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.


User name: Scott

•

Password: Pa$$w0rd

•

Domain: Adatum

2.

Click Start, in the Search box, type mmc, and then press Enter.

3.


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.


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.

L6-62


 Task 7: Verify the presence of the certificate for Marcel 1.


User name: Marcel

•

Password: Pa$$w0rd

•

Domain: Adatum

2.

Click Start, in the Search box, type mmc, and then press Enter.

3.


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.


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

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.


L6-63

 Task 10: Verify receipt of the secured message 1.


User name: Scott

•

Password: Pa$$w0rd

•

Domain: Adatum

2.


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.


On the host computer, start Hyper-V™ Manager.

2.


3.


4.

Repeat these steps for 10233B-VAN-EX1 and 10233B-VAN-CL1. Close the virtual machine connection windows.

5.


6.


7.


L6-64


L7-65

Module 7: Planning and Deploying Messaging Compliance

Lab: Planning and Deploying Messaging Compliance Exercise 1: Planning a Message Transport Implementation  Task 1: Review the A. Datum documentation •

Review the points related to message transport in the Exercise 1 scenario.

 Task 2: Document the required configuration for message transport •

Complete the following proposal document by answering the questions. A. Datum Message Transport Plan Document Reference Number: JC040417/1 Document Author Date


Requirement Overview 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 a disclaimer 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 Sales group. The third transport rule applies to Internet-delivered messages with the Company Internal classification, and blocks these messages. The fourth transport rule applies to messages classified as Acquisitions Confidential. Exchange Server blocks these messages if they are addressed to anyone other than the Strategic Acquisitions team. 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. Note


Results: After this exercise, you should have created a message transport plan.

L7-66


Exercise 2: Planning a Message Journaling and Archiving Solution  Task 1: Review the A. Datum documentation •





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 •

Complete the following proposal document by answering the questions. A. Datum Journaling and Archiving Plan Document Reference Number: JC040417/2 Document Author Date


Requirement Overview 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 new PST files, and you should provide them with instructions about how to move the content from PST files to personal archives. Question: How can users access personal archives? Does this affect which users will receive personal archives usage? Answer: Users can access personal archives by using the Microsoft® Office Outlook® 2010 messaging client, Office Outlook 2007, or Microsoft Outlook Web App. You may want to enable personal archives only after users upgrade to a version of Outlook that supports personal archives.


L7-67

(continued) A. Datum Journaling and Archiving Plan 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 messages sent to this group. Question: How can you prevent users from deleting messages? Answer: Enable mailboxes with litigation holds to prevent the mailbox owners from deleting messages. Question: Can auditors prevent users from deleting messages? Answer: Yes. You can assign auditors to the Legal Hold management role. The auditors can then enable a litigation hold on a mailbox-by-mailbox basis. Note


Results: After this exercise, you should have created a journaling and archiving plan.

L7-68


Exercise 3: Planning a Messaging Records Management Implementation  Task 1: Review the A. Datum documentation •





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 •

Complete the following proposal document by answering the questions. A. Datum Messaging Records Management Plan Document Reference Number: JC040417/3 Document Author Date


Requirement Overview 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 using them. 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. Note


Results: After this exercise, you should have created an MRM plan.


L7-69

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

4.

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

L7-70


20. On the Actions page, click Next. 21. On the Exceptions page, click Next. 22. On the Create Rule page, click New. 23. On the Completion page, click Finish.

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

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

L7-71

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

L7-72


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. On the Completion page, click Finish.

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


3.



L7-73

4.


5.


6.


7.


8.


9.


L7-74


L8-75

Module 8: Planning and Deploying High Availability

Lab: Planning and Deploying High Availability Exercise 1: Designing High Availability for Exchange Servers  Task 1: Review the A. Datum Corporation documentation •


High Availability Interviews

•

User Distribution Summary

•




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


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.


Complete the following proposal document by answering the questions. A. Datum High Availability Design for San Diego Document Reference Number: JC040422/1 Document Author Date


Requirement Overview Determine how high availability will be provided for all server roles in San Diego. Additional Information Identify infrastructure changes that may be required due to the proposed deployment. Proposals Question: Will this site have offsite disaster recovery? If so, where should that site be located? Answer: No, this is a small site with only 500 users. Offsite disaster recovery is not part of the requirements. Question: How do you provide high availability for databases? Answer: Provide high availability by creating a DAG. Question: How do you provide high availability for Client Access servers? Answer: Provide high availability by creating a client access array. Question: How do you provide high availability for message transport? Answer: Provide high availability by installing a second Hub Transport server. Question: Is high availability required for the Edge Transport server role? Answer: Yes, outgoing mail is routed through a local Edge Transport server. To make it highly available, there should be two Edge Transport servers in the San Diego site.


L8-77

(continued) A. Datum High Availability Design for San Diego Question: How many Exchange servers will be located in this site? Which roles will they host? Answer: There will be four servers, and in the perimeter network there will be two Edge Transport servers. On the internal network, there will be two Exchange servers. Each Exchange server on the internal network will have the Mailbox, Hub Transport, and Client Access server roles. Question: How will databases be configured on the DAG members? Answer: Half of the active databases will be located on each server, with passive copies on the other server. Even though a single server has the capacity to support all mailboxes, splitting the load may improve performance. Each passive database copy will be configured with a 6-hour replay lag to prevent logical corruption of both databases. Question: How will load balancing be performed for the Client Access server role? 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.


Complete the following proposal document by answering the questions. A. Datum High Availability Design for Vancouver Document Reference Number: JC040422/2 Document Author Date


Requirement Overview Determine how high availability will be provided for all server roles in Vancouver. Additional Information Identify infrastructure changes that may be required due to the proposed deployment. Proposals Question: Will this site have offsite disaster recovery? If so, where should that site be located? 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 North America. The San Diego site can be used for offsite disaster recovery. Network links to San Diego from Vancouver may need to be improved with increased bandwidth for communication. Question: How do you provide high availability for databases? Answer: Provide high availability by creating a DAG, which will include a server in San Diego for offsite disaster recovery.

L8-78


(continued) A. Datum High Availability Design for Vancouver Question: How do you provide high availability for Client Access servers? Answer: Provide high availability by creating a client access array in Vancouver. The client access array in San Diego can be used when offsite disaster recovery is performed. Question: How do you provide high availability for message transport? Answer: Provide high availability by installing a second Hub Transport server in Vancouver. The Hub Transport servers in San Diego will be used when offsite disaster recovery is performed. Question: Is high availability required for the Edge Transport server role? Answer: Yes, incoming and outgoing mail is routed through a local Edge Transport server. To make it highly available, there should be two Edge Transport servers in the San Diego site. Question: How many Exchange servers will be located in this site? Which roles will they host? 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 transport within the site and between sites. • Three dedicated Client Access servers in a client access array. This ensures that even if a Client Access server fails, there is sufficient capacity to support all users. • Three mailbox servers in Vancouver, and two additional Mailbox servers in San Diego. To support the 6,000 users in Vancouver, two Mailbox servers are required. To provide high availability in Vancouver, a third server is required. To provide site resilience, two Mailbox servers are located in San Diego. Question: How will databases be configured on the DAG members? Answer: One third of the active databases will be located on each server, with passive copies on another local server, and on a server in San Diego. Evenly spreading the load in Vancouver can increase performance. In San Diego, two servers provide sufficient capacity to host all mailboxes, if required. Each passive database copy in San Diego will be configured with a 6-hour replay lag to prevent logical corruption of the databases. Logical corruption is a very rare event. So, there will be no replay lag for passive database copies in Vancouver. Question: How will load balancing be performed for the Client Access server role? Answer: The Client Access server role is not combined with the Mailbox server role. Therefore, NLB can be used. It is also possible to use hardware load balancing, if desired.

Note



L8-79

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.


2.


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. This does not indicate a problem. The necessary permissions were configured in Task 1.

8.


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.

L8-80


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, VANEX2, and VAN-EX3, and then click OK. 19. In the Manage Database Availability Group Membership window, click Manage. 20. On the Completion page, click Finish.

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

6.


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. 11. On the Completion page, click Finish. 12. Click Start, point to All Programs, click Microsoft Exchange Server 2010, and then click Exchange 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”


L8-81

 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. Question: What is the status for Mailbox Database 1 on each server? 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 is selected 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. Question: What is the status for Mailbox Database 1 on each server? Answer: The status for Mailbox Database 1 on each server is as follows:

5.

•

VAN-EX1: Healthy

•

VAN-EX2: Mounted

•

VAN-EX3: Healthy

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.

L8-82




2.


3.


4.


5.


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.


8.


L9-83

Module 9: Planning a Disaster Recovery Solution

Lab: Planning a Disaster Recovery Solution Exercise 1: Planning Disaster Recovery for Vancouver  Task 1: Review the A. Datum documentation •

In the Exercise 1 scenario, review the Disaster Recovery SLA Notes.

 Task 2: Answer questions related to the documentation 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.

•


•



Complete the following proposal document by answering the questions. A. Datum Disaster Recovery Plan for Vancouver Document Reference Number: JC040430/1 Document Author Date


Requirement Overview 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 back up a database availability group (DAG) with three copies, including site resilience. A three-member DAG meets the requirement for no data loss when a single server fails. It also meets the requirement for only minutes of downtime. Question: Do you need to make any changes to the DAG to meet the SLA requirements? Answer: Yes. The database copies in San Diego have only a 6-hour replay lag. The SLA specifies that to use a DAG as a replacement for backup, you must have at least a 12-hour replay lag. A longer replay lag provides more time to discover a corruption, and to stop the replay process.

L9-84


(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 you must 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 harddeleted messages for the full 30 days. Question: Are any changes required for deleted mailbox retention? Answer: Yes. The default retention time for deleted mailboxes is 30 days. The SLA specifies that you must 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 to document your configuration changes. If a Client Access server fails, you can replace it with a new one, and then make the required configuration changes. You can copy customized webpages from a 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 Transport server, reuse the same computer account to retain the configuration by installing in Recovery mode. 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 from the remaining server, and then import it to the new server. However, to speed up this process, you could 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 folders were being used only to support free/busy searches and offline address book downloads for Microsoft® Office Outlook® 2003 clients, then a backup is not required. You can regenerate that data. If the public folders are used for collaboration between users, then they do need to be backed up, because public folder databases are not replicated in a DAG.

Note


Results: After this exercise, you should have created a disaster recovery plan for the Vancouver site.


L9-85

Exercise 2: Planning Disaster Recovery for San Diego  Task 1: Review the A. Datum documentation •



 Task 2: Answer questions related to the documentation 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.

•


•


•

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.

L9-86



Complete the following proposal document by answering the questions. A. Datum Disaster Recovery Plan for San Diego Document Reference Number: JC040430/1 Document Author Date


Requirement Overview 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 the backup 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-based backup solution—such as Microsoft System Center Data Protection Manager—then each backup will finish very quickly. To meet the archive requirements, you must back up to tape once a week for offsite storage. Question: Do you need to make any changes to the DAG to meet the SLA requirements? Answer: No, this DAG does not require replay as part of the SLA, because a backup is being performed. 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 deleteditem retention must be increased to retain messages for 30 days. Also, you should enable singleinstance recovery on the Mailbox servers. This ensures that you can recover even hard-deleted messages for 30 days. Question: Are any changes required for deleted mailbox retention? Answer: Yes. The default retention time for deleted mailboxes is 30 days. The SLA specifies that you must 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 basic messaging functionality. Next, you can restore historical data to a recovery database, and merge the 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. Note


Results: After this exercise, you should have created a disaster recovery plan for the San Diego site.


L9-87

Exercise 3: Implementing Single-Item Recovery  Task 1: Enable single-item recovery for a mailbox 1.


2.


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.


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

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

L9-88


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 Search Mailbox, 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].


L9-89

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.


3.

In the Exchange Management Shell, type the following command, and then press ENTER: Search-Mailbox “Discovery Search Mailbox” –SearchQuery ‘Subject:“SIR”’ –TargetMailbox Luca –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.



2.


3.


4.


5.


6.


7.


8.



L9-90


L10-91

Module 10: Planning Microsoft® Exchange Server 2010 Monitoring and Troubleshooting

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

•


•


•


•


•

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.

L10-92 Module 10: Planning Microsoft Exchange Server 2010 Monitoring and Troubleshooting

 Task 2: Configure Load Generator with suitable values to simulate the required load 1.

Switch to the VAN-DC1 computer.

2.

Click Start, point to All Programs, click Microsoft Exchange, and then click Exchange Load Generator 2010.

3.

In Microsoft Exchange Load Generator 2010, click Start a new test.

4.

Click Create a new test configuration, and then click Continue. Note

Do not configure the Define the length of a ‘simulation day’ value.

5.

On the Specify test settings page, under Define the total length of the simulation, in the Hours box, type 0.

6.

In the Minutes box, type 10.

7.

In the Directory Access Password box, type Pa$$w0rd.

8.

In the Mailbox Account Master Password box, type Pa$$w0rd, and then click Continue with recipient management.

9.


10. Click Continue. 11. On the Advanced recipient settings page, select the following check boxes: •


•


•


•


•

Use contacts

12. In the Number of contacts box, type 20 and then click Continue. 13. On the Specify test user groups page, click the PLUS SIGN (+). 14. In the resulting item, in the Client Type list, click Outlook 2007 Online. 15. On the Specify test user groups page, click the PLUS SIGN (+) sign. 16. In the resulting item, in the Client Type list, click Outlook 2007 Cached, and in the Action Profile list, click Heavy. 17. Click Continue, and on the Remote configurations page, click Continue. 18. On the Configuration summary page, click Save the configuration file as. 19. In the Save As dialog box, in the File name box, type Baseline, and then click Save. 20. In the Configuration Saved dialog box, click OK. 21. Click Skip initialization phase and run the simulation immediately. 22. Switch to the VAN-EX1 computer.


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.


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

Counter

MSExchangeIS

RPC Requests

MSExchangeIS

User Count


Local delivery rate


Messages Delivered/sec


Messages Queued For Submission


Messages Sent/sec




Retry Remote Delivery Queue Length


Submission Queue Length


(continued) Performance object

Counter


Messages Received/sec


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 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 Queue Length MSExchangeTransport Queues - Retry Remote Delivery Queue Length MSExchangeTransport Queues - Submission Queue Length

Average


(continued) Counter

Average

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? Answer: No. Results: After this exercise, you should have created an Exchange Server performance baseline.

L10-95


Exercise 2: Measuring the Production System Performance under Additional 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.


7.

Click Continue.

8.

On the Advanced recipient settings page, select the following check boxes.

9.

•


•


•


•

Create one per server

•


•

Use contacts

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.


L10-97

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.


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

Average


(continued) Counter

Average

Processor - % Processor Time Server - Pool Nonpaged Failures Server - Work Item Shortages System - Processor Queue Length 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.



2.


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 Exchange Server 2010 Exercise 1: Designing an Exchange Server 2010 Upgrade Strategy  Task 1: Review the A. Datum documentation •



•


•


•

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 Reference Number: JC060610/1 Document Author Date


Requirement Overview 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 reasonable timeline for completing this migration? Answer: Answers will vary. Because this upgrade does not require any client reconfigurations for users, the organization could pursue a fairly aggressive timeline. Estimates for completing the upgrade 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. As a best practice, you should disable schema replication on the Schema Master while performing the upgrade. After the upgrade is successfully completed, you can re-enable replication. In a large organization, allow enough time for the schema upgrade to replicate to all domain controllers before you prepare the domains.

L11-100

Module 11: Upgrading to Microsoft Exchange Server 2010

(continued) A. Datum Upgrade Design 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 the schema 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 Server administrators are likely located in London, as well as the central team of administrators who have permission throughout the organization. London is also the site with the most users and the frontend 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 provide coexistence 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 migration process. If only a single location has coexistence, it is easy to configure message routing with a single routing group connector. If time constraints dictate that multiple locations must have coexistence, 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 use the external name of mail.adatum.com, which is currently used by the load-balanced front-end servers for Exchange Server 2003. A new legacy.adatum.com name will be configured for the loadbalanced front-end servers. The Exchange Server 2010 Client Access servers will be configured with the legacy URL for the Exchange Server 2003 front-end servers. All users will initially connect to mail.adatum.com. Outlook Web Access users with Exchange Server 2003 mailboxes will be redirected to the Exchange Server 2003 front-end servers. The Exchange Server 2010 Client Access server will proxy connections for ActiveSync users. The Exchange Server 2010 Client Access server will communicate directly with Exchange Server 2003 computers 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 Exchange Server 2010 and the London routing group. This will allow messages to be delivered between Exchange 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 as all of the Exchange Server 2010 infrastructure is in place in London. Live mailbox moves are not supported from Exchange Server 2003 to Exchange Server 2010. So, you will need to move mailboxes outside of standard business hours or arrange for downtime to move mailboxes.

Lab: Upgrading to Microsoft Exchange Server 2010

11-101

(continued) A. Datum Upgrade Design Question: How will you move Internet message delivery from Exchange Server 2003 to Exchange Server 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 Edge Synchronization, which simplifies the management of Edge Transport servers. After Edge Synchronization is configured, then you can direct incoming messages to the new Edge Transport servers rather than the existing anti-spam appliances. To support outgoing mail directly from Exchange Server 2010 to the Internet, you must create a send connector. Then you must disable outbound mail delivery from Exchange Server 2003 to the Internet. Question: When you begin migrating the second site to Exchange Server 2010, what process will you use? Answer: The same process as was used in London. The Client Access server will be implemented first, and then other server roles. After you verify that message delivery and all services work correctly, you can begin migrating mailboxes in the site. To ensure that message delivery is efficient, you should create an additional routing group connector 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 to Exchange Server 2010. Any Exchange Server 2003 computers that no longer have mailboxes can be uninstalled. 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 remain in place to provide external Outlook Web Access connectivity for all external users with Exchange Server 2003 mailboxes.

Note


Results: After this exercise, you should have completed the A. Datum Upgrade document.

 To prepare for the next module Note No virtual machines are required for the next lab.

L11-102

Module 11: Upgrading to Microsoft Exchange Server 2010

L12-103

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

Lab: Integrating Exchange Server 2010 with Other Messaging Systems Exercise: Designing Exchange Server 2010 Integration with Office 365  Task 1: Document the required configuration for migrating Northwind Traders email to Office 365 •

Complete the following proposal document by answering the questions. A. Datum Corporation and Northwind Traders Integration Plan Document Reference Number: JC040495/1 Document Author Date


Requirement Overview Determine how to how migrate Northwind Traders email to Office 365. Proposals Question: Does this scenario require a hybrid implementation of Office 365? Answer: Yes. For the best interoperability between the on-premises Exchange Server organization for A. Datum and Office 365, you should implement a hybrid scenario. Question: Will inbound routing be to the on-premises Exchange Server organization or to Office 365? Answer: Inbound routing should be through the on-premises Exchange Server organization. This allows the Edge Transport server in London to perform anti-spam and antivirus scanning for all messages. Using Microsoft Forefront® Online Protection for Exchange (FOPE) in Office 365 to scan all messages would be expensive because additional licenses for FOPE would need to be purchased for thousands of A. Datum Corporation users that do not have Office 365 mailboxes. Question: Will outbound routing be centralized or decentralized? Answer: Outbound routing will be centralized through the on-premises Exchange Server organization. This is the only way that the legal disclaimer that includes the company logo can be applied to all outbound messages. Question: How will you configure mail exchanger (MX) resource records? Answer: After the mailboxes are moved, you should direct the MX records for northwindtraders.com to the Edge Transport servers in the A. Datum Corporation data center in London. The MX records for adatum.com are already directed to the Edge Transport server in the A. Datum Corporation data center in London. Question: How will you migrate mailboxes to Office 365? Answer: The only option for migrating mailboxes from a POP3/IMAP messaging system to Office 365 is to use the IMAP migration. This migrates mailbox contents through an Internet message access protocol (IMAP) connection.

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

(continued) A. Datum Corporation and Northwind Traders Integration Plan Question: Will you configure single sign-on? Answer: Yes. There are 800 users at Northwind Traders. That large number of users will generate many help desk calls if they cannot use the same user credentials for email logon as they use internally for AD DS. Question: Do you need to configure a user principal name (UPN) to support single sign-on? Answer: Yes. You need to verify that the UPN for the adatum.com domain is configured to be adatum.com. This matches the email addresses of the users. This should be configured before directory synchronization begins as part of the hybrid deployment. Question: What Active Directory® Federation Services (AD FS) servers do you require to support single sign-on? Answer: To be highly available, there should be two load balanced federation servers and two load balanced federation server proxies. The federation servers can be installed on existing domain controllers because there are fewer than 1,000 users. The federation server proxies can be installed on existing web or proxy servers in the perimeter network. Question: What certificates do you need to support single sign-on? Answer: Single sign-on with AD FS requires two certificates. One SSL certificate is installed on the Default Web Site of the federation servers and federation server proxies. The subject of this certificate needs to be an Internet routable domain name that matches the DNS name configured for load balancing on federation servers and federation server proxies. The subject name also needs to match the DNS name that is configured as the Federation Service name. The federation servers also use a token-signing certificate that is automatically generated. No configuration is required for the token-signing certificate.

Results: After this exercise, you should have created a plan to migrate Northwind Traders email to Office 365.

10233BD-ENU-TrainerHandbook

Recommend Documents