Exam Ref 70-341 Core Solutions of Microsoft Exchange Server 2013 Paul Robichaux Bhargav Shukla PUBLISHED BY Microsoft Press A Division of Microsoft Corporation One Microsoft Way Redmond, Washington 98052-6399 Copyright © 2015 by Bhargav Shakula, Paul Robichaux No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher. Library of Congress Control Number: 2014951861 ISBN: 978-0-7356-9724-9 Printed and bound in the United States of America. First Printing Microsoft Press books are available through booksellers and distributors worldwide. If you need support related to this book, email Microsoft Press Book Support at [email protected] Please tell us what you think of this book at http://aka.ms/tellpress. This book is provided ”as-is” and expresses the author’s views and opinions. The views, opinions and information expressed in this book, including URL and other Internet Web site references, may change without notice. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. “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 marks are property of their respective owners.” Acquisitions Editor: Karen Szall Developmental Editor: Karen Szall Editorial Production: Troy Mott, Ellie Volckhausen Technical Reviewers: Charlie Russel; Technical Review services provided by Content Master, a member of CM Group, Ltd. Copyeditor: Marcia Baker Indexer: Julie Grady Cover: Twist Creative • Seattle Contents at a glance Introductionxiii Preparing for the exam xvii CHAPTER 1 Install, configure, and manage the mailbox role 1 CHAPTER 2 Plan, install, configure, and manage client access CHAPTER 3 Plan, install, configure, and manage transport 181 CHAPTER 4 Design and manage an Exchange infrastructure 271 99 Index323 This page intentionally left blank Contents Introduction xiii Microsoft certifications xiii Acknowledgmentsxiv Free ebooks from Microsoft Press xiv Errata, updates, & book support xiv We want to hear from you xv Stay in touch xv Preparing for the exam Chapter 1 xvii Install, configure, and manage the mailbox role 1 Objective 1.1: Plan the mailbox role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Planning for storage requirements 3 Planning mailbox role capacity and placement 5 Planning for virtualization 8 Designing public folder placement strategy 13 Validating storage by running Jetstress 15 Objective summary 17 Objective review 18 Objective 1.2: Configure and manage the mailbox role . . . . . . . . . . . . . . . 19 Deploying mailbox server roles 19 Creating and configuring Offline Address Book 22 Designing and creating hierarchical address lists 28 Creating and configuring public folders 32 Objective summary 37 Objective review 37 What do you think of this book? We want to hear from you! Microsoft is interested in hearing your feedback so we can continually improve our books and learning resources for you. To participate in a brief online survey, please visit: www.microsoft.com/learning/booksurvey/ v Objective 1.3: Deploy and manage high availability solutions for the mailbox role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Creating and configuring a Database Availability Group 38 Identifying failure domains 41 Managing DAG networks 43 Managing mailbox database copies 44 Objective summary 50 Objective review 51 Objective 1.4: Monitor and troubleshoot the mailbox role. . . . . . . . . . . . . 51 Troubleshooting database replication and replay 52 Troubleshooting database copy activation 53 Troubleshooting mailbox role performance 55 Monitoring database replication 57 Objective summary 59 Objective review 59 Objective 1.5: Develop backup and recovery solutions for the mailbox role and public folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Managing lagged copies 60 Determining the most appropriate backup solution/strategy 62 Performing a dial tone restore 64 Performing item-level recovery 66 Recovering the public folder hierarchy 68 Recovering a mailbox server role 69 Objective summary 70 Objective review 71 Objective 1.6: Create and configure mail-enabled objects. . . . . . . . . . . . . 72 vi Contents Configuring resource mailboxes and scheduling 72 Configuring team mailboxes 76 Configuring distribution lists 77 Configuring moderation 78 Configuring a linked mailbox 79 Objective summary 80 Objective review 81 Objective 1.7: Manage mail-enabled object permissions. . . . . . . . . . . . . . 82 Configuring mailbox permissions 82 Setting up room mailbox delegates 83 Setting up auto-mapping 85 Objective summary 86 Objective review 86 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Chapter 2 Objective 1.1: Thought experiment 88 Objective 1.1: Review 88 Objective 1.2: Thought experiment 89 Objective 1.2: Review 90 Objective 1.3: Thought experiment 91 Objective 1.3: Review 91 Objective 1.4: Thought experiment 92 Objective 1.4: Review 92 Objective 1.5: Thought experiment 93 Objective 1.5: Review 94 Objective 1.6: Thought experiment 95 Objective 1.6: Review 95 Objective 1.7: Thought experiment 96 Objective 1.7: Review 96 Plan, install, configure, and manage client access 99 Objective 2.1: Plan, deploy, and manage a Client Access Server (CAS). . . 101 Designing to account for differences between legacy CAS and Exchange 2013 CAS 101 Configuring Office Web Apps server 105 Objective summary 109 Objective review 109 Objective 2.2: Plan and configure namespaces and client services. . . . . 110 Designing namespaces for client connectivity 111 Configuring URLs 115 Planning for certificates 118 Configuring authentication methods 122 Objective summary 124 Objective review 125 Contents vii Objective 2.3: Deploy and manage mobility solutions . . . . . . . . . . . . . . . 125 Deploying Mobile OWA 126 Configuring OWA policies 127 Configuring Exchange ActiveSync Policies 133 Mobile device mailbox policies 134 Configuring allow/block/quarantine policies 136 Deploying and manage Office Apps 146 Objective summary 151 Objective review 152 Objective 2.4: Implement load balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Configuring namespace load balancing 153 Configuring Session Initiation Protocol (SIP) load balancing 158 Configuring Windows Network Load Balancing (WNLB) 158 Objective summary 162 Objective review 162 Objective 2.5: Troubleshoot client connectivity . . . . . . . . . . . . . . . . . . . . . 163 Troubleshooting Outlook Anywhere connectivity 163 Troubleshooting POP/IMAP 167 Troubleshooting web services 169 Troubleshooting mobile devices 170 Objective summary 171 Objective review 172 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 viii Contents Objective 2.1: Thought experiment 173 Objective 2.1: Review 173 Objective 2.2: Thought experiment 174 Objective 2.2: Review 175 Objective 2.3: Thought experiment 176 Objective 2.3: Review 176 Objective 2.4: Thought experiment 177 Objective 2.4: Review 177 Objective 2.5: Thought experiment 178 Objective 2.5: Review 179 Chapter 3 Plan, install, configure, and manage transport 181 Objective 3.1: Plan a high availability solution for common scenarios. . . 183 Understanding transport high availability and message routing 184 Planning for shadow redundancy 186 Planning for Safety Net 189 Planning for redundant MX records 191 Objective summary 192 Objective review 192 Objective 3.2: Design a transport solution. . . . . . . . . . . . . . . . . . . . . . . . . . 193 Design inter-site mail flow 193 Design inter-org mail flow 195 Plan for Domain Secure and TLS 204 Design message hygiene solutions 205 Design Edge Transport 207 Design shared namespace scenarios 211 Objective summary 213 Objective review 214 Objective 3.3: Configure and manage transport. . . . . . . . . . . . . . . . . . . . . 215 Configuring Edge servers 216 Configuring Send and Receive connectors 218 Configuring transport rules 227 Configuring accepted domains 229 Configuring email policies 231 Configuring address rewriting 235 Objective summary 236 Objective review 237 Objective 3.4: Troubleshoot and monitor transport. . . . . . . . . . . . . . . . . . 239 Predicting mail flow 239 Interpreting message tracking and protocol logs 240 Troubleshooting SMTP message flow 246 Troubleshooting Domain Secure and TLS 250 Troubleshooting shared namespaces 250 Objective summary 251 Objective review 252 Contents ix Objective 3.5: Configure and manage hygiene. . . . . . . . . . . . . . . . . . . . . . 253 Managing connection filtering 254 Managing content filtering 255 Managing recipient filtering 258 Managing Sender ID 259 Managing anti-malware 259 Managing attachment filtering 261 Objective summary 262 Objective review 263 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Objective 3.1: Thought experiment 264 Objective 3.1: Review 264 Objective 3.2: Thought experiment 265 Objective 3.2: Review 265 Objective 3.3: Thought experiment 266 Objective 3.3: Review 267 Objective 3.4: Thought experiment 268 Objective 3.4: Review 268 Objective 3.5: Thought experiment 269 Objective 3.5: Review 269 Chapter 4 Design and manage an Exchange infrastructure 271 Objective 4.1: Plan for impact of Exchange on Active Directory services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Planning Active Directory deployment 272 Determining DNS changes required for Exchange 274 Preparing Active Directory for Exchange 279 Objective summary 283 Objective review 284 Objective 4.2: Administer Exchange workload management. . . . . . . . . . 285 x Contents Workload management explained 285 Monitoring system and user workload events 286 Managing workload throttling settings 288 Objective summary 292 Objective review 292 Objective 4.3: Plan and manage role based access control. . . . . . . . . . . . 293 Determine appropriate RBAC roles and cmdlets 294 Limit administration using existing role groups 295 Evaluate differences between RBAC and Active Directory split permissions 299 Configure a custom-scoped role group 303 Objective summary 307 Objective review 308 Objective 4.4: Design an appropriate Exchange solution for a given SLA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Plan for change management and updates 309 Design a solution that meets SLA requirements around scheduled downtime 311 Design a solution that meets SLA requirements around Recovery Point Objective/Recovery Time Objective 313 Design a solution that meets SLA requirements around message delivery 314 Objective summary 315 Objective review 315 Answers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Objective 4.1: Thought experiment 317 Objective 4.1: Review 317 Objective 4.2: Thought experiment 318 Objective 4.2: Review 318 Objective 4.3: Thought experiment 319 Objective 4.3: Review 320 Objective 4.4: Thought experiment 321 Objective 4.4: Review 321 What do you think of this book? We want to hear from you! Microsoft is interested in hearing your feedback so we can continually improve our books and learning resources for you. To participate in a brief online survey, please visit: www.microsoft.com/learning/booksurvey/ Contents xi This page intentionally left blank Introduction T his book is written for IT Professionals who want to earn MCSE: Messaging certification. This certification includes four exams: ■■ 70-341 Core Solutions of Microsoft Exchange Server 2013 ■■ 70-342 Advanced Solutions of Microsoft Exchange Server 2013 ■■ 70-346 Managing Office 365 Identities and Requirements ■■ 70-347 Enabling Office 365 Services Exam 70-341, the focus of this book, is intended for IT Professionals who have experience managing Exchange Server 2013 environment. This book covers all four exam domains and all related objectives for each domain. The domains and objectives measure the core knowledge needed to administer an Exchange Server 2013 infrastructure. While the book covers details of each exam domain and objective, it does not intend to teach its readers Exchange Server 2013 from scratch. The book assumes that the reader is an experienced Exchange 2013 administrator who is looking to enhance their understanding of Exchange Server 2013 and prepare for exam 70-341. This book covers every exam objective, but it does not cover every exam question. Only the Microsoft exam team has access to the exam questions themselves and Microsoft regularly adds new questions to the exam, making it impossible to cover specific questions. You should consider this book a supplement to your relevant real-world experience and other study materials. If you encounter a topic in this book that you do not feel completely comfortable with, use the links you’ll find in text to find more information and take the time to research and study the topic. Great information is available on MSDN, TechNet, and in blogs and forums. Microsoft certifications Microsoft certifications distinguish you by proving your command of a broad set of skills and experience with current Microsoft products and technologies. The exams and corresponding certifications are developed to validate your mastery of critical competencies as you design and develop, or implement and support, solutions with Microsoft products and technologies both on-premises and in the cloud. Certification brings a variety of benefits to the individual and to employers and organizations. Introduction xiii MORE INFO ALL MICROSOFT CERTIFICATIONS For information about Microsoft certifications, including a full list of available certifications, go to http://www.microsoft.com/learning/en/us/certification/cert-default.aspx. Acknowledgments Bhargav Shukla As any author can attest, turning their knowledge and writing into a published book is never a task a single person can take on. I’d like to start with my sincere thanks to Karen Szall and team at Microsoft Press who kept us honest, provided valuable guidelines, constant feedback and important edits that can turn our technical mumblings into something a bit more consumable for the readers. I’d also like to thank my mentors and friends who have never ceased to amaze me with their deep knowledge of Exchange server. Over past 20 years, I have only learnt more every day. I could never be an Exchange expert without their help and willingness to share. Huge thanks to all of you who I have learnt from over the years! And for my ability to write this book, it took some determination and commitment. Nights, weekends and holidays were a blur and spending time with me was luxury at times for my family. Without their support, understanding and encouragement, I could have never finished writing this book on time! My sincere thanks to them! Paul Robichaux All the books I’ve worked on during my career have shared similarities, but each one is unique too. I share Bhargav’s appreciation for the large number of people who have mentored and taught me over the years. Karen Szall ably guided the Microsoft Press team into taking our text and turning it into a polished finished product, and we benefited greatly from the expert technical review of Microsoft certification guru Charlie Russel. Free ebooks from Microsoft Press From technical overviews to in-depth information on special topics, the free ebooks from Microsoft Press cover a wide range of topics. These ebooks are available in PDF, EPUB, and Mobi for Kindle formats, ready for you to download at: http://aka.ms/mspressfree Check back often to see what is new! xiv Introduction Errata, updates, & book support We’ve made every effort to ensure the accuracy of this book and its companion content. You can access updates to this book—in the form of a list of submitted errata and their related corrections—at: http://aka.ms/ER341/errata If you discover an error that is not already listed, please submit it to us at the same page. If you need additional support, email Microsoft Press Book Support at [email protected] Please note that product support for Microsoft software and hardware is not offered through the previous addresses. For help with Microsoft software or hardware, go to http://support.microsoft.com. We want to hear from you At Microsoft Press, your satisfaction is our top priority, and your feedback our most valuable asset. Please tell us what you think of this book at: http://aka.ms/tellpress The survey is short, and we read every one of your comments and ideas. Thanks in advance for your input! Stay in touch Let’s keep the conversation going! We’re on Twitter: http://twitter.com/MicrosoftPress. Introduction xv This page intentionally left blank Preparing for the exam Microsoft certification exams are a great way to build your resume and let the world know about your level of expertise. Certification exams validate your on-the-job experience and product knowledge. Although there is no substitute for on-the-job experience, preparation through study and hands-on practice can help you prepare for the exam. We recommend that you augment your exam preparation plan by using a combination of available study materials and courses. For example, you might use the Exam ref and another study guide for your ”at home” preparation, and take a Microsoft Official Curriculum course for the classroom experience. Choose the combination that you think works best for you. Note that this Exam Ref is based on publicly available information about the exam and the author’s experience. To safeguard the integrity of the exam, authors do not have access to the live exam. Introduction xvii This page intentionally left blank CHAPTER 1 Install, configure, and manage the mailbox role T he mailbox server role in Exchange 2013 hosts mailbox databases and other items, such as Client Access protocols, Transport service and Unified Messaging. All processing of a specific mailbox takes place on the Mailbox server hosting an active copy of the mailbox. Client connectivity is handled I M P O R TA N T by the Client Access role, which can be co-located on the same server. But it only proxies the connections to Have you read Mailbox server components for further processing and page xvii? rendering of the mailbox data being requested. It contains valuable information regarding The Mailbox role is also expanded in Exchange the skills you need to 2013 to include Public Folders. Public Folders do not pass the exam. use dedicated public folder databases and are now stored in specially designed mailboxes store both public folder hierarchy and public folder content. This allows for public folders to take advantage of the existing high availability and storage technologies in use by mailbox databases. With Exchange 2013, there is higher focus on service availability, easier management, and reduced costs. To achieve such goals, managed availability is introduced to provide internal monitoring. The internal monitoring of components is aimed at preventing failures, proactively restoring services, and initiating server failovers automatically or alerting administrators to take action. Automation, coupled with managed availability, is driven by the focus on measuring quality and the continuous availability of service to end users, instead of focusing on the uptime of individual components. Simplification and automation have also been integrated in other database functions. When using JBOD configuration to achieve cost efficiency, disk failures in previous versions meant manual intervention to maintain healthy copies of mailbox databases. Automatic reseed functionality allows for automatic database reseeding on a spare disk on the same server. Failures affecting resiliency or redundancy, such as long I/O times or excessive memory consumption by replication processes, are addressed by automatically rebooting the server. While this might sound like a drastic measure, it doesn’t affect service availability because the assumption is that redundancy is provided using Database Availability Groups (DAGs) and other high availability features provided by Exchange 2013. The network configuration of DAGs has also been simplified by automatically configuring DAG networks. DAGs can also distinguish between the Messaging Application Programming 1 Interface (MAPI) and Replication networks, configuring them automatically. This greatly simplifies the setup, thus protecting against errors when configuring DAG networks manually. NOTE MANUAL VS. AUTOMATIC CONFIGURATION OF DAG NETWORKS While Exchange 2013 functionality makes setup easier by configuring DAG networks automatically, in complex networks you might need to configure DAG networks manually. You might also need to troubleshoot DAG networks if errors are encountered and if replication or MAPI traffic is affected. It is important for you to pay attention to cmdlets and parameters that enable you to configure DAG networks manually. Objectives in this chapter: ■■ Objective 1.1: Plan the mailbox role ■■ Objective 1.2: Configure and manage the mailbox role ■■ Objective 1.3: Deploy and manage high availability solutions for the mailbox role ■■ Objective 1.4: Monitor and troubleshoot the mailbox role ■■ Objective 1.5: Develop backup and recovery solutions for the mailbox role and public folders ■■ Objective 1.6: Create and configure mail-enabled objects ■■ Objective 1.7: Manage mail-enabled object permissions Objective 1.1: Plan the mailbox role Deploying the mailbox role requires the careful planning of mailbox role components. Despite advancements in storage technologies and improved I/O characteristics, it’s detrimental to deploy mailbox storage without considering storage characteristics, such as disk latency. Capacity planning is also just as important. With 16 terabytes as the supported maximum database size, it could be tempting to maximize database size with larger Serial ATA (SATA) disks. When considering such extremes, it’s important to consider other dependencies, such as time to reseed after a disk failure, time to restore from backups when multiple copies of the database are neither deployed nor available, the ability to meet recovery time objectives in case of an outage or a disaster, and so on. This objective covers how to: 2 ■■ Plan for storage requirements ■■ Plan mailbox role capacity and placement ■■ Plan for virtualization ■■ Design public folder placement strategy ■■ Validate storage by running Jetstress Chapter 1 Install, configure, and manage the mailbox role Planning for storage requirements Exchange 2013 supports multiple storage architectures and physical disk types. Each feature offers different performance characteristics and has its benefits. Direct attached storage, for example, has no dependency on an external data network used by Internet Small Computer System Interface (iSCSI) or a dedicated storage network used by Fibre-Channel storage. Similarly, Solid State Disk (SSD) drives offer fast data transfers at a cost of much smaller storage capacities per drive. In general, Exchange 2013 is designed to achieve efficiencies by reducing costs, and the goal is achieved by shifting balance in code, reducing I/O footprint, and optimizing reads and writes, so multiple databases can be placed on the same physical drive. Using bigger SATA drives allows for such efficiencies to materialize. Anyone with a few years of experience deploying Microsoft Exchange environments can attest that no single solution meets customer requirements, since every customer is unique and so are their design requirements. The Microsoft guidance on Exchange 2013 storage design aims to address most common configurations by providing best practices guidance. For example, single copy databases may be best protected by using a redundant array of independent disks (RAID) configuration, while JBOD might provide best efficiencies when at least three copies of a database exist in a DAG. EXAM TIP It is important for you to be able to differentiate which configuration serves a proposed design the best. It is also important to understand the caveats spelled out in exam questions such as, "What is the supported configuration that is most cost effective?" Sometimes the requirements might seem to conflict, but paying close attention to details will help identify possible answers and rule out distractors. When configuring disks, it is important for you to understand how to create a supported layout. When configuring disk sector size, you must pay attention to nuances such as a 512-byte sector that is supported on Exchange 2013, while 4 kilobyte sector disks aren’t supported on any version of Microsoft Exchange server. EXAM TIP If a question in the exam has a possibility of producing a different answer based on a different version of Exchange server (that is, RTM vs SP1), exam questions will clearly spell out which version of Exchange Server is applicable for a given question. The placement of database and related files is another important consideration for a Mailbox server. Best practices suggest that the operating system, and the pagefile should be a RAID-protected volume separate from any Exchange data logical unit numbers (LUNs).The placement of the database and log files is also an important consideration. If you’re deploying a stand-alone mailbox database and protecting it with traditional backup systems, whether to separate database and log files on their own separate volumes depends on the backup Objective 1.1: Plan the mailbox role Chapter 1 3 methodology in use. Placing database and log files on the same volume is supported. Best practices, however, suggest that database files and log files should be located on separate volumes backed by separate physical discs in stand-alone configurations. When multiple copies of a database are deployed in a DAG configuration, the requirement changes to a single database and a log per volume. When determining the disk size, the size of the database being hosted becomes one of many factors to consider. You’ll find that the Exchange Role Requirements Calculator accounts for other items, such as impact of content index, which now equals roughly 20 percent of the size of the database file. An additional requirement for space is used by the master merge process. You can benefit from a reduction in space required for the master merge if you choose to place multiple databases per volume. No restriction exists on the placement of an active copy of a database or on the same volume as a replica of a different database. While considering all of these factors for a database or a set of databases that are going to reside on a given disk, it not only becomes important to stay within supportability guidance, but you must also stay within the design requirements laid out for a given environment. Factors such as the time required to recover a database in case of a disaster, can affect your ability to benefit from large supported database sizes. The best practice guidance from Microsoft also differentiates between stand-alone database configurations and a database protected by multiple copies in a DAG. For example, the recommendation is not to exceed 200 gigabytes for a database if it’s in a stand-alone configuration. But if you plan to setup multiple copies for a database, best practices accommodates up to 2 terabytes for any given database. EXAM TIP Pay attention to exam questions that differentiate between supported vs. best practices recommendations. Microsoft documents both scenarios clearly, and, for a given configuration, the difference between the supported configuration and best practices can be significant. The transaction logs required to recover from a catastrophe also differ from one configuration to another. A stand-alone database configuration protected by traditional backups requires backups to protect transaction logs. Using circular logging doesn’t provide the capability to revert to a given point in time before data loss. In contrast, if multiple copies of a database are deployed in a DAG configuration, circular logging is the recommended best practice in the light of complementary functionality, such as lagged copy and single item recovery. Depending on how you choose to truncate logs has a direct impact on how much disk space you need to allocate for a given configuration. Other important considerations for disk configuration are: partition type GUID Partition Table (GPT) vs. Master Boot Record (MBR), volume type (simple vs. dynamic), and File System—easy to remember because only the NTFS file system is supported for compression—which isn’t supported for Exchange database and log files. The other two features relate to the security of data on the disk. How should you secure database and log files from prying eyes in a highly secure environment? Two possibilities are Encrypting File System (EFS) and BitLocker. EFS isn’t supported for Exchange database and log files, while BitLocker is fully supported. The last feature to 4 Chapter 1 Install, configure, and manage the mailbox role consider is file share support. NFS file systems are unsupported and shouldn’t be deployed to host database and log files. The Server Message Block (SMB) 3.0, introduced with Windows Server 2012, is supported only when configured in a virtualized environment. This configuration assumes SMB 3.0 file share is presented to a hypervisor host and a VHD disk is created on a given SMB volume. The VHD disk is attached to a virtualized Exchange server, and the disk is presented as block storage. It isn’t supported to present the SMB 3.0 share directly to an Exchange server, and host database and log files on it. Planning mailbox role capacity and placement Planning for the capacity of a mailbox role involves the consideration of a number of factors. These factors include the understanding of an existing messaging deployment if the planned deployment is a migration from a previous version, the understanding of user messaging profiles, and the desired mailbox size. The other factors to consider are desired resiliency and disaster recovery objectives, compliance and data retention requirements, data recovery objectives, Service Level Agreements (SLAs), organizational growth plans, and the use of thirdparty applications. All of these factors help you determine the number of servers, server hardware utilization, server placement, and environmental dependencies, such as domain controller configuration and placement. REAL WORLD DOMAIN CONTROLLER PLACEMENT When planning for an Exchange deployment, I learned that the customer environment consisted of an empty domain root and two child domains: Domain A and Domain B. Users of both domains were hosted on Exchange servers located in Domain A. Typically, you deploy a set of domain controllers in the same Active Directory site as Exchange servers for a given Active Directory domain, which is Domain A in this example. However, in this case, we needed to account for additional domain controllers to contain the Global Catalog of users from Domain B to provide the best possible user experience and resiliency. Without such a configuration, any time a user from Domain B logged in to their mailboxes, the Exchange servers would have to reach out to domain controllers located in a different site that belonged to Domain B and was connected through WAN links. As you’ll notice, the centralized Exchange server design had an impact on hardware and software requirements for the additional domain controllers. The user profile is one of the most important factors when determining compute resources required by a mailbox server. A software development firm with a staff of developers and support professionals located in a different geographic region might depend more heavily on an email system than a company developing locomotives where design professionals might frequently communicate via email, while production and factory workers might need limited access to emails. How many emails are sent on average by a given user category is as important Objective 1.1: Plan the mailbox role Chapter 1 5 as how big an average email is for any given category. This helps you determine processing, storage, and network resources required by a given mailbox server. Determining a user profile when migrating from an earlier version of Exchange server is relatively easy, because you can use Exchange Profile Analyzer if you’re migrating from Exchange 2007. You can leverage performance counters if you’re migrating from Exchange 2010 to obtain detailed per-user statistics. Another important factor is mailbox database size. How big of a mailbox is desired for a given user profile? Each job profile may have different capacity requirements. Compliance requirements can change these requirements drastically, however, challenging your storage requirements assumptions. REAL WORLD IMPACT OF LEGAL HOLD ON MAILBOX STORAGE SIZING An organization had strict mailbox size requirements, deploying the smallest possible number of mailboxes for any given job profile. Storage design accounted for storage overhead for content indexing, as well as 20 percent free space for buffering. They had a requirement that when any person is involved in a legal action, the mailbox must be placed on indefinite legal hold and all data must be retained in the mailbox including deletions. The legal hold was removed from the mailbox only when legal action had concluded and the legal requirements no longer applied to the mailbox. This requirement meant a design consideration for a mailbox server with additional storage to accommodate for additional data when a mailbox is placed on legal hold and a business-process automation script. This script automatically moved mailboxes on legal hold from their mailbox server to a server designated for litigation; this server contained other similar mailboxes and had the additional storage required for such mailboxes. Another important consideration in mailbox server design is high availability and site resiliency requirements. For example, you might be required to provide all users with uninterrupted mailbox access despite the failure of a single mailbox server. This requirement means accounting for additional mailbox servers hosting mailbox database copies of all users. You also have to reduce the usable capacity of a given server to account for failover capacity. In a two server configuration, this could mean up to 50 percent of capacity needs to be reserved to help mailbox failovers. Similarly, in a three mailbox server configuration with each server hosting active mailboxes, the minimum reserved capacity can be as much as 33 percent. If a requirement dictates that all mailboxes must be available in case of disaster at the primary site where all active mailboxes are located, you need to create a DAG that spans multiple sites, and place a mailbox server containing copies of mailbox databases at a secondary site. This impacts the requirement of additional hardware, an additional datacenter location and space considerations, and network requirements to accommodate database replication traffic. Other requirements include active user traffic in case of a failover, or activation in case of a disaster or outage at the primary site. 6 Chapter 1 Install, configure, and manage the mailbox role What if existing IT standards or procurement contracts with the vendor dictate using specific server hardware profile for mailbox servers? This might mean you need to scale out by deploying more servers if the given hardware profile can’t accommodate all of the planned mailbox resources. Should you migrate or deploy Public Folder databases? This might impact storage capacity planning and the location of mailbox servers in a distributed environment to account for resiliency and user experience. When determining the scale out vs. the scale up model, you need to account for the number of database copies, resiliency requirements, and tolerance to failure domains. In a scale up configuration, you are planning to have more mailboxes per server, which means bigger servers with more processing power and storage capacity, as well as a higher number of mailboxes impacted during failures. The scale-out model requires the same account of total resources divided into smaller chunks, resulting in a larger number of smaller servers deployed to the account for the given environment. This increases the numbers of servers, but reduces the impact on the number of mailboxes affected for given failure. The cost for smaller servers can also provide a cost advantage. Conversely, a larger number of servers in the scale out model also means more management overhead for IT to license, install, monitor, and maintain a higher number of servers. The datacenter footprint is also affected directly by your choice of the scale up vs. the scale out model. No single design can accommodate all of the possible variations and different requirements for an Exchange deployment. This is why every successful Exchange deployment considers each of these unique factors based on the given requirements to select the most effective model for deployment. When designing for storage capacity, the size of the mailboxes is only one of many factors. You need to account for the space required for a mailbox for its given capacity, including the database whitespace, a recoverable items folder size, content indexing, log space (if logs are stored on the same disk as the database), and an additional—usually about 20 percent—buffer, because you can’t fill the disk at 100 percent capacity and expect the system to function with no triggered alerts. Disk I/O is another important consideration. While the Exchange 2013 code improvements have reduced I/O requirements significantly, you still need to account for proper I/O calculations to ensure the given disk not only has sufficient capacity to host the planned number of mailboxes, but also that the I/O for the given disk is sufficient to address all read-and-write requirements for mailbox data and related tasks, such as content indexing. When using external storage such as iSCSI or Fibre-Channel storage, plan for aggregate I/O capacity of each storage channel. When using iSCSI, network bandwidth consideration is crucial. Fibre-Channel SAN is limited by capacity of underlying Fibre-Channel fabric. And, don’t forget transport storage, because transport components are now part of the Mailbox role. Transport capacity planning needs to account for queuing for active emails, shadow queues, and a Safety Net. To account for failures, you have to account for poison queue Objective 1.1: Plan the mailbox role Chapter 1 7 messages, messages queued for delivery to unreachable targets (failed database copy or an inability to reach the Internet destination for outbound messages), and messages stored as part of the Safety Net mechanism for transporting high availability. Planning for memory requirements includes accounting for database cache, which makes up for a significant portion of server memory, content indexing, and other exchange processes that provide vital functions, such as background maintenance, managed availability, and other agents. If you deploy multi-role servers, you must also account for the additional memory required for Front-End server role components also sharing resources on the same server hardware. To perform actual calculations for a given mailbox profile and other factors, Microsoft has documented formulas that can be used if you want to size the mailbox role manually. For more information about those published formulas, see: http://blogs.technet.com/b/exchange/archive/2013/05/06/ask-the-perf-guy-sizingexchange-2013-deployments.aspx. Using the Exchange 2013 role requirements calculator is recommended, in order to avoid errors and calculate for all scenarios based on the provided input. Planning for virtualization In today’s IT environments, it’s difficult to imagine a datacenter with no virtualization in use, no matter at how large or small a scale. Some environments use virtualization for some workloads, and physical servers for another. Then, there are environments that deploy virtualized workloads for nearly anything that can be virtualized! When planning for an Exchange 2013 deployment, you’ll most likely face a question of whether the Exchange 2013 servers can be virtualized. That question has no simple answer. Look at the many variables that affect the decision to virtualize Exchange 2013 servers. Because Exchange 2013 supports virtualizing all server roles, you don’t need to determine whether a given server role is supported when virtualized. Exchange 2013 is supported on any version of Windows Server with Hyper-V technology, or a Hyper-V Server. It’s also fully supported to virtualize Exchange 2013 servers using any third-party hypervisor validated under Windows Server Virtualization Validation Program (SVVP). Some well-known virtualization platforms found on the SVVP validated list include VMware’s vSphere and ESX platforms, Citrix XenServer, and Oracle VM. IMPORTANT MICROSOFT AZURE AND EXCHANGE 2013 While it’s possible to virtualize Exchange 2013 server roles using Microsoft Azure VMs, the deployment of production Exchange servers on Microsoft Azure VMs is not supported. See http://support2.microsoft.com/kb/2721672 for a list of supported server software and roles on Azure VMs. 8 Chapter 1 Install, configure, and manage the mailbox role After determining the supported platform, the design discussions usually turn to features of the given virtualization platform to determine which features can be used in conjunction with Exchange server functionality to get the most out of the technology and platforms features being deployed. The Live Migration of a virtual machine (VM) is a popular feature that every virtualization administrator wants to deploy and know if Exchange supports it. Live Migration enables administrators to move VMs from one hypervisor host to another to achieve better resource utilization and perform scheduled software or hardware maintenance. Exchange 2013 supports such functionality with Microsoft Hyper-V and other hypervisors. The key to being supported when deploying such migration functionality is to ensure that the migration process for a VM doesn’t deploy snapshot-type functionality where a VM is saved to the disk and restored from it. The VM must remain online during the migration process, or the VM must shut down and perform a cold boot. Another popular feature is snapshot functionality. Think of snapshot functionality as a point-in-time backup of your VM. For example, let’s say you’re planning to make significant changes to your environment and want to be able to revert to the current stable configuration in case of a failure. Your virtualization administrator may be happy to point out the ability to take snapshots and revert to them if needed. The virtualization administrator may not know the application specifics and complexities of using snapshots with Exchange. Exchange components, such as log shipping for database replication which are dependent on accurate time keeping and when the snapshot feature is used. The introduced time travel to the time passed by reverting to an older snapshot has undesired and unpleasant side effects. This can help understand why the snapshot feature isn’t supported for use with Exchange VMs. Using snapshots on Exchange VMs has some unexpected and most commonly undesired consequences. In most circumstances, these consequences can’t be undone, leaving you to deal with bigger issues than you bargained for. While they aren’t a variation of the snapshot feature, differencing disks are a similarly interesting feature that promises to reduce disk space usage by creating a master or parent disk that contains common shared data, primarily the VMs operating system. By creating differencing disks, all changes are written to a differencing disk, which has its own issues. Take dependency on the parent disk, for an example. Even an accidental change to the parent disk invalidates the differencing disks that depend upon the parent disk. In the case of a change to the parent disk, you end up with Exchange servers that can’t boot anymore. While data might not be lost, the service to end users is certainly affected, at the very least. As you probably guessed by now, the snapshot feature is not supported with Exchange VMs. Another great feature many modern hypervisors offer is guest replication. This feature replicates VMs to another host, local or remote, to provide the capability to start up replica VM if the hypervisor host with a primary VM copy fails. For Exchange 2013 VMs, the recommendation is to use DAG functionality, as well as other availability and disaster recovery Objective 1.1: Plan the mailbox role Chapter 1 9 features provided by Exchange server. Using hypervisor-based replication functionality with Exchange 2013 isn’t supported. Maximizing resource usage with virtualization is a natural tendency. It often results in the oversubscription of processors, as well as memory overcommit using dynamic memory mechanisms. While modern hypervisors are continuously improving to provide better resource sharing, it cannot protect against intentional overcommit. When you have critical workloads, such as Exchange server roles in a VM, oversubscription usually has negative effects on such workloads. Unexpected behavior of Exchange server services is often observed when resource oversubscription is deployed. REAL WORLD IMPACT OF DYNAMIC MEMORY ON EXCHANGE VM While testing Exchange 2013 features in my lab environment, I was unable to perform the expected functions, and the errors weren’t descriptive enough to determine what the problem was. As I started looking into the issue, I noticed that some of the Exchange services were stopped. After spending many hours troubleshooting the issue, I noticed that default configuration was using dynamic memory when creating the VM. Like most personal labs, my hypervisor host was oversubscribed and, when multiple VMs ramped up resource demand, it started affecting resource availability to VMs. When the Exchange server lost some of its allocated memory, which is an expected behavior when dynamic memory is configured, the services using the memory crashed due to the loss of the resource they were depending on. The issue was fixed by setting the memory on Exchange VM to a static amount, which is a change that requires VM to be shut down and restarted. Exchange 2013 code is optimized to strike a balance between the efficient use of memory and reducing the I/O footprint. To achieve these efficiencies, Exchange relies on a calculated cache for each database being hosted on the server, as well as the memory reserved for Exchange subsystems. When dynamic memory is in use, this can result in incorrect memory calculations and it can cause Exchange to start with less memory than is available. Not surprisingly, Microsoft doesn’t support the use of dynamic memory with Exchange VMs. Processor oversubscription is supported, but the recommended ratio is 1:1, with a supported ratio of 2:1 over the subscription maximum. This means that for every physical processor core on a hypervisor host, no more than two virtual processors should be assigned to VMs running on the given host. This isn’t only limited to Exchange VMs running on the host, but it does include processors assigned to all VMs. Hyperthreading is another advanced feature that can improve performance. An example of hyperthreading, as you can see in Figure 1–1, is when your system detects four logical processors when the system is configured with only one physical socket and two physical cores. 10 Chapter 1 Install, configure, and manage the mailbox role FIGURE 1-1 An example of a system with hyperthreading enabled Hyperthreading is great for managing multiple workloads with the parallel execution of threads, but it isn’t designed to provide you more processing capacity than the system has. For example, the system referred to in Figure 1-1 has a CPU with a maximum speed of 2.4 GHz. The system has one socket, with two CPU cores and four logical processors. How much processing capacity does the system have? 2.4 GHz? 4.8 GHz or 9.6 GHz? The correct answer is 4.8 GHz, because the system has two physical cores, each capable of running at a maximum of 2.4 GHz. Four logical cores is an indication that hyperthreading is enabled on the system. This might allow four parallel threads to execute instead of two, making the system more efficient. But, as discussed earlier, it can’t provide more than 4.8GHz of maximum processing power. When configuring processing capacity for virtualization environment and virtualizing Exchange servers, it’s supported to have hyperthreading enabled on the virtualization host. But, when sizing Exchange servers for your environment, you need to consider the actual processor cores available to the system and not the logical processor count. When considering storage for VMs, the virtualization administrator has many options at their disposal to deploy appropriate storage for given VMs. Options include local storage, DAS, iSCSI storage, Fibre-Channel storage, NFS shares, and, beginning with Windows Server 2012, SMB 3.0 shares. For Exchange VMs to be supported, the disks assigned to Exchange VMs must be a block storage. This means, you can’t map the NFS or SMB share to Exchange VM and store database and log files on it. The disk where Exchange related files are stored must be available to VM as Objective 1.1: Plan the mailbox role Chapter 1 11 a block-level storage disk. These disks must be visible through the disk management console or when you run Diskpart on the Exchange VM. Hypervisors use different virtual disk formats to store data for VMs. These disks can be configured as fixed disks, taking up all of the allocated space on the host volume when they are created. For example, on a 500 GB host volume, a 50 GB fixed disk takes 50 GB of space on a host volume upon creation, leaving 450 GB of free space on the host volume, assuming nothing else is stored on it. This is true even though the disk isn’t initialized by the VM and no data is stored on it yet. Hypervisors also allow the disks to be configured as dynamically expanding disks. Dynamically expanding disks take little space upon creation and only expand in proportion to the actual data being stored on it. So, a dynamically expanding disk may only take 1 MB or less on the host volume upon creation. When the VM stores data on the disk, it expands to accommodate the data being written to it. While this might sound like the most efficient way to use disk space on host volumes, it comes with a performance penalty. When VM needs to store more data to a dynamically expanding disk, hypervisor needs to expand the virtual disk file as the data is being written to it, causing delays in responding to I/O calls from VM. The delays may be small and unnoticeable, or they can amount to noticeable thresholds, depending on the underlying storage architecture and the parallel I/O activity on the same host volume. This can have a detrimental effect on Exchange performance and is undesirable, so Exchange 2013 only supports fixed virtual disks. Where you store these virtual disks it is also important for your deployment of Exchange servers to be supported. Virtualized Exchange 2013 supports virtual disks stored in the following scenarios: ■■ Local or directly attached storage ■■ Fibre-Channel storage presented as block-level volumes to the virtualization host ■■ iSCSI storage presented as block-level storage to the virtualization host ■■ iSCSI storage presented as block-level storage to the Exchange VM ■■ SMB 3.0 share mappe to virtualization host The virtual disks must be fixed virtual disks. When using SMB 3.0 share, it is not supported to map the share to Exchange 2013 VM and store database and log files directly to it. Hypervisors such as VMware also support NFS shares to store virtual disks attached to VMs. But it isn’t supported to store virtual disks attached to an Exchange VM on NFS storage. While this might be a point of contention between Exchange administrators and virtualization administrators, it helps you understand why Exchange doesn’t support such storage. Exchange requires various guarantees, such as Forced Unit Access, Write-Through, Write Ordering, and so on from storage, to maintain data integrity and system reliability. When storage is unable to provide such guarantees, the critical Exchange system and user data are at risk, which isn’t acceptable or desirable to any system administrator supporting such complex systems. NFS storage implementations, historically, haven’t met these guarantees, so it isn’t a supported solution for Exchange deployments. 12 Chapter 1 Install, configure, and manage the mailbox role The sum of all individual components makes up for a fully functioning system, but it doesn’t end there. What if the hypervisor host your Exchange VM is running on fails? The answer might sound as easy as deploying multiple instances of mailbox servers and creating DAG with each database having two or three replicas, providing there’s enough protection from failures. But, it’s just as important to account for all of the possible failure domains. Are your hypervisor hosts configured to have separate failure domains, so a failed router in one rack doesn’t affect a replica of your database? Are they in separate racks? Are they using separate phases of power, so a failure on one power line doesn’t affect all replicas at the same time? Are all disks used for all replicas separated, so single SAN failure doesn’t affect all the replicas of a given database? All these questions lead to one goal: failures are a fact of any IT infrastructure. Failures will happen, so account for all possible failure domains. Determine the cost of deploying a solution that can account for mitigating all possible failure domains, while staying within your design and budget guidelines. Strike the best possible balance to achieve highest possible availability by eliminating ill effects of single failures on your Exchange environment. MORE INFO VIRTUALIZING EXCHANGE 2013 You can find current information and guidance for virtualizing Exchange 2013 here: https://technet.microsoft.com/en-us/library/jj619301. Designing public folder placement strategy In Exchange 2013, public folders were given special treatment. Instead of using dedicated public folder databases in previous versions, public folders are now hosted on regular mailbox databases. By moving public folders to mailbox database, Exchange can now provide better resiliency by leveraging the same DAG architecture that regular mailboxes have enjoyed since Exchange 2010. Public folders still maintain a hierarchy, however, the hierarchy isn’t stored in a public folder mailbox, known as the Primary hierarchy mailbox. Primary Hierarchy Mailbox is the only writable copy of the public folder hierarchy in the entire Exchange organization. An Exchange administrator can create additional public folder mailboxes, and each of these secondary hierarchy mailboxes contains a read-only copy of the public folder hierarchy. Both Primary and Secondary hierarchy mailboxes can contain public folder content. Creating new public folder mailboxes is a function now moved to New-Mailbox cmdlet. When creating a new public folder mailbox, use the PublicFolder parameter. This is different from creating a new public folder. Once a mailbox to host public folders is created, you can create a new public folder by using the New-PublicFolder cmdlet. When you create multiple public folder mailboxes, Exchange server automatically distributes users equally across public folder mailboxes for load-balancing purposes. In large environments, restricting the new public folder from the serving hierarchy is important because when users access a new public folder mailbox, which isn’t excluded from serving hierarchy, they might only see an incomplete public folder structure until the hierarchy synchronization is complete. Use Objective 1.1: Plan the mailbox role Chapter 1 13 the IsExcludedFromServingHeirarchy parameter when creating a new public folder mailbox to exclude it from serving an incomplete hierarchy to its users. When hierarchy synchronization completes, the value of the IsHeirarchyReady parameter on public-folder mailbox properties is set to $true. This helps the administrator determine when an exclusion set on the public folder can be removed. While users can access public folder hierarchy from any public folder mailbox, because only one writeable copy of hierarchy exists, any new public folder creation or deletion request is proxied to the primary hierarchy mailbox. Unlike regular mailboxes, the public folder mailbox is a shared resource accessed by multiple users simultaneously. Activity on a public folder has a direct impact on the server where the public folder mailbox is located. To avoid client connectivity issues, consider having multiple public folder mailboxes in the environment. If a certain public folder in hierarchy is heavily used, create or move the public folder to a dedicated public folder mailbox. Also consider restricting a heavily used public folder mailbox from the serving hierarchy. In a geographically dispersed environment, create public folder databases in the location nearest to the user that access the public folder contents stored in them. This reduces round trips to remote locations that might be connected with slower wide area network (WAN) links and can introduce excessive delays, resulting in a poor Outlook client behavior and user experience. When deploying public folder mailboxes in close proximity to user locations, also consider changing the DefaultPublicFolderMailbox property on user mailboxes, so users can use their closest public folder mailbox to retrieve the public folder hierarchy. When deploying public folders on Exchange 2013 servers, it’s important to understand that because Exchange 2013 servers don’t support legacy public-folder databases, there’s no co-existence. When migrating from Exchange 2010 or Exchange 2007, the recommendation is not to create any modern public folder mailboxes on Exchange 2013 until after all the user mailboxes are migrated to Exchange 2013. Migration from older versions of Exchange server to new public folder mailboxes is a oneway process in the sense that you can roll back to legacy public folders by deleting all public folder mailboxes on Exchange 2013, setting the PublicFolderMigrationComplete parameter to false on a previous version of Exchange server. But, any data changed or added to the new public folder mailboxes doesn’t synchronize with legacy public folders and is lost when public folder mailboxes on Exchange 2013 are deleted during the roll-back process. This is an important consideration during the migration planning process from legacy public folders to new public folder mailboxes on Exchange 2013. With new public-folder mailbox functionality, you can easily move a rapidly growing public folder and its contents to a different public folder mailbox. Because of the separation that can happen from using different mailboxes for different public folders, it becomes complex to account for all of the subfolders that belong to the public folder being moved. If you need to keep the data of all subfolders with the parent public folder being moved, you need to use the Move-PublicFolderBranch.ps1 script, provided with the Exchange 2013 server installation. 14 Chapter 1 Install, configure, and manage the mailbox role With a new mailbox architecture, the public folder mailboxes now automatically inherit the size limits from the mailbox database that they belong to. You must carefully evaluate mailbox sizes, including warning, send, and receive quotas that a public folder mailbox might inherit and change it for a public folder mailbox, if necessary. When changing public-folder mailbox quotas from database defaults, it’s important that the underlying storage has enough capacity to account for those exceptions and additional storage that public folder mailboxes might consume because of non-default quotas configured on them. Because modern public folders are now similar in architecture as mailboxes and use the same underlying mailbox databases, it’s natural to think mechanisms, such as mailbox audit logs that work with regular mailboxes, would also work with public folder mailboxes. But, currently, mailbox audit logs don’t work on public folder mailboxes. This is important when you define goals for meeting auditing requirements for each of the messaging components being deployed. It is also important to distinguish mailbox audit logging from public-folder access permissions auditing. Assigning permissions is an administrative action that moved to role based access control (RBAC) in Exchange 2013. This allows for auditing administrative actions when permissions on public folders are changed. Validating storage by running Jetstress Even though the I/O requirements were significantly reduced in Exchange 2013 when compared to previous versions, performing validation using proper testing tools is still as important to ensure the success of any Exchange 2013 deployment. Jetstress is used to validate all of the hardware and software I/O components, including storage drivers, disk firmware, and many other storage-related components. While Jetstress doesn’t actually verify details, such as whether a particular firmware version is present for a given disk, a successful Jetstress result validates the storage stack that is configured optimally to meet your design requirements. While it might be obvious, it’s important to point out that as any other tool, Jetstress is going to test what it’s asked to test for. If the provided user profile information and other test parameters are incorrect, the passing result might not be an accurate reflection of your production requirements and a failing result might not mean much in reality. The installation of Jetstress is dependent on ESE libraries that are going to be used on production Exchange 2013 server. Also, Jetstress is run before Exchange server is installed on the server to be tested. This means, required ESE libraries must be obtained manually from installation media of Exchange 2013 server version that are going to be used to install Exchange 2013 on a given server. Jetstress should never be run on a server that has Exchange 2013 already installed. When validating storage using Jetstress, all of the factors affecting the given storage should be considered. If shared storage, such as SAN, is planned, all concurrent I/O profiles on shared storage should be tested or simulated to achieve accurate pass/fail results. Testing single LUN on new SAN with no load may pass the test with flying colors, but it doesn’t accurately reflect Objective 1.1: Plan the mailbox role Chapter 1 15 the reality under which the shared storage is performing when in production. If multiple databases are planned to be located on the same volume, the test should account for it. If shared workloads other than exchange are expected to have I/O impact on the same volume, expected I/O from other applications should also be simulated during Jetstress testing. Freely available tools, such as Iometer, can be leveraged to test shared I/O on the volume, if needed. When testing RAID subsystems, accounting for disk failures is also important. When a disk in a RAID array fails, access to the data stored on the array is uninterrupted. Performance of the RAID array is degraded until the failed disk is replaced and rebuild process is complete. Jetstress tests should account for both healthy operation and performance degradation during the rebuild operation. While required storage performance characteristics don’t change when Exchange 2013 servers are virtualized, the factors that can affect storage performance certainly do! Virtualized environments might mean a shared logical unit number (LUN) hosting virtual disks for many VMs. Each VM have its own I/O requirements. During peak usage periods, this can result in concentrated I/O causing degradation in storage performance. When host-based failovers are configured, a failed host might mean additional resource usage on surviving hosts due to additional VMs now running on it. This also requires additional I/O on shared spindles. When testing virtualized Exchange servers for storage system performance with Jetstress, accounting for these additional factors is important. When running Jetstress, how much time you allocate for testing is an important factor to ensure that test results are accurate. The tuning of test parameters might be required before running extended tests, so the recommendation is to run initial short 15-minute tests to determine the number of simultaneous threads an underlying storage system can support. Once the appropriate level of disk latency and IOPs are achieved using tuned parameters in short tests, longer tests should be carried out. Strict mode tests should be carried out for durations from up to six hours, and lenient mode tests should be carried out for durations greater than six hours. The strict mode tests storage for stricter maximum read and write latencies of 100ms. The lenient mode, in contrast, tests the storage against the maximum read and write latency target of 200ms. Before performing any testing, you should also ensure that the test systems are configured optimally for an underlying storage subsystem. Factors such as server BIOS, storage controller firmware and driver levels, and hard disk firmware have a direct impact on the outcome of Jetstress and should be at manufacture-recommended and -supported levels. When SAN- based storage is planned, the same considerations apply to Fibre-Channel HBA drivers, Fibre-Channel switch firmware, and SAN controller operating-system levels. When Jetstress tests result in a failure, it usually means one of two factors. A natural tendency is to look at a storage subsystem and tune or reconfigure it to ensure the tests pass. But it might also be the result of misconfiguration of Jetstress test parameters. Starting with the validation of test parameters and storage driver/firmware levels is the best first step toward remediation. If further tests still fail, this almost always means the storage has failed to meet the test requirements and must be remediated. Putting the solution in production 16 Chapter 1 Install, configure, and manage the mailbox role is detrimental, assuming the failure is of the tool testing the storage, because Jetstress is a simple tool that directly relies on the test parameters and the storage subsystem being tested. For the test to be successful, all three criteria being evaluated must pass. The three criteria are database IOPS target, I/O database read averaged latency, and I/O log write averaged latency. Database I/O target is derived by using IOPS requirements calculated per storage-sizing guidance. Thought experiment Exchange 2013 design considerations In this thought experiment, apply what you have learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter. You are an Exchange administrator for Contoso, Ltd. Contoso doesn’t have a messaging system and plans to deploy Exchange 2013. Contoso currently uses Microsoft Hyper-V as its virtualization platform. The Hyper-V administrator recommends use of dynamic VHDX files located on the SAN volume for virtual machines for Exchange 2013 server roles. The Virtualization administrator states his goal of achieving a consolidation ratio of 100 VMs per virtualization host. The Storage administrator prefers to create large RAID arrays consisting of multiple disks and creates multiple volumes from the existing array as needed. Contoso also plans to deploy public folders for collaboration. Contoso has multiple locations connected with slower WAN links and wants to ensure the best possible user experience when accessing public folder content. 1. What would be your recommendations for virtualization platform configuration to ensure Exchange 2013 deployment is supported? 2. Do you agree with the proposed storage configuration? Do you have any concerns to discuss? 3. How would you plan public folder deployment to address the requirement? Objective summary ■■ ■■ ■■ ■■ Exchange 2013 storage doesn’t require fast disks. Optimal storage design for Exchange 2013 requires striking a careful balance of price, performance, and capacity. Deploying newer functionality can replace traditional practices, such as deploying lagged copies of database along with single item recovery, which can address backup requirements of an organization replacing traditional backups. What Exchange 2013 considers supported configuration may differ from what the vendor is willing to support. This applies to storage, as well as virtualization. Placement of Exchange 2013 server roles isn’t always a strictly technical decision. Centralized deployments may work for a small company with a highly mobile workforce, but it might not be the best option for a large company with multiple international locations, each governed by different rules and compliance requirements. Objective 1.1: Plan the mailbox role Chapter 1 17 ■■ While supported, not every environment can benefit from the high availability and resource management functionality modern virtualization platforms provide. Exchange 2013, when using database replicas, can ensure the integrity of data that HA provided by virtualization platform can’t due to lack of application awareness. Objective review Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions, and explanations of why each answer choice is correct or incorrect, in the “Answers” section at the end of this chapter. 1. Select supported disk configuration for Exchange 2013 deployment. The deployment must provide the best possible cost benefits for design consisting of large mailboxes for every user. The planned minimum mailbox size is 5 GB per user. A. Dedicated RAID5 configuration of 10 SSD disks per server. B. VHD files stored on 7,200 RPM 4 TB SATA disks, served by NFS storage array using dedicated 10 Gbps network. C. Dedicated RAID5 volume consisting of 15,000 RPM 1 TB SCSI disks on fiber chan- nel SAN storage array. D. Dedicated RAID10 volume consisting of 15,000 RPM 1 TB SCSI disks on Direct At- tached Storage. 2. You need to determine the user profile for the existing Exchange 2010 environment that will be used to determine server and storage sizing for planned Exchange 2013 deployment. Which tool should you use to minimize administrative effort and meet the requirement? A. Exchange Profile Analyzer B. Performance Counters C. Transaction Log Files D. Exchange Log Analyzer 3. You plan to create a new public folder mailbox on an Exchange 2013 server located at a remote site that’s connected to the main site using slower WAN links. You want to ensure users don’t get incomplete folder hierarchy. What should you do? A. Create a new public folder mailbox using the New-Mailbox cmdlet. Exclude the new public folder from the serving hierarchy using the IsExcludedFromServingHeirarchy parameter. B. Create a new public folder mailbox using the New-Mailbox cmdlet. Set the IsHierarchyReady parameter to $false to exclude the new public folder from the serving hierarchy. C. Create a new public folder mailbox using the New-Publicfolder cmdlet. Set the IsHierarchyReady parameter to $false to exclude the new public folder from the serving hierarchy. 18 Chapter 1 Install, configure, and manage the mailbox role Objective 1.2: Configure and manage the mailbox role Exchange 2013 setup is now greatly simplified, and it also accounts for installing operating system component prerequisites as a part of the setup, if selected. But this simplification doesn’t prevent the need to carefully plan the deployment of the mailbox server roles, taking into account the unique qualities of the environment where Exchange 2013 is being deployed. In this section, you learn the details of how to configure and manage mailbox role and related components. This objective covers how to: ■■ Deploy mailbox server roles ■■ Create and configure Offline Address Book (OAB) ■■ Design and create hierarchical address lists ■■ Create and configure public folders Deploying mailbox server roles The first step to successfully deploy a mailbox server is to ensure that all of the prerequisites are met. Starting with authentication provider, you must be certain that at least one writeable domain controller exists in each Active Directory site where you plan to deploy an Exchange 2013 server. The supported operating system running on the Active Directory controller is Windows Server 2003 or later. Referencing mail-enabled objects is critical for Exchange server roles. For Exchange server to function properly, you must deploy at least one global catalog server in each Active Directory site where you plan to deploy an Exchange 2013 server. The network infrastructure using the IPv6 protocol is supported only when IPv4 is also installed and enabled. In small environments, it’s tempting to collocate Exchange 2013 server on a server that’s also a domain controller to reduce the number of servers required. While it is a supported to install Exchange 2013 on a domain controller, for security and performance reasons, the recommendation is to install Exchange 2013 server on a member server in a domain. If you choose to collocate an Exchange server with a domain controller, the server can’t later be demoted to a member server or promoted to a domain controller from a member server after Exchange server is installed. Since the Resilient File System (ReFS) was introduced in Windows Server 2012, it hasn’t shared much of the limelight, despite the new features that offer a better integrity of data. Exchange 2013 supports storing database files, transaction log files, and content index files on partitions formatted with ReFS. But partitions storing Exchange binary files and diagnostics logging data generated by Exchange server must be formatted using the NTFS file system. Windows Server Core installations reduce the management overhead and increase the security profile of the server by reducing the attack surface. Core installations, however, aren’t Objective 1.2: Configure and manage the mailbox role Chapter 1 19 supported for Exchange 2013 server installations. If you have Windows Server 2012 or Windows Server 2012 R2, it’s possible to convert from a Core installation to a Full installation of the server. But if you have a Windows 2008 R2 Core installation, you must reinstall the operating system using the Full installation option. Windows Server 2012 R2 is only supported with Exchange 2013 Service Pack 1 or later. Preparing the organization is one of the first steps that needs to be run before installing any Exchange 2013 server roles. In an environment where role separation is required, the Exchange administrator might not have the ability to modify the Active Directory schema. In such cases, the Active Directory administrator with Schema Admins and Enterprise Admins privileges needs to run the preparation steps before the Exchange administrator can install Exchange 2013 servers. In Active Directory forests with multiple domains, it’s also important to run Active Directory preparation steps from a computer in the same domain and site as the domain controller that is a Schema Master. Because this first step requires access to Active Directory, tools that enable you to administer Active Directory are required on the server where the setup is being run. Remote Tools Administration Pack (RSAT) includes all of the required tools and must be installed if the computer is not a domain controller; it can be installed via server manager interface or by using PowerShell. If the server is running Windows Server 2008 R2, you can use the command line Add-WindowsFeature RSAT-ADDS. On Windows Server 2012 or later, run Install-WindowsFeature RSAT-ADDS instead. While the difference is subtle, note the cmdlet, which is different between the two versions, while the component being installed is the same. When using setup.exe in unattended mode, which can also be used for unattended setup, you must also use the /IAcceptExchangeServerLicenseTerms switch for setup to succeed. No abbreviated aliases exist for the switch. When preparing a schema, you must allow for the replication to complete from a schema master to all of the domain controllers in all of the domains of the forest. You need to do this before you can proceed to the next steps of preparing Active Directory and preparing domains where Exchange servers and Exchange server users are to be located. In an Active Directory forest with multiple domains, you must prepare every domain where Exchange server users reside, even if an Exchange server won’t be installed in that domain. When extending the Active Directory schema, Exchange server setup adds and updates classes, attributes, and other items. In simple terms, this is how Active Directory is made aware of what Exchange objects are going to be made up of. When preparing Active Directory, in new environments, an Exchange Organization is created using the name provided by the administrator. In existing environments, an existing Exchange organization is updated to include Exchange containers, objects, and attributes. When an Exchange server is installed, you’ll find that the corresponding Exchange server object is created within the Exchange organization container in Active Directory. 20 Chapter 1 Install, configure, and manage the mailbox role The last step in preparation of Active Directory is the preparation of domains. During this step, Exchange-related containers and security groups are created. Setup also assigns permissions to the containers, so the Exchange server can access them. If the Exchange administrator also has required Active Directory permissions, the Exchange Setup Wizard can run all three Active Directory preparation steps automatically. After the successful installation of Exchange servers, Exchange administrators with permissions to create objects can create new security principals, such as a user in Active Directory, before creating an Exchange mailbox if needed. This model of security might not be preferred in organizations with strict role separation requirements. In such environments, Active Directory administrators are unable to manage Exchange objects, such as mailbox creation, distribution group creation, and so on. Likewise, an Exchange administrator isn’t permitted to create a new user in Active Directory. To achieve such role separation, Exchange setup provides the capability to create Active Directory split permissions. This can be achieved during the setup or after Exchange servers are set up, by running setup.exe with the /ActiveDirectorySplitPermissions switch set to True. When using the Setup Wizard, the Apply Active Directory split permission security model to the Exchange organization option is only available if you are setting up the first Exchange server in a new organization. In an existing organization, you must use setup.exe in unattended mode with the previously mentioned switch to change the existing permission model. EXAM TIP It’s possible to change the Exchange server security model from Active Directory split permissions to shared permissions and vice versa. An Exchange administrator with the proper Active Directory permissions can run setup.exe with the /ActiveDirectorySplitPermissions switch set to true or false to implement or remove Active Directory split permissions, respectively. When permissions are involved, larger environments tend to have separation of roles and duties that extend beyond just separation between Exchange and Active Directory administrators. For example, you can have an Exchange architect who is responsible for setting objectives for the Exchange server design and deployment. They might also serve as a subject matter expert and a point of escalation when needed. Daily management tasks might be further delegated to other Exchange administrators. Similarly, an organization might hire temporary staff to assist with timebound, short-term needs where hiring a new person might not be warranted or possible. Exchange setup accounts for such requirements where the person setting up an Exchange server might not be responsible for managing an entire Exchange organization and might only need limited permissions that enable them to successfully install new Exchange server roles. For delegated setup to work, you must have at least one Exchange server installed in the organization. Next, the organization administrator must provision a new Exchange server in Active Directory. This can be achieved by running setup.exe from the command line and Objective 1.2: Configure and manage the mailbox role Chapter 1 21 using the /NewProvisionedServer switch. If you’re provisioning a new server using a different computer to run the setup, you must also include the computer name of the server being provisioned with the /NewProvisionedServer switch. After provisioning a new server, the user who is performing an installation of Exchange server needs to be added to the Delegated Setup role group. EXAM TIP While delegated setup permissions enable an administrator to install a new Exchange server, it doesn’t provide the ability to decommission an existing Exchange server. You need to be an Exchange administrator to successfully uninstall Exchange server from a computer. Creating and configuring Offline Address Book Address books are part of the functionality Exchange server offers to enable users to find other users easily. Address books are created and maintained by mailbox servers. The Offline Address Book (OAB) enables users to use Address Book functionality when they aren’t connected to Exchange server. Address lists are a building block of OAB. Address lists represent a collection of recipients and other mail-enabled objects, such as contacts, groups, and room/equipment resources. When Exchange 2013 is installed, it automatically creates multiple default address lists that contain contacts, distribution lists, rooms, users, and public folders. The default Global Address List (GAL), which contains all mailbox-enabled or mail-enabled objects from the Active Directory forest where Exchange is installed, is also created. You can also create custom address lists to contain mail-enabled objects from certain departments, geography, or any other organizational entity that can help users identify which address list is most likely to contain a user they want to find. Custom address lists tend to be a subset of objects contained in a global address list. New address lists can be created using the New-AddressList cmdlet or by using the Exchange Admin Center (EAC). When creating a new address list, you can restrict which recipients should be included in the new address list by using built-in filter parameters, such as the ConditionalDepartment. This only selects users with a department attribute that matches a defined value of the parameter. Here’s an example of creating a new address list named Finance that includes all users with a department attribute set to Finance. Create new address list New-AddressList –Name Finance –IncludedRecipients AllRecipients –ConditionalDepartment Finance The same can be achieved using the Exchange Admin Center, as you can see in Figure 1–2. 22 Chapter 1 Install, configure, and manage the mailbox role FIGURE 1-2 Create a new address list using Exchange Admin Center When built-in filter parameters might not be sufficient to create a custom address list, you can create recipient filters using the OPATH filtering syntax. To create a custom address list using the recipientfilter parameter, you can’t use the Exchange Admin Center (EAC) and you must use the Shell. In the following example, let’s create a custom address list to include all users with a mailbox from finance or the sales department, based on their department attribute value. Create new address list using recipient filter New-AddressList –Name ""Finance-Sales"" –RecipientFilter {((RecipientType -eq 'UserMailbox') -and ((Department -eq 'Finance') -or (Department -eq 'Sales')))} For the list of filterable properties that can be used with a recipient filter, see the article Filterable properties for the RecipientFilter parameter at http://technet.microsoft.com/en-us/ library/bb738157(v=exchg.150).aspx. While default GAL contains all objects, when an organization is required to provide separation between different departments to achieve compliance or other business reasons, a single default GAL doesn’t serve the purpose. To address the requirement, you need to create additional global address lists and provide separation using Address Book policies. The process is also referred to as Global Address List (GAL) segmentation. Objective 1.2: Configure and manage the mailbox role Chapter 1 23 Each Address Book policy consists of four components: ■■ Address Lists ■■ Room Address List ■■ Global Address List ■■ Offline Address Book When you create address lists, you use recipient address filters to create a logical separation between entities. For example, you can create two separate address lists, each containing employees and contacts from the Finance department and the Sales department, respectively. You also create separate room address lists to contain rooms and resources that should only be available to one department. A new GAL is then created to include custom address and room lists, as well as corresponding OAB objects containing their corresponding GAL objects. When this procedure is complete, you will have two Address Book policies separating two department Address Books. The logical separation still isn’t achieved since user mailboxes need to be configured to start using their corresponding GALs and OABs. You can configure user mailboxes to use new GALs and OABs by using the Set-Mailbox cmdlet. NOTE CREATE GAL AND OAB OBJECTS Currently, EAC doesn’t provide an interface to create new GAL or OAB objects. You must use Shell to create GAL and OAB objects. When creating Address Book Policies (ABPs), a room address list is required, even if you don’t have any room objects or shared resources to include in the list. In the following example, we create an empty room list to meet the requirement. The example assumes that no conference room mailboxes exist in the environment. Let’s walk through this process. GAL segmentation walk-through #Create address lists for each department New-AddressList –Name "Finance AL" –IncludedRecipients AllRecipients –ConditionalDepartment Finance New-AddressList –Name "Sales AL" –IncludedRecipients AllRecipients –ConditionalDepartment Sales #Create room address lists for each department New-AddressList -Name "Finance Room AL" -RecipientFilter {(RecipientDisplayType -eq 'ConferenceRoomMailbox')} New-AddressList -Name "Sales Room AL" -RecipientFilter {(RecipientDisplayType -eq 'ConferenceRoomMailbox')} #Create Global Address Lists for each department New-GlobalAddressList -Name "Finance Global Address List" -IncludedRecipients MailboxUsers -ConditionalDepartment Finance New-GlobalAddressList -Name "Sales Global Address List" -IncludedRecipients MailboxUsers -ConditionalDepartment Sales 24 Chapter 1 Install, configure, and manage the mailbox role #Create Offline Address book objects for each department New-OfflineAddressBook -Name "Finance OAB" -AddressLists "\Finance Global Address List" -VirtualDirectories "SERVER01\OAB (Default Web Site)" New-OfflineAddressBook -Name "Sales OAB" -AddressLists "\Sales Global Address List" -VirtualDirectories "SERVER01\OAB (Default Web Site)" #Create Address Book Policies (ABPs) for each department New-AddressBookPolicy -Name "Finance ABP" -AddressLists "Finance AL" -OfflineAddressBook "\Finance OAB" -GlobalAddressList "\Finance Global Address List" –RoomList "\Finance Room AL" New-AddressBookPolicy -Name "Sales ABP" -AddressLists "Sales AL" -OfflineAddressBook "\ Sales OAB" -GlobalAddressList "\Sales Global Address List" -RoomList "\Sales Room AL" #Assign the ABPs for each mailbox Set-Mailbox "FinUser1" –AddressBookPolicy "Finance ABP" Set-Mailbox "SalesUser1" –AddressBookPolicy "Sales ABP" So far, we’ve followed all of the logical steps to provide a separation between two departments. Notice how we only changed one mailbox for each department in the previous example. Obviously, in the real world, you have to change all of the mailboxes of each department to apply the correct ABPs to each. Here’s one more item not covered yet: name resolution. When a user from Outlook types a name in the address bar, Outlook provides the capability to resolve the name from GAL. Despite the separation created using ABPs, name resolution continues to work across logical boundaries created by ABPs. This is because name resolution is an organizational function and, despite logical separation, the objects from both departments continue to exist in a single Exchange organization. To address this problem, two departments, when using ABPs, must be considered external to each other. The Address Book Policy routing agent provides this function. The ABP routing agent must be manually installed and enabled to provide name resolution separation. Take a look at the process. Install and enable ABP routing agent #Install ABP routing agent Install-TransportAgent -Name "ABP Routing Agent" -TransportAgentFactory "Microsoft.Exchange.Transport.Agent.AddressBookPolicyRoutingAgent. AddressBookPolicyRoutingAgentFactory" -AssemblyPath $env:ExchangeInstallPath\ TransportRoles\agents\AddressBookPolicyRoutingAgent\Microsoft.Exchange.Transport.Agent. AddressBookPolicyRoutingAgent.dll #Enable transport agent Enable-TransportAgent "ABP Routing Agent" #Restart transport service Restart-Service MSExchangeTransport #Enable ABP routing agent Set-TransportConfig -AddressBookPolicyRoutingEnabled $true Objective 1.2: Configure and manage the mailbox role Chapter 1 25 After following these steps, name resolution across departments shouldn’t work and, along with configured Address Book policies, it provides the desired separation between two departments. Figure 1–3 provides an example of a Sales user trying to resolve the display name of a Finance user (finuser1) while ABP separation is in place and the ABP routing agent is configured. FIGURE 1-3 ABP routing agent blocking name resolution across ABP boundaries Now let’s look at more details of Offline Address Books. Because OABs are offline copies of address lists associated with an OAB, the files corresponding to the OABs need to be generated on Exchange servers. On Exchange 2013 servers, this is the function of the Microsoft Exchange OABGen service. The Microsoft Exchange OABGen service isn’t a schedule-based function. Instead, based on server resource availability, it’s throttled or paused as needed. Exchange 2013 supports and produces OAB v4 files only. OAB v4 was introduced with the release of Exchange 2003 Service Pack 2 and is supported by Outlook 2007 and later. OAB v4 Unicode format allows client computers to receive differential updates, instead of full OAB downloads, as well as a reduction in file size. Exchange 2013 uses web-based distribution, which Outlook clients use to download OAB files. In contrast to public folder-based distribution in previous versions, web-based distribution provides distinct advantages, such as the ability to support more concurrent clients for OAB distribution, a reduction in bandwidth usage, and more control over the distribution end point. Clients use Autodiscover to locate the OAB distribution point they should connect to, which, in turn, can be load-balanced end points providing better resiliency. 26 Chapter 1 Install, configure, and manage the mailbox role EXAM TIP When Exchange server is installed, the OAB virtual directory is configured with an internal URL using a Fully Qualified Domain Name (FQDN) of the server. The external URL isn’t populated and is left empty. When external clients use Autodiscover to locate the OAB endpoint, they won’t find an OAB external URL in an Autodiscover response and they won’t be able to download OAB. This limits the clients’ ability to look up users, contacts, and other mail-enabled objects when offline or not connected to the Exchange server. Another change in Exchange 2013 regarding OAB is generation. OAB generation is no longer associated with a particular mailbox server like in previous versions. When we created an example OAB in the previous ABP exercise, you may have noticed we didn’t specify a generation server. The OAB generation functionality is now associated with a specialized mailbox called the arbitration mailbox. When Exchange server is installed, multiple arbitration mailboxes are automatically created and are associated with different persisted capabilities, which define the purpose and function of an arbitration mailbox. An arbitration mailbox with persisted capability OrganizationCapabilityOABGen is responsible for OAB generation. The new functionality can now benefit from higher availability provided by a DAG when a mailbox is located on a database protected by DAG. Because no generation server exists, changing the OAB generation server simply means moving the arbitration mailbox to a different database on a different server if the database isn’t protected by DAG. If a mailbox is located on a database copy protected by DAG, you can simply activate a different copy of the database on a different server to move the arbitration mailbox to a different server. To provide close proximity to an OAB generation mailbox in a distributed environment, you can create additional arbitration mailboxes as needed. When creating an arbitration mailbox, specify the Arbitration parameter to the New-Mailbox cmdlet. After creating an arbitration mailbox in the desired location, enable OAB generation by using the –OABGen $True parameter with the Set-Mailbox cmdlet. When an OAB download request is received by a client access server, it proxies the request to the mailbox server hosting an active arbitration mailbox in the same Active Directory site. If more than one mailbox server contains an active arbitration mailbox with an OAB generation capability, the client access server sends the requests using round-robin distribution. This could result in the frequent full download of OABs by the client and isn’t recommended. IMPORTANT CU5 UPDATES AND ITS IMPACT ON OAB DOWNLOADS Cumulative Update 5 (CU5) introduces important changes to OAB generation logic and configuration options. After the CU5 update, you can assign the generation of an OAB to a specific mailbox. This addresses the issue that existed prior to CU5, resulting in a full OAB download. Detailed documentation about this change can be found on the Exchange team blog at http://blogs.technet.com/b/exchange/archive/2014/05/13/oab-improvements-inexchange-2013-cumulative-update-5.aspx. Objective 1.2: Configure and manage the mailbox role Chapter 1 27 The OAB generation schedule configuration has also been changed in Exchange 2013. Schedule property on the OAB object is no longer affected when the OAB is generated. The OAB generation is now controlled based on the configuration of the OABGeneratorWorkCycle and the OABGeneratorWorkCycleCheckpoint properties of a mailbox server. The default values of these attributes are set to one day, resulting in the OAB generation taking place once every day. Values of these parameters can be changed using the Set-MailboxServer cmdlet. If you need to manually force the generation of a particular OAB, you can use the Update-OfflineAddressBook cmdlet. You can also restart the mailbox assistant service, but it’s more impactful on the server resources and it isn’t the best or most preferred option when a better option exists. Designing and creating hierarchical address lists While GAL provides the ability to easily find recipients from an organization, it doesn’t reflect management or seniority relationships within recipients of the organization. The hierarchical address book (HAB) enables end users to look for recipients using an organizational hierarchy, thus providing an efficient method for locating internal recipients. The HAB is enabled at the organization level by using the Set-OrganizationConfig cmdlet. When enabling HAB, you need to provide a distribution group to use as the root of HAB. You can create a separate organizational unit (OU) to store all HAB-related distribution groups or use an existing OU in Active Directory. You also need to create more distribution groups, each corresponding to the hierarchy of the company. For example, HQ, designating company headquarters, locations, and departments. The hierarchy is created by using a distribution group nesting. You need to add subordinate distribution groups to their parents as a member. For example, distribution group HQ is added to the root distribution group, and department distribution groups HR and Accounting are added to the distribution group HQ to represent a hierarchy. Individual recipients show up in the HAB based on their distribution group membership. For example, the CEO of the company might be a member of distribution group HQ, whereas the Director of Human Resources might be added to the HR distribution group, and so on. Once the distribution group for the HAB root is created and the HAB is enabled at the organization level, set the value of the IsHierarchicalGroup property on the distribution group to $true. You also need to repeat this step for all of the distribution groups that are members of the HAB. When you have multiple members for a given location, such as HQ, in the HAB display, they are organized alphabetically in ascending order. It might be more desirable to show the members based on their seniority. HAB enables you to achieve that by setting the value of the SeniorityIndex attribute on the recipient or the distribution group. In HAB, objects are organized based on seniority index values from higher to lower. 28 Chapter 1 Install, configure, and manage the mailbox role Let’s take a look at the process of creating the HAB root distribution group and enabling HAB for Contoso, Ltd. Enable Hierarchical Address Book #Add OU for Hierarchical Address Book dsadd ou "OU=HAB,DC=Contoso,DC=com" #Create root Distribution group New-DistributionGroup -Name "Contoso,Ltd" -DisplayName "Contoso,Ltd" -Alias "ContosoRoot" -OrganizationalUnit "Contoso.com/HAB" -SamAccountName "ContosoRoot" -Type "Distribution" #Enable HAB using Contoso Distribution Group created for HAB root Set-OrganizationConfig -HierarchicalAddressBookRoot "Contoso,Ltd" #Designate distribution group as member of HAB Set-Group -Identity "Contoso,Ltd" -IsHierarchicalGroup $true At this point, you have an empty HAB, which would look similar to Figure 1–4 when using the Outlook client. FIGURE 1-4 Hierarchical Address Book with no members Now let’s create subordinate distribution groups HQ, New York, and London, and then add them to their relevant parent distribution groups. HQ also has HR and Accounting sub groups. We also set the seniority index of a few recipients and add them to the appropriate distribution groups in the hierarchy. Objective 1.2: Configure and manage the mailbox role Chapter 1 29 Create subordinate groups and configure hierarchy #Create subordinate distribution groups New-DistributionGroup -Name "HQ" -DisplayName "HQ" -Alias "HQ" -OrganizationalUnit "Contoso.com/HAB" -SamAccountName "HQ" -Type "Distribution" New-DistributionGroup -Name "HR" -DisplayName "HR" -Alias "HR" -OrganizationalUnit "Contoso.com/HAB" -SamAccountName "HR" -Type "Distribution" New-DistributionGroup -Name "Accounting" -DisplayName "Accounting" -Alias "Accounting" -OrganizationalUnit "Contoso.com/HAB" -SamAccountName "Accounting" -Type "Distribution" New-DistributionGroup -Name "New York" -DisplayName "New York" -Alias "New York" -OrganizationalUnit "Contoso.com/HAB" -SamAccountName "NY" -Type "Distribution" New-DistributionGroup -Name "London" -DisplayName "London" -Alias "London" -OrganizationalUnit "Contoso.com/HAB" -SamAccountName "London" -Type "Distribution" #Designate distribution groups as member of HAB Set-Group -Identity "HQ" -IsHierarchicalGroup $true Set-Group -Identity "HR" -IsHierarchicalGroup $true Set-Group -Identity "Accounting" -IsHierarchicalGroup $true Set-Group -Identity "New York" -IsHierarchicalGroup $true Set-Group -Identity "London" -IsHierarchicalGroup $true #Add distribution groups to Add-DistributionGroupMember Add-DistributionGroupMember Add-DistributionGroupMember Add-DistributionGroupMember Add-DistributionGroupMember appropriate parent -Identity "ContosoRoot" -Member "HQ" -Identity "ContosoRoot" -Member "New York" -Identity "ContosoRoot" -Member "London" -Identity "HQ" -Member "HR" -Identity "HQ" -Member "Accounting" #Add members to appropriate Add-DistributionGroupMember Add-DistributionGroupMember Add-DistributionGroupMember distribution groups -Identity "HQ" -Member "Ray" -Identity "HQ" -Member "Peter" -Identity "HR" -Member "Mary" #Assign appropriate seniority index to members Set-Group -Identity "HR" -SeniorityIndex 100 Set-User -Identity "Ray" -SeniorityIndex 100 Set-User -Identity "Peter" -SeniorityIndex 99 After the completion of the previous steps, we now have an example HAB, complete with subordinate groups and their members. Because we also assigned seniority to Ray, he is displayed before Peter in the list, overriding the default alphabetical ordering. The same also applies to the HR department, which displays before Accounting in the hierarchy. Figure 1–5 represents the example HAB. 30 Chapter 1 Install, configure, and manage the mailbox role FIGURE 1-5 Hierarchical Address Book with members Notice how London is listed after HQ and before New York. Because we chose not to assign any seniority index to the locations, they’re displayed using default alphabetical display order. However, Ray is displayed before Peter and HQ is displayed before Accounting as defined by the seniority index. The Name List tab still provides you with a nonhierarchical reference to all recipient objects, as shown in Figure 1–6. FIGURE 1-6 Name List view of the Address Book Objective 1.2: Configure and manage the mailbox role Chapter 1 31 It’s important for you to understand that the effort involved in a large environment to enable HAB goes beyond the simple steps demonstrated here. In such an organization, you might need to create many distribution groups representing each leaf of hierarchy and then add DLs as needed. You also need to define each individual member’s seniority index where necessary, which in large environments can be daunting. It’s best to have a defined business process that mandates appropriate steps, either performed manually by the administrative staff or by scripting triggered on appropriate intervals to keep HAB updated according to changes occurring in the environment. Creating and configuring public folders Creating public folders in Exchange 2013 is a different process compared to previous versions. This is because public folders are now stored in public folder mailboxes. In a new installation where no public folders exist, the first step is to create a public folder mailbox. Because this is the first public folder mailbox in the organization, it contains public folder hierarchy information and becomes the primary hierarchy mailbox. The public folder mailbox can also contain public folder content. The primary hierarchy mailbox is the only writeable copy of the hierarchy in the organization. All other public folder mailboxes created contain a read-only copy of the public folder hierarchy. You can create a public folder mailbox using EAC or the Shell. Similar to any other mailbox, the cmdlet you use to create the public folder mailbox is New-Mailbox. To designate a mailbox as a public folder mailbox, use the PublicFolder parameter. There is no difference in the syntax for creating the first public folder mailbox containing the primary public folder hierarchy and secondary public folder mailboxes. Exchange server automatically creates the public folder with an appropriate copy of the hierarchy. To verify which mailbox contains the primary writeable copy of the public folder hierarchy, you can issue Get-OrganizationConfig | Format-List RootPublicFolderMailbox at the Shell. After creating a public folder mailbox, you can now create a public folder that users see in the hierarchy and can store content in. To create a public folder, you can use New-PublicFolder cmdlet or EAC. You can specify a name for the folder being created, the path in the hierarchy where the folder is created and, optionally, the public folder mailbox where the content for the folder is stored. You don’t need to define the path if you’re creating a public folder in the root of the hierarchy. When you create a public folder, it inherits the settings of its parent folder, which includes the permissions assigned to the parent public folder. To assign permissions to a public folder, you can use EAC or use the Add-PublicFolderClientPermission cmdlet. You can either choose to assign permissions such as ability to read, create or delete items, or assign a role, such as owner, editor, or author. Each role represents a combination of permissions on the public folder. For example, the Reviewer role enables the assignee permissions to see the public folder and its contents, but it has no ability to edit or delete them. Public folders also allow the ability to submit content via email. To do so, you must mailenable a public folder. Similar to other public folder-related procedures, you can use EAC to 32 Chapter 1 Install, configure, and manage the mailbox role mail-enable a public folder, or you can use the Enable-MailPublicFolder cmdlet. When mailenabling a public folder, you don’t need to provide an email address for the folder. You can, however, change the primary email address or assign additional email addresses to a mailenabled public folder, if needed. If you use the Shell, you can use the Set-MailPublicFolder cmdlet to update an email address and other mailbox properties, such as the mailbox quota. Another important consideration for when you mail-enable a public folder mailbox, is to ensure that only authorized users can submit content via email. You can choose to accept emails from individual recipients or members of a distribution group. Use the Set-MailPublicFolder cmdlet with the AcceptMessagesOnlyFrom, AcceptMessagesOnlyFromDLMembers, or AcceptMessagesOnlyFromSendersOrMembers parameters to assign appropriate sender restrictions. Now that only one writeable copy of the public folder hierarchy exists, it’s critical that the public folder mailbox containing a writeable copy of the hierarchy is highly available. Ensure that the public folder mailbox is located on a database copy protected by DAG and has multiple database copies located in appropriate locations to provide protection against local and site failures. The same protection should also be applied to all public folder mailboxes that store critical public folder content. If public folders are accessed by users located across multiple locations and regions connected via WAN or slower network links, you can improve the user experience when accessing a public folder hierarchy. You can also provide uninterrupted access in case of network failures between a client location and other sites. You do this by creating a public folder mailbox in close proximity to the client location where network connectivity between client and Exchange server is robust. After creating a public folder mailbox in such a location, you need to change all user mailboxes for a given office or regions to use the new public folder mailbox as their default access location for the public folder hierarchy. You can do so by using the Set-Mailbox cmdlet with the DefaultPublicFolderMailbox parameter. While this provides users with uninterrupted access to the public folder hierarchy, uninterrupted access to the content can only be guaranteed if the public folder content is also stored on public folder mailboxes that are locally accessible. That is why locating public folder content requires careful planning and an understanding of the usage of public folders and the factors affecting it, such as a public folder containing regional data or a public folder containing company data that might be applicable to all public folder users. Moving a public folder mailbox may be necessary due to organizational or infrastructure changes. If you need to move a public folder mailbox, you can do so by issuing a mailbox move request, similar to moving a regular mailbox. This enables you to move the public folder mailbox, including all of its content, including the primary or read-only copy of a public folder hierarchy, to a different database located on the same or a different server, which may or may not be a part of DAG. When you need to provide high availability to a public folder mailbox, you should move it to a database configured with multiple copies protected by DAG. If you’re using the Shell, you can use the New-MoveRequest cmdlet to move a public folder server. Objective 1.2: Configure and manage the mailbox role Chapter 1 33 When the organization grows, you might need to change where the public folders are stored. You might need to move a public folder to a different public folder mailbox to provide close proximity access to its primary user base. Or, you might need to move a public folder that exceeds the assigned mailbox storage quota. Moving a single public folder is as simple as issuing the New-PublicFolderMoveRequest cmdlet. NOTE PUBLIC FOLDER MOVE REQUESTS You can perform only one public folder move request at a time. Before creating another public folder move request, you must remove the completed public folder move requests, using the Remove-PublicFolderMoveRequest cmdlet. If you need to move a public folder, including all of the public folders within its branch, you can’t use the New-PublicFolderMoveRequest cmdlet. While the cmdlet enables you to move multiple individual public folders to a different mailbox, it doesn’t move an entire branch of a selected public folder. To move the entire branch of a public folder, you must use the Move-PublicFolderBranch.ps1 script, which is included with an Exchange server installation. The process of creating public folders in a new environment might seem relatively simple. Migrating public folders from a previous version of Exchange servers requires careful planning. This is because when the public folder data is migrated to Exchange 2013 servers, it doesn’t synchronize with a previous version of public folders. Migrating from a previous version of public folders is a multi-step process. The supported version of Exchange servers for such a migration is Exchange Server 2007 SP3 RU10 and Exchange Server 2010 SP3 or later. The first step in the migration process is to use public-folder migration scripts to create the public folder name to size mapping and the public folder to the proposed new public-folder mailbox mapping. The collection of statistics enables you to understand the impact on new Exchange 2013 servers. It also enables you to create the required public folder mailboxes according to the appropriate folder size mapping created by the scripts. Before you proceed with migration, ensure that no public folder mailboxes exist on Exchange 2013 and that no public folder migration requests exist. You can verify any existing public-folder migration requests by running the Get-PublicFolderMigrationRequest cmdlet. If a migration request exists, you need to make sure no migration is in progress or you risk losing data when you remove the migration request to start the new migration. After ensuring that starting a new public folder migration is appropriate, start the process by creating public folder mailboxes. When you create the first public folder mailbox, set the property of the HoldForMigration parameter to $true. Use the csv file created by the migration script PublicFoldertoMAilboxMapGenerator.ps1 to create additional public folder mailboxes. 34 Chapter 1 Install, configure, and manage the mailbox role After the successful creation of all required public folder mailboxes, you can start the migration request by using the New-PublicFolderMigrationRequest cmdlet. The time it takes to migrate the public folder data depends on the amount of data being migrated, the load on the source and destination servers, and other environmental factors, such as the network infrastructure. When the migration is started, Exchange servers synchronize public folder data from a previous version of Exchange servers to the new public folder mailboxes created earlier. However, during the initial data synchronization process, users can continue using legacy public folders and make changes. When the migration process reaches the status of autosuspended, you can lock the public folders on a legacy exchange server for final migration. To verify the status of the migration process, run the Get-PublicFolderMigrationRequest cmdlet. To lock down the legacy public folders for final migration, run Set-OrganizationConfig -PublicFoldersLockedForMigration:$true. After performing this step, users won’t be able to access public folders or make any changes. If public folder databases are distributed across multiple locations, it might take several hours for the change to converge. You can verify the status of public folder databases by verifying the PublicFoldersLockedForMigration flag. Once all of the legacy public folders are locked for migration, you can set the PreventCompletion property on the public folder migration request to $false. This action allows the final synchronization of public folder data to take place. You also need to resume the public folder migration request by issuing the Resume-PublicFolderMigrationRequest cmdlet. The amount of time required for the final synchronization depends on the amount of changes made by users to the public folder data after the migration process reaches the autosuspended status, and before the legacy public folders are locked for migration. Before you can enable public folders on Exchange 2013, you need to ensure that the migration is complete, which you can verify by running the Get-PublicFolderMigrationRequest cmdlet and ensuring that the status is Completed. Once complete, you can allow user access to migrated public folders on Exchange 2013 servers by setting the IsExcludedFromServingHierarchy property on the public folder mailboxes to $false. You also need to set the organization configuration property PublicFolderMigrationComplete to $true on legacy Exchange servers, and then set the PublicFoldersEnabled property of the organization configuration on Exchange 2013 servers to Local. Users can access data from migrated public folders on Exchange 2013 after the successful completion of the previously shown process. But there might be times when a migration doesn’t complete successfully and you need to roll back the migration, so users can continue to access public folders from legacy exchange servers. To roll back the migration, you need to set the organization property PublicFoldersLockedForMigration on legacy Exchange servers to $false, remove all of the public folder mailboxes created on Exchange 2013 servers, and set the PublicFolderMigrationComplete flag on the organization property to $false from legacy Exchange servers. Objective 1.2: Configure and manage the mailbox role Chapter 1 35 Once the new public folders are deployed on the Exchange 2013 mailbox, you might need to address such issues as accidental deletions of a public folder or the deletion of a public folder mailbox. This can happen because of a user action, a failed public folder, or a public folder mailbox move. Because the public folder mailboxes are now similar to user mailboxes, restoring a deleted public folder mailbox is similar to restoring a deleted mailbox. Use the NewMailboxRestoreRequest cmdlet and provide the appropriate values for SourceStoreMailbox, SourceDatabase and TargetMailbox. If the public folder mailbox is intact, but a public folder is deleted instead, you can restore the public folder by using a similar process to the one previously mentioned. You also need to include the IncludeFolders parameter with the public folder path of the folder that needs restoring. The process gets more involved when a deleted public folder or the public folder mailbox is past its retention period as defined on the mailbox and mailbox database properties. The process to restore a public folder mailbox and public folders past their retention period requires recovering data using a recovery database. For more information on this topic, see Develop backup and recovery solutions for the mailbox role and public folders in Objective 1.5 later in this chapter, which covers this topic in detail. The process applies to both regular and public folder mailboxes. At a high level, the process involves creating a recovery database, restoring data from backups, mounting restored databases, and extracting the data from the recovery database. Extracted data can then be exported to a folder or merged into an existing mailbox. Thought experiment Public Folders and GAL considerations In this Thought experiment, apply what you learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter. You are an Exchange administrator for Litware, Inc. Litware is migrating from Exchange 2010 and has deployed Exchange 2013 servers. Litware frequently acquires small companies that complement its products. It requires acquired companies to migrate to Litware’s existing Exchange platform. Litware requires that each acquired company have a limited view of the Address Book and it shouldn’t be able to look up other units through GAL. Litware also requires that public folders be available during single server failures. The company requires that users can browse the public folder structure without lengthy delays, regardless of their location and their connectivity to the centralized datacenter where all Exchange 2013 servers are located. 1. Recommend a solution to meet Litware’s goals to provide Address Book lookups. 2. What is the impact of public folder requirements proposed by Litware? 36 Chapter 1 Install, configure, and manage the mailbox role Objective summary ■■ ■■ ■■ ■■ ■■ ■■ Schema updates are required anytime you install an Exchange 2013 server, including when you apply updates. Plan for schema update dependencies, including OS components required, such as the Remote Tools Administration Toolkit to make schema updates. If you’re using the Setup Wizard and have appropriate permissions to make schema and domain changes, you don’t need to perform schema updates separately before running setup. When using the command line setup, if you run Prepare Domain before applying schema updates and before preparing Active Directory, setup tries to perform those steps automatically and it will succeed if the account running setup has required permissions. Address book segmentation allows logical separation between business units or different companies hosted on the same Exchange organization. HABs provides an organizational hierarchy view, making navigation and search of recipient easier compared to flat address-book structure provided by the default address-book view. Public folder migration requires that careful planning and downtime is required. Rollback is possible, but it might involve data loss because no backward synchronization exists from Exchange 2013 public folders to legacy public folders. Objective review Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter. 1. Contoso, Ltd. has deployed an Exchange 2013 environment in the child domain ny.contoso.com. The empty forest root domain is called consoto.com. Contoso, Ltd. later introduces a new domain, London.contoso.com. What should you do before enabling recipient objects in the domain London.contoso.com? A. Run setup.exe /prepareschema. B. Run setup.exe /preparead. C. Run setup.exe /preparedomain. 2. When an Exchange server crashed, users complained their Address Books didn’t include recent new hires. You need to move the OAB generation to a different server. What should you do? A. Run Move-OfflineAddressBook cmdlet. B. Run Set-OfflineAddressBook cmdlet. C. Run Move-Mailbox cmdlet. D. Run Update-OfflineAddressBook cmdlet Objective 1.2: Configure and manage the mailbox role Chapter 1 37 3. Contoso, Ltd. has implemented a hierarchical address book (HAB). You need to ensure the company’s CEO is listed before other employees, regardless of the alphabetical order of names. What should you do? A. Run Set-Mailbox cmdlet to change CEO’s mailbox. B. Run Set-DistributionGroup to change the seniority index. C. Run Set-OrganizationConfig –OrganizationSummary $true. D. Run Set-AddressList cmdlet. Objective 1.3: Deploy and manage high availability solutions for the mailbox role When deploying a critical platform such as messaging, the assumption is that such systems are going to be available without interruptions. Maintaining such complex systems without any downtime is a real challenge, especially if the platform doesn’t provide native functionality to address maintenance and unexpected downtime scenarios. Exchange 2013 not only continues to provide native functionality, but it also has improved features providing high availability for the mailbox role. Improvements such as support for multiple databases per disk provide for better utilization of disk space, as well as disk IOPS by allowing to store active, passive, and lagged copies of different databases on the same disk. Enhancements, such as automatic log replay, ensure data integrity by allowing page patching on lagged copies. This objective covers how to: ■■ Create and configure a Database Availability Group (DAG) ■■ Identify failure domains ■■ Manage DAG networks ■■ Manage mailbox database copies Creating and configuring a Database Availability Group In Exchange 2013, DAG is an integral component for both high availability and site resilience. DAG is a group of up to 16 mailbox servers that hosts mailbox database copies and provides automatic database level recovery from failures. You can host a mailbox database copy on any mailbox server that’s a member of DAG. You must ensure that at least two copies of a database are hosted on separate DAG members to provide high availability. DAG is a boundary for mailbox database replication. So, you can’t create a copy of mailbox database on a mailbox that’s a member of a different DAG. Exchange 2013 makes deploying DAG easy because it leverages the concept of incremental deployment. The incremental deployment process enables you to install a mailbox server role 38 Chapter 1 Install, configure, and manage the mailbox role without requiring a complex cluster setup. You can create DAG with a single Exchange server, and then add more Exchange servers when they are provisioned at a later date. While single server can’t provide high availability, it makes the process of building DAG easier by staging the DAG object and configuration in the environment. A DAG is created by using the New-DatabaseAvailabilityGroup cmdlet. When creating a DAG, you’re required to provide the DAG name and, optionally, the witness server name and the location of the witness directory where the file share witness data is stored. DAG is created as an empty Active Directory object. When the first mailbox server is added as a DAG member, the directory object is used to store server membership information and DAG configuration settings. While an administrator isn’t required to create and configure a cluster setup, Exchange 2013 DAG relies on failover clustering components and creates a failover cluster automatically when adding the first server to the DAG. The Cluster Network Object (CNO) is also created in the Active Directory. The CNO is identified with the same name as the name of the DAG you’re creating. EXAM TIP If DAG members are running Windows Server 2012 or Windows Server 2012 R2, prestaging the CNO is required. Pre-staging the CNO isn’t required when creating DAG without a cluster administrative access point, as the following discusses. If you need to pre-state a CNO for creating a new DAG, the process requires permissions in Active Directory to be able to create a computer object and assign necessary permissions to it. First, you must create a computer in Active Directory. Next, when you create the computer object, ensure the object name is the name of the DAG you plan to create. Then, for additional security, the recommendation is that you disable the CNO computer object. Finally, after you create the CNO, assign Full Control permissions to Exchange Trusted Subsystem on the CNO. Or, you can assign Full Control permissions only to the first node to be added to the DAG. After the DAG is created, it’s given a network name and an IP address. The failover cluster-core resource group contains an IP address resource and a network name resource in the cluster core group. The name of the DAG is registered in DNS and is resolvable on the network. With changes to the failover cluster in Windows Server 2012 R2 and Exchange 2013 Service Pack 1, DAG can be created without an administrative access point. When you create a DAG without an administrative access point, an IP address and a network name aren’t assigned to the cluster. The cluster-core resource group doesn’t contain an IP address and network name resource. A CNO isn’t created in Active Directory and the name of the cluster/DAG isn’t registered in DNS. You can’t use failover cluster administration tools to connect and manage the failover cluster, and you must use the Shell to manage a DAG without an administrative access point. Objective 1.3: Deploy and manage high availability solutions for the mailbox role Chapter 1 39 When creating a DAG with an administrative access point, if the DAG member servers are to be located across different IP subnets within an Active Directory site, or if the members are to be located across different Active Directory and physical sites for site resiliency, then you must provide multiple IP addresses for DAG configuration. You must provide one IP from each subnet the DAG members will be connected to. This allows for DAG to be managed, regardless of which DAG member owns the cluster-core resource group. When creating a DAG, one of the design considerations is the configuration of a witness server. When using failover cluster, the decision of when to consider a node of cluster out of service relies on the number of votes. Each member of the DAG is considered one vote. When you have a DAG with an even number of nodes, this creates the possibility of a split number of votes, where half the DAG members might vote a node to be out of service and the other half might vote for it to be in service. This can happen when network connectivity between locations is affected and nodes are located across the affected link evenly. In such situations, a tie-breaker mechanism becomes essential. File witness provides that mechanism. When the vote achieves the majority among all failover cluster members, then it’s considered to have reached a quorum. When a DAG is created, a file witness is required. The file witness might not be required when the DAG has an odd number of members, but failover clustering and DAG failover decision-making automatically accounts for the file witness when it’s necessary. If a file witness isn’t specified, the task of creating a DAG searches for a Client Access server in the local Active Directory site that doesn’t have a mailbox role installed. If one is found, it automatically creates a default directory and shares on that server to be used as a witness file share. If you specify a witness server and the directory, the task tries to create a specified directory and share automatically. This can succeed if the server is Exchange 2013 server because the Exchange Trusted Subsystem object has required permission to create the directory and share on the server. If the witness server isn’t an Exchange 2013 server, you must add the Exchange Trusted Subsystem group to the local Administrators group on the witness server. If the witness server is the Active Directory domain controller, the Administrators group permissions equate to permissions assigned to domain administrators. To provide required functionality, while assigning the least privilege necessary to do so, it isn’t advisable to co-locate the file witness on the Active Directory domain controller. It is, however, a supported configuration. The witness server can’t be a server that’s also a member of the same DAG. The witness server is required to be a Windows Server running any version of Windows Server 2003 or later. Using a single witness server for multiple DAGs is possible, but the witness directory must be unique for each DAG. File witness location also plays an important role in ensuring availability of DAG members. In a single-site DAG configured to provide high availability to all users hosted on database copies protected by a given DAG, the file witness needs to be located into the same physical site location and Active Directory site. When a DAG is designed to provide site resiliency in a configuration where all active users are located in a primary location, the file witness should be located at the primary site. This 40 Chapter 1 Install, configure, and manage the mailbox role ensures that the majority is maintained at a primary site, even when the network link fails between primary and secondary sites. If you have more than two locations available, Exchange 2013 also supports a locating file witness in a third location. This enables DAG members located in primary and secondary sites to participate in quorum, even when they’re unable to communicate to each other between a primary and secondary site. This design can only work if network links provide robust connectivity between primary/secondary sites to the site where the file witness is located. EXAM TIP With Microsoft Azure Infrastructure as a Service offering, there’s a lot of interest in using a file server located in Azure as a file share witness. Even with VPN links from each datacenter to Azure, this configuration is currently not supported by Exchange 2013. When extending DAG across multiple datacenters, you must account for outages and its effect on active users. Exchange administrators often prefer to optimize the use of compute resources available to them. They consider hosting active users from two separate locations on mailbox servers that are part of same DAG. The problem with this design is it can’t provide high availability to all users. When a network outage occurs between two locations, mailbox servers in only one of the two datacenters can achieve quorum. This means the active databases in the datacenter with lost quorum are dismounted and users experience service interruption. Overall design considerations, such as file share witness in the third datacenter, can affect the outcome as well. Without use of the third site for file share witness, it’s better to deploy two separate DAGs with the majority of mailbox servers for each DAG located where the majority of active users are located. This can ensure that a lost quorum at any site affects the least possible users. Once the DAG is created, the next step is to add a server to the DAG. You can add a server to the DAG using EAC or by running the Add-DatabaseAvailabilityGroupServer cmdlet. When you add the first server to the DAG, the CNO computer account for DAG is automatically enabled. Existing databases aren’t highly available until additional copies of the databases are created manually. You can use the EAC or run the Add-MailboxDatabaseCopy cmdlet to add copies to a database. A new database copy can be created on any mailbox server within the same DAG. A mailbox server can host only one active or passive copy of a database. Circular logging must be disabled before creating the first copy of the database. You can enable circular logging after adding the first copy of the database. Circular logging doesn’t need to be disabled when adding additional copies of the database. Identifying failure domains Any solution is as strong as its weakest component. To provide the best possible availability using DAG, you must account for all the components that affect it and how to remove the points of failure by providing redundancy. Another factor to consider when designing such highly available solutions is the cost. As you add more components and more redundancy Objective 1.3: Deploy and manage high availability solutions for the mailbox role Chapter 1 41 to account for the failure of each component, the cost of the solution increases. Good designs always account for striking an optimal balance between availability and cost based on the available budget. Discussions of the cost benefit of a design is beyond the scope of this book. This section covers each failure domain and its impact on the high availability of Exchange 2013. When looking at possible failures, you need to look at software, hardware, and environmental factors that can affect the operations of a component and the service itself. For example, the failure of a disk might affect only a database, while Exchange 2013 continues to function. Whereas, the failure of the Top of the Rack (ToR) router might affect more than one server in a given rack. Starting at server level failures, the server hardware, such as the power supply, network, and disk, are the most common factors. Most of the modern server class hardware now supports and commonly ships with redundant power supplies and network cards. But they still need to be configured properly to provide resiliency against failures. If a power supply fails on a server equipped with two power supplies, the server continues to function. But what if both power supplies were connected to the same power feed? What if the feed itself fails? The same concept applies to the network and disks. If your network adapters are teamed, you need to make sure they’re connected to separate switches and that the switches are configured properly. For storage, a common practice is to protect against disk failures by using different RAID levels. As you might have noticed, to protect against failures, adding more components to provide redundancy also raises the cost of the solution. Exchange 2013 is designed to provide the best cost efficiencies, while reducing the cost where possible. When DAG is configured and databases have multiple copies configured appropriately, a single power supply failure or a network card failure would affect the given server, but not the service to the user. This provides the administrator with the flexibility to fix the failed component, while the end user is provided with uninterrupted service. With the use of spare disks and auto-reseed functionality, Exchange 2013 automates the process that the administrator would have to manually perform otherwise. When combined with at least three copies of a database, Exchange 2013 supports JBOD configuration, eliminating the need for RAID and extra disks needed for the RAID configuration, reducing the cost of the required hardware and providing automation with the automatic reseed functionality. For a single datacenter deployment, it’s best to ensure that servers from the same DAG are located in different racks, have connectivity to different network switches, and are connected to a separate power feed. This ensures that any power, network or other rack-level failures, or human errors won’t affect the entire DAG and surviving components are sufficient to provide uninterrupted service to end users. Another benefit of such a design is that, with proper capacity planning, Exchange administrators can remove a mailbox server from a service to perform required maintenance without interrupting service. 42 Chapter 1 Install, configure, and manage the mailbox role You also need to account for other external dependencies, such as file share witness. While it’s possible to configure alternate witness server and alternate witness directory, if witness server fails, DAG doesn’t automatically use alternate witness server and directory. Alternat the witness server and directory, if preconfigured, can only help speed site failovers, but not without manual intervention. While a Distributed File System (DFS) might seem like a good solution to provide redundancy, it’s possible that the replication of the latest data hasn’t completed to the file-share witness copy that Exchange server might connect to. So, it isn’t supported to use DFS to host the file-share witness directory. Managing DAG networks In Exchange 2010, when you create a DAG, the initial DAG networks were created automatically based on the subnets enumerated by the cluster service. For environments where the interfaces for a specified network (MAPI or Replication network), were on multiple subnets, multiple redundant DAG networks were created and the administrator had to perform the procedure manually to collapse the networks into their appropriate function, such as MAPI or Replication network. The process was many times overlooked, resulting in unexpected DAG behavior, such as incorrect network being used for replication. In Exchange 2013, network management is automated. For automatic DAG network configuration to work correctly, MAPI networks must be registered in DNS and, in a routed network with multiple subnets, must also have a default gateway assigned. Replication networks must not be registered in DNS and they must not have a default gateway assigned to the interface. If these prerequisites are met, DAG network configuration is performed automatically and collapsing DAG networks is no longer necessary. DAG network management is also automatic in Exchange 2013 by default. DAG networks aren’t visible in EAC and can only be viewed using Shell. To view, edit, and otherwise manually manage DAG networks, you must configure DAG for manual network configuration. You can do so by checking the Configure Database Availability Group Networks Manually check box on the DAG object using EAC, or you can run the Set-DatabaseAvailabilityGroup cmdlet with the ManualDagNetworkConfiguration parameter set to $true. Be default, DAG can use MAPI networks, not only for service client traffic, but also for replication traffic, if needed. If you create a dedicated replication network and want to force all of the replication to take place on a dedicated network when the link is operational, you can run the Set-DatabaseAvailabilityGroupNetwork cmdlet and set the value of the ReplicationEnabled parameter to $false on the MAPI network. This enables you to force replication traffic over a dedicated replication network, but this setting is ignored if DAG can’t replicate data over replication networks, and the only available replication path is the MAPI network. When using a dedicated iSCSI networks for data storage, it is important to segregate the iSCSI traffic from MAPI and replication traffic. After a manual network configuration is enabled on DAG, you can set the IgnoreNetwork parameter to $true. Objective 1.3: Deploy and manage high availability solutions for the mailbox role Chapter 1 43 Managing mailbox database copies After creating a DAG, the first step to provide high availability for a database is to add the passive copy of an existing database. For any given database, you can have up to 15 maximum passive copies due to the maximum of 16 servers limit per DAG. After adding a database copy, DAG starts the initial copy of the database from the active copy. This process is known as seeding. While this automated process works for most environments, you might want the seeding process not to start automatically. When creating a database copy, you can set the value of the SeedingPostponed parameter to $true. This suspends the seeding operation on the creation of the database copy and you must explicitly seed the database copy. EXAM TIP When creating a database copy, the mailbox server must not only be a member of the same DAG, but the database path used by the specified database must also match on the server where the copy is hosted. The creation of the database copy fails if the path to the directory or mount point where the original database is located isn’t available on the mailbox server where the copy is being created. A database on DAG might have more than one copy. When a passive copy of the database needs to be activated, many factors are taken into account by the best copy selection (BCS) process. One of the factors is the activation preference parameter, which can be set by the administrator. You can set the value of the ActivationPreference parameter on a database copy with the value of 1 or higher. The value of this parameter can’t be more than the number of database copies of a given database. While the activation preference helps define in which order a database copy is to be selected for activation, it’s by no means a binding order for the BCS process of Exchange 2013. BCS takes into account multiple factors, such as the replay queue length and protocol health to ensure that not only is the selected database copy healthy, but that the server where the database copy is hosted is also healthy to ensure that a failover operation doesn’t cause service interruption. When creating a database copy, you can also opt to create a lagged copy of the database. A lag is defined by the ReplayLagTime and TruncationLagTime parameters. The maximum allowed lag time is 14 days. A lagged copy can be used as a backup. An administrator can roll back to a point in time within the configured lag window by manipulating log files that haven’t been played back into the lagged database copy. Exchange 2013 also introduces logic to improve service availability. If the database has a bad page, Exchange 2013 plays forward the lagged database copy over the risk of losing data. The play forward logic also applies to copies of the database, which might not have enough space to keep all the logs or be the only database copy available for activation. 44 Chapter 1 Install, configure, and manage the mailbox role When a database without an additional copy is using circular logging, it uses JET circular logging. When a database with multiple copies on the DAG uses circular logging, it uses the continuous replication circular logging (CRCL) instead of JET circular logging. To account for this difference in the circular logging method, circular logging must be disabled on the database before creating another copy of the database. After creating a second copy of the database, circular logging can be enabled, which then uses CRCL. When you create subsequent copies of the database, you don’t need to disable circular logging because it’s already configured to use CRCL, not JET circular logging. After a database copy is created, over its lifecycle, it can have one of many states. The GetMailboxDatabaseCopyStatus cmdlet enables you to view whether the database copy is healthy and what state it’s in. For example, a newly created database copy can be in the Initializing state. While in this state, the system is verifying the database and log stream are in a consistent state. A database can also be in this state during the transition from one state to another. EXAM TIP The healthy state of a database copy can sometimes be confused with the mounted state. Only an active copy of the database can have a copy status of Mounted. All other database copies, when they aren’t affected by failures or other conditions, have a copy status of Healthy. When a database copy fails to activate, Exchange 2013 provides the ability to test the replication health for the given database by running the Test-ReplicationHealth cmdlet. This cmdlet performs tests against many components that can affect database replication health such as cluster service, replay service, and active manage. The Test-ReplicationHealth cmdlet is an important tool in an Exchange administrator’s troubleshooting toolbox. Let’s take a look at some important mailbox database copy maintenance tasks. Activate a mailbox database copy When you’re performing maintenance on a server hosting an active copy of a database, you can initiate a switchover of the active database to another server by activating a passive copy. The database switchover process dismounts the current active database and mounts the database copy on the specified server. The operation succeeds if the database copy on the selected server is healthy and current. The following example moves the active database named DB1 to server Server2. Activating database DB1 on Server2 Move-ActiveMailboxDatabase DB1 –ActivateOnServer Server2 Besides simply activating a database copy on a different server, the Move-ActiveMailboxDatabase cmdlet also enables you to override the AutoDatabaseMountDial setting, as well as skip one of the many health check requirements. These parameters allow the administrator to provide Objective 1.3: Deploy and manage high availability solutions for the mailbox role Chapter 1 45 service at a degraded level, instead of taking the database offline if the requirements, the health checks, or the database mount dial aren’t met. Activate a lagged mailbox database copy Activating a lagged copy can be an operation preferred during times when a lagged copy is the only copy available, or a lagged copy can be activated when a point in time recovery is needed when other database copies are affected by database corruption. If you want to activate a lagged copy simply to make it current, and activate it when all other database copies are unavailable, the operation is a simple process of replaying all the log files to make the database copy current. One important factor that must be considered for this operation is the time it takes to replay all of the log files into the database before the copy can be activated. The number of log files depends on the configured lag for the copy. If the database copy is configured for a 14-day lag, it can have up to 14 days of logs for a given database that must be replayed before the copy can be activated. The log replay rate is dependent on the storage architecture and the server resource configuration. The process of activating a lagged copy and replaying all of the logs requires you to carry out the following steps. ■■ Suspend replication for the lagged copy being activated: Suspend-MailboxDatabaseCopy DB1\Server3 -SuspendComment “Activate lagged copy of DB1 on Server3” -Confirm:$false ■■ ■■ Make a copy of the database copy and log files. While this is an optional step, it’s a highly recommended best practice because it protects you from losing the only lagged copy that might be needed if the next step of replaying log files fails. Activate lagged copy and replay all log files: Move-ActiveMailboxDatabase DB1 -ActivateOnServer Server3 -SkipLagChecks If a lagged copy needs to be activated for recovery to a certain point in time, the process is a bit different than activating copy to make it current. For example, a database copy is configured for a 14-day lag. For example, active copy of the database is found to be corrupt and it’s determined that the corruption caused data loss 10 days ago. In this case, the lagged copy only needs to account for four days of logs that need to be replayed. The process of activating lagged copy to a specific point in time requires you to carry out the following steps. 1. Suspend replication for the lagged copy being activated: Suspend-MailboxDatabaseCopy DB1\Server3 -SuspendComment “Activate lagged copy of DB1 on Server3” -Confirm:$false 46 Chapter 1 Install, configure, and manage the mailbox role 2. Make a copy of the database copy and log files. While this is an optional step, it’s a highly recommended best practice because it protects you from losing the only lagged copy that might be needed if the next step of replaying log files fails. 3. Remove all log files past the determined point of recovery (all log files past the first four days in the previous example). 4. Delete the checkpoint file for the database. 5. Perform the recovery using eseutil. This process replays the log files into the database and can take a considerable amount of time. Many factors affect how long the process can take, such as the number of log files to be replayed, the hardware configuration of the server performing the replay operation, and the disk configuration, which can determine the speed at which the logs can be replayed. In the following example, eXX should be replaced with the actual log generation prefix, such as E00. Eseutil /r eXX /a 6. After the log replay finishes successfully, the database is in a clean shutdown state, and it can be copied and used for a recovery purpose. The best practice for the recovery of lost data is to mount the database files in a recovery database created for the recovery purpose. You can create a recovery database using the New-MailboxDatabase cmdlet with the Recovery parameter. 7. You can extract recovered data by mounting the recovery database and using the mailbox restore request to export the data to a PST or merge into an existing mailbox. 8. After the recovery process is complete, resume replication for the database: Resume-MailboxDatabaseCopy DB1\Server3 Instances might occur when you need to activate a lagged database copy and request redelivery of missing emails from SafetyNet. This is similar—but improved—to the transport dumpster feature in Exchange 2013. By default, SafetyNet stores copies of the successfully processed messages for two days. While the majority of steps to activate a lagged copy and request redelivery of messages from SafetyNet are similar to the previously mentioned process for point-in- time recovery, the following mentions certain differences. ■■ After suspending the lagged copy, you need to determine the logs required to bring the database to a clean shutdown state. You can determine these required logs by running eseutil and by inspecting the database header: Eseutil /mh <DBPath> | findstr /c:”Log Required” ■■ Note HighGeneration number from the output. The HighGeneration number indicates the last log file required. Move all log files with a generation number higher than HighGeneration to a different location, so they’re not played back in the database when it’s activated. Objective 1.3: Deploy and manage high availability solutions for the mailbox role Chapter 1 47 ■■ ■■ On the server hosting the active copy of the database, stop the Microsoft Exchange Replication service, so the logs don’t continue replicating to the lagged copy. Perform the database switchover and activate the lagged copy: Move-ActiveMailboxDatabase DB1 -ActivateOnServer Server3 -MountDialOverride BestEffort -SkipActiveCopyChecks -SkipClientExperienceChecks -SkipHealthChecks –SkipLagChecks ■■ After activation, the database automatically requests redelivery of the missing messages from SafetyNet. Move the mailbox database path After a database is created, if you need to move the database files from their current location to a new location, the actual steps might seem as simple as editing the database path using EAC or the Move-DatabasePath cmdlet. But this is both a disruptive and a time-consuming operation. It’s disruptive because when the database path is changed, the database is automatically dismounted for the move operation and it’s mounted after files are copied to new location. The database is unavailable for the duration of the operation and users can’t connect to their mailboxes. You can’t change the database path on a replicated database. To move the database path of a replicated database, you must first remove all copies of the database, essentially bringing the database down to a single copy, then perform the move operation, and then add copies of the database. For database copies, you need to create a new folder structure in the same path as the primary database’s new location and manually copy all the files from the old location to the new location before adding the database copies again. This saves time and effort because seeding isn’t required again. Only log files generated after removing the database copies need to be replicated. EXAM TIP You can’t move a database path if circular logging is enabled on a database. You must first disable circular logging before moving the database path. Update a mailbox database copy Updating a mailbox database copy is essentially a seeding operation. The seeding process creates a baseline copy of the active database, which then continues replication of additional logs as they’re generated. When creating a database copy, you can suspend the initial seeding operation. This creates a database copy, but it doesn’t actually copy any data to create the baseline copy. A database copy that had its seeding suspended is eventually required to be updated before it can be considered a healthy copy that can be used as a switchover or failover target. 48 Chapter 1 Install, configure, and manage the mailbox role Updating to a database copy is also required when a database copy becomes diverged or is unrecoverable. Disk failure hosting a database copy is one such example where the database is unrecoverable and must be updated to create database baseline and resume replication. Other events requiring seeding of a database copy are corrupt log file that can’t be replayed into the passive database copy and when offline defragmentation is performed on any copy of the database, after the log generation sequence of database is reset back to 1. Before you can update a database copy, you must suspend it. When starting an update, you can select which database copy should be used as a source. This is helpful in situations where a passive database copy is local to the copy being updated and might be a better option than seeding from the active copy, which could be hosted in a different datacenter. While passive copy can be used for seeding, after an update is complete, log replication always uses active copy as its source. It’s also possible to select which network should be used for seeding. Here’s an example where a database copy for database DB3 needs to be updated. If you use Server3, which has a healthy copy of the database as a source, the command to update the database copy is as follows. Update-MailboxDatabaseCopy -Identity DB3\Server2 -SourceServer Server2 While using EAC or the previously mentioned cmdlet enables you to update a database copy online, you can also opt for an offline copy process to update a mailbox database copy. When you manually copy the offline database, you first need to dismount the copy of the active database. This results for in-service interruption for users hosted on the database. The process for the manual copy method is as follows: ■■ ■■ ■■ ■■ After you dismount the active copy of the database, copy the database and log files to a shared network location or an external drive. Mount the database to restore service to users. On the server that will host database copy, copy the database files from the shared network location or external drive to the same database path as the active database copy. Add the database copy with the SeedingPostponed parameter. NOTE CIRCULAR LOGGING When using the manual copy process, you must ensure that the database isn’t configured for circular logging. Objective 1.3: Deploy and manage high availability solutions for the mailbox role Chapter 1 49 Thought experiment DAG design considerations In this Thought experiment, apply what you learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter. Contoso, Ltd. is planning to deploy high availability for its Exchange 20213 mailboxes. The company plans to deploy DAG to provide high availability for all user mailboxes. Contoso, Ltd. has two datacenters with 60 percent user mailboxes located in the primary datacenter. Two datacenters are connected with WAN links with sufficient bandwidth to replicate all user mailbox data generated daily. 1. What are the considerations when deciding among a single DAG across two datacenters: two DAGs with mailbox servers distributed across two datacenters, or one DAG for each location with no mailbox servers from a DAG across site? Which design would you recommend? Why? 2. Based on your recommendation for your DAG layout, where should the file share witness be deployed? Objective summary ■■ ■■ ■■ 50 DAG provides high availability when multiple database copies are created for the database the mailbox is hosted on. Creating a DAG and adding a mailbox server to DAG doesn’t automatically provide redundancy to the databases located on the mailbox servers. Failovers or switchovers can cause resource overconsumption if the number of failures in a DAG aren’t accounted for in the design. For example, if a mailbox server is designed for 5,000 active users and two servers in the DAG fail, resulting in two databases from other servers, each containing 3,000 users, can result in the mailbox server going over its designed limit of resource usage. This can have adverse effects on the service levels from degraded performance and slow response times or worse. When a DAG is designed to stretch across multiple sites, the file-share witness location is critical to ensuring high availability. The best practice is to locate the majority of the mailbox servers on the primary site. If users are located across multiple sites evenly, you should separate DAGs for each major site. Chapter 1 Install, configure, and manage the mailbox role Objective review Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter. 1. You are an Exchange administrator for Contoso, Ltd. You need to deploy a DAG without an administrative access point. What should you do? A. Deploy mailbox servers on Windows Server 2008 R2. B. Deploy mailbox servers on Windows Server 2012 R2. C. Deploy mailbox servers on Windows Server 2012. 2. You are an Exchange administrator for Contoso, Ltd. You need to move databases from the system drive to a new data drive. Select the required steps to complete the task successfully. A. Enable circular logging on the database. B. Disable circular logging on the database. C. Run Dismount-Database cmdlet. D. Run Move-DatabasePath cmdlet. 3. You are an Exchange administrator for Contoso, Ltd. You need to configure DAG networks to exclude SCSI network from replication. Which steps must you take? Select all that apply. A. Run Set-DatabaseAvailabilityGroup and set ManualDagNetworkConfiguration to $false B. Run Set-DatabaseAvailabilityGroup and set ManualDagNetworkConfiguration to $true C. Set-DatabaseAvailabilityGroupNetwork cmdlet and set IgnoreNetwork to $true D. Set-DatabaseAvailabilityGroupNetwork cmdlet and set IgnoreNetwork to $false Objective 1.4: Monitor and troubleshoot the mailbox role Maintaining a healthy and highly available Exchange 2013 environment requires monitoring the environment for issues affecting database replication, database copy activation, and mailbox role performance. Managed availability provides the monitoring and remediation of known issues when possible. But, that shouldn’t replace monitoring of the environment for misconfigurations or other environmental health issues, which can potentially result in larger unplanned outages if not addressed early. Objective 1.4: Monitor and troubleshoot the mailbox role Chapter 1 51 This objective covers how to: ■■ Troubleshoot database replication and replay ■■ Troubleshoot database copy activation ■■ Troubleshoot mailbox role performance ■■ Monitor database replication Troubleshooting database replication and replay In a normal operation, transaction logs are replicated to database copies, inspected for errors, and, if no errors are encountered, they’re replayed into the database copy. In case of lagged copy of a database, the logs are inspected, but not replayed until the lagged copy meets the lag time requirements. Log truncation also occurs on the active copy of the database when the truncation criteria is met and the process requires all of the copies to be healthy. All of the database copies must have replayed the log file to be truncated. In the case of lagged copies, the logs must have been inspected successfully. If one of the database copies doesn’t meet this criteria, log truncation can’t occur, even if circular logging is configured or the database backup has successfully completed. If a database copy is offline or unreachable, it can cause a problem in log replication and truncation. This is because an active copy won’t truncate any logs until all of the copies are verified. When the logs aren’t truncated, all of the database copies, including the active ones, keep accumulating logs. This creates the potential of running out of disk space if the faulty database copy isn’t remediated or removed to allow the truncation process to resume. When planned maintenance takes an extended amount of time, and unplanned outages make database copies unavailable, both developments affect database copies and the log truncation process. You can identify a copy with problems by running the Get-MailboxDatabaseCopyStatus cmdlet. Any copies with a copy queue length greater than zero, replay queue length greater than zero, or a failed or suspended state need to be investigated for cause and must be remediated. When you have a database with a copy queue length greater than zero, the replication service is unable to replicate the required log files from the active database copy to the given replica. If the problem is on the source server, all of the passive copies of the database will have a copy queue length greater than zero. This usually occurs when a required log file is missing. This could be the result of a misbehaving or misconfigured anti-virus, or even an accidental delete by an administrator. In such instances, restoring the missing file becomes necessary before the replication can resume. Once the missing log file is restored, run the Resume-MailboxDatabaseCopy cmdlet to resume the replication of log files to the passive database copies. If mailbox servers hosting passive database are configured with a different disk layout and capacity, or if the disk hosting replica is shared with another application for storage, it may 52 Chapter 1 Install, configure, and manage the mailbox role run out of disk space before the expected log truncation can occur. In this case, the affected database copy will have the copy queue length greater than zero. To resume log file copy from active database, address the disk space issue on the target server. When you have a database with a replay queue length greater than zero, the replication service is unable to replay the received log files into the database copy. In addition to the previously mentioned disk space and file level permission issues, this can also be caused by log file inspection failing to successfully inspect the received log files. Corruption of a received log file or file level anti-virus scanners are the common culprits, but they aren’t the only ones. When the database copy status is FailedandSuspended, the replication to the database is suspended and it is going to impact the log truncation process, as previously discussed. When a database copy is in this state, the detection of a failure requires manual intervention. A common cause for this error is when the server is unable to mount the database for the replay of log files, or the database has diverged from the active mailbox database to the point where it must be updated manually using the Update-MailboxDatabaseCopy cmdlet. As discussed in the previous section, Managing mailbox database copies, you can specify which database copy should be used as a source if the target server is in a remote site and you need to avoid replication over WAN links. The incremental resync feature included in Exchange 2013 is designed to automatically correct a divergence between database copies. When the incremental resync detects divergence, it searches a log file stream to locate a point of divergence, locates changed database pages, and then requests them from active copy. The changes are applied to the diverged database copy to bring it back in sync with the primary copy. Important to note is that when a database has reached failed and suspended status, the divergence can’t be repaired by the incremental resync process and manual intervention becomes a necessity. The database replication process also includes a content index catalog. The content index catalog is one of the components included in health checks, which is used by the BCS process. When a content index is corrupt, the Get-MailboxDatabaseCopyStatus shows the index state as FailedAndSuspended. Similar to the failed and suspended state of a mailbox database, the content index can be fixed by running the Update-MailboxDatabaseCopy cmdlet with the parameter CatalogOnly. Troubleshooting database copy activation For DAG to provide protection from failures and provide the ability to perform scheduled maintenance without affecting users, the passive copy of the database must be healthy and be able to mount as active copy when needed. Activating a database copy is a complex operation involving many components, such as Active Manager, cluster service, and quorum and network components. Not only does a database need to be healthy, but the underlying components must also be healthy and functional. Objective 1.4: Monitor and troubleshoot the mailbox role Chapter 1 53 When a database copy fails to mount, troubleshooting depends on symptoms and a combination of other factors. A methodical approach to troubleshooting yields the best results. Exchange 2013 also provides numerous events and tools that can be used to determine the status and possibly cause of the problem you’re trying to troubleshoot. The proactive use of such tools can help prevent an unexpected outage. One such tool is the Test-ReplicationHealth cmdlet. This cmdlet is designed to provide on demand an inspection of continuous replication, an availability of the Active Manager, the health and status of cluster service, and the quorum and network components. The cmdlet can be run locally on a mailbox server or remotely against a mailbox server that’s a member of a DAG. The following is a sample output of the Test-ReplicationHealth cmdlet. Sample output from Test-ReplicationHealth cmdlet [PS] C:\>Test-ReplicationHealth Server -----Server1 Server1 Server1 Server1 Server1 Check ----ReplayService ActiveManager TasksRpcListener DatabaseRedundancy DatabaseAvailability Result -----Passed Passed Passed *FAILED* *FAILED* Error ----- There were database... There were database... Each check against the given server checks the individual component or criteria for success or failure. You might have noticed that Server1 in the previous example has passed three checks and failed two. The first three checks are to ensure replication service is running, Active Manager is running and has a valid Primary Active Manager or Secondary Active Manager role, and the tasks listener is running and listening for remote requests. The database redundancy and availability checks ensure that you have more than one copy of the database configured and that those copies are healthy. When the first three checks fail, you need to ensure that the relevant services are running and, in case of Active Manager, the cluster service is functioning and Active Manager can communicate with other DAG members to achieve quorum. If the database redundancy and availability checks fail, first you need to make sure the database in error is configured to have more than one copy. And for the databases with multiple copies, check the reason of failure by checking the detail status of each component provided by the cmdlet. The replication issues previously discussed can also be a contributing factor to the redundancy and availability check failures. Be sure to perform the necessary troubleshooting, as discussed earlier. Besides replication and copy configuration issues, database copy activation is also affected by configuration, which might not necessarily be a misconfiguration. For example, a mailbox server can be configured to block database activation on a given server. This is usually the case when an administrator wants to perform maintenance on the server and has configured the server to avoid the activation of databases during the maintenance 54 Chapter 1 Install, configure, and manage the mailbox role window. It is also possible to configure the DatabaseCopyAutoActivationPolicy parameter of the Set-MailboxServer cmdlet to the value IntrasiteOnly. This configuration enables an administrator to restrict the activation of the databases to the same site as the server where the database is currently active. This prevents cross-site failover and activation. While this isn’t a misconfiguration, it can certainly block the activation of a database copy on a given server. Other configuration parameters that can affect database activation on a server are MaximumActiveDatabases and MaximumPreferredActiveDatabases. These parameters are designed to provide a mechanism that can help address design requirements. For example, if a mailbox server is designed to host 10 active databases with 5,000 users each, the server can still host more than 10 active database copies. This creates a potential of degraded server performance when more databases on the server are activated than the server is designed to handle. The MaximumActiveDatabases and MaximumPreferredActiveDatabases are designed to protect against such degradation by enabling administrators to configure preferred active database value. Limiting maximum number of active and preferred databases can help optimize server performance by hosting only the number of databases the server is designed to handle.. While it might seem that two parameters have the potential of conflict, MaximumPreferredActiveDatabases is only honored during the best copy and server selection, the database and server switchovers, and when rebalancing the DAG. So, preferred active database limit is a soft limit that should be configured for lower optimum active number of databases, whereas, the maximum active databases should be a number higher than the preferred active database number and should match the designed mailbox server capacity for maximum active databases. When a database fails to mount, ensure you’re not only checking for errors or database copy, Active Manager, cluster, network and server health conditions, but are also accounting for configuration parameters that might block activation of a database copy on a given server. NOTE BEST COPY SELECTION PROCESS While it isn’t covered here, it’s important to understand how the best copy selection (BCS) process finds a database that may best meet availability needs while minimizing potential of service interruption and data loss. More information about BCS can be found in this TechNet article at http://technet.microsoft.com/en-us/library/dd776123(v=exchg.150).aspx. Troubleshooting mailbox role performance When a server is unavailable, redundancy features for transport and high availability features for a mailbox role continue to provide service to end users. But what happens when a server is functional, but its performance is severely degraded? Exchange 2013 has numerous workloads, each with its defined function. Replication service, for example, is responsible for the replication of log files to database copies, among other functions, and transport component is responsible for the routing of messages. Each resource consumes system resources, such as CPU, memory, and network resources. Objective 1.4: Monitor and troubleshoot the mailbox role Chapter 1 55 Each user connecting to the Exchange 2013 servers also consumes resources. The client application or mobile devices they use can have a direct impact on how many resources are consumed by a user. Actions taken by a user, such as changing a view in Outlook or performing a long-running search query against an archive mailbox, can also have an impact on the mailbox server resources. Third-party applications connecting to Exchange using one of many protocols also have an impact on resource consumption on mailbox servers. Exchange 2010 provided user-throttling functionality, which allowed controlling how resources are consumed by individual users. This capability is available and is expanded for Exchange 2013. When released, Exchange 2013 also offers system workload management, which applies to system components and their impact on resource usage. The cmdlets enabling you to manage system workloads have been deprecated. The deprecated cmdlets include *-ResourcePolicy, *-WorkloadManagementPolicy, and *-WorkloadPolicy system workload management cmdlets. New features in Exchange 2013 enable users to increase resource consumption for short periods without experiencing throttling or complete lockout. While lockout can still occur if users consume large amounts of resources, the lockout is temporary and the user is unblocked automatically as soon as usage budgets are recharged. You can set the rate at which users’ resource budgets are recharged. Exchange 2013 also uses burst allowances to let users consume a higher amount of resources for short periods of time without any throttling, while implementing traffic shaping to introduce small delays, before user activity causes a significant impact on the server. Introducing small delays reduces the request rate from the user, but it’s mostly unnoticeable by the user. This mechanism also helps prevent or reduce user lockouts. Throttling policies in Exchange 2013 are managed by scopes. The built-in throttling policy has Global scope. This policy applies to all users in your organization, but it shouldn’t be confused with the policy that has an Organization scope. The purpose of the organization policy is to allow customization of throttling parameters, which has different values from the defined default values in global policy. If you need to customize any of the built-in throttling parameter values, you shouldn’t modify global policy, since it might be overwritten by future updates. Instead, you should create an organization policy and include only parameters that have a different value from global policy. This policy applies to all users. You can also create a policy with the throttling scope as Regular. These policies can be applied to individual users, instead of the Global scope of the abovementioned policies. The Regular scope policies are quite useful when you need to change throttling behavior for only a small subset of users or applications. To manage throttling configuration, use the *-ThrottlingPolicy cmdlets. For example, you can use the New-ThrottlingPolicy cmdlet to create a new throttling policy with the Regularthrottling policy scope. After customizing the required parameters, you can assign this policy to individual user mailboxes as needed, using the Set-ThrottlingPolicyAssociation cmdlet. Or, you can also configure throttling policy assigned to a user using set-Mailbox cmdlet. Many resources can be applied to a policy. You can refer to the individual parameters in this TechNet article at http://technet.microsoft.com/en-us/library/dd351045(v=exchg.150).aspx. 56 Chapter 1 Install, configure, and manage the mailbox role NOTE SYSTEM WORKLOAD MANAGEMENT While deprecated, you should familiarize yourself with workload classifications. The classifications Urgent, Customer Expectation, Internal Maintenance, and Discretionary are prioritized, with Urgent receiving the highest priority and Discretionary receiving the lowest. Monitoring database replication Exchange 2013 provides built-in mechanisms to monitor database replication and database failovers. Mailbox database copy status provides vital information about given database copies. Although you read about this earlier, let’s look at some of the status information the mailbox database copy returns and what it means. ■■ ■■ ■■ ■■ ■■ ■■ ■■ Failed When a database is in a failed state, the copy is unable to copy and replay log files, and it isn’t suspended by administrative action. Because the copy isn’t suspended, the system retries the failed operation periodically. If the system succeeds (for example, when the transient issue is resolved), the copy is marked as healthy. Suspended The database copy state changes to suspended when administrative action, such as running the Suspend-MailboxDatabaseCopy cmdlet, suspends the database copy. This isn’t an error state because it’s the direct result of an administrative action. Healthy The database copy is copying and replaying log files successfully. ServiceDown When the Microsoft Exchange Replication Service isn’t reachable or isn’t running on the server that hosts the database copy, this state is reported. Manual intervention to remediate the faulty service is required. Resynchronizing The mailbox database copy is suspected to have diverged from the active database. The system compares a diverged database copy with an active copy and tries to detect and resolve a divergence. The database copy returns to a healthy state if the divergence is resolved. If the error can’t be addressed, the copy is transitioned to a FailedAndSuspended state. DisconnectedAndHealthy This state is an indication that the database copy was in a healthy state before the loss of connectivity between an active database copy and the database copy reporting this state. Investigate network communication to remediate. FailedAndSuspended When a database copy is in this state, it requires manual intervention to remediate the underlying issue that caused the copy to fail. Unlike the Failed state, the system won’t retry the failed operation periodically. Because of the verbosity and variety of status reported, the Get-MAilboxDatabaseCopyStatus can serve as a great monitoring and troubleshooting tool for database copies. The Test-ReplicationHealth cmdlet is another such tool that can provide great insight into the replication of health of database copies, as previously discussed. Objective 1.4: Monitor and troubleshoot the mailbox role Chapter 1 57 Another great source of information regarding high-availability system state and mailbox database failures is crimson channel event logs. In addition to the well-known Application, Security, and System event logs provided by Windows, a new event channel was introduced in Windows Server. Crimson channel event logs store events from a single application or a component, making it easier for the administrator to find relevant events. Exchange 2013 logs events to crimson channels HighAvailability and MailboxDatabase FailureItems for DAG and database copies. The HighAvailability channel contains events related to startup and shutdown of the replication service. The HighAvailability channel is also used by Active Manager to log events related to Active Manager role monitoring and database action events, such as database mount operations and log truncation. The MailboxDatabaseFailureItems channel is used to log events associated with any database copy failures. When the database copies failover without administrative action, it might be important to find out what caused the database copy to failover, whether it was an administrative action, and why a passive copy was selected for activation. While this information is logged in the crimson event channels mentioned earlier, a correlation of multiple related events may be time-consuming. Exchange 2013 includes a script called CollectOverMetrics.ps1, which reads DAG member event logs and gathers information about database operations over a specified time period. The result of running this script can provide insight into information, such as the time at which switchover/failover operation started and ended, the server on which the database was mounted, the reason for operation such as administrative action or a failure, and if the operation completed successfully or failed to complete. The output is written to a CSV file and an HTML summary report can also be generated. CollectReplicationMetrics.ps1 is another such script that collects metric in real time. The script collects data from performance counters related to database replication. The script can collect performance counter data from multiple mailbox servers, write the data to a CSV file, and report various statistics. Thought experiment Database failovers In this Thought experiment, apply what you learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter. You are a consultant helping Contoso, Ltd. troubleshoot its Exchange 2013 environment. The manager states that the databases frequently fail over to different servers and don’t always honor their activation preference. Many times, the databases failover to a third server located in a remote site, which results in slow response times. Contoso wants you to recommend how to determine the cause of the failovers and how to prevent databases from failing over to a remote site. What would you recommend to address the stated concerns? 58 Chapter 1 Install, configure, and manage the mailbox role Objective summary ■■ ■■ ■■ The mailbox role performance is actively managed and internal processes are automatically throttled when the system is under stress and required resources could be scarce. Exchange 2013 allowed for the configuration of system workload policies on release, but an improper configuration might cause adverse effects, hence, the *-WorkLoadPolicy cmdlets have since been deprecated. User actions could have an adverse impact on server performance. Exchange 2013 includes a default Global throttling policy to prevent a user or a third-party application from monopolizing resources on the server. If a change to the built-in throttling parameters is required, the best practice is to create a new Organization throttling policy and include parameters that differ from the built-in policy. A throttling policy with Regular scope can also be created if changes only need to apply to a single user or a subset of users. Database replication, replay, and copy activation functionality is dependent on many environmental health and configuration factors. Anything from disk space issues to network connectivity can affect availability of a database copy or failure to replicate data from active copy to other copies. Built-in Exchange cmdlets and event logs provide important insight into what could be a potential cause and understanding status codes can help reduce the time to resolve the issue by methodically approaching the troubleshooting and remediation. Objective review Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter. 1. When a mailbox database copy is activated on a different mailbox server, you’re asked to determine whether the copy failed as the result of an error on the active copy or because of an administrative action. Which of the following tools would you use? Choose all that apply. A. CollectOverMetrics.ps1. B. Crimson event logs. C. Search-AdminAuditLog. D. Get-DatabaseAvailabilityGroup 2. When troubleshooting replication errors for a database copy, you notice all the copies of the database have a copy queue length greater than zero. You verified that all servers hosting passive database copies are able to communicate to the server hosting active copy. Which of the following has the potential to cause this issue? A. Low disk space on servers hosting replica database copies. B. The required log file is missing on the server hosting the primary copy. Objective 1.4: Monitor and troubleshoot the mailbox role Chapter 1 59 C. A network issue resulting in the transmission failure of required log files. D. TCP chimney offload configuration is incorrect on nerwork adapter. 3. When troubleshooting a DAG, you noticed that performance on a Mailbox server is degraded. You noticed that it has more active mailbox databases than the server is designed to host. Which action can help ensure only defined number of mailbox databases can be active at a time? A. Run Set-MailboxServer cmdlet. B. Run Update-MailboxDatabaseCopy cmdlet. C. Run Set-DatabaseAvailabilityGroup cmdlet. D. Run Add-ServerMonitoringOverride cmdlet. Objective 1.5: Develop backup and recovery solutions for the mailbox role and public folders Objectives that define what’s expected are as important as capabilities of a backup and recovery solution. Time required to recover data, also known as Recovery Time Objective (RTO), and the point to which the data must be restored, also known as Recovery Point Objective (RPO), are two of the most important design objectives for any backup and recovery solution. Without defined RPO and RTO objectives, a backup and recovery solution can only be as good as the guesswork of IT departments of what users expect of the system. Even though designing a backup and recovery solution is beyond the scope for this book, understanding what defined RPO and RTO mean to Exchange 2013 is important. You learn about the features and functionality of Exchange 2013 that can help with the restoration of data and meet RPO/RTO objectives when data loss has occurred. This objective covers how to: ■■ Manage lagged copies ■■ Determine most appropriate backup solution/strategy ■■ Perform a dial tone restore ■■ Perform item-level recovery ■■ Recover the public folder hierarchy ■■ Recover a mailbox server role Managing lagged copies Lagged copies are database copies configured to lag the log replay into the passive copy of the database. Exchange 2013 allows for a maximum of 14 days of lag. Unlike regular database copies that are designed to provide high availability, lagged copies are designed to provide 60 Chapter 1 Install, configure, and manage the mailbox role protection against logical corruption. Logical corruption can occur when the data is expected to be written to disk, but despite an acknowledgement, the disk subsystem fails to write data to the disk. This is also known as a lost flush. Another possibility is that an application can add or update mailbox data in a way that isn’t expected by the user. Unexpected malformed data is a valid MAPI operation for Exchange server, known as a store logical corruption. While Exchange server has a built-in detection mechanism that detects and tries to correct lost flush occurrences, operations that cause store logical corruption are valid MAPI operations. Such corruptions require external backup mechanisms, such as a lagged database copy to prevent data loss. The time it takes to recover data using a lagged copy depends on the configured lagged time for the lagged copy, the amount of logs that needs to be replayed to get to the point before corruption, and the speed at which the underlying hardware can replay the logs into the copy used for recovery. Creating a lagged database copy is as simple an operation as creating a regular database copy. When creating a lagged copy, you need to run the Add-MailboxDatabaseCopy cmdlet with the ReplayLagTime parameter, configured with lag time span in dd:hh:mm:ss format. The TruncationLagTime parameter provides the ability to delay the truncation of logs that have been replayed into the database. You can set the truncation lag to the maximum of 14 days, which is similar to the replay lag time, but it shouldn’t be used on its own to provide protection against corruption. The important difference is the status of the database. Replay lag time prevents logs from updating the database copy by stopping the log replay up to the configured lag time. This provides you with the ability to replay only the logs required before the time of corruption. Truncation lag preserves the logs, but only after it has been replayed in the database. If a lagged copy is an important aspect of your data recovery strategy, you also need to make sure a single-lagged copy isn’t susceptible to corruption itself. Storing lagged copy data on a RAID array, or having multiple lagged database copies is ideal, so a disk failure or corruption doesn’t invalidate your lagged copy. When configuring lagged copies, you also need to account for the additional disk space required to store additional logs that would otherwise be truncated. The importance of required disk space is worth stressing because for a very active user profile, the amount of daily mail storage can be high. Now add many active users to make up a database and you might account for more than a few gigabytes of space daily. If the database copy is lagged to a maximum of 14 days, it can easily balloon to a considerable log storage. When you configure a lagged copy, it’s also important to configure SafetyNet hold time to be equal to or more than lag time. This allows a lagged copy to request missing emails from SafetyNet successfully when activated. Increasing SafetyNet hold time has a direct impact on the disk space required to store emails protected by SafetyNet. If SafetyNet is configured to exceed the lag time of a lagged database copy, the lagged copy can be activated without replaying the pending log files. This is because the activated Objective 1.5: Develop backup and recovery solutions for the mailbox role and public folders Chapter 1 61 copy requests the missing emails from SafetyNet, and SafetyNet can provide emails from the configured lagged time window. When a database copy is created in DAG, the BCS process can select lagged copy for activation if it’s the only copy available for activation when the active copy of the database fails. You can exclude a lagged database copy from the BCS process by suspending a database copy with the ActivationOnly parameter. This only excludes the database copy from activation, while allowing the logs to be replayed up to the configured lag time. When activating a lagged copy, the best practice is to make a copy of the lagged database and log files first. This provides you with an additional copy in cases where an activated lagged copy may be determined not to provide all of the data expected, and you might need relay additional logs or fewer logs than originally determined. Objective 1.3, previously discussed, covers the process of activating a lagged mailbox database copy. Determining the most appropriate backup solution/ strategy When considering appropriate backup solutions, understanding the impact of defined SLAs, such as RPO and RTO, is critical. For example, if the requirement dictates that the backup solution must be able to protect the environment from database corruption for up to 30 days, lagged copies can’t help protect the data due to its maximum configurable lag of 14 days. If a requirement dictates that the time to restore data after data loss is reported must be less than 24 hours, you must account for the time it takes for offsite tapes to arrive, the time it takes to restore data from the tapes to the disk, the time it takes to replay restored logs and bring the database to its consistent state, and the time it takes to extract data from the recovery database into a PST file or a target mailbox. DAGs provide the ability to recover not only from the disk, server, and other local failures, but also from disaster scenarios when DAG is spanned across sites, providing site resiliency and disaster recovery capabilities. Exchange 2013 also provides the ability to recover accidentally deleted items using its single-item recovery features. When combined with an appropriate retention policy, this provides a vast improvement over using tape-based backup and restore strategy, which takes considerable time to restore a few items from the backup. Compliance and data loss prevention features of Exchange 2013 reduce the time to recover deleted items, while reducing administrative overhead associated with the restore process. Even when using lagged database copies for recovery, the size of individual mailboxes and the size of the database on disk are the factors that greatly impact your ability to restore data while meeting RPO and RTO requirements. Exchange 2013 supports large mailboxes and databases that can be larger than 2 terabytes (TB). When recovering such mailboxes, it takes time to extract data from a lagged copy to the recovery database, and then onto the 62 Chapter 1 Install, configure, and manage the mailbox role target mailbox or PST). As the mailbox size grows, so does its time to recover. While restoring data from tape eliminates time, lagged copies still need a replay of logs required to reach the determined point in time for successful recovery. The larger the database, the greater the amount of stored logs that need to be replayed into the lagged copy, directly impacting the time it can take to recover the data. When selecting backup technologies for Exchange, you also need to ensure the selected backup technology is supported by Exchange 2013. Exchange server currently supports only Volume Shadow Copy Service (VSS)-based applications that support VSS writer for Exchange 2013. This requirement ensures that Exchange is made aware of the backup process start and completion times, as well as other important information that helps Exchange determine the state of backup and, upon successful completion, Exchange can truncate log files appropriately. The VSS writer functionality that was part of the Microsoft Exchange Information Store service was moved to the Microsoft Exchange Replication service. This new writer, named Microsoft Exchange Writer, is now used by Exchange aware VSS based applications, allowing them to backup from active or passive database copies. Providing protection against the deletion of an entire mailbox is also built-in to Exchange 2013. When configuring a mailbox database, you have the ability to specify two retention- related parameters. While the DeletedItemRetention parameter doesn’t provide the retention of an entire deleted mailbox, it enables you to configure the amount of time individual items deleted from a mailbox are retained and can be recovered. By default, this retention period is 14 days. This retention attribute applies to all mailboxes that don’t have their unique deleted item retention value defined. MailboxRetention is the attribute that provides the ability to configure the retention period for a mailbox that was deleted. The database cleanup process won’t delete the deleted mailbox permanently until after the configured mailbox retention time requirements are met. If the deleted mailbox needs to be restored within the mailbox retention period, the administrator doesn’t need to rely on any lagged copies or other backup/restore applications. You can configure deleted item retention and mailbox retention parameters using the Set-MailboxDatabase cmdlet. With the ability to integrate a Lync 2013 server with an Exchange 2013 server, administrators can choose to store user’s Lync contact information in the Unified Contact Store, which is located in the user’s mailbox. If a backup being restored exists before the time the Unified Contact Store integration was enabled, the restored data won’t contain the user’s Lync contacts. This results in the loss of Lync-related data while restoring the requested mailbox data. If the backup doesn’t contain the user’s Lync contacts, then it’s important to determine the status of the Unified Contact Store and to move the user’s contacts to the Lync server before performing the restore. The other important consideration is the time passed between the backup and the restore request. The user might have added more contacts since the last backup that contains their Unified Contact Store data. Restoring such backup results in losing the contacts added after the backup was performed. This can be prevented by moving a users’ contacts back to the Lync server. Objective 1.5: Develop backup and recovery solutions for the mailbox role and public folders Chapter 1 63 Performing a dial tone restore Dial tone recovery allows the restoration of service to be separated from the restoration of data. In case of a data loss due to server or site failure, where restoring data from backup is the only option, you might want to provide users with the ability to continue sending and receiving emails while the lost data is being recovered. Using dial ti recovery, you can create an empty database on the same server in case of the loss of database or, on an alternate mailbox server, in case of a server failure. Users can continue using their mailbox to send and receive emails while the data is being restored. Once data is restored successfully, the administrator can merge the data, completely restoring the user’s mailbox. If the database has failed, but the server-hosting original database is still functional, you can choose to create a dial tone database on the same server. This eliminates the need to reconfigure client profiles that were configured manually. If the server hosting the original mailbox database suffers hardware failures, you can create a dial tone database on a different server. Clients using Autodiscover are automatically updated to a new server. Clients configured manually might need to be updated to connect to a new server before they can connect to the dial tone database. The process of performing dial tone recovery is mostly similar in both cases, with minor differences. Additional steps, which are listed here, are required when using a different server for dial tone recovery. 1. Create an empty dial tone database to replace the failed database. Creating the empty dial tone database is no different than creating a new mailbox database using the New-MailboxDatabase cmdlet. But you might want to make sure that any existing files of the database being recovered are preserved. This can be helpful if the files are needed for recovery operations. Create the dial tone database using the New-MailboxDatabase cmdlet. After creating the new database, all of the users from the failed database need to be homed to the newly created dial tone database. Use the Set-Mailbox cmdlet to rehome all of the affected mailboxes to the new dial tone database. Mount the dial tone database to allow client computers to connect and start using the new empty mailbox. For computers using Autodiscover, the configuration should be automatic. For clients with manually configured profiles, manual configuration needs to be updated before clients can connect to the dial tone database. 2. Restore the old database. Restoring the old database depends on your backup method. If you’re relying on a lagged copy, determine the point in time to which you need to restore. Replay the required logs into a copy of the lagged database to bring the database to a consistent state. If you’re using VSS-based backups using Windows Backup or third-party backup software, restore the database using its respective restore mechanism. 64 Chapter 1 Install, configure, and manage the mailbox role REAL WORLD MAILBOX DATABASE RESTORE AND LOG FILE REPLAY When using third-party software, most software also includes an option to mount the database after restore. While this might sound like a good option, it’s important to understand what happens when mounting a restored database. When you mount a restored database, Exchange replays the required logs before mounting the database when it determines the database is in Dirty Shutdown state. Unless you dismount the database for each backup, every backed up database will be in Dirty Shutdown state, which is expected. While backup software attempting to mount the database and replaying the log files automatically might seem less administrative effort, when the mount process fails for one reason or another, the impact is apparent. It takes much more time to restore data from tape than to copy it from one disk to another. If you have the capacity on the server, it’s better to restore the data, but not to mount the database automatically; make a copy of the restored data; and then use eseutil to bring the restored database to a consistent Clean Shutdown state. If eseutil fails to bring the database to the consistent state, you can use the second copy on disk instead of reverting to tape for the restore. If the failure doesn’t require you to revert to a specific point in time, you can copy the logs from the point of backup to the current time if they’re available from the failed copy. This lets you roll the database forward to the point of failure. This preserves all possible data up to the point of failure. Use eseutil to replay the log files and bring the database to a consistent Clean Shutdown state. While this isn’t required, it provides better control over a recovery process and enables you to address any failures more interactively than mounting the database and allowing it to replay the logs. Create a recovery database. If you used eseutil, the recovery database won’t be used for the log replay process. If you didn’t use eseutil to bring the database to a consistent state, copy the recovered database and all of the required log files to the recovery database location. Mount the recovery database to force log replay and bring the recovered database to a consistent state. Dismount the recovery database after it mounts successfully, and then copy the recovered database files to a safe location. 3. Swap the dial tone database with the restored database. At this point, your users are using a dial tone database and you have recovered the failed database. Now you need to swap the database files, so the dial tone database files are replaced with the recovered database. The dial tone database is smaller compared to the recovered database, so it’s easier to take dial-tone database files, mount them in a recovery database, and merge the dial tone data with the recovered data, while users connect to their recovered mailbox and continue to use the service. This process involves downtime and, until the dial tone data is merged with the recovered database to which users are connected after the swap, users won’t be able to access their newly created data. Objective 1.5: Develop backup and recovery solutions for the mailbox role and public folders Chapter 1 65 To swap the database, dismount the dial tone database and copy the dial tone database files containing newly generated user data to the recovery database file location. Ensure you have preserved and moved the recovered database to a safe location to avoid the risk of overwriting recovered data in the recovery database location. Now, copy the recovered database from the safe location to the dial-tone database file location, and mount the dial tone database. As discussed earlier, users can connect to their mailboxes containing recovered data, but they won’t have access to their newly created data. Mount the recovery database, which now contains the new dial tone data generated by users after the creation of the dial tone database and before the swap with the recovered data. 4. Merge the data from recovery database to the dial tone database. At this point, you can issue New-MailboxRestoreRequest against each mailbox from the dial tone database. Use the recovery database as the source, and the mailbox on the dial tone database as a target, merge the dial tone data from the recovery database to the dial tone database. Once complete, users have access to both recovered and dial tone data. The recovery process is complete and the recovery database can now be removed. Performing item-level recovery When a user deletes items from their mailbox and the restoration of the items is required at a later date, either for legal discovery or because the user needs access to the accidentally deleted data, compliance and retention features of Exchange 2013 provide administrators with the flexibility to perform such recovery without requiring a lengthy recovery process of restoring from backups. This certainly impacts the online storage capacity and database size, and it must be carefully balanced not to impact one aspect of the system while addressing another. The recoverable items folder provides the ability to retain the deleted items when the user accidentally deletes the mailbox items, or the items are deleted on purpose including purging, where the user is intent on permanently removing items from their mailbox. When the user empties the deleted items folder or uses hard delete, folders within the recoverable items folder, which are only accessible by the administrator, allow for the recovery of such items to meet recovery and compliance needs of the organization. When a litigation hold or a single item recovery is enabled for a mailbox, the items that are hard deleted or removed from the deleted items folder are stored in the Purges folder in the user’s mailbox. This folder isn’t accessible to the user. Enabling a single item recovery is a simple operation of setting the SingleItemRecoveryEnabled parameter to $true using the Set-Mailbox cmdlet. 66 Chapter 1 Install, configure, and manage the mailbox role Recovering messages using single item recovery is a two-step process. The search performed to find deleted messages recovers found items from the user’s mailbox to a defined mailbox, which can be any other mailbox except the source from which the messages are being recovered. While this isn’t a requirement, the discovery mailbox is typically an ideal target for such operations. After the data is recovered into the target mailbox, the next step is to restore the recovered items to the source mailbox or to a PST file if needed. To perform the search, issue the Search-Mailbox cmdlet with the SearchQuery parameter. Search query uses Keyword Query Language (KQL) syntax. KQL includes search elements such as subject, sender, and other email properties or free-form test search looking for specific content within a message. You also need to specify the mailbox where items found by search query are stored. Once the items are found and recovered to a specified mailbox, the next step is to run the same Search-Mailbox query on the mailbox where the items are recovered, and use the user mailbox as a target. This copies the recovered items from the mailbox used as a target in the first step to the user’s mailbox. You can also use the DeleteContent parameter in this step to delete the recovered items from the source mailbox after the content is restored to the user’s mailbox. If these steps are used for legal discovery process, the final target mailbox might not be the user’s mailbox and you could need to adjust the second step of the process accordingly. If you need to export recovered data from the first step of the single item recovery process to a PST file, you can use the New-MailboxExportRequest cmdlet to extract data from the mailbox where it’s stored after running the Search-Mailbox cmdlet in the first step. You also need to specify a file share location that Exchange server has permission to, ideally an Exchange server, in order to avoid permission issues. This location is then used to store the exported PST file. While not directly a backup or restore requirement, you might have instances where a user reports corruption on their mailbox items, such as folders reporting on an incorrect item count or search folders not functioning as expected. This isn’t a data loss, but a corruption of items that exist in the mailbox database. Exchange 2013 provides the ability to address such corruption using the New-MailboxRepairRequest cmdlet. When you issue the cmdlet, you can specify a mailbox to run the repair request against a mailbox database if you believe corruption is affecting more than one mailbox in a given database. The operation of running a repair request is disruptive and the mailbox being repaired is unavailable for the duration of the repair operation. Because of the disruption potential and performance impact on the server, only one repair request can be active for a given database and only 100 repair requests can be active for a mailbox-level repair per server. Objective 1.5: Develop backup and recovery solutions for the mailbox role and public folders Chapter 1 67 Recovering the public folder hierarchy Recovering public folder data historically has been a difficult request. Because public folders are now located on a mailbox database and use similar mailbox architecture, the recovery of data follows a similar logic as discussed in previous topics. Depending on whether or not the deleted items are within the retention window, you need to restore data either by using Outlook, by using the Recover Deleted Items option, or by using the recovery database if data needs to be restored from earlier backups. However, the mailbox containing the public folder hierarchy plays a vital role for the public folder infrastructure. The loss of a primary or secondary hierarchy mailbox requires a restoration process that’s different for a primary and a secondary hierarchy mailbox. The impact of losing a secondary hierarchy mailbox means user mailboxes configured to use that mailbox for a hierarchy might connect to other hierarchy mailboxes in the environment, which might not be optimal, depending on the user location. Most commonly, the public folder account hosting the secondary public folder hierarchy is also used to store the public folder content. When such a public folder mailbox is accidentally deleted, users are unable to access data contained in the deleted public folder mailbox. When a secondary hierarchy mailbox is accidentally deleted, if it’s within the database retention period, it can simply be restored using the same steps as a user mailbox. You can simply connect the public folder mailbox back to the related Active Directory user account, which is created and disabled automatically when a public folder mailbox is created. If the Active Directory account deletion is the cause of the public folder mailbox being deleted, you can simply create a new user, disable it, and connect the recovered public folder mailbox to it. Use the Connect-Mailbox cmdlet to connect the disabled public folder mailbox to the related Active Directory user. If the deleted mailbox is beyond the retention period, you need to recover the mailbox using the backup and recovery database. The process is similar to recovering a user mailbox. If the deleted public folder mailbox contains public folder data as well, you must also point the public folders hosted on the deleted mailbox to an existing public folder mailbox or a newly created public folder mailbox. Use the Set-PublicFolder cmdlet with the OverrideContentmailbox parameter to point the public folder to an existing public folder mailbox. If you need to also restore the data from the deleted public folder, include the IncludeFolders switch. When a primary public folder hierarchy mailbox is deleted, the impact on the public folder environment is bigger. This is because the primary hierarchy mailbox is the only mailbox in the environment that hosts writable copy of the hierarchy. When the only writable copy of the hierarchy is missing, you can’t create new public folders. When using EAC, administrators are able to see the list of public folders in the environment. While the restore process of the public folder mailbox with the primary copy of hierarchy is similar to other mailboxes, the restoration of the mailbox immediately initiates the full hierarchy sync with all the secondary hierarchy mailboxes. All of the changes made to the 68 Chapter 1 Install, configure, and manage the mailbox role hierarchy between the time the primary hierarchy mailbox was last backed up and when it was deleted are lost. This includes newly created public folders and any updates to permissions on public folders. This is also why it’s critical to protect public folder mailboxes hosting primary hierarchy using multiple database copies on DAG, as well as to review backup procedures to ensure appropriate coverage exists to reduce exposure to data loss affecting the hierarchy and public folder permissions and content. The public folder account in Active Directory can be protected by enabling the feature Protect object from accidental deletion on the Active Directory container where the account is located. Recovering a mailbox server role When you lose a mailbox server due to a hardware issue or another event affecting the mailbox server, your mailboxes might survive the event if the server was a member of a DAG and if databases were configured with additional copies. If the server wasn’t a member of a DAG or the affected databases weren’t replicated, you can use concepts discussed earlier in this chapter to restore databases on different hardware, if available. Recovering a mailbox server from failure requires the replacement hardware to have similar performance characteristics, have the same operating system version, and have the same drive letters and/or mount point configuration. You also need to determine the installation path if Exchange 2013 was installed in a nonstandard location. Because every Exchange server object is stored in the Active Directory, you can retrieve the install path from the Active Directory object using ADSIEdit or LDP.exe, if necessary. You can do so by inspecting the msExchInstallPath attribute on the Exchange server object located in the Configuration partition of Active Directory. Once required information is available, reset the Active Directory account of the failed mailbox server. For recovery to succeed, you need to install the same operating system on the replacement server and name the new server with the same name of the failed server. The recovery will fail if the same name isn’t used on the replacement server. Join the server to the Active Directory domain. This step will fail if you didn’t reset the Active Directory account of the failed server because you’re trying to join the new server to the domain using the same name. After successfully joining the domain and installing the required prerequisites for Exchange 2013, you can start the Exchange 2013 setup using a command-line setup with switch /m:RecoverServer. You must also use the /TargetDir switch if Exchange was installed in a nonstandard location on the server. After the setup is complete, you might need to restore any custom settings applied to the failed server. If the failed server was a member of a DAG and contained replicated database copies, the process looks slightly different. Before you start with any of the previous recovery steps, you need to remove any existing mailbox database copies from the failed server. This is a configuration change only because the server doesn’t exist anymore. Use the Remove-MailboxDatabaseCopy cmdlet to do so. Similarly, you also need to remove the failed server’s configuration from the DAG by using the Remove-DatabaseAvailabilityGroupServer cmdlet. You might even need to use the ConfigurationOnly switch if the failed server isn’t Objective 1.5: Develop backup and recovery solutions for the mailbox role and public folders Chapter 1 69 reachable on the network. You also need to evict the failed server node from the cluster using the Remove-ClusterNode cmdlet with the Force switch. After performing these steps, perform the server recovery process mentioned earlier. Because the server was part of a DAG, after recovery you need to add the server back to the DAG using the Add-DatabaseAvailabilityGroupServer cmdlet. Add the mailbox database copies that existed on the server before the failure using the Add-MailboxDatabaseCopy cmdlet. Ensure that lag configuration is accurate for the lagged copies that might have existed on the server before the failure. Thought experiment Legal hold In this Thought experiment, apply what you learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter. You are a consultant, who is engaged by Contoso, Ltd. to assist with the planning and deployment of appropriate data protection strategies for its Exchange 2013 environment. This company is often a target of lawsuits and must retain email records for the executives who could be involved in a litigation process. The emails must be retained, even if the user intentionally deletes them. The emails must be available as long as the litigation process requires and a litigation process averages six months. The solution must require the least amount of administrative effort to produce emails required by the litigation team. Can you use lagged copies to achieve the stated goals? Why? Objective summary ■■ ■■ ■■ 70 When configuring lagged copies, the impact on storage is higher because you are required to store larger amount of logs that can’t be truncated like normal database copies. You should also account for additional storage space when a lagged copy needs to be used for the recovery process, because it’s ideal to preserve an extra copy before replaying logs into lagged copy during the recovery process. If relying on SafetyNet when activating a lagged copy for recovery, the SafetyNet configuration must match or exceed the lag time configured on lagged copy to be effective during the recovery operation. Dial tone recovery is a fine balance between service availability and data availability. If data must be available when the user is accessing their mailbox, using dial tone might not be an effective strategy. In such cases, users could be without email access until the required data is restored. Chapter 1 Install, configure, and manage the mailbox role ■■ ■■ ■■ When using dial tone recovery, downtime can’t be completely eliminated. When data is restored from backup, swapping the recovery database with the dial tone database involves downtime. To eliminate downtime, you can merge data from the recovered database to the dial tone database. But the time it might take to completely restore all of the data depends on the amount of data that needs to be merged from the restored database. This is always higher than the data contained in the dial tone database for each user. Single item recovery reduces administrative overhead and provides protection, both accidental and intentional deletions by the users, but the feature isn’t enabled by default. Single item recovery and litigation hold can provide the ultimate protection against data loss, but at an additional cost for storage and other resources. While recovery of public folder hierarchy is significantly simplified compared to previous versions of Exchange server, careful planning is still required to prevent the loss of the primary hierarchy mailbox. Because public folder mailboxes can be hosted on regular mailbox databases and can be protected by a DAG, it’s highly recommended to configure multiple database copies and include site resilience in the architecture where feasible. Objective review Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter. 1. An Exchange administrator reports that a lagged copy was activated during an outage at a primary datacenter. The administrator has since reconfigured the lagged copy, but wants to prevent it from being activated in the future without manual intervention. What must you do to configure the lagged copy to meet the stated requirements? A. Suspend lagged copy. B. Suspend lagged copy for activation only. C. Remove permissions assigned to the Exchange Trusted Subsystem on the lagged copy folder. 2. You have received reports of corrupt search folders from 50 users. You notice all of the users are on the same mailbox database. You want to fix the corruption in the shortest amount of time. What must you do? A. Issue New-MailboxRepairRequest against the mailbox database. B. Issue New-MailboxRepairRequest against the individual mailboxes. C. Distribute users to multiple databases and run New-MailboxRepairRequest on their mailboxes. D. Perform offline repair of database. Objective 1.5: Develop backup and recovery solutions for the mailbox role and public folders Chapter 1 71 3. When applying new Exchange cumulative update on one of the Mailbox servers, the update failed. You need to fix the issue. What must you do? Choose all that apply. Restart the server and apply the update again. A. Restart the server and uninstall the failed update. B. Run setup.exe from commandline with /recoverserver switch C. Restart the server using last known good configuration option. Reinstall the update. Objective 1.6: Create and configure mail-enabled objects Recipients and mail-enabled objects are the core of the Exchange environment. A mailenabled object is an object, such as a user mailbox, to which Microsoft Exchange can deliver or route messages. Exchange 2013 supports multiple different types of mail-enabled objects enabling various collaboration scenarios. This objective covers how to: ■■ Configure resource mailboxes and scheduling ■■ Configure team mailboxes ■■ Configure distribution lists ■■ Configure moderation ■■ Configure a linked mailbox Configuring resource mailboxes and scheduling Resource mailboxes are mailboxes that represent a location based, or a nonlocation-based, resource, such as a meeting room or a projection system. For these shared resources, resource mailboxes provide the ability to send requests that allow the requestor to reserve the resource. The scheduling can be automated, if desired, in which case, the Exchange assistant processes automatically accept or decline the requests based on the defined time and availability restrictions. You also have an option to configure such resources to be managed by a delegate. In such cases, the delegate is responsible for manually accepting and rejecting the resource scheduling requests based on business processes or other approval criteria. Location based resources are addressed in Exchange 2013 as room resources. When you create a meeting request, Outlook client automatically shows you the Room Finder with all of the available rooms. You can then select an appropriate room for your meeting and reserve it if it’s available for the scheduled meeting time. Recurring requests can also be sent to the room resources and, if automatic processing is configured, acceptance depends on the configured criteria. 72 Chapter 1 Install, configure, and manage the mailbox role To create a room resource, you can use the New-Mailbox cmdlet with the Room parameter. You can also create a room resource from EAC. Let’s create a room resource for a room called New York Executive Briefing Room using EAC. To create a room mailbox, select the Resources tab from the recipients section, and then click + and, from the resulting drop-down menu, select the Room Mailbox option, as you can see in Figure 1–7. FIGURE 1-7 Creating a room mailbox resource from EAC The resulting dialog box in Figure 1–8 enables you to provide the required details, such as display name, alias, room capacity, and location. Objective 1.6: Create and configure mail-enabled objects Chapter 1 73 FIGURE 1-8 Room Mailbox details dialog box You can also provide an organization unit (OU) if you need to store the resource mailbox you’re creating in a specific OU. Creating the same resource mailbox using the Shell would look like the following. Creating a room resource mailbox using the Shell New-Mailbox ` -Name 'New York Executive Briefing Room' ` -DisplayName 'New York Executive Briefing Room' ` -ResourceCapacity '10' ` -Alias 'NYEBR' -Office 'New York City Office' ` -Room:$true When creating the resource mailbox using EAC, you might notice it applies additional defaults to the room mailbox, such as the automatic acceptance of meeting requests. Once created, room resources can be configured to set the meeting length and recurrence limits, assign a delegate, and auto reply to senders. Let’s configure the room resource just created to limit the meeting duration to two hours and a recurrence limit of no more 74 Chapter 1 Install, configure, and manage the mailbox role than three months from the request date. Using Shell, you need to use the Set-Mailbox cmdlet as follows. Configuring room resource parameters Get-Mailbox NYEBR | Set-CalendarProcessing -MaximumDurationInMinutes 120 -BookingWindowInDays 90 When using Outlook to create a meeting request, the newly created room is now visible in Room Finder. In large organizations with many locations and rooms, organizing rooms by location becomes critical to enable users to efficiently locate room resources without sifting through a long list of room resources. Exchange 2013 allows creating room lists, which enables you to organize room resources by location. Essentially, room lists are distribution groups with RoomList designation. Once you create a room list, you can add rooms that belong to the location the room list represents. Let’s create a room list for the New York City location and add the room resource created earlier to the room list. Creating room list and adding room resource to the room list New-DistributionGroup -Name "New York City Conference Rooms" –RoomList Add-DistributionGroupMember -Identity "New York City Conference Rooms" -Member NYEBR Figure 1-9 shows an example of a new meeting dialog box, which shows both the room list and the room created earlier in the Room Finder. FIGURE 1-9 Outlook Room Finder EXAM TIP Familiarize yourself with a variety of scheduling and configuration parameters associated with room and equipment resources. As mentioned, Exchange 2013 also enables you to create nonlocation-specific resource mailboxes, such as shared equipment. While most of the cmdlets and parameters are the Objective 1.6: Create and configure mail-enabled objects Chapter 1 75 same, the difference is, when creating an equipment resource, you issue the New-Mailbox cmdlet with –Equipment:$true, instead of –Room:$true used in the earlier example. Also note, you can’t create special equipment distribution lists as you can with room lists. Configuring team mailboxes A shared mailbox is a resource created when multiple users need to access common information. This could be a mailbox receiving support queries from customers or a shared calendar for a team working on a project. This shared resource isn’t a user mailbox and it doesn’t have its own username and password. Instead, users logon to their own mailboxes, and then connect to the shared mailbox to access shared information. You can create a shared mailbox using the New-Mailbox cmdlet with the Shared parameter. Once created, you can assign specific permissions to the team members or a distribution group to access the mailbox, and to be able to send as, or on behalf of, the shared mailbox. The three permissions need to be assigned using three unique methods. To assign full permissions to the mailbox so a user can manage the mailbox content, including editing and deleting mailbox items, you need to use the Add-MailboxPermission cmdlet with the FullAccess parameter. EXAM TIP The full access permission doesn’t allow the user to send an email as, or on behalf of, the shared mailbox. To assign the send on behalf of permission, you need to use the Set-Mailbox cmdlet with the GrantSendOnBehalfTo permission. To assign the send as permission, you need to use the Add-ADPermission cmdlet. When a user is assigned full permission on the shared mailbox, the Exchange automapping process includes the mailbox in an Autodiscover response. If the user’s Outlook client is configured using Autodiscover, the shared mailbox is automatically connected to the user’s profile and becomes visible in the navigation pane, as you can see in Figure 1–10. 76 Chapter 1 Install, configure, and manage the mailbox role FIGURE 1-10 Shared mailbox displayed in Outlook navigation pane While auto-mapping can help a user eliminate manual steps required to connect to a shared mailbox, if a user has permissions on multiple shared mailboxes, connecting all of them to the Outlook client automatically might become unnecessary. Exchange 2013 provides an administrator with the ability to turn off auto-mapping for a given mailbox. The administrator can simply disable auto-mapping by setting the Automapping parameter value to $false when assigning permissions to the user using the Add-MailboxPermission cmdlet. If you want to disable auto-mapping after assigning the permissions, you must first remove the permissions, then assign them again with the Automapping parameter set to $false. Configuring distribution lists Distribution lists provide an important collaboration capability by allowing a sender to reach a group of recipients by sending an email to a group object, instead of sending it to each recipient individually. When you create a new distribution group, Exchange creates a universal distribution group object in Active Directory. To mail enable an existing group in Active Directory, it must be a universal distribution group. But if you migrated from a previous version of Exchange server, it’s possible you have distribution groups that are security groups, domain local groups, and global distribution groups in Active Directory. By default, Exchange 2013 enables not only administrators, but also users to create distribution groups. When a user creates a distribution group, the user is the designated Objective 1.6: Create and configure mail-enabled objects Chapter 1 77 owner of the distribution group, and they can manage membership and other attributes of the group. When an administrator creates a distribution group, they can designate an appropriate individual as the owner of the group, which in turn, enables the designated owner to manage the distribution group membership and related configuration. If you want to block the end users’ ability to create their own distribution groups, you can use RBAC assignment policies to change the default permissions assigned to the users and block their ability to create a distribution group. You can also allow users to manage group members for the groups for which they’re the designated owners, while removing their ability to create new distribution groups. To provide the consistent naming of distribution groups in the organization, you can create a distribution groupnaming policy, which enables you to configure a prefix and a suffix based on predefined text or by using the value of an attribute, such as city or title. The group naming policy is stored at the organization level and can be created or changed using the Set-OrganizationConfig cmdlet with the DistributionGroupNamingPolicy parameter. You can only have a single group naming policy for an entire organization. When creating distribution groups using EAC, group naming policy is automatically ignored. If administrators use Shell to create a distribution group, the group naming policy is applied to the name unless the administrator uses the IgnoreNamingPolicy parameter. Because distribution groups contain multiple users from a specific department or an entire organization, depending on the purpose of the distribution group, it’s important to manage whether distribution groups accept email from outside senders or only from senders within the organization. By default, newly created distribution groups only accept emails sent by senders from the same organization. An administrator can configure a distribution group to accept messages from outside senders, if desired. Along with simple email sender restrictions, distribution groups also allow for moderation capabilities. When enabled, a moderator or a group of moderators, must be assigned, so when a message is sent to the distribution group, it can be approved or rejected. It is also possible to create exceptions, so certain senders don’t require approval by moderators to send messages to the distribution group. Configuring moderation As described in an earlier section, you can set moderation on distribution lists. But moderation is a transport function and it can also be applied to individual user mailboxes, if needed. To apply moderation to a distribution group, updating moderation properties of the distribution group is a relatively simple task. But, if you want to apply moderation to a user mailbox, you must create a transport rule that uses the Forward the message for approval action when an email is sent to a designated mailbox. In both cases, you can create exceptions, so designated senders can bypass the moderation process. The moderators always bypass the moderation process when they send an email to the distribution group or the mailbox they’re required to moderate. 78 Chapter 1 Install, configure, and manage the mailbox role When a mailbox or distribution group configured for moderation receives a message, the message is forwarded to the moderators. Moderators can approve the message, in which case, the message is delivered to the intended recipients. The moderators can reject the message and, optionally, choose to provide a reason for the rejection, which is then visible to the sender without revealing the identity of the moderator; or the moderator can ignore the message, which eventually times out and the sender is notified that no action was taken by the moderator. Because moderation is a transport function, it’s important to understand that when co-existing with Exchange 2007, the moderation might not work when the message is routed through an Exchange 2007 hub transport server. When a message is sent to multiple recipients and only a subset of the recipients are moderated, the messages is bifurcated. One message is sent to the recipients who don’t require moderation and that message is delivered immediately. The other message is sent to the moderator, who must take the appropriate action. The message is then sent to the recipient or back to the sender, based on the moderator’s action. When a distribution group is moderated and it contains recipients who are also moderated, moderation must take place for each moderated recipient individually, even after the message is approved by the moderator of the distribution group. This might not be a desired behavior in certain environments. Distribution groups allow the moderator-accepted message to bypass further moderation when the BypassNestedModerationEnabled attribute is configured. When more than one moderator is assigned to a distribution group or a recipient for moderation, what happens when one moderator approves the message while another rejects it? The moderation process ignores the subsequent moderator actions once it receives the first moderator’s response. Whatever action the first moderator decides to take remains valid and the message is processed accordingly. If one moderator approves the message and other moderators are away, the message is deleted from their mailboxes by the moderation process because the message no longer needs a moderator’s decision. Configuring a linked mailbox A linked mailbox is a mailbox accessed by a user who is in a separate trusted forest. Most common Exchange 2013 deployments are single forest deployments. But deployment requirements might exist where account forests that host user accounts are separated from resource forests that serve resources, such as Exchange mailboxes. In such a case, the two separate forests require a trust configured to allow the use of resources by the users from the separate forest. The trust must be set up, so the resource forest trusts the account forest. While the one-way outgoing trust is sufficient to create linked mailboxes, the administrator is required to provider administrator credentials of the account forest every time a linked mailbox is created. This behavior can be avoided if a one-way outgoing trust is also established from the account forest trusting the resource forest, which is hosting the linked mailboxes. Objective 1.6: Create and configure mail-enabled objects Chapter 1 79 Before you can create a linked mailbox, the user account, also known as master linked account, must exist in the account forest. To create a linked mailbox, use the New-Mailbox cmdlet. You need to provide a linked domain controller name and a linked master account name. The linked domain controller represents a domain controller in the account forest where the user account resides. The linked master account represents the user who is connected to linked mailbox. You also need to provide the administrator credentials of the account forest if the account forest doesn’t trust the resource forest. The following example shows how to create a linked mailbox in the resource forest Contoso for Ayla Kol, whose user account resides in the Fabrikam forest. New-Mailbox ` -Name "Ayla Kol" ` -LinkedDomainController "DC1_FABRIKAM" ` -LinkedMasterAccount "FABRIKAM\aylak" ` -OrganizationalUnit Users ` -UserPrincipalName [email protected] ` -LinkedCredential:(Get-Credential FABRIKAM\administrator) If required, you can change the master account linked to the linked mailbox using the Set-Mailbox cmdlet with the LinkedMasterAccount parameter. Thought experiment Moderation In this Thought experiment, apply what you learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter. Contoso, Ltd. has deployed Exchange 2013 servers. You are tasked to deploy a strategy to address the following scenarios: ■■ Stop mail storms caused by the use of “reply all” to a distribution group. ■■ Stop the data leak of sensitive information by requiring manager approval. Can you use moderation to address the requirements? Objective summary ■■ ■■ 80 Shared resources, such as Equipment and Room resources, can be managed in Exchange using special mailbox types. You can’t convert an existing user mailbox into a resource mailbox. You must create a new resource mailbox. Moderation is a transport function, and it can be applied to both distribution groups and individual users. It can also be applied to create multiple layers of moderation, if needed. Chapter 1 Install, configure, and manage the mailbox role ■■ Linked mailboxes requires the resource forest to trust the account forest. A trust from the account forest to the resource forest is optional. Objective review Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter. 1. You configured a shared mailbox and assigned full permissions to users. One of the users mentioned they already have multiple mailboxes connected to their Outlook and they don’t want to connect to a shared mailbox automatically. What must you do? A. Run Set-ADPermission cmdlet. B. Run Set-Mailbox cmdlet. C. Remove mailbox permissions for the user, and then add it again. D. Run Set-CASMailbox cmdlet. 2. You deployed Exchange 2013 in a resource forest. You can configure required trust with the account forest. An administrator mentions they are prompted for the administrator account and password from the account domain every time they create a linked mailbox. What must you do to stop the credential prompts? A. Add an administrator’s account to the Domain Admins group in the resource forest. B. Add an administrator’s account to the Domain Admins group in the account forest. C. Add an administrator’s account to the Enterprise Admins group in the account forest. D. Create a one-way trust from the account forest to the resource forest. 3. You recently created a new distribution group with default settings. The distribution group must be able to receive emails from external senders. Which of the following meets the requirement? A. No further action is needed. Default settings of new distribution group allows external senders to send email to members of the distribution group. B. Configure AccessMessagesOnlyFrom parameter on the distribution group. C. Configure BypassModerationFromSendersOrMembers parameter on the distribu- tion group. D. Configure RequireSenderAuthenticationEnabled parameter on the distribution group. Objective 1.6: Create and configure mail-enabled objects Chapter 1 81 Objective 1.7: Manage mail-enabled object permissions In a collaborative environment, enabling users to be able to delegate permissions or use shared resources effectively requires permission manipulation on mail-enabled objects. Some permissions are manageable by users, while others could require administrative action. This objective covers how to: ■■ Configure mailbox permissions ■■ Set up room mailbox delegates ■■ Set up auto-mapping Configuring mailbox permissions In scenarios such as a manager and their assistants, tasks are delegated to assistants when needed. These tasks might include responding to emails, accepting or rejecting meeting requests, and other organizational tasks. To address such scenarios, Exchange allows the setting up of permissions on the mailbox. Users also have the ability to set up permissions using Outlook to delegate tasks by assigning appropriate permissions. As an administrator, you can use EAC or Shell to assign permissions to delegates, as needed. Permissions can be assigned, so users have access to the mailbox, have the ability to send on behalf of, or to send as, a recipient. The permissions can also be assigned to distribution groups. Earlier, in the section Configure Team Mailboxes, you learned about using the Add-MailboxPermission cmdlet to assign permissions. When a permission is assigned by an administrator to a mailbox using Shell or EAC, the change isn’t visible to the user whose mailbox the permissions are assigned to. By default, Exchange Trusted Subsystem and Exchange Servers groups have full access on all mailboxes in the environment. This is required for the system to take necessary mailbox-related actions. When assigning the permissions using Add-MailboxPermission, use of the InheritanceType parameter enables the administrator to specify whether or not all of the subfolders inherit the assigned permissions. To provide an inheritance on all subfolders of a mailbox when assigning the permissions, set the InheritanceType parameter to All. 82 Chapter 1 Install, configure, and manage the mailbox role Setting up room mailbox delegates A room mailbox was created earlier in the section, Configure resource mailboxes and scheduling. In the example, room was configured to accept or decline booking requests automatically. You can configure room mailbox delegates to manage bookings manually instead. To assign delegates, using EAC, edit the room mailbox, select the Booking Delegates option, and then click Select Delegates Who Can Accept Or Decline Booking Requests. Once selected, you need to add the delegates who can manage resource scheduling for the room mailbox. Figure 1–11 provides an example. FIGURE 1-11 Configure delegates for room mailbox You can also perform the same task using Shell, using the following cmdlet: Set-CalendarProcessing -Identity 'New York Executive Briefing Room' -ResourceDelegates @ ('Administrator') In this example, an administrator was assigned as a delegate to the room mailbox. Figure 1-12 displays a resource booking request sent to the room being forwarded to the administrator for processing. Objective 1.7: Manage mail-enabled object permissions Chapter 1 83 FIGURE 1-12 Resource booking request forwarded to administrator for processing You can also decide whether the resource mailbox should automatically process the requests and other parameters, discussed earlier in the section Configure resource mailboxes and scheduling. And you can granularly control which users can request to book the resource automatically if the resource is available, and which users must require approval before they can schedule the resource. From EAC, select your Administrator Account drop-down menu located in the upper-right corner of EAC and select Another User. Select the room resource you want to configure. A new window opens, displaying the room resource’s Options window. Select Settings and the Resource tab. Here you can configure scheduling permissions as needed. Figure 1-13 shows an example configuration, where user Ray Chow is allowed to schedule the resource automatically if the resource is available. The same can also be configured from Shell, using the Set-CalendarProcessing cmdlet. 84 Chapter 1 Install, configure, and manage the mailbox role FIGURE 1-13 Configure scheduling permissions on a room mailbox Setting up auto-mapping When a user is assigned full permissions on a mailbox, the mailbox is automatically mapped to the user’s profile. If the user is using an Outlook client that’s configured to use the Autodiscover process, the auto-mapped mailbox is visible in the user’s Outlook profile without any user intervention. While this auto-mapping process eliminated manual configuration by the user, the user might have access to multiple mailboxes and might not like to have all of the mailboxes automatically mapped to their profile. You can configure the auto-mapping feature only when assigning the permissions. The following example assigns user Ray Chow full access permissions to the shared mailbox and disables auto-mapping. Add-MailboxPermission –Identity "Shared Mailbox" -User "Ray Chow" -AccessRights FullAccess -InheritanceType All –AutoMapping $false Auto-mapping can only be configured when assigning the permissions, and it can’t be changed after the assignment. If you need to change the auto-mapping permissions, you can do so by removing the user’s permissions and reassigning permissions with the desired auto-mapping configuration. Objective 1.7: Manage mail-enabled object permissions Chapter 1 85 Thought experiment Mailbox permissions In this thought experiment, apply what you have learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter. You are an administrator for Contoso, Ltd. You are tasked with explaining possible mailbox permissions that administrators can assign. What are the talking points that you must include in your document? Objective summary ■■ ■■ While schedule processing for room mailboxes can be delegated to a user or a group of users, exceptions can be configured to allow in-policy or out-policy requests to be handled in an automated way for certain users. This depends on resource availability. This can be helpful to reduce the burden on delegates, while still providing the necessary controls. Auto mapping can be helpful to eliminate the manual steps required by the user to connect to other mailboxes they have permissions to. But, it’s possible for the administrator to disable auto-mapping when configuring permissions on the mailbox object. Objective review Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter. 1. You have configured a shared mailbox and delegated approval tasks to a user. You need to allow CEO of the company to be able to request the room resource regardless of room scheduling restrictions. What must you do? A. Run Set-CalendarProcessing cmdlet with AllBookInPolicy parameter B. Run Set-CalendarProcessing cmdlet with AllRequestInPolicy parameter C. Run Set-CalendarProcessing cmdlet with AllRequestOutOfPolicy parameter D. Run Set-CalendarProcessing cmdlet with RequestOutOfPolicy parameter 2. You would like the room resource mailbox to stop from automatically accepting sched- uling requests tentatively. What must you do? A. Configure AddNewRequestsTentatively parameter B. Configure AutomateProcessing parameter C. Configure Confirm parameter D. Configure ScheduleOnlyDuringWorkHours parameter 86 Chapter 1 Install, configure, and manage the mailbox role 3. You have configured a shared mailbox and assigned full permissions to a user. The user reports that he is unable to send email as the shared mailbox. What must you do to fix the issue? A. Run Set-Mailbox cmdlet B. Run Add-ADPermission cmdlet C. Run Set-CASMailbox cmdlet D. Run Set-SharingPolicy cmdlet Objective 1.7: Manage mail-enabled object permissions Chapter 1 87 Answers This section contains the solutions to the Thought experiments and answers to the objective review questions in this chapter. Objective 1.1: Thought experiment 1. The Hyper-V administrator recommends using dynamic VHDX files located on the SAN volume for virtual machines for the Exchange 2013 server roles. While the recommendation by itself might not be an issue, the administrator also stated his goal of achieving consolidation ratio of 100 VMs per virtualization host. This could mean the storage volume might be shared with multiple VMs. When sharing single volume with multiple VMs, I/O characteristics of the volume needs to be able to sustain a peak load of all VMs, while meeting storage I/O and latency requirements of virtualized Exchange server roles. The stated goal of achieving the consolidation ratio of 100 VMs per virtualization host is a concern. If more than two virtual CPUs are allocated per physical CPU core, the virtualized Exchange server role configuration will be unsupported. 2. The storage administrator prefers to create large RAID arrays consisting of multiple disks and creates multiple volumes from the existing array, as needed. The concern with this idea is, as more volumes are created, despite the ability to spread I/O from multiple workloads to multiple underlying spindles, the possibility of competing I/O is higher. This situation becomes more pronounced during peak usage periods. While the proposed solution might not be an issue, the concern should be discussed and a solution should be tested using Jetstress with load simulation that represents an expected concurrent I/O from all applications that will share the array. 3. To provide the best possible user experience in remote locations when connectivity is provided by slower WAN links, it’s ideal to locate public folder mailboxes that host content frequently accessed by users in the datacenters that provide fast and robust connectivity to such locations. Careful planning of a public folder hierarchy is required, because only one writable copy can exist for any given public folder active at a time. Objective 1.1: Review 1. Correct answer: C A. Incorrect: While both RAID5 and SSD disks are supported for use with Exchange 2013 mailbox server roles, it fails to meet the stated goal of achieving the best possible cost benefits for large mailboxes allocated to each user. SSD disks are fast, but they don’t provide a large capacity at a low cost. B. Incorrect: NFS storage isn’t supported for use by physical or virtualized Exchange 2013 roles. 88 Chapter 1 Install, configure, and manage the mailbox role C. Correct: While 15,000 RPM SCSI disks on Fibre-Channel SAN might not be the cheapest option, it is the only supported configuration that is cheaper of the two valid options, making it the only correct choice for the given objective. D. Incorrect: Even though DAS deployments might be cheaper, when combined with RAID10 configuration, the number of disks required will increase the cost of overall solution. 2. Correct answer: B A. Incorrect: Exchange Profile Analyzer is designed for Exchange 2007 and doesn’t work with Exchange 2010 servers. B. Correct: Performance counters from Exchange 2010 servers contain information required to determine the user profiles for a given environment. C. Incorrect: Transaction log files might seem like a legitimate choice to determine user profile data, but they aren’t human readable text files that can be parsed to obtain user profile information. D. Incorrect: Exchange Log Analyzer is a tool to analyze message tracking logs. However, it can’t provide required profile analysis per user. 3. Correct answer: A A. Correct: New-Mailbox is the cmdlet used to create a new public folder mailbox in Exchange 2013. The IsExcludedFromServingHeirarchy parameter prevents Exchange from serving the public folder hierarchy to its user. B. Incorrect: New-Mailbox is the correct cmdlet, but IsHeirarchyReady is a parameter managed by Exchange server. Its value is automatically changed to true by Exchange server when the hierarchy synchronization is complete. C. Incorrect: The New-PublicFolder cmdlet is used to create a folder in the hierar- chy after the public folder mailbox is created using the New-Mailbox cmdlet. The IsHierarchyReady parameter is irrelevant due to the wrong cmdlet usage. Objective 1.2: Thought experiment 1. Because Litware requires the ability to limit the Address Book views to the Address Book, segmentation should be deployed. Creating separate address lists for each acquired company and assigning appropriate Address Book policies can provide required segmentation. The Address Book policy-routing transport agent should also be installed and enabled to block name resolution across logical boundaries created by ABPs. 2. An existing stated environment implies centralized design. Proposed public folder goals require installation of an Exchange server hosting public folder mailboxes in remote locations to avoid latency and poor performance. Availability requirements also implies that DAG should be deployed. The impact of these design changes require that Exchange servers be deployed in remote locations, departing from current centralized deployment, which has all Exchange servers deployed in a central location. Answers Chapter 1 89 Objective 1.2: Review 1. Correct answer: C A. Incorrect: Preparing a schema is required only once per organization during setup or when applying updates. B. Incorrect: Preparing Active Directory is required only once per organization during setup or when applying updates. C. Correct: Preparing a domain is required once per domain that will host recipient objects or Exchange servers. In this example, a new domain is introduced after a deployment of Exchange servers was made in a different domain. Because the new domain was never prepared for Exchange server objects and is to be host recipients, it needs to be prepared. 2. Correct answer: C A. Incorrect: The Move-OfflineAddressBook cmdlet is used to set the OAB generation server in Exchange 2010. B. Incorrect: The Set-OfflineAddressBook cmdlet doesn’t have parameters to move OAB generation to a different server. C. Correct: In Exchange 2013, OAB generation is moved to an arbitration mailbox. To move OAB generation to a different server, you must move the arbitration mailbox with OAB generation capabilities to a mailbox database hosted on the desired server. D. Incorrect: Update-OfflineAddressBook cmdlet forces an update to generate updated OAB files downloaded by users. It does not move generation to different server. 3. Correct answer: A A. Correct: To change the display order of the CEO’s mailbox, the seniority index must be set on the mailbox object. B. Incorrect: Changing the seniority index on the distribution group changes the display order of the group object, but not of its member recipient objects. C. Incorrect: Set-OrganizationConfig has no impact on the display order of recipients in the HAB. D. Incorrect: Set-AddressList cmdlet does not change seniority property for a mailbox. 90 Chapter 1 Install, configure, and manage the mailbox role Objective 1.3: Thought experiment 1. The DAG design needs to account for a 60/40 split of users between two datacenters. A single DAG stretching two datacenters can provide service to all users during normal operation. But when connectivity between datacenters is lost, depending on the location of file share witness, only one of the two datacenters can obtain a majority and continue servicing users. Affecting 40 percent of users due to network outage isn’t a desirable outcome. Creating two DAGs stretching across sites can provide users from each datacenter with uninterrupted service even during the outage of a network link between sites because each DAG can maintain the majority for its location. This design also has a higher cost impact. Because site resiliency is not a stated requirement, a single DAG for each location can provide the same level of availability, while saving money. 2. If a single DAG is deployed per location with no mailbox servers located across the sites, a file share witness should be located in the same site as the mailbox servers for DAG. If one stretched DAG per site is deployed, the file share witness should be located at the primary site being served by the DAG. A third site for a file share witness can’t be recommended because there’s no mention of availability of a third site, planned or existing. Also, network link quality and redundancy is an unknown. Locating a file share witness in a third site requires robust and redundant network links from each site to a third site where the file share witness is to be located. Objective 1.3: Review 1. Correct answer: B A. Incorrect: Failover Cluster functionality required to create a cluster without an administrative point doesn’t exist in Windows Server 2008 R2. B. Correct: Failover Cluster functionality required to create a cluster without an administrative point was introduced in Windows Server 2012 R2. C. Incorrect: Failover Cluster functionality required to create a cluster without an administrative point doesn’t exist in Windows Server 2012. 2. Correct answers: B and D A. Incorrect: Database files of a database with circular logging can’t be moved to a different location. B. Correct: Circular logging is required to be disabled before moving a database file to a different location. C. Incorrect: Database doesn’t need to be dismounted before moving database files to a different path. The Move-DatabasePath cmdlet automatically dismounts the database and mounts it again. If a database is manually dismounted before running the Move-DatabasePath cmdlet, the cmdlet won’t automatically mount the database after moving the database file to a new location. D. Correct: The Move-DatabasePath cmdlet dismounts the database, moves the database file to new path, and mounts the database. Answers Chapter 1 91 3. Correct answers: B and C A. Incorrect: By default, DAG manages networks automatically Setting ManualDagNetworkConfiguration to $false is similar to automatic management of networks. The required goal is opposite. B. Correct: By setting ManualDagNetworkConfiguration to $true, you are enabling ability to manage DAG networks manually. This is required to achieve stated goal. C. Correct: to remove SCSI network from DAG networks, you need to set IgnoreNetwork to $true. D. Incorrect: Until IgnoreNetwork is congifured to $true, DAG automatically uses all networks. Setting IgnoreNetwork to $false does not help achieve the stated objective. Objective 1.4: Thought experiment You need to address two primary concerns. One is frequent failovers of the databases. It is important to find out why the failovers are occurring in the first place. Using CollectOverMetrics. ps1 is the best way to collect data from all servers in the DAG and correlate the events that could be causing the databases to fail over. This could also help prevent the failovers from happening if the root cause can be remediated. The concern about activation preference can be addressed by explaining the process of BCS, which uses an activation preference as one of many factors of determining which copy is the best copy for activation, given its health and the possibility of data loss or performance degradation. Along with a review of data collected by script, as previously discussed, it can be determined why the preferred copy wasn’t selected. Lastly, as discussed in the section, Troubleshooting database copy activation, you can force activation of local copies only by configuring intrasite only property on the mailbox server configuration. Objective 1.4: Review 1. Correct answers: A, B, and C A. Correct: CollectOverMetrics.ps1 can collect logs from a specified mailbox server or from all servers in the DAG. The CSV file and HTML report can help determine if the copy failed over due to an error or as the result of an administrative action. B. Correct: While not as efficient as CollectOverMetrics.ps1, crimson event logs can help determine if the copy failed over due to an error or as the result of an administrative action. This process requires more work because the administrator must manually collect all events from all servers and correlate the events manually. 92 Chapter 1 Install, configure, and manage the mailbox role C. Correct: Searching admin audit logs can help determine what actions the admin- istrator performed and if an action could have affected the active database copy, resulting in a switchover or a failover of the database. If the database failed over due to an error on the server, and not as an administrative action, searching the administrative log isn’t effective and can only partially address the concern. D. Inorrect: Get-DatabaseAvailabilityGroup only returns database availability group properties and does not help achieve stated goal 2. Correct answers: A and B A. Correct: Low disk space can prevent logs from being copied over to database copies. B. Correct: A missing or corrupt log file required for database copies to be consis- tent can cause copy queue length greater than zero as the system can’t replicate required data until the missing or corrupt log file is restored. C. Incorrect: Because it’s stated that all the servers are able to communicate to the server hosting active database copy, a network issue causing transmission failure was ruled out. D. Incorrect: TCP chimney offload helps improve processing of network data. 3. Correct answer: A A. Correct: Configuring MaximumActiveDatabases parameter using Set-MailboxServer cmdlet defines how many databases can be active on a mailbox server at a time. B. Incorrect: Update-MailboxDatabaseCopy cmdlet does not have option to config- ure maximum databases per server. C. Incorrect: Set-DatabaseAvailabilityGroup cmdlet allows configuration of DAG but can’t set maximum databases per server. D. Incorrect: Add-ServerMonitoringOverride cmdlet allows override of managed availability probes, monitors and responders. Objective 1.5: Thought experiment While it might seem that a 14-day maximum limit on lagged copies might not be able to meet the requirements of a litigation hold, which could be up to six months on average, the retention of deleted data is provided by a single item retention and legal hold features. These features store deleted data in folders hidden from a user, but they are part of the user’s mailbox. The discovery and restoration of deleted data can be performed using a single-item recovery process and rarely requires the use of lagged copy. Lagged copies have the required data if the single item recovery and legal hold limits are configured appropriately. Lagged copies are merely holding the same data already protected by retention settings. Answers Chapter 1 93 Objective 1.5: Review 1. Correct answer: B A. Incorrect: Suspending a lagged copy suspends all operations including a copy of the log files from the active copy of the database and replay of the log files that meet the lag requirements. This doesn’t meet the stated goal. B. Correct: Only suspending a lagged copy for activation doesn’t completely suspend the database copy. It only suspends the activation of the lagged copy by removing it from the BCS process. This allows a lagged copy to receive log files and replays them if the lagged configuration requirements are met. Because activation is blocked, manual intervention is required if the copy must be activated. C. Incorrect: Removing permissions assigned to Exchange Trusted Subsystem (ETS) on an Exchange server should never be recommended. It has undesired and unexpected consequences because Exchange server relies on the permissions to carry out required tasks on the server. D. Incorrect: Removing permissions assigned to Exchange Trusted Subsystem (ETS) on an Exchange server should never be recommended. It has undesired and unexpected consequences because Exchange server relies on the permissions to carry out required tasks on the server. 2. Correct answer: C A. Incorrect: Only one repair request can run against a mailbox database at any given time. B. Incorrect: While up to 100 active mailbox repair requests can be active on a server, only one request can be active against a given database. C. Correct: Distributing mailboxes to multiple databases allows multiple repair requests to run against mailboxes simultaneously. While this requires moving mailboxes, it’s the only option that meets the stated goal of fixing corruption on all mailboxes in the shortest amount of time. D. Incorrect: performing offline repair on the database does not achieve stated goal. 3. Correct answer: C A. Incorrect: cumulative updates are full Exchange installs. If a CU fails, simply trying a reinstall does not fix the issue. B. Incorrect: cumulative update uninstalls Exchange before installing new updates. You can’t uninstall a CU after it is installed. C. Correct: you must recover Exchange server using setup if CU fails to install, since CU install uninstalls Exchange from the server first before installing updated version of Exchange server. D. Incorrect: you can’t recover a failed CU install by using last known good configu- ration option 94 Chapter 1 Install, configure, and manage the mailbox role Objective 1.6: Thought experiment Mail storms caused by Reply All from multiple recipients on the distribution groups can be addressed by moderating the distribution group. Moderators can reject all unnecessary replies, or simply ignore them and only approve valid responses. A data leak of sensitive information might be seen as best addressed by DLP features of Exchange 2013. But, at the core of the requirement, you’re required to configure approval when certain content is detected in a message. Because moderation is a transport function, you can meet the stated requirement with moderation. Objective 1.6: Review 1. Correct answer: C A. Incorrect: The Set-ADPermission cmdlet enables you to configure Send As per- missions on a mailbox. It doesn’t address a stated requirement. B. Incorrect: The Set-Mailbox cmdlet doesn’t have the capability to configure auto- mapping properties on a shared mailbox. C. Correct: Auto-mapping properties can only be configured when assigning per- missions using the Add-MailboxPermission cmdlet. If already assigned, you must remove the permissions to change the property of auto-mapping behavior. D. Incorrect: Set-CASMailbox cmdlet can’t be used to configure auto mapping properties of a mailbox. 2. Correct answer: D A. Incorrect: Adding an administrator account to the Domain Admins group in resource forest provides access to domain administration functions in resource forest only. B. Incorrect: Adding an administrator account to the Domain Admins group in account forest provides access to domain administration functions in account forest only. C. Incorrect: Adding an administrator account to the Enterprise Admins group in account forest provides access to enterprise administration functions in account forest only. D. Correct: When an account forest trusts a resource forest, adding a linked mailbox can proceed without requiring an administrator to provide credentials due to an existing trust. Answers Chapter 1 95 3. Correct answer: D A. Incorrect: Default configuration of a new distribution group only allows internal users to submit messages. B. Incorrect: AcceptMessagesOnlyFrom parameter allows you to configure recipients who can send messages to the distribution group. It is not practical for external senders who may not be known. C. Incorrect: BypassModerationFromSendersOrMembers parameter is used for moderation of a group. It does not allow external senders to submit messages to a distribution group. D. Correct: for external senders to be able to send messages to a distribution group, you must allow unauthenticated sender to submit messages. RequireSenderAuthenticationEnabled parameter allows you to do that. Objective 1.7: Thought experiment When using Add-MailboxPermission or EAC to assign delegate permissions on the mailbox, you need to account for few important aspects. One is the type of permissions you can assign to the mailbox. Most commonly discussed permissions are full access to the mailbox, but it may not be desired in all instances. Exchange allows you to assign other permissions such as read only, change permission and change if the delegate created the item. Inheritance is another consideration. When permissions are assigned, you can configure the permission to apply to all folders within the mailbox. Again, this may not be desired and in such instances, do not set InheritanceType parameter to All. When users have full or other limited access to another mailbox, chances are, they would also like to send email on behalf of the user or as the user if necessary. For an example, a support desk analyst may not want to be identified individually when responding to a support request. In such instance, you would need to assign send as permissions on the mailbox. Objective 1.7: Review 1. Correct answer: D A. Incorrect: AllBookInPolicy applies to all users who can schedule the resource if their request is within defined policy requirements. B. Incorrect: AllRequestInPolicy applies to all users who are allowed to request scheduling of resource when their request is within defined policy requirements. C. Incorrect: AllRequestOutOfPolicy applies to all users. Users are allowed to request scheduling of resource if request is out of policy. D. Correct: RequestOutOfPolicy allows specified user to request resource scheduling even if the request is out of policy parameters configured for given resource mailbox. 96 Chapter 1 Install, configure, and manage the mailbox role 2. Correct answer: A A. Correct: when AddNewRequestTentatively parameter is set to $false, the resource mailbox stops adding in-policy scheduling requests to be added to the resource calendar tentatively while awaiting approval from delegate. B. Incorrect: AutomateProcessing parameter allows you to configure calendar processing on the resource mailbox. This parameter affects all requests and isn’t designed to handle tentative processing only. C. Incorrect: Confirm parameter applies to all PowerShell cmdlets and is used to stop processing when a confirmation from administrator is needed. It does not help achieve stated objective. D. Inorrect: ScheduleOnlyDuringWorkHours parameter allows you to control whether the resource mailbox should accept meeting requests outside of configured working hours of the resource mailbox. It does not help address stated requirement. 3. Correct answer: B A. Incorrect: Set-Mailbox cmdlet allows you to modify settings of an existing mail- box. It can’t be used to configure send as permissions. B. Correct: Add-ADPermission cmdlet allows you to configure send as permissions on a mailbox using impersonation. C. Incorrect: Set-CASMailbox cmdlet is used to configure client access settings of a mailbox. D. Incorrect: Set-SharingPolicy cmdlet is used to modify free/busy sharing with users outside the organization. Answers Chapter 1 97 This page intentionally left blank Index Symbols 5xx SMTP error 259 -AuthMechanism 225 -DomainSecureEnabled 225 -ForceFullSync switch 218 /IAcceptExchangeServerLicenseTerms switch 20 /NewProvisionedServer switch 22 –OABGen $True parameter 27 /PrepareAllDomains switch 282 *-ResourcePolicy cmdlet 286 /TargetDir switch 69 “*” wildcard 236 -WorkloadManagementPolicy cmdlet 286 *-WorkloadPolicy cmdlet 286 A ABPs. See Address Book Policies (ABPs) accepted domains authoritative 196, 230 configuring 229–231 creation of 229 defined 196 external relay 197 internal relay 196 AcceptMessagesOnlyFromDLMembers parameter 33 AcceptMessagesOnlyFrom parameter 33 AcceptMessagesOnlyFromSendersOrMembers parameter 33 Access Control Entries (ACEs) 302 access rules allow/block/quarantine (ABQ) process 136–145 creating 141–142 for users 143–145 managing device 138–143 ACEs. See Access Control Entries (ACEs) Action Reject parameter 262 Action SilentDelete parameter 262 Action Strip parameter 262 Active Directory deployment planning 272–274 distribution lists and 76–77 domain controllers 19, 273 Edge subscription object in 209 GC servers 272–273 impact of Exchange on 271–284 install path from 69 mailbox server roles deployment 19–22 message routing 185, 193–195 permissions 293 preparing for Exchange 279–282 site link costs 195 site topology 273 SPF records 277–279 split permissions 21, 299–302 tools 20 Active Directory Domain Services (AD DS) 271 Active Directory Federated Services (AD FS) 123 Active Directory Lightweight Directory Services (AD LDS) 208 Active Directory Rights Management Services (AD RMS) 202 ActiveDirectorySplitPermissions parameter 301 Active Manager 54 ActiveSync 102–104 ActiveSyncEnabled parameter 170 AdapterEnabled parameter 276 Add-ADPermission cmdlet 76, 302 Add-AttachmentFilterEntry cmdlet 262 Add-ContentFilterPhrase cmdlet 258 Add-DatabaseAvailabilityGroupServer cmdlet 41, 70 Add-IPAllowListProvider cmdlet 254 Add-IPBlockListProvider cmdlet 254 323 Add-MailboxDatabaseCopy cmdlet Add-MailboxDatabaseCopy cmdlet 41, 61, 70 Add-MailboxPermission cmdlet 76, 77, 82 Add-PublicFolderClientPermission cmdlet 32 addressable objects 230 Address Book Policies (ABPs) 24, 25 address books creation and configuration of 22–28 hierarchical 28–31 address lists custom 22–23 hierarchical 28–31 address rewriting 210, 235–236, 251 Address Rewriting Inbound Agent 235 Address Rewriting Outbound Agent 235 address spaces 220 Add-RoleGroupMember cmdlet 296 AD DS. See Active Directory Domain Services (AD DS) Add-WindowsFeature 159 Add-WindowsFeature RSAT-ADDS 20 AD FS. See Active Directory Federated Services (AD FS) AD LDS. See Active Directory Lightweight Directory Services (AD LDS) Administration Delegation Wizard 293 AD RMS. See Active Directory Rights Management Services (AD RMS) ADSIEdit 282 affinity requirements 154, 156 allow/block/quarantine (ABQ) process 136–145 device access rules and 138–143 device connection policies and 137–138 DeviceID and 136 organization-wide settings for 145 user access and 143–145 AllowNonProvisionableDevices parameter 170 Alternate Service Account (ASA) 157 anti-malware 259–261 apps. See Office Apps arbitration mailboxes 27 ASA. See Alternate Service Account (ASA) Attachment Filter 206 attachment filtering 261–262 authentication Basic 122 configuration of methods 122–123 Forms Based Authentication 102, 123 Kerberos 122 AuthMechanism setting 227 authoritative domains 196, 230 324 AutoDatabaseMountDial setting 45 AutoDiscover 279 auto-mapping and 85 client access and 100 load balancing namespace 154 namespaces 111–113 Outlook and 102, 114 SCP record for 113 security alerts and 113 testing 164, 164–165 URL 111 AutoDiscoverServiceInternalUri parameter 113 auto-mapping 77, 85 automatic database reseeding 1–2 automation 1–2 auto-reseed functionality 42 Azure. See Microsoft Azure Azure services. See services Azure two-factor authentication 123 B backup MXing 191 backup solutions determining most appropriate 62–63 for mailbox role 60–71 for transaction logs 4 Barracuda Networks 206 best copy selection (BCS) process 44, 55, 62 binary transfer (BDAT) 244 BitLocker 4 BlackBerry Enterprise Server (BES) 287 bound model 115 Bring Your Own Device (BYOD) 138 buffers 7 built-in management roles 295–299 bypassed items 257 BypassNestedModerationEnabled attribute 79 C CAL. See client access license (CAL) capacity planning 2, 42, 310 CAS. See Client Access server (CAS) role CAS arrays 153 CAS servers load balancing 156–157 central processing units (CPUs) 99 content index catalog Certificate Principal Name 119 certificates 112 configuration of 110 for connectors 250 management of 100 planning 118–122 self-signed 121–122, 169, 204, 209 SSL 154, 205 TLS and Domain Security and 226 Unified Messaging (UM) 119 wildcard 119 certification authorities (CAs) 106, 113, 118, 119, 205 change management 309–310 circular logging 4, 41, 45, 48, 49, 52 Clear-MobileDevice cmdlet 127 client access DNS configuration for 279 Client Access Array 100 client access license (CAL) 206, 274 Client Access server (CAS) role 99–180 certificate management and 100 client connectivity and 1 differences between legacy and Exchange 2013 101–105 function of 181 load balancing 153–163 location of 182 mobility solutions 125–151 namespaces for 110–115 new features for 99–101 plan, deploy, and manage 101–110 session affinity and 99 troubleshooting client connectivity 163–171 upgrading 99 URL configuration 115–118 client connectivity namespaces for 111–116 troubleshooting 163–171 Client Frontend serverName connector 221, 245 Client Proxy serverName connector 222 client throttling 288–290 Cluster Network Object (CNO) 39–40 CollectOverMetrics.ps1 script 58 CollectReplicationMetrics.ps1 script 58 ConditionalDepartment parameter 22 configuration accepted domains 229–231 address rewriting 235–236 allow/block/quarantine policies 136–145 authentication methods 122–123 certificates 110 connectors 218–228 DAGs 2, 38–41 databases 4 distribution lists 77–78 DNS 274–279 Edge servers 216–218 email policies 231–234 Exchange ActiveSync properties 133–134 JBOD 1–3 linked mailboxes 79–80 mailbox permissions 82 mailbox role 19–37 mail-enabled objects 72–81 message hygiene 253–263 moderation 78–79 namespace load balancing 153–157 namespaces 110–115 Office Web Apps server 105–108 OWA policies 127–132 resource mailboxes 72–76, 84 scheduling 72–76 sender policy framework (SPF) records 277–279 SMTP server 168 team mailboxes 76–77 transport 215–239 transport rules 227–228 URLs 115–118 ConfigurationSyncInterval cmdlet 218 Connection Filter 206 connection filtering 254–255 connectivity logs 241 connectors 212. See also receive connectors; See also send connectors certificates and 226, 250 configuration of 218–228 creating 231–232 Partner 226 policies for 234 send 277 TLS and Domain Security configuration 225–227 understanding 198–200 Content Filter 206, 255–258 content filtering 255–258 content index 4 content index catalog 53 325 continuous replication circular logging (CRCL) continuous replication circular logging (CRCL) 45 copy queue length 52 Core installations 19–20 CPUs (central processing units) 99 CPUStartPercent property 289 crimson channel event logs 58 Cumulative Update 5 (CU5) 27 cumulative updates (CUs) 310 custom address lists 22–23 custom recipient scope 304 custom-scoped role groups 303–308 CutoffBalance 289 D dail tone restores 64–66 data exporting recovered 67 loss 64 restoring from backup 64 Database Availability Groups (DAGs) adding servers to 41 creation and configuration of 38–41 database copies and 44–50 failure domains and 41–42 high availability and 27 mailbox servers within 184 manual vs. automatic configuration of 2 message routing and 186 network configuration of 1–2 network management 43–44 recovery capabilities 62 database copies activating 45–48 activation troubleshooting 53–55 lagged 46–48, 60–62 moving path 48 status of 57–58 DatabaseCopyAutoActivationPolicy parameter 55 database IOPS target 17 database restriction filter 306 databases copy queue length 52 failovers 57–58 file placement 3 lagged copies of 44–45 managing copies of 44–50 326 mounting restored 64, 66 moving path 48 Public Folder 7 recovery 47, 65 replication and replay of 52–53 replication monitoring 57–58 restoring 64–65 seeding 44, 48–49 size of 4 stand-alone configuration 4 states for 45 switchover process 45 Databases role 305 Data Loss Prevention (DLP) featues 309 rules 203–204 deep content analysis 203 Default Frontend HSV-EXMBX02 connector 222 Default Frontend serverName connector 200, 221, 245 DefaultPublicFolderMailbox parameter 14, 33 Default serverName connector 221 DeferWaitTime parameter 260 delay notifications 233 delegated setup permissions 22 delegates mailbox 83–85 DelegatingOrgWide permissions 299 DeleteContent parameter 67 DeletedItemRetention parameter 63 delivery groups 186 delivery queues 246 Delivery Reports tab 243 deployment Active Directory 272–274 mailbox server roles 19–22 device access rules 136–145 managing 138–143 DeviceID 136 DFS. See Distributed File System (DFS) direct attached storage 3 Disable-App cmdlet 148, 149 Disable-TransportAgent 235 DisconnectedAndHealthy state for database copy 57 Discovery workload 289 disk configuration 3, 4 disk failures 16, 49 Enterprise Mobility Suite disk I/O 7 disk latency 2–18 disk size 4 disk space for lagged copies 61 Distributed File System (DFS) 43 distribution group expansion servers 186 DistributionGroupNamingPolicy parameter 78 distribution groups 28 distribution lists configuring 77–78 moderation on 78–79 DNS. See Domain Name System (DNS) DNSBL 254 DNSRoutingEnabled parameter 227 domain controllers colocation with 19 linked 80 number of 273 placement of 5 read-only 273 domain names renaming 119 Domain Name System (DNS) 271 changes required for Exchange 274–279 client access configuration 279 connectivity 208 default Windows settings 275 forcing specific DNS settings 275–277 inbound mail configuration 274 lookups 276–277 MX records and 191 outbound mail configuration 274–277 split-brain 275–276 domains accepted 196–197 authoritative 196, 230 configuring accepted 229–231 external relay 197, 212, 230 internal relay 196–197, 212, 230 preparing for Exchange 2013 282 remote 197–198 Domain Secure 204–206, 250–251 DomainSecureEnabled parameter 226, 227, 250 Domain Security 225–227, 232 dynamically expanding disks 12 dynamic memory 10 E EAC. See Exchange Admin Center (EAC) EAS. See Exchange ActiveSync (EAS) Edge Server role 182, 207–210 Edge servers configuration 216–218 Edge subscriptions 208–209 EdgeSync about 208 managing 217–218 subscription 217 synchronization schedule and 210 EdgeSync bootstrap replication account (ESBRA) 209–210 EdgeSync replication account (ESRA) 210 Edge Transport role 206, 208–210 Edge Transport servers adding and removing 216–217 email addresses address rewriting 235–236 assigning 212 policies for 212, 230 email encryption 204–206, 210 email messages address rewriting 251 anti-malware management 259–261 attachment filtering 261–262 content filtering 255–258 message tracking 240–243, 245 outbound messages 314 quarantined 256 recipient filtering 258–259 Sender ID 259–260 spam confidence level (SCL) 256–258 email policies configuration of 231–234 global policies for 231–233 EMS. See Exchange Management Shell (EMS) Enable-App cmdlet 148, 149 Enable-ExchangeCertificate cmdlet 205, 226, 250 Enable-Mailbox cmdlet 299 Enable-TransportAgent 235 Encrypting File System (EFS) 4 Enterprise Admins security group 281 Enterprise Mobility Suite (EMS) OWA policies in 132 transport rules in 202 327 EOP EOP. See Exchange Online Protection (EOP) eseutil 47, 65 ESRA. See EdgeSync replication account (ESRA) ethical firewalls 228 Event ID 140 105 Event ID 141 106 Event ID 142 106 event logs 58 EXCH 119 Exchange 2007 coexistence with 101–104 Exchange 2010 coexistence with 104–105 Exchange 2013 backup technology supported by 63 coexistence with Exchange 2007 101–104 coexistence with Exchange 2010 104–105 deployment considerations 271 DNS changes for 274–279 high availability features of 1–2 impact of, on Active Directory services 271–284 integration with Office Web Apps server 105–108 new features of 309 performance monitoring 271 preparing Active Directory for 279–282 role based access control 293–308 setup utility 280 SLAs and 308–315 workload management 285–293 Exchange ActiveSync (EAS) mobile device access and 125 policy configuration 133–134 protocol 170 quarantined devices list in 140 turning on/off 134 Exchange Admin Center (EAC) address list creation in 22–23 apps management in 147–148 connector configuration in 218 connector creation in 223–225 managing connectors in 198 OWA policies in 129–131 role group creation 303–308 Rule Creation Wizard 201 transport rule configuration in 227 transport rules in 202 Exchange Connectivity Analyzer (ExRCA) 163–166 ExchangeCost parameter 195 328 Exchange Credential Service 210 Exchange Management Shell (EMS) connector configuration in 218 DNS settings 276 installing and managing apps in 148–149 Exchange Online Protection (EOP) 205, 260, 274 Exchange Profile Analyzer 6 Exchange Protected Groups OU 302 Exchange Queue Viewer 247, 248 Exchange Recipient Filter 258 Exchange-related objects 299 Exchange Role Requirements Calculator 4 Exchange RPC protocol 119 Exchange Server Authentication 219 Exchange Setup Wizard 21 Exchange Trusted Subsystem 299, 302 Exchange Trusted Subsystem object 40 Exchange Web Services (EWS) connections 103, 104 troubleshooting 169 Exchange Windows Permissions Group 299 exclusive scopes 306–307 ExportEdgeConfig.ps1 script 217 EXPR 119 ExRCA tool 169, 170 ExternalClientAuthenticationMethod 166 external clients 113–114 ExternalClientsRequireSsl parameter 167 ExternalConnectionSettings parameter 168 ExternalDelayDSNEnabled parameter 232 ExternalDNSAdapterEnabled parameter 276 ExternalMailEnabled switch 259 ExternalPostmasterAddress parameter 232 external relay domains 197, 212, 230 external storage 7 ExternalURL parameter 102, 116 F FailedAndSuspended state for database copy 57 failed state for database dopy 57 failover capacity 6 failover clustering 39, 158 failovers causes of 58 monitoring 57–58 Hyper-V technology failure domains 41–42 failure notification s 234 FBA. See Forms Based Authentication (FBA) FET. See Front End Transport (FET) service Fibre-Channel storage 3, 7 file share witness 40–41, 43 file systems 4 filterable properties 23 filtering agents 206–207, 211, 253–262 Filter parameter 247 firewalls 122, 134, 169, 195, 228 Force switch 70 ForceWacViewing* parameters 108 Forms Based Authentication (FBA) 102, 123 ForwardeeLimit 291 Front End Transport (FET) service 182, 210, 244, 276 full access permission 76 full control permissions 39 Fully Qualified Domain Name (FQDN) 27, 100, 105, 112, 115, 118, 120 G GAL. See Global Address List (GAL) Get-AcceptedDomain cmdlet 212, 251 Get-ActiveSyncDeviceAccessRule cmdlet 142 Get-ActiveSyncDeviceClass cmdlet 140 Get-ActiveSyncDeviceStatistics cmdlet 144 Get-AddressRewritingEntry cmdlet 251 Get-App cmdlet 148 Get-AttachmentFilterEntry cmdlet 261 Get-AttachmentFilterListConfig cmdlet 262 Get-MailboxDatabaseCopyStatus cmdlet 45, 52, 53, 57 Get-ManagementRole cmdlet 295 Get-MessageTrackingLog cmdlet 243 Get-MessageTrackingReport cmdlet 242 Get-MobileDevice cmdlet 137 Get-PublicFolderMigrationRequest cmdlet 35 Get-Queue cmdlet 247–248 Get-QueueDigest cmdlet 247, 248 Get-ReceiveConnector cmdlet 222, 224 Get-RecipientFilterConfig cmdlet 259 Get-SendConnector cmdlet 220, 226 Get-TransportConfig cmdlet 190, 231 Get-TransportRuleAction cmdlet 227 Get-TransportRulePredicate cmdlet 227 Get-TransportService cmdlet 245, 276 Global Address List (GAL) default 22 segmentation 23–26 global catalog (GC) servers planning placement of 272–273 globally unique identifiers (GUIDs) 111 GlobalThrottlingPolicy_GUID 289 GrantSendOnBehalfTo permission 76 group naming policy 78 guest replication 9 GUID Partition Table (GPT) 4 [email protected] domain 100 H hard fail messages 207 healthy state for database copy 57 Help Desk role group 296 hierarchical address book (HAB) 28–31 hierarchical address lists 28–31 high availability 6 costs and 41 Database Availability Groups and 38–41 database copies and 44–50 failure domains and 41–42 for mailbox role 38–51 load balancing and 153 MX records and 191–192 Safety Net and 189–190 shadow redundancy and 186–188 transport 183–192 HighAvailability channel 58 HighGeneration number 47 HoldForMigration parameter 34 host name resolution 208 HTTP-based protocols 111 HTTP GET request 154 HTTP protocol 119 hub and spoke routing 195 hub sites 193, 194, 195 Hub Transport role 182 hygiene. See message hygiene Hypertext Transfer Protocol (HTTP) 99 hyperthreading 10–11 hypervisors 12–13 Hyper-V technology 8 329 IgnoreStartTLS parameter I IgnoreStartTLS parameter 227, 250 IISAuthenticationMethods 166 IMAP services troubleshooting 167–170 ImportEdgeConfig.ps1 script 217 inbound messages 274 delivery of 185 four-step flow for 182 predicting flow of 239 processing 210–211 receive connectors and 200 shadow redundancy and 187–188 troublieshooting 249 IncludeFolders switch 68 incremental deployment 38 Information Rights Management (IRM) 105 Install-AntispamAgents.ps1 script 207 Install-WindowsFeature RSAT-ADDS 20 InternalClientAuthenticationMethod 166 InternalClientsRequireSsl parameter 167 InternalDelayDSNEnabled parameter 232 InternalDNSAdapterEnabled parameter 276 InternalMailEnabled parameter 259 internal monitoring 1–2 internal relay domains 196–197, 212, 230 InternalSMTPServers parameter 207, 232 InternalUrl parameter 116 International Mobile Equipment Identifier (IMEI) 137 Internet Group Management Protocol (IGMP) 160 Internet Information Services (IIS) authentication 102 logs 287 management tools 134 Internet Message Access Protocol (IMAP) 99 Internet Small Computer System Interface (iSCSI) 3 inter-org mail flow 195–204 interpreters. See handlers inter-site mail flow 193–195 I/O database read averaged latency 17 I/O log write averaged latency 17 Iometer 16 IP addresses 207 connection filtering and 254–255 for DAG configurations 40 in Received header 234 load balancing and 156 330 MX records and 191 of DNS servers 276 shared 160 SPF records and 278 IPv6 protocol 19 iSCSI 7 IsExcludedFromServingHierarchy parameter 14, 35 IsHeirarchyReady parameter 14 IsHierarchicalGroup property 28 item-level recovery 66–67 J JBOD configuration 1–2, 3, 42 JET circular logging 45 Jetstress 15–17 JournalingReportNdrTo parameter 232 K Kemp Technology ESP 134 Kerberos 157 Kerberos authentication 122 Kerberos Constrained Delegation 123 Keyword Query Language (KQL) 67 L lagged database copies 44–45 activating 46–48, 62 configuration of 61 corruption of 61 creating 61–62 managing 60–62 replication 52 Layer 4 load balancers 154–155 Layer 7 load balancers 154, 155 LDP.exe 113 least-cost routing 193–194 legacy host names 101–102 legal holds mailbox storage and 6 linked domain controller 80 linked mailboxes 79–80 linked master account 80 LinkedMasterAccount parameter 80 Linux-based DNS server 274 list providers 254 Mail Recipients role 294 Live Migration 9–10 load balancing 153–163 affinity requirements 154, 156 internal mail delivery 314 namespace 153–157 session initiation protocol (SIP) 158–159 Windows network load balancing (WNLB) 158–161 location-based resources 72 lockouts 56 log files corrupt 49, 53 inspection failures 53 placement of 4 replaying 64 logical corruptions 61 logical unit numbers (LUNs) 3, 16 log truncation 52 lost flush 61 Lync 2013 server 63 Lync contacts 63 M MailboxDatabaseFailureItems channel 58 mailboxes arbitration 27 auto-mapping 85 database size 6 high availability and 6 legal holds and 6 linked 79–80 moving 33 permissions configuration 82 primary hierarchy 32–33 protecting against deletion 63–64 public folder 13–15, 32–36, 68–70 quarantine 256 resource 72–76, 84 retention of 63–64 room 83–85 site resiliency requirements and 6 standalone servers for 186 team 76–77 mailbox policies mobile device 134–136 MailboxRetention parameter 63 mailbox role backup and recovery solutions for 60–71 capacity and placement planning 5–8 configuration of 19–37 deployment of 19–22 function of 181 hierarchical address lists 28–31 high availability solutions for 38–51 location of 182 mail-enabled objects 72–81 management of 19–37 monitoring 51, 57–58 offline address book configuration 22–28 overview of 1–2 performance troubleshooting 55–57 planning 2–18 public folder placement strategy 13–15 public folders 32–36 recovering 69–70 storage requirements 3–5 storage validation 15–17 troubleshooting 51–60 virtualization planning 8–13 Mailbox server database placement 3 hardware requirements for 7–8 installing filter agents on 207–208 mailbox processing by 1–2 scale out vs. the scale up model 7 Mailbox Transport Delivery service 182, 185 Mailbox Transport Submission service 182 mail connectors 186 mail-enabled objects creation and configuration of 72–81 distribution lists 77–78 linked mailboxes 79–80 moderation 78–79 permissions management 82–87 resource mailboxes 72–76 team mailboxes 76–77 mail exchanger (MX) records inbound messages and 274 public 274 Mail Exchanger (MX) records backup MXing 191 lookups 219 redundant 191–192, 210 mail flow 239–240 Mail Recipient Creation role 300 Mail Recipients role 294 331 Malware Filter Malware Filter 206, 253 malware filtering agent 259–261 managed availability 1–2 managed availability cmdlets 310 management adapter 159 Management Portal. See Azure Management Portal Management Role Assignments 294 Management Role Entries 294 management roles built-in 294–299 custom-scoped 303–308 Management Role Scope 294 Management Scope 294 MAPI networks 43–44 Master Boot Record (MBR) 4 master linked account 80–81 MaxBurst 289 MaxConcurrency 289 MaximumActiveDatabases parameter 55 MaximumPreferredActiveDatabases parameter 55 MaxMessageSize parameter 225, 234 MaxReceiveSize parameter 232 MaxRecipientsPerMessage parameter 225 MaxRetriesForLocalSiteShadow parameter 232 MaxRetriesForRemoteSiteShadow parameter 232 MaxSendSize parameter 232 memory requirements 8 MessageCount parameter 247 message delivery 314 MessageExpirationTimeout parameter 190, 234 Message Header Analyzer app 146 message hygiene 211 anti-malware 259–261 attachment filtering 261–262 bypassed items 257 configuration and management of 253–263 connection filtering 254–255 content filtering 255–258, 257–258 recipient filtering 258–259 Sender ID management 259–260 solutions 205–207 spam confidence level (SCL) 256–258 Message-ID header 242, 243 MessageRateLimit 290 message routing 184–185, 239–240 message size limits 232, 234 message tracking 240–243, 245 332 message transport. See transport Messaging Application Programming Interface (MAPI) 1 Microsoft Azure 41 Microsoft Azure VMs 8 Microsoft Exchange Information Store service 63 Microsoft Exchange Replication service 48, 63 Microsoft Exchange Writer 63 Microsoft Management Console (MMC) 248 migration to public folder mailboxes 14 Mobile Device Details dialog box 144 mobile devices controlling individual 143–145 mailbox policies 134–136 troubleshooting 170–171 Mobile OWA (MOWA) 126, 126–127 mobility solutions 125–151 allow/block/quarantine policies 136–145 EAC policies 133–134 mobile device mailbox policies 134–136 Mobile OWA (MOWA) 126–127 Office Apps 146–151 OWA policies 127–132 ModerateMessageByManager parameter 228 moderation configuring 78–79 functions 228–229 mounted state of database copy 45 Move-ActiveMailboxDatabase cmdlet 45 Move-DatabasePath cmdlet 48 Move-PublicFolderBranch.ps1 script 34 MSExchangeDelivery.exe 182 msExchangeIMAP4 167 msExchangeIMAP4BE 167 msExchangePOP3 167 msExchangePOP3BE 167 MSExchangeSyncAppPool 134 MSExchange Throttling counter 287 MSExchangeTransport.exe 182 MSExchange User Throttling counter 287 MSExchange WorkloadManagement Classification counter 287 MSExchange Workload Management counter 287 MSExchange WorkloadManagement Workloads counter 287 multiple address spaces 211–213 outbound messages mutual TLS (MTLS) 204 My Custom Apps user role 147 My Marketplace Apps user role 147 N name resolution 25 namespaces AutoDiscover 111, 113, 154 certificates and 118–121 configuration of 110–115 internal 115 load balancing 153–157 requirements 99 shared 211–213, 250–251 single 114–115 troubleshooting 250–251 NAT. See network address translation (NAT) Negotiate authentication 122 network address translation (NAT) 156, 157 network interface cards (NICs) 219 network load balancing (NLB) clusters 159–162 network outages 41 networks DAG 43–44 load balancing 157–158 MAPI 43–44 replication 43–44 New-AcceptedDomain cmdlet 229 New-ActiveSyncDeviceAccessRule cmdlet 142 New-ActiveSyncVirtualDirectory cmdlet 134 New-AddressList cmdlet 22 New-App cmdlet 148 New Certificate Wizard 120–121 New-DatabaseAvailabilityGroup cmdlet 39 New Device Access Rule dialog box 141 New-EdgeSubscription cmdlet 209, 216 New-EmailAddressPolicy cmdlet 231 New-Mailbox cmdlet 13, 32, 73, 76, 80 New-MailboxDatabase cmdlet 47, 64 New-MailboxExportRequest cmdlet 67 New-MailboxRepairRequest cmdlet 67 New-MailboxRestoreRequest cmdlet 36, 66 New-MoveRequest cmdlet 33 New-OWAMailboxPolicy cmdlet 132 New-PublicFolder cmdlet 32 New-PublicFolderMigrationRequest cmdlet 35 New-PublicFolderMoveRequest cmdlet 34 New-ReceiveConnector cmdlet 224 New-RoleAssignmentPolicy cmdlet 298 New-ThrottlingPolicy cmdlet 56, 289, 291 New-TransportRule cmdlet 227, 228 NICs. See network interface cards (NICs) non-delivery reports (NDRs) 197, 234, 260 nonlocation-specific resource mailboxes 75 NTFS file system 4 NTLM authentication 122, 170 O OAB. See offline address book (OAB) OABGeneratorWorkCycleCheckpoint property 28 OABGeneratorWorkCycle property 28 OABGen service 26 OAB v4 files 26 Office Apps blocking or allowing 150 deployment and management of 146–151 installation of 146–150 providing to specific users 149 removal of 146–150 self-service management of 150 Office Web Apps server configuration of 105–108 offline address book (OAB) 26 creation and configuration of 22–28 generation of 27–28 one-arm configuration 157 OPATH filtering syntax 23 organizational units (OUs) 280 OrganizationCapabilityOABGen 27 Organization Management role 301 Organization Management role group 294, 296, 298 organization unit (OU) 74 organization-wide ABQ settings 145 Org Custom Apps role 147 Org Marketplace Apps role 147 OU scope 304 outbound messages 274–277, 314 flow of 182 predicting flow of 239 processing 211 send connectors and 199–200 shadow redundancy and 188 troubleshooting 249 333 Outbound Proxy Frontend serverName connector Outbound Proxy Frontend serverName connector 221 Outlook external clients 113–114 Outlook Anywhere 102, 104, 115, 163–166 Outlook Anywhere URL 117–118 Outlook Room Finder 75 Outlook Web App (OWA) 103, 126 connections 102, 104 Delivery Reports tab 243 email attachment in 106, 107 features 128–129 health checks 154 policy configuration 127–132 Out of Office (OOF) settings 169 OverrideContentmailbox parameter 68 OWA. See Outlook Web App (OWA) OWA for Devices 126, 126–127 OWA policies creating and managing in EAC 129–131 creating and managing in EMS 132 P Partner connectors 226 performance monitoring 271, 287–288 permission groups 200 permissions Active Directory 21, 281, 293 assigning 82 auto-mapping and 85 built-in role groups and 297–298 default user 78 delegated setup 22 DelegatingOrgWide 298–299, 299 ETS object 40 full access 76 full control 39 GrantSendOnBehalfTo 76 mail-enabled objects 82–87 public folders 32 RBAC model 293–308 Regular assignment 299 split 21, 299–302 personal exemptions 143–145 platform-as-a-service. See PaaS play forward logic 44 poison message queue 247 334 POP3 services troubleshooting 167–170 POP/IMAP requests 103, 105 port flooding 159 Post Office Protocol (POP) 99 power supply 42 PreventCompletion property 35 Primary Active Manager (PAM) 312 primary hierarchy mailbox 13, 32–33, 68–69 PrimaryUpdatePath parameter 261 processor oversubscription 10 Protocol Analysis 206 protocol logging 169 ProtocolLoggingEnabled parameter 169 protocol logs 241, 243–245 ProvidedTo parameter 149 Proxy Through Client Access Server setting 249 public DNS registrars 274 Public Folder databases 7 PublicFolderMigrationComplete parameter 14, 35 PublicFolder parameter 32 public folders 1–2 backup and recovery solutions for 60–71 creation and configuration of 13, 32–36 deletion of 36 hierarchy, recovering 68–70 migration of 34–35 moving 33 placement strategy for 13–15 restoration of 36 PublicFoldersEnabled property 35 PublicFoldersLockedForMigration property 35 PublicFoldertoMAilboxMapGenerator.ps1 34 Purges folder 66 Q quarantine mailbox 256 quarantine policies 136–145 queued messages 240 queues 246–249 delivery 246 poison message 247 submission 246 troubleshooting 248–249 unreachable 246 viewing 247–248 scheduled downtime R RAID arrays disk failures and 16 RAID levels 42 RBAC. See role-based access control (RBAC) read-only domain controllers (RODCs) 273 real-time transport protocol (RTP) 158 receive connectors 198, 200, 212 authentication mechanisms 224–225 certificates and 226 creation and configuration of 221–226 TLS configuration of 227–228 receive protocol logs 241 RechargeRate 289 Recipient Filter 206 recipient filtering 212, 258–259 recipient filter scope 304 RecipientRateLimit 291 RecipientSyncInterval cmdlet 218 recoverable items folder 66 Recover Deleted Items option 68 recovery databases 47, 65 Recovery parameter 47 Recovery Point Objective (RPO) 60–63, 313 recovery solutions dail tone restores 64–66 determining appropriate 62 item-level recovery 66–67 lagged copies 60–62 mailbox server role 60–71, 69–70 public folder hierarchy 68–70 Recovery Time Objective (RTO) 60–63, 313 Redirect-Message cmdlet 311 redundancy 42, 43, 314 database 54 MX records and 191–192, 210 need for 272 redundant array of independent disks (RAID) 3 RejectMessageOnShadowFailure parameter 188, 232 RejectResponse parameter 262 Remote Desktop Protocol 208 remote domains 197–198 RemoteIPRanges parameter 224 remote procedure call (RPC) 182 remote procedure call (RPC) over HTTP 100 Remote Tools Administration Pack (RSAT) 20 Remove-ActiveSyncVirtualDirectory cmdlet 134 Remove-App cmdlet 148 Remove-AttachmentFilterEntry cmdlet 262 Remove-ClusterNode cmdlet 70 Remove-ContentFilterPhrase cmdlet 258 Remove-DatabaseAvailabilityGroupServer cmdlet 69 Remove-MailboxDatabaseCopy cmdlet 69 repair requests 67 replay lag time 61 ReplayLagTime parameter 44, 61 replication monitoring 57–58 ReplicationEnabled parameter 43 replication networks 2, 43–44 replication service 55 RequireTLS parameter 225, 227, 250 Resilient File System (ReFS) 19 resource mailboxes 72–76, 84 resource record (RR) 278 RestrictedDiscovery policy 291 Resume-MailboxDatabaseCopy cmdlet 52 Resume-PublicFolderMigrationRequest cmdlet 35 resynchronizing state for database copy 57 retention of mailboxes 63–64 reverse proxies 123–124, 169 role-based access control (RBAC) 15, 271, 280, 293–308 custom-scoped role groups 303–308 roles and cmdlets 294–298 split permissions 299–302 role requirements calculator 8 room address lists 24, 75 room mailboxes 73, 74, 83–85 Room parameter 73 room resources 73, 74 RPC protocol 100 RTP. See real-time transport protocol (RTP) Rule Creation Wizard 201 S Safety Net 8, 47–48, 61, 189–190, 232, 246, 314 SafetyNetHoldTime parameter 190, 233 scale out configuration 7 scale up configuration 7 ScanErrorAction parameter 260 ScanTimeout parameter 260 scheduled downtime 311–313 335 scheduling scheduling resource mailboxes and 72–76 schema extensions 280 preparation of 281 Schema Admins group 281 Schema Master 20 Scoped Send Connector check box 220 Search-Mailbox cmdlet 67 Search-MessageTrackingReport cmdlet 242 SearchQuery parameter 67 secondary hierarchy mailbox 68 SecondaryUpdatePath parameter 261 secure real-time transport protocol (SRTP) 158 Secure Sockets Layer (SSL) connections 105 Secure Sockets Layer (SSL) protocol 204, 221 security alerts 112, 113 Security Group Creation role 300 security groups 280 security principals 299 seeding 44 SeedingPostponed parameter 44 seeding process 48–49 self-signed certificates 100, 121–122, 169, 204, 209 send connectors about 198–200 certificates and 226 creation and configuration 218–221, 231–232 DNS configuration on 277 message processing and 212 TLS configuration of 227 troubleshooting 249–250, 250 Sender Filter 206 Sender ID 206, 207, 259–260, 277–279 sender policy framework (SPF) records 207, 277–279 send protocol logs 241 SeniorityIndex attribute 28 Serial ATA (SATA) 2 server SMTP 168 Server Message Block (SMB) 5 servers Edge 215–217 Edge Transport 216–217 global catalog (GC) 272–273 load balancing CAS 155–156 mailbox. See Mailbox server Office Web Apps 105–108 336 Windows DNS 274 Server Virtualization Validation Program (SVVP) 8 Service Connection Point (SCP) 111, 113–114, 165 ServiceDown state for database copy 57 service level agreements (SLAs) 271, 308–315 message delivery and 314 RPO/RTO and 313 scheduled downtime and 311–313 Service Principal Names (SPNs) 157 session affinity 99 Session Initiation Protocol (SIP) load balancing 158–159 Set-AcceptedDomain -DomainType cmdlet 212 Set-ActiveSyncOrganizationSettings cmdlet 145 Set-ADSite cmdlet 195 Set-ADSiteLink cmdlet 195 Set-App cmdlet 148, 149 Set-CalendarProcessing cmdlet 84 Set-CASMailbox cmdlet 127–128, 133, 144, 145, 170 Set-ClientAccessServer cmdlet 113 Set-ContentFilterConfig cmdlet 256, 257 Set-ContentFilterConfig -Enabled 258 Set-ContentFilterConfig -ExternalMailEnabled 258 Set-ContentFilterConfig -InternalMailEnabled 258 Set-DatabaseAvailabilityGroupNetwork cmdlet 43 Set-EdgeSyncServiceConfig cmdlet 210, 218 Set-FrontEndTransport cmdlet 276 Set-FrontEndTransportService cmdlet 183 Set-ImapSettings cmdlet 168, 169 Set-IPAllowListConfig cmdlet 255 Set-IPAllowListProvidersConfig cmdlet 255 Set-IPBlockListConfig cmdlet 255 Set-IPBlockListProvidersConfig cmdlet 255 Set-Mailbox cmdlet 24, 27, 33, 56, 64, 66, 80 Set-MailboxDatabase cmdlet 63 Set-MailboxServer cmdlet 28, 55 Set-MailboxTransportService cmdlet 183 Set-MailPublicFolder cmdlet 33 Set-MalwareFilteringServer cmdlet 259–261 Set-OrganizationConfig -AppsForOfficeEnabled parameter 150 Set-OrganizationConfig cmdlet 28, 78, 105 Set-OutlookAnywhere cmdlet 166 Set-OWAMailboxPolicy cmdlet 132 Set-OWAVirtualDirectory 129 Set-PopSettings cmdlet 168, 169 Set-PublicFolder cmdlet 68 transaction logs Set-RecipientFilterConfig cmdlet 259 Set-SendConnector cmdlet 245 Set-SendConnector -FrontEndProxyEnabled cmdlet 221 Set-SenderIdConfig cmdlet 259 Set-ThrottlingPolicyAssociation cmdlet 56, 291 Set-TransportConfig cmdlet 182, 188, 205, 225, 231–233 Set-TransportConfig -InternalSMTPServers cmdlet 207 Set-TransportConfig -SafetyNetHoldTime parameter 190 Set-TransportConfig -ShadowRedundancyEnabled cmdlet 188 Set-TransportConfig -TLSSendDomainSecureList 205 Set-TransportRule cmdlet 227 Set-TransportService cmdlet 182, 194, 233–234, 245, 276 setup utility 280 Set-WebServicesVirtualDirectory cmdlet 169 ShadowMessageAutoDiscardInterval parameter 189, 233 ShadowMessagePreferenceSetting parameter 189, 233 shadow redundancy 186–188, 232, 246 ShadowRedundancyEnabled parameter 233 ShadowResubmitTimeSpan parameter 189, 233 shared equipment 76 shared namespaces designing 211–213 troubleshooting 250–251 Shared parameter 76 signature updates 260 SingleItemRecoveryEnabled parameter 66 Single Mail Transfer Protocol (SMTP) 99, 182, 183, 244 single sign-on (SSO) 102 site link costs 195 site resiliency requirements 6 smart card authentication 123 smart host delivery 219 S/MIME encryption 202 SMTP. See Single Mail Transfer Protocol (SMTP) SMTP domain 114 SMTP message flow queues and 246–249 troubleshooting 246–251 SMTP server configuration 168 snapshot functionality 9 soft fail messages 207 Solid State Disk (SSD) drives 3 SortOrder parameter 247 spam confidence level (SCL) 256–258 Spamhaus 254 SPF. See send policy framework (SPF) records split-brain DNS 118, 275–276 split permissions 21, 281, 299–302 SSL certificates 154, 205 stand-alone database configurations 4 StartDagServerMaintenance.ps1 script 312 Start-EdgeSynchronization cmdlet 217 STARTTLS 204 StopDagServerMaintenance.ps1 script 312 storage requirements planning for 3–5 store-and-forward behavior 183 strict mode tests 16 Subject Alternate Name (SAN) 119 Subject Name 119 submission queue 246 suspended state for database copy 57 switchover process for databases 45 system event log 286 system workload management 56 T TargetServer parameter 218 TCP port 25 208, 222 TCP port 443 208 TCP port 587 221 TCP port 3389 208 TCP port 5060 158, 162, 163 TCP port 5061 158 TCP port 50636 208 team mailboxes configuration of 76–77 Test-OutlookConnectivity cmdlet 166 Test-ReplicationHealth cmdlet 45, 54–55, 57 text (TXT) resource record 278 throttling 56–57 ThrottlingPolicyScope parameter 291 throttling settings 288–291 TlsReceiveDomainSecureList parameter 225, 232, 233, 250 TlsSendDomainSecureList parameter 225, 232, 233, 250 Top of the Rack (ToR) router failure of 42 transaction logs backups 4 replication of 52–53 337 TransientFailureRetryInterval parameter TransientFailureRetryInterval parameter 194 transport 181–270 accepted domains 229–231 configuration of 215–239 connectors 198–200, 218–228, 277 data loss prevention rules 203–204 designing transport solution 193–215 Domain Secure 204–206 Edge 207–210 email policies 231–234 filtering agents 206–207, 211, 253–262 inbound messages 182, 185, 187–188, 200, 210–211, 239, 249, 274 inter-org mail flow 195–204 inter-site mail flow 193–195 management 215–239 message hygiene 205–207 message routing 184–185, 239–240 message tracking 240–243, 245 MX records and 191–192 outbound messages 182, 188, 199–200, 211, 239, 249, 274, 314 pipeline 181–183 planning high availability 183–192 predicting mail flow 239–240 protocol logs 241, 243–245 rules 200–202, 203 Safety Net and 189–190 shadow redundancy and 186–188 shared namespaces 211–213 troubleshooting 239–254 transport agents 206–208 Transport Layer Security (TLS) 204–206, 221, 225–227, 250 TransportRole attribute 222 Transport Rule agent 253 TransportRuleAttachmentTextScanLimit parameter 233 transport rules 314 configuration 227–228 moderation configuration for 228–229 priorities for 227 Transport service 182, 186, 203 policies for 233–234 transport storage 7 troubleshooting client connectivity 163–171 338 database copy activation 53–55 database replication and replay 52–53 Domain Secure 250–251 mailbox role 51–60 mailbox role performance 55–57 mobile devices 170–171 Outlook Anywhere connectivity 163–166 POP/IMAP services 167–170 queues 248–249 shared namespaces 250–251 SMTP message flow 246–251 TLS 250–251 transport 239–254 web services 169 truncation lag 61 TruncationLagTime parameter 44, 61 U unbound model 114–115 Unified Contact Store 63 Unified Messaging (UM) 312 Unified Messaging (UM) Call Router service 158 Unified Messaging (UM) certificates 119 Unified Messaging (UM) integration 119 universal distribution groups 77–78 Universal Security Group (USG) 296 UNIX-based DNS server 274 unreachable queue 246 unscoped top-level roles 295 UpdateFrequency parameter 260 Update-MailboxDatabaseCopy cmdlet 53 Update-MalwareFilteringServer.ps1 script 261 Update-OfflineAddressBook cmdlet. 28 Update-RoleGroupMember cmdlet 296 UpdateTimeout parameter 261 URLs AutoDiscover and 111 configuration of 115–118 Outlook Anywhere 117–118 prioritizing 112 SCP 111, 113 UserList parameter 149 User Options Role 296 user profiles 5–6, 100 user-throttling functionality 56 XSHADOW ESMTP (extended SMTP) V validation Jetstress for 15–17 VerifySecureSubmitEnabled parameter 233 VHD disk 5 View-Only Recipients Role 296 virtual disks 12 virtualization planning for 8–13 virtual machines (VMs) impact of dynamic memory on 10 I/O requirements 16 Live Migration of 9–10 storage for 11–12 Volume Shadow Copy Service (VSS)-based applications 63 W WACDiscoveryEndPoint parameter 105 WacViewing* parameters 108 Web Application Open Platform Interface (WOPI) protocol 105 web-based distribution 26 web services troubleshooting 169 wildcard certificates 119 Windows DNS server 274 Windows Failover Clustering 158 WindowsIntegratedAuthentication 170 Windows network load balancing (WNLB) 158–162 Windows Server 8 Windows Server 2003 19 Windows Server Core installations 19–20 witness servers 40–41, 43 workload events 286–288 workload management 56, 285–293 about 285–286 throttling settings 288–291 workload event monitoring 286–288 workload policies 286 X XSHADOW ESMTP (extended SMTP) 244 339
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project
advertisement
© 2021